Paradigm CTO: 이더리움 칸쿤 업그레이드 이후, 다음 프라하 업그레이드에서는 어떤 조치가 있을까요?

원문 제목：What comes after Ethereum's Cancun hard fork?

원문 저자：Georgios Konstantopoulos，Paradigm Research Partner \& CTO

원문 번역：defioasis，吴说区块链

요약

이 글의 목적은 Paradigm Reth 팀이 프라하(Prague)에서 포함되어야 할 EIP(이더리움 개선 제안)에 대한 의견을 개요하고, 프라하는 칸쿤 이후의 다음 EL(이더리움 실행 계층) 하드 포크이며, 2024년의 "EL 핵심 개발자" 계획 개요를 제시하는 것입니다. 아래의 의견은 계속 발전 중이며, Reth 팀의 현재 견해를 나타내며, 더 넓은 Paradigm 팀의 견해를 반드시 대표하지는 않습니다.

우리는 2024년 3분기에 프라하 하드 포크가 이더리움 테스트넷에서 실행 가능하며, 연말 이전에 메인넷에 구현될 수 있다고 생각합니다. 이는 다음을 포함해야 합니다:

(1) 스테이킹 관련 EIPs, 예를 들어 EIP-7002는 재스테이킹(re-staking)과 신뢰 없는 스테이킹 풀을 가능하게 합니다.

(2) 독립적인 EVM 변경.

(3) 우리는 프라하 또는 다른 미래 EL 하드 포크의 어려운 문제를 더 탐구하고자 하는 팀과 협력할 의향이 있으며, Reth 코드베이스 수정에 대한 제안을 기꺼이 수용하겠습니다.

권장 사항:

(1) 우리는 다음 EIP를 우선 고려해야 한다고 생각합니다: 7002, 6110, 2537.

(2) 우리는 EOF가 규정에서 설명된 대로 지원되기를 바라지만, 가능한 한 빨리 범위를 확정하고 이 범위를 약속하는 메타 EIP를 생성하기를 원합니다. (주: EOF는 EVM 객체 형식을 의미하며, 이더리움의 코드 실행 환경에 몇 가지 변경을 가했습니다. 개발자들은 다음 실행 계층 업그레이드인 프라하에 EOF를 포함할 것을 제안했지만, 현재 의견이 분분하며, 일부는 그 규격이 최종 확정되지 않았다고 생각하고, 일부는 Verkle Tries가 다음 업그레이드의 초점이라고 생각합니다.)

(3) 우리는 EIP-4844의 최대 Blob Gas 증가에 대해 개방적인 태도를 가지고 있습니다. 우리는 정확한 숫자에 대한 구체적인 의견은 없지만, 데이터 분야의 전문가들과 협력하여 이 주제를 조사할 것을 초대합니다. (주: Blob은 L2가 L1에 거래 데이터를 제출하는 데 사용되는 저장 구조이며, 자체 가격 시스템 Blob Gas를 가지고 있습니다.)

(4) 우리는 기본 검토 저항을 높이는 데 도움이 되는 EIP-7547: 포함 목록(Inclusion lists)의 도입에 대해 개방적인 태도를 가지고 있습니다.

비추천 사항:

(1) 우리는 프라하에서 Verkle Tries의 도입을 지지하지 않지만, 클라이언트 팀이 2024년 2분기부터 이 방향으로 노력하는 것을 지지하며, 2025년 중/후반 오사카에서 이를 구현할 것을 약속합니다. (주: 미래의 이더리움이 전환할 데이터 구조로, 현재의 Merkle Trie 구조에 비해 Verkle는 증명 크기와 검증 효율성 등에서 장점을 가지고 있으며, 미래 이더리움의 무상태 구현에 필수적인 요소입니다.)

(2) 우리는 L1 실행 Gas 제한이나 계약 크기를 늘려서는 안 된다고 생각하지만, 데이터 전문가들과 협력하여 이것이 네트워크에 미치는 영향을 연구할 것을 초대합니다. 우리는 과거 테스트에서 Reth 노드가 문제 없이 증가된 부하를 처리할 수 있음을 보여주었기 때문에 이에 대해 개방적인 태도를 가지고 있습니다.

