원래의:What comes after Ethereums Cancun hard fork?》
저자: 게오르기오스 콘스탄토풀로스
편집자: Odaily Moni
1. 콘텐츠 개요
이 기사에서는 프라하(프라하) 하드 포크(칸쿤 업그레이드 후 다음 실행 계층 하드 포크)에 포함된 중요한 EIP(이더리움 네트워크 개선 프로토콜)에 대한 Paradigm Reth 팀의 이해와 2024년 “EL Core Dev”에 대한 이해를 분석합니다. 계획의 모습.
프라하 하드포크는 2024년 3분기에 이더리움 테스트넷에서 진행될 수 있으며 연말 이전에 메인넷에 구현될 수 있습니다.업그레이드 내용에는 다음이 포함됩니다.：
1. 외부 신뢰가 필요하지 않은 리스테이킹 및 스테이킹 풀을 활성화하기 위해 EIP-7002 등 스테이킹 관련 EIP를 포함하는 것이 좋습니다.
2. 독립적인 EVM 변경;
또한 Paradigm은 프라하와 같은 EL 하드 포크의 어려운 문제를 추가로 조사하려는 모든 팀과 협력할 의향이 있으며 Reth 코드 베이스 수정을 포함한 지침을 기꺼이 제공할 것입니다.
Paradigm이 인정한 방향:
1. Paradigm은 7002, 6110, 2537 EIP에 우선순위가 부여되어야 한다고 믿습니다.
2. Paradigm은 사양에 설명된 EOF(Ethereum Object Format)를 지원하지만, 가능한 한 빨리 범위를 결정하고 이 범위 전용의 메타-EIP를 생성하기를 희망합니다.
3. Paradigm은 EIP-4844 Max Blob Gas를 추가할 의향이 있으며 정확한 숫자에 대해 너무 많이 언급하지는 않지만 데이터 과학자가 EIP 조사에 협력하도록 초대할 것입니다.
4. Paradigm은 기본 계층 검열에 저항하는 데 도움이 될 수 있는 EIP-7547: 포함 목록 버전을 출시할 준비가 되어 있습니다.
Paradigm이 동의하지 않는 방향:
1. Paradigm은 프라하 하드포크에 사용된 Verkle Tries 데이터 구조를 지원하지 않지만 클라이언트 팀이 2024년 2분기에 작업을 시작할 수 있도록 지원하고 2025년 중후반에 오사카에서 업그레이드하여 출시할 것을 약속합니다.
2. Paradigm은 L1 실행 가스 한도나 계약 규모를 늘려서는 안 된다고 생각하지만, 이 접근 방식이 Ethereum 네트워크에 미치는 영향을 조사하는 데 데이터 담당자가 협력하도록 초대할 것입니다. 동시에 Paradigm은 과거 테스트에서 Reth 노드가 문제 없이 증가된 부하를 처리할 수 있다는 것을 보여주었기 때문에 자신의 견해를 완화할 의향이 있습니다.
3. Paradigm은 사이버 공간의 장단점을 더 잘 이해하기 위해 지갑/계정 추상화 EIP를 서로 테스트해야 한다고 믿습니다. 지갑/계정 추상화가 상호 배타적이지 않다면 향후 계정 추상화와 관련된 여러 EIP를 배포하려는 의지가 있을 것입니다.
4. 커뮤니티가 소문난 NSA 백도어에 동의한다면 Paradigm은 EIP-7212(secp 256 r 1)의 경계선을 넘을 수 있다고 믿습니다.
5. 기타 로드맵 주제: Paradigm은 합의 계층 EIP 또는 CL/EL(합의 계층/실행 계층) 포크 결합에 대해 실제로 이해하지 못하지만 EIP 7549와 EIP 7251의 두 가지 제안은 유망해 보입니다. Paradigm은 또한 EL 측에서 가능한 한 PeerDAS 노력에 기여하기를 원하며 현재 SSZ 루트(EIP 6404, 6465, 6466)의 도입을 피하려고 합니다. 마지막으로 Paradigm은 EIP-4844나 EIP-4444 모두 이를 명시하지 않았기 때문에 만료된 blob, 기록 및 상태에 대한 장기 데이터 보관 솔루션이 있어야 한다고 믿습니다. 그러나 Ethereum이 그러한 솔루션을 제공할 의향이 있는지 여부는 아직 결정되지 않았습니다. .
자세한 내용은 다음과 같습니다.
식별의 패러다임 방향
추상적으로 말하면 Paradigm은 주로 다음 두 가지 측면을 지원합니다.
1) 합의 계층과 실행 계층 사이의 간격을 더욱 좁힙니다.
2) EVM 수정은 한 사람이 수행할 수 있으며 독립적으로 또는 병렬로 테스트할 수 있습니다.
EIP-7002
이 EIP는 실행 계층 측에서 스마트 계약을 활성화하여 합의 계층 측에서 단일 또는 다중 검증자를 제어함으로써 무신뢰 재스테이킹 및 스테이킹 풀을 잠금 해제합니다. Paradigm의 관점에서 볼 때 이 EIP는 어느 정도 의미가 있으며 적어도 기존 스테이킹 풀이 인출을 가능하게 하는 스마트 계약에서 중앙 집중화 계층을 제거할 수 있게 해줍니다.
게다가 EVM에 Stateful Precompilation을 도입하는 것도 Paradigm이 EVM 구현에서 충족해야 한다고 동의하는 기능이지만, 그 이상으로 Paradigm은 이것이 바로 구현 가능한 EIP라고 믿습니다.
EIP-6110
이 EIP는 실행 레이어 상태에 입금 기능을 도입하여 합의 레이어에서 수행해야 하는 상태 관리를 단순화합니다. 구현 측면에서 이는 합의 계층 철회를 추적하는 것과 유사하므로 전반적인 Paradigm은 이것이 구현하기 쉽고 독립적인 EIP라고 생각합니다.
EIP-2537
현재 BLS 12-381에는 여러 구현이 있으며 많은 SNARK, BLS 서명 알고리즘 및 EIP-4844에서 일반적으로 사용되는 곡선입니다. Paradigm은 BLS 12-381 구현 복잡성이 사전 컴파일된 인터페이스를 통해서만 곡선의 검증 알고리즘을 노출하므로 BLS 12-381 곡선의 사전 컴파일된 해시도 필요할 수 있다고 생각합니다.
이더리움 개체 형식(EOF)
간단히 말해서 EOF는 Solidity와 Vyper를 모두 지원합니다. 릴리스 범위가 더 넓어짐에 따라 분석을 더 쉽게 하기 위한 코드 형식 지정 및 확인 조정도 정당화됩니다. Paradigm은 이 이상의 모든 사항에 대해 신중하게 고려할 것을 권장하고 아래에서 권장합니다. 일부 EIP는 또한 기꺼이 다음을 수행합니다. 추가 조정을 해보세요.
좋은 점:
● 이더리움/테스트넷을 사용하여 테스트하고 한 사람이 구현할 수 있는 EVM 전용 변경 사항입니다.
● Vyper 및 Solidity가 원하는 EVM 변경 사항.
● 성과를 개선하고 계약 규모 제한을 늘리는 데 도움이 됩니다.
● EVM이 런타임 시 바이트코드 분석을 수행할 필요성을 제거합니다. 이는 캐싱 없이 최대 50%의 시간이 소요될 수 있으며 계약 규모가 증가함에 따라 시간도 증가합니다.
● 부분 코드 로딩을 활성화하면 Zhejiang은 대규모 스마트 계약 실행을 돕습니다.
● Devex: dupN/swapN 및 기타 도구 개선으로 너무 깊은 스택 문제를 수정할 수 있습니다.
● 미래에 적용 가능한 기능: 새로운 보안 교차 L2 기능이 도입될 수 있으며 도구는 어떤 기능이 호환되는지 파악합니다.
단점:
● 범위 및 이동 대상.
● 이를 포함시키려는 대규모 추진에 대한 지지는 없습니다.
● 레거시 코드에는 여전히 지원이 필요합니다.
● 채택 이전에는 이더리움 메인넷과 다른 EVM 체인 간에 일시적인 차이가 있었습니다.
Paradigm은 다음 EOF 기능이 2024년까지 배포되어야 한다고 믿으며 가능한 한 빨리 범위를 지정하고 구현에 전념할 것을 권장합니다. 후속 배포에서는 추가 문제를 고려해야 합니다. 따라서 Paradigm에서는 다음을 권장합니다.
● EIP-3540(EOF - EVM 개체 형식 v1): 코드와 데이터 컨테이너를 도입하고 이더리움 바이트코드에 구조와 버전 관리를 추가합니다.
● EIP-3670 (EOF - 코드 검증): 배포 시 EOF 형식을 따르지 않는 계약을 거부하고 보다 구조화된 코드만 실행할 수 있으며 유효하지 않거나 정의되지 않은 명령은 비활성화됩니다.
● EIP-663(무제한 SWAP 및 DUP 지침): 이 EIP는 JUMPDEST 분석을 즉각적인 값으로 사용하면 부작용이 있을 수 있지만 언어가 되는 EVM에서 많이 원하는 기능인 Solidity의 너무 깊은 스택 문제를 해결합니다.
● EIP-4200 (EOF - 정적 상대 점프): 더 나은 정적 분석, 정의되지 않은 점프 없음. 더 나은 aot 컴파일 및 상대 점프는 코드 재사용성에 더 도움이 됩니다.
● EIP-4750 (EOF – 기능): 동적 점프는 사용할 수 있지만 정적 점프는 사용할 수 없는 서브루틴 문제를 해결해야 하며, Verkle 데이터 구조와 잘 작동하고 계약 크기 제한을 늘릴 수 있는 부분 코드 로딩도 허용해야 합니다.
● EIP-5450 (EOF - 스택 검증): 코드 및 스택 요구 사항을 확인합니다. CALLF(EIP-4750)를 제외한 모든 명령어에 대한 런타임 스택 언더플로 및 오버플로 검사를 제거합니다.
● EIP-7480 (EOF - 데이터 부분 접근 명령어): 바이트코드의 데이터 부분에 대한 액세스를 허용합니다.
● EIP-7069 (CALL 명령어 개선)CALL에서 가스 관측성을 제거할 수 있으면 향후 가스 가격을 다시 책정하는 것이 더 쉬워질 것입니다. 이번 EIP는 EOF와는 별개이지만 Paradigm은 이번 하드포크가 이번 EIP를 도입할 수 있는 좋은 기회라고 믿고 있습니다.
패러다임이 맞다EIP-6206 (EOF-JUMPF 및 비반환 함수)확실하지는 않습니다. 이 EIP가 EOF 함수에서 테일 콜 최적화를 허용하더라도 Paradigm은 여전히 유용성을 위해 언어 분석을 확인해야 합니다. 그렇지 않은 경우 Paradigm은 이를 범위에서 제거하고 후속 EOF 업데이트에 포함하는 것이 적절하다고 간주합니다.
Paradigm에서는 위 작업 부하를 정규직 기준으로 약 1~2인-월로 추정하며, 평가 작업 부하가 더 클 경우 위 범위를 더욱 좁힐 의향이 있습니다.
레거시 바이트코드에 대한 참고사항:
● 새로운 레거시/비EOF 바이트코드는 억제될 수 있지만 기존 레거시 바이트코드는 효과적으로 EOF v 0으로 작동하므로 더 이상 사용되지 않습니다. 레거시 바이트코드에는 여전히 post-EOF JUMPDEST 분석이 필요하며, Verkle Tries에서 이를 청크로 분할하려면 특수 코드 처리가 여전히 필요합니다.
● Paradigm이 아는 한, 소스 코드에 액세스하지 않고는 EOF가 아닌 바이트코드에서 EOF로의 변환을 검증하는 것이 불가능합니다. 그러나 Paradigm은 이러한 변환을 용이하게 하기 위한 메커니즘을 조사할 의향이 있습니다.
● 대안으로 Paradigm은 상태를 EOF로 마이그레이션하는 만료 방법을 기꺼이 탐색할 것입니다.
EIP-4844 blob 수 늘리기
Paradigm은 이 변경 사항에 열려 있으며 이에 따라 MAX_BLOB_GAS_PER_BLOCK 및 TARGET_BLOB_GAS_PER_BLOCK을 추가합니다.
블록당 3개의 Blob(0.375MB) 목표(최대 6개의 Blob, 약 0.75MB)에 해당하는 TARGET_BLOB_GAS_PER_BLOCK 및 MAX_BLOB_GAS_PER_BLOCK의 값을 선택합니다. 이러한 초기 제한은 크지 않지만 이 EIP가 네트워크에 가하는 스트레스를 최소화하고 네트워크가 더 큰 블록으로 안정성을 입증함에 따라 후속 업그레이드에서 증가될 수 있습니다.
실제로 관련된 코드 변경은 그리 크지 않지만 Paradigm은 EIP-4844 스트레스 테스트 인프라를 재사용할 수 있도록 txpool에서 이러한 상위 항목의 실제 영향을 조사해야 합니다. 합의 계층은 더 많은 블롭을 전파하는 데 어려움을 겪을 수 있으므로 Paradigm은 합의 계층 팀의 의견도 존중합니다.
패러다임이 방향과 일치하지 않음
Verkle Tries
간단히 말해서, Paradigm은 팀이 2024년 2분기에 여기에 리소스를 할당하고 2025년 2~3분기 배포에 오사카 하드 포크를 약속했기 때문에 2024년 말/2025년 초까지 Verkle 배포가 완료될 가능성은 거의 없어 보입니다.
좋은 점:
● 더 작은 스토리지 증명을 통해 저렴한 라이트 클라이언트.
● 블록 헤더에 사전 상태 읽기를 포함하여 무상태 실행을 수행합니다. 이는 정적 상태 액세스로 인해 성능이 향상될 수도 있습니다.
● 바이트코드를 청크하고 부분 코드 로드를 활성화하여 계약 크기 제한을 늘립니다.
● 상태를 복원하는 데 드는 비용이 낮아지므로 상태 만료가 더 수용 가능해집니다.
단점:
● 변경의 영향 및 통합 노력이 구현되고 테스트되었습니다.
● 가스 회계 변경: Verkle Tries는 가스 회계 기능에 증인 크기 조정을 도입했으며 Paradigm은 스토리지 가격 변경이 아직 조사되지 않은 점을 우려하고 있습니다(예: Verkle 이후 헤드 가스 소비자의 비용은 얼마입니까).
● 애플리케이션 통합: 오버레이 변환이 실행 중일 때 Merkle Patricia Trie 유효성 검사기가 포함된 애플리케이션은 무엇을 해야 합니까? eth_getProof는 어떻게 동작해야 합니까?
Verkle Tries에는 특정 장점이 있지만 Paradigm은 타사 도구/계약이 어떻게 적응해야 하는지, 전환이 2차 솔루션 등에 어떤 영향을 미칠지에 대해 더 많은 고려가 필요하다고 믿습니다. 처음에 Paradigm은 기존 MPT에서 상태를 읽을 때 Verkle Tries를 업데이트해야 한다고 규정했기 때문에 마이그레이션 정책을 경계했지만 더 이상 그렇지 않은 것으로 보입니다. 따라서 Paradigm은 실행 가능한 마이그레이션 경로로 오버레이 방법을 지원합니다.
대부분의 리소스에서는 MPT에서 상태를 읽을 때 Verkle 트리를 업데이트해야 한다고 명시하고 있기 때문에 Verkle 마이그레이션 전략에 대한 문서는 종종 오래된 것 같습니다. Paradigm은 최신 방법으로 업데이트된 주요 전환 문서를 보고 싶습니다.이 문서. Paradigm은 또한 전환 전략에 대한 생태학적 투자 계획 초안을 보고 싶어합니다.
따라서 Paradigm은 여전히 2025년 출시를 지원하며 이번 하드포크에는 배포되지 않습니다.
L1 가스 한도
Paradigm은 수요 측면에서 일부 오해가 있을 수 있다고 생각하며 실제로 L1 가스 한도를 높이는 것이 실제로는 큰 영향을 미치지 않을 것입니다. Paradigm은 또한 대부분의 클라이언트가 평균 부하 증가를 처리할 수 있다고 생각하지만 Paradigm은 최악의 시나리오를 경계하기를 원하므로 현재 L1 Gas 한도를 늘리는 것을 권장하지 않습니다. Paradigm은 Blob 가스 제한을 늘리는 것이 단기적으로는 더 유망한 솔루션이라고 믿습니다.
Paradigm은 커뮤니티가 EVM의 리소스 측정 중단과 관련된 관련 방향의 연구에 협력하도록 초대하고 싶습니다. 게시자: Broken Meter종이이 연구 분야의 좋은 출발점이 되어야 합니다.
계정 추상화
Paradigm은 하드 포크에 하나 이상의 EIP(또는 ERC 포함)를 포함할 의향이 있지만 이상적으로는 각 제안 간의 더 많은 사용자 경험과 개발자 경험 비교를 확인하고 싶습니다. 그러면 도구의 절충 공간과 노력을 더 잘 이해할 수 있습니다. 완성. Paradigm은 다음 EIP/ERC에 중점을 두고 있으며, 커뮤니티는 언제든지 Paradigm에 제안을 할 수 있습니다.
● EIP-3074: AUTH 및 AUTHCALL 연산 코드
● ERC-4337: Alt Mempool을 사용한 계정 추상화
● RIP-7560: 기본 계정 추상화 - 핵심 EIP - 이더리움 마술사 모임
마지막으로 계정 추상화는 위에서 언급한 EIP-4337 및 EIP-7560에만 적용되는 반면 다른 제안은 주로 가스 후원 및 배치 운영이라는 두 가지 영역을 다룬다는 점을 기억하세요. (계정 추상화는 검증 기능을 추상화하는 것과 같습니다. 주요 목표는 키 순환을 활성화하고 다중 서명을 핵심 요소로 만들고 양자 저항에 대한 자동화된 경로를 제공하는 것입니다.)