(3) 우리는 지갑/계정 추상화 EIP가 서로 간의 실전 테스트가 더 필요하다고 생각하여, 이들 간의 균형 공간을 더 잘 이해할 수 있도록 하고자 합니다. 만약 이들이 서로 배타적이지 않다면, 우리는 미래에 AA(계정 추상화)와 관련된 여러 EIP를 배포할 의향이 있습니다.

(4) EIP-7212(secp256r1)에 대해, 만약 커뮤니티가 소문에 있는 NSA(미국 국가안보국) 백도어에 대해 이의가 없다면, 우리는 이를 지지할 수 있습니다.

(5) 기타 로드맵 주제: 우리는 CL(합의 계층) EIP 또는 CL/EL(실행 계층) 포크의 결합에 대해 직접적인 견해는 없지만, EIP-7549와 EIP-7251은 매우 유망해 보입니다. 우리는 가능하다면 EL 측면에서 PeerDAS 작업에 기여할 의향이 있습니다. 우리는 현재 SSZ 루트(EIP-6404, 6465, 6466)의 도입을 피하고자 합니다. 마지막으로, 만료된 blobs, 역사 및 상태에 대한 장기 데이터 아카이브 솔루션의 기회가 있다는 점에 주목하며, EIP-4844와 EIP-4444는 이를 명시하지 않았고, 이더리움이 이러한 솔루션을 제공할지 여부는 아직 결정되지 않았습니다.

구체적인 이유는 다음과 같습니다

권장 사항

우리는 1) 합의 계층(CL)과 실행 계층(EL) 간의 격차를 더욱 좁히고; 2) EVM의 수정이 단독 작업으로 수행될 수 있으며, 격리되고 병렬로 테스트될 수 있도록 해야 한다고 생각합니다.

EIP-7002

이 EIP는 실행 계층(EL)의 스마트 계약이 합의 계층(CL)의 하나 이상의 검증자를 제어할 수 있도록 하여 신뢰 없는 재스테이킹과 스테이킹 풀을 해제합니다. 우리의 관점에서 이것은 최소한 기존의 스테이킹 풀이 인출을 수행하는 스마트 계약에서 중앙 집중화된 계층을 제거할 수 있기 때문에 당연한 EIP입니다.

우리는 EVM 구현에서 상태 프리컴파일을 도입하는 새로운 추상화를 포착해야 하지만, 그 외에는 이것이 직접 실행할 수 있는 EIP라고 생각합니다.

EIP-6110

이 EIP는 실행 계층(EL) 상태에서 예금을 도입하여 합의 계층(CL)에서 수행해야 하는 상태 관리를 간소화합니다. 구현 관점에서 이는 합의 계층의 인출을 추적하는 것과 유사하므로, 전반적으로 이것도 쉽게 구현할 수 있는 독립적인 EIP라고 생각합니다.

EIP-2537

현재 시장에는 여러 가지 BLS12-381 구현이 있으며, 이는 많은 SNARKs(제로 지식 증명 기술), BLS 서명 알고리즘 및 EIP-4844에서 자주 사용되는 곡선입니다. 우리는 구현 복잡도가 낮다고 생각하며, 이는 단지 프리컴파일 인터페이스에서 곡선의 검증 알고리즘을 공개하는 것입니다. 우리는 BLS12-381 곡선 프리컴파일의 해시 알고리즘이 필요할 수도 있습니다.

EOF

간략한 요약: Solidity와 Vyper가 채택할 명확한 범위 버전을 지원합니다. 코드 형식과 검증 조정은 분석을 더 쉽게 만들며, 이는 의심할 여지 없는 선택입니다. 우리는 이 외의 모든 내용에 대해 신중하게 고려할 것을 권장합니다. 아래에 몇 가지 EIP를 추천하지만, 우리는 추가적으로 간소화할 의향이 있습니다.

장점:

(1) EVM에 국한된 변경으로, ethereum/tests를 통해 테스트할 수 있으며, 한 사람이 구현할 수 있습니다.

(2) Vyper와 Solidity가 원하는 EVM 변경.

(3) 성능 향상 및 계약 크기 제한 증가에 기여합니다.

(4) EVM이 실행 시간에 바이트코드 분석을 수행할 필요가 없으며, 캐시와 관련이 없는 경우 이 분석은 최대 50%의 시간을 소모할 수 있으며, 계약 크기가 증가함에 따라 증가합니다.

(5) 부분 코드 로딩을 지원하여 대형 스마트 계약 실행에 도움이 됩니다.

(6) 개발자 경험: Solidity에서 dupN/swapN을 사용하여 "스택이 너무 깊다" 문제를 수정하고, 다른 도구를 개선할 수 있습니다.

(7) 미래 검증: L2에서 새로운 기능을 안전하게 도입할 수 있으며, 도구는 어떤 것이 호환되는지 알고 있습니다.

단점:

(1) 범위와 이동 목표.

(2) 이를 포함시키기 위해 강력히 추진하는 지지자가 없음.

(3) 여전히 레거시 코드를 지원해야 함.

(4) 채택되기 전에 이더리움 메인넷과 다른 EVM 체인 간에 일시적인 불일치가 존재함.

우리는 다음 EOF 기능이 2024년에 배포되어야 한다고 생각합니다. 우리는 가능한 한 빨리 범위를 확정하고 이를 고수할 것을 권장합니다. 다른 내용은 후속 배포에 고려되어야 합니다. 우리의 제안:

(1) EIP-3540: EOF - EVM 객체 형식 v1: 코드 및 데이터 컨테이너를 도입하고 이더리움 바이트코드에 구조 및 버전 관리를 추가합니다.

(https://eips.ethereum.org/EIPS/eip-3540)

(2) EIP-3670: EOF - 코드 검증: EOF 형식을 따르지 않는 계약의 배포를 거부합니다. 보다 구조화된 코드를 강제하고, 무효 및 정의되지 않은 명령어를 비활성화합니다.

(https://eips.ethereum.org/EIPS/eip-3670)

(3) EIP-663: 무제한 SWAP 및 DUP 명령어: 이는 Solidity의 "스택이 너무 깊다" 문제를 해결합니다. JUMPDEST 분석이 즉시 값으로서 부작용을 초래할 수 있기 때문입니다. 이는 EVM 언어에 매우 유익합니다.

(https://eips.ethereum.org/EIPS/eip-663)

(4) EIP-4200: EOF - 정적 상대 점프: 더 나은 정적 분석, 불확실한 점프 없음. 더 나은 AOT 컴파일. 상대 점프는 코드 재사용에 유리합니다.

(https://eips.ethereum.org/EIPS/eip-4200)

(5) EIP-4750: EOF - 함수: 동적 점프는 가능하지만 정적 점프는 사용할 수 없는 서브루틴 문제를 해결해야 합니다. 이는 또한 부분 코드 로딩을 허용하며, Verkle 및 계약 크기 제한 증가 기능과 잘 어울립니다.

(https://eips.ethereum.org/EIPS/eip-4750)

(6) EIP-5450: EOF - 스택 검증: 코드 및 스택 요구 사항을 검증합니다. CALLF(EIP-4750) 명령어를 제외하고, 모든 명령어의 런타임 스택 언더플로우 및 오버플로우 검사를 제거합니다.

(https://eips.ethereum.org/EIPS/eip-5450)

(7) EIP-7480: EOF - 데이터 세그먼트 접근 명령어: 바이트코드의 데이터 세그먼트에 접근할 수 있도록 합니다.

(https://eips.ethereum.org/EIPS/eip-7480)

(8) EIP-7069: 개선된 CALL 명령어: CALL에서 Gas 관측 가능성을 제거하여 미래에 Gas 재가격 책정을 더 쉽게 할 수 있도록 합니다. 이는 EOF와는 관련이 없지만, 우리는 이를 도입할 좋은 기회라고 생각합니다.

(https://eips.ethereum.org/EIPS/eip-7069)

EIP-6206에 대한 우리의 견해는 덜 확실합니다: EOF - JUMPF 및 비반환 함수. 이는 EOF 함수에서 꼬리 호출 최적화를 허용하지만, 우리는 여전히 언어가 그 유효성을 분석하는 것을 보고 싶습니다. 이러한 분석이 없다면, 우리는 이를 범위에서 제외하고 후속 EOF 업데이트에 포함시키는 것이 가능하다고 생각합니다.

우리는 위의 작업이 한 사람이 전일제로 진행되며, 1-2개월의 시간이 필요할 것으로 예상합니다. 위에서 언급한 범위를 축소하는 것이 진행 상황을 유지하는 것을 의미한다면, 우리는 추가적으로 축소할 의향이 있습니다.

레거시 바이트코드에 대한 설명:

(1) 우리는 새로운 레거시/비 EOF 바이트코드를 금지할 수 있지만, 기존의 레거시 바이트코드를 제거할 방법이 없으며, 이는 실제로 EOF의 "v0" 버전 역할을 합니다. 레거시 바이트코드는 EOF 이후에도 JUMPDEST 분석이 필요하며, Verkle Tries에서 이를 분할하는 것도 특별한 코드 처리가 필요합니다.

(2) 우리가 아는 한, 소스 코드 아티팩트 없이 비 EOF 바이트코드를 검증 가능하게 EOF로 변환할 방법이 없지만, 우리는 이러한 변환을 촉진하는 메커니즘을 탐색할 의향이 있습니다.

(3) 또한, 우리는 상태를 EOF로 강제로 마이그레이션하는 방법을 탐색할 의향이 있습니다.

EIP-4844 Blob 수 증가

우리는 이 변경에 대해 개방적인 태도를 가지고 있으며, 이는 MAXBLOBGASPERBLOCK(블록당 최대 Blob Gas 제한) 및 TARGETBLOBGASPERBLOCK(블록당 목표 Blob Gas 제한)을 증가시킬 것입니다.

EIP-4844를 배경으로: TARGETBLOBGASPERBLOCK 및 MAXBLOBGASPERBLOCK의 값은 각각 블록당 3개의 blobs(0.375 MB)의 목표와 6개의 blobs(0.75 MB)의 최대값에 해당하도록 선택되었습니다. 이러한 작은 초기 제한은 이 EIP가 네트워크에 미치는 압력을 최소화하기 위한 것이며, 네트워크가 더 큰 블록에서 신뢰성을 보여줄 것으로 예상되므로 향후 업그레이드에서 증가할 것입니다.

실제로 이는 작은 코드 변경이며, 우리는 거래 풀에서의 실제 영향을 조사해야 하지만, EIP-4844의 스트레스 테스트 인프라를 재사용하여 이 작업을 수행할 수 있다고 생각합니다. CL(합의 계층)은 더 많은 blobs를 전파하는 데 더 큰 어려움이 있을 수 있으며, 우리는 CL 팀의 의견을 따릅니다.

비추천 사항:

Verkle Tries

우리는 2024년 말에서 2025년 초에 Verkle tries를 배포할 경로를 보지 못합니다. 우리는 팀이 2024년 2분기에 이를 위해 자원을 할당하고, 2025년 2분기에서 3분기 사이의 오사카 하드 포크에서 이를 배포할 것을 약속합니다.

장점:

(1) 더 작은 저장 증명을 통해 더 저렴한 경량 클라이언트를 구현합니다.

(2) 블록 헤더에 읽기 프리 상태를 포함하여 무상태 실행을 구현하며, 이는 정적 상태 접근으로 인해 성능 향상을 가져올 수 있습니다.

(3) 바이트코드를 분할하고 부분 코드 로딩을 활성화하여 계약 크기 제한을 높입니다.

(4) "revive" 상태의 비용이 낮아짐에 따라 상태 만료가 더 실현 가능해집니다.

단점:

(1) 변경의 영향 및 구현 및 테스트의 통합 작업량.

(2) Gas 계산 변경: Verkle tries는 증명 크기를 Gas 계산 함수에 도입합니다. 우리는 저장 가격 변화에 대한 논의가 아직 이루어지지 않았다는 점이 우려됩니다(예: Verkle 이후, 최상위 Gas 소비자의 비용은 얼마가 될까요?).

(3) 애플리케이션 통합: Overlay 변환 실행 중 Merkle Patricia Trie 검증기가 있는 애플리케이션은 무엇을 해야 할까요? eth_getProof는 어떻게 작동해야 할까요?

우리는 Verkle tries의 장점을 이해하지만, 제3자 도구/계약이 어떻게 적응해야 할지, 그리고 변환이 Layer 2 솔루션 등에 어떤 영향을 미칠지에 대해 더 많은 고민이 필요하다고 생각합니다. 처음에는 기존 MPT(Merkle Patricia Trie)에서 상태를 읽을 때 Verkle tries를 업데이트해야 한다고 규정했기 때문에 마이그레이션 전략에 회의적이었지만, 이제는 더 이상 그런 것 같지 않습니다. 따라서 우리는 오버레이 트리 방법을 실행 가능한 마이그레이션 경로로 지지합니다.

Verkle 마이그레이션 전략에 대한 문서가 전반적으로 구식인 것 같으며, 대부분의 자료는 여전히 MPT에서 상태를 읽을 때 Verkle trie를 업데이트해야 한다고 지적하고 있지만, 사실은 그렇지 않습니다. 우리는 최신 방법으로 주요 변환 문서(예: https://notes.ethereum.org/@parithosh/verkle-transition)를 업데이트하기를 희망합니다. 우리는 또한 전환 전략에 대한 EIP 초안을 보고 싶습니다.

따라서 우리는 여전히 2025년 출시를 지지하지만, 프라하 포크에서 배포되어서는 안 된다고 생각합니다.

L1 Gas 제한

우리는 파생 수요로 인해 L1 Gas 제한을 높이는 것이 실제로 큰 효과가 없다고 생각합니다. 우리는 또한 대부분의 클라이언트가 평균 부하 증가를 처리할 수 있다고 생각하지만, 최악의 상황에 대해 경계를 유지하고 싶기 때문에 L1 Gas 제한을 높이는 것을 추천할 수 없습니다. 우리는 단기적으로 Blob Gas 제한을 늘리는 것이 더 유망한 해결책이라고 생각합니다.

계정 추상화

우리는 하나 이상의 EIP(또는 ERC를 포함하는 것)를 포함하는 것에 대해 개방적인 태도를 가지고 있지만, 각 제안 간의 사용자 경험 및 개발자 경험 비교를 통해 도구 통합의 균형 공간과 작업량을 더 잘 이해하기를 원합니다. 우리는 다음 EIP/ERC에 관심이 있지만, 더 많은 제안을 환영합니다:

(1) EIP-3074: AUTH 및 AUTHCALL 연산 코드

(https://eips.ethereum.org/EIPS/eip-3074)

(2) ERC-4337: Alt Mempool을 사용하는 계정 추상화

(https://eips.ethereum.org/EIPS/eip-4337)

(3) EIP-5806: 프록시 거래

(https://eips.ethereum.org/EIPS/eip-5806)

(4) EIP-5920: PAY 연산 코드

(https://eips.ethereum.org/EIPS/eip-5920)

(5) EIP-6913: SETCODE 명령어

(https://eips.ethereum.org/EIPS/eip-6913)

(6) EIP-7377: 마이그레이션 거래

(https://eips.ethereum.org/EIPS/eip-7377)

(7) RIP-7560: 네이티브 계정 추상화 - 핵심 EIP - 이더리움 마법사 연합

(https://ethereum-magicians.org/t/rip-7560-native-account-abstraction/16664)

우리는 위의 내용에서 "계정 추상화"가 "추상 검증 기능을 구현하여 키 교체를 가능하게 하고, 다중 서명을 블록체인의 핵심 특성으로 만들며, 자동 양자 저항 경로를 제공하는 것을 주요 목표로 한다"는 점을 상기시킵니다(h/t VB). 이는 위의 4337 및 7560에만 해당하며, 다른 제안은 Gas 후원 및 배치 작업의 두 가지 범주로 나뉩니다.