이더리움의 칸쿤 하드포크 이후 다음 업그레이드는 어떤 모습일까요?

이 글의 목적은 프라하 하드포크에 대한 패러다임 레스 팀^[4]의 견해, 칸쿤에 이은 다음 EL 하드포크가 될 프라하, 그리고 2024년 "EL 핵심 개발 "2024년 프로그램. 다음 견해는 개발 중이며, 현재 Reth 팀의 견해를 나타내며 반드시 더 넓은 패러다임 팀의 견해와 일치하는 것은 아닙니다.

이것은 다음을 포함해야 합니다:

재스테이크 및 무신뢰성 플레지 풀을 가능하게 하는 EIP-7002와 같은 모든 플레지 관련 EIP.

독립적인 EVM 변경.

우리는 브래그 또는 기타 향후 EL 하드포크에 대해 더 자세히 알아보고자 하는 모든 팀과 협력할 의향이 있으며, Reth 코드베이스의 위치 수정에 대한 멘토링이나 지침을 기꺼이 제공할 수 있습니다.

지원:

우리는 다음 EIP를 우선적으로 지원해야 한다고 생각합니다:

우리는 다음 EIP를 우선적으로 지원해야 한다고 생각합니다:

7002^[5], 6110^[6], 2537^{[7 ]}.

규격 ^[8]에 설명된 대로 EOF를 지원하지만, 가능한 한 빨리 범위를 정의하고 해당 범위에 커밋하는 메타-EIP를 만들고자 합니다.

EIP-4844 최대 블롭 가스^[9] 버전을 추가할 의향이 있습니다. 정확한 수치에 대한 의견은 없지만, 이 문제를 조사하기 위해 데이터 전문가를 초대합니다.

기본 계층이 조사에 저항할 수 있도록 EIP-7547: 포함 목록^[10] 버전을 기꺼이 공개할 의향이 있습니다.

지원되지 않음:

브래그에서 버클 시도^[11]의 사용을 지원하지 않지만, 2024년 2분기부터 이를 구현하기 위해 노력하는 고객 측 팀을 지원합니다! 2025년 중/후반에 오사카에 출시하기 위해 노력하고 있습니다.

우리는 L1 실행 가스 한도나 계약 규모를 늘려야 한다고 생각하지 않지만, 네트워크에 미치는 영향을 조사하기 위해 데이터 담당자와 협력할 것을 권유합니다. 과거 테스트 결과 Reth 노드가 증가된 부하를 문제없이 처리할 수 있는 것으로 나타났기 때문에 저희의 견해를 수정할 의향이 있습니다.

저희는 지갑/계정 추상화 EIP가 트레이드오프 공간을 더 잘 이해하기 위해 서로에 대한 더 많은 테스트가 필요하다고 생각합니다. 상호 배타적이지 않다면 향후 여러 AA 관련 EIP를 배포할 수 있습니다.

커뮤니티가 ^[12] 소문으로 떠도는 ^[13] NSA ^[14] 백도어^[14]에 괜찮다면 저희는 EIP-7212(secp256r1)를 허용할 수 있습니다.

기타 로드맵 주제: CL EIP 또는 CL/EL 포크의 결합에 대한 구체적인 견해는 없지만, EIP 7549^[15]와 7251^[16]이 유망해 보입니다. 저희도 가능한 한 EL 쪽에서 PeerDAS 작업에 기여하고 싶습니다. 당분간 SSZ 루트를 도입하는 것은 피하고 싶습니다(EIP 6404, 6465, 6466). 마지막으로, 만료된 블롭, 히스토리 및 상태에 대한 장기 데이터 아카이빙 솔루션을 제공할 수 있는 기회에 주목하고 있는데, EIP-4844^[17]과 EIP-4444^[18] 모두 이를 명시하고 있지 않으며, 이더넷은 이러한 솔루션을 제공할 의사가 있습니다.

이유는 다음과 같습니다.

지원

추상적으로는 1) CL과 EL 간의 간극을 더욱 좁히고, 2) 단일 플레이어 작업으로 실행할 수 있고 분리 및 병렬로 테스트할 수 있는 EVM 수정을 지원합니다.

EIP-7002^[19]

이 EIP는 신뢰할 수 없는 리플레지 및 서약 풀을 잠금 해제합니다. 저희의 관점에서 볼 때, 이는 최소한 기존 담보 풀이 인출을 구현하는 스마트 콘트랙트에서 중앙 집중성 계층을 제거할 수 있게 해줄 것이기 때문에 당연한 EIP입니다.

상태 저장 사전 컴파일을 도입하는 것은 EVM 구현에서 캡처해야 하는 새로운 추상화이지만, 그렇지 않다면 구현하기 쉬운 EIP라고 볼 수 있습니다.

EIP- 6110^[20]

이 EIP는 EL 상태의 예치를 도입하여 CL에서 수행해야 하는 상태 관리를 간소화합니다. 구현 측면에서는 CL 출금 추적과 유사하므로 전반적으로 구현하기 쉬운 독립형 EIP라고 생각합니다.

EIP-2537^[21]

BLS12-381의 여러 구현이 나와 있으며, 많은 SNARK, BLS 서명 알고리즘, EIP- 4844에서 자주 사용되는 커브입니다. 4844 커브는 SNARK, BLS 서명 알고리즘 및 EIP- 4844에서 자주 사용됩니다. 이 구현은 미리 컴파일된 인터페이스를 통해 커브에 대한 검증 알고리즘을 노출하기 때문에 복잡성이 낮다고 생각합니다. 아마도 해시에서 BLS12-381 곡선의 사전 컴파일도 가능할 것입니다.

EOF^[22] 이더넷 객체 형식

TL;DR: 솔리디티와 바이퍼가 사용할 범위가 지정된 버전을 지원합니다. 분석을 더 쉽게 만들어주는 코드 형식 및 유효성 검사 조정은 당연한 일이며, 추가적으로 정리할 것을 권장합니다.

이점:

EVM 전용 변경 사항으로, 이더/테스트로 테스트하고 한 사람이 구현할 수 있습니다.

바이퍼와 솔리디티가 원하는 EVM 변경을 수행하세요!

성능을 개선하고 컨트랙트 한도 크기를 늘립니다.

캐시가 없을 때 최대 50%까지 소요되는 EVM을 사용하면 런타임에 바이트코드 분석이 필요하지 않으며, 컨트랙트 크기에 따라 시간이 늘어납니다.

코드를 부분적으로 로드할 수 있어 대규모 컨트랙트를 실행하는 데 도움이 됩니다.

Devex: 솔리디티에서 dupN/swapN을 사용하여 "스택이 너무 깊게 쌓이는 현상"을 수정하는 등 여러 가지 툴링이 개선되었습니다.

미래 대비: 새로운 기능을 L2에 안전하게 도입할 수 있으며, 툴이 호환되는 기능을 파악합니다.

결함:

대상 변경.

포용을 강력히 주장하는 지지자가 없음.

구 코드를 지원할 필요성이 여전히 있음

이 코드가 채택되기 전까지는 메인 이더리움 네트워크와 다른 EVM 체인 사이에 일시적인 차이가 있을 것입니다.

우리는 2024년에 다음과 같은 EOF 기능이 배포되어야 한다고 생각합니다. 가능한 한 빨리 범위를 정하고 규정 준수를 약속하는 것이 좋습니다. 그 외의 모든 기능은 추후 배포를 고려해야 합니다. 권장 사항:

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

EIP-3670: EOF - 코드 유효성 검사^[24]: 배포 시 EOF 형식을 따르지 않는 모든 계약을 거부합니다. 보다 구조화된 코드를 강제하고 유효하지 않거나 정의되지 않은 명령어를 비활성화합니다.

EIP-663: 무제한 스왑 및 DUP 명령^[25]: 솔리디티의 "스택이 너무 깊게 쌓이는" 문제를 해결합니다. 이로써 솔리디티의 "스택이 너무 깊게 쌓이는" 문제가 해결되었으며, 즉각적인 값으로 분석하는 점프데스트는 부작용이 있을 수 있으며, EVM 언어에 이 기능이 있으면 좋겠다는 의견이 있었습니다.

EIP-4200: EOF - 정적 상대 점프^[26]: 더 나은 정적 분석, 불확실한 점프 없음. 자동 컴파일이 개선됩니다. 상대 점프는 코드 재사용성에 더 좋습니다.

EIP-4750: EOF - 함수^[27]: 동적 점프는 있지만 정적 점프가 없는 서브루틴을 처리해야 합니다. 또한 부분 코드 로딩을 허용하여 Verkle에서 잘 작동하며 컨트랙트 크기 제한을 추가합니다.

EIP-5450: EOF - 스택 유효성 검사 ^[28]: 코드 및 스택 요구 사항의 유효성을 검사합니다. CALLF(EIP-4750)를 제외한 모든 명령어는 런타임 스택 언더플로 및 오버플로 검사를 제거합니다.

EIP-7480: EOF - 데이터 세그먼트 액세스 명령어 ^[29]: 바이트코드의 데이터 세그먼트에 대한 액세스를 허용합니다.

EIP-7069: 개선된 CALL 명령어^[30]: CALL에서 가스 관측값을 사라지게 하여 향후 가스 가격 재평가를 더 쉽게 할 수 있도록 합니다. EOF와는 별개이지만, 지금이 도입하기에 좋은 기회라고 생각합니다.

EIP-6206: EOF - 점프프와 비반환 기능^[31]에 대해서는 확신이 서지 않습니다. EOF 함수에서 꼬리 호출 최적화가 가능하지만, 그 유용성에 대한 언어 분석이 필요합니다. 이것이 없다면 범위에서 삭제하고 후속 EOF 업데이트에 포함시킬 수 있다고 생각합니다.

위와 같은 예산은 한 사람이 1~2개월 풀타임으로 근무할 때 필요한 금액입니다. 모멘텀을 유지하는 데 도움이 된다면 위에서 언급한 범위를 더 줄일 의향이 있습니다.

레거시 바이트코드에 대한 참고 사항:

새로운 레거시/비-EOF 바이트코드는 금지할 수 있지만, 사실상 EOF 역할을 하는 기존 레거시 바이트코드 " v0". 레거시 바이트코드는 여전히 EOF 이후에도 점프데스트 분석이 필요하며, 버클 트라이로 분할하기 위해 여전히 특수 코드 처리가 필요합니다.

저희가 아는 한, 소스 아티팩트에 대한 액세스 없이 비 EOF 바이트코드에서 EOF로 검증 가능한 변환은 없지만, 이러한 변환을 용이하게 하는 메커니즘을 연구하는 데는 열려 있습니다.

또는, EOF로의 상태 마이그레이션을 강제하는 만료 방법을 모색할 수 있습니다.

EIP-4844 블롭 수 증가

우리는 이 변경에 대해 열려 있으며, 이는 MAX_BLOB_GAS_PER_BLOCK 및 TARGET_BLOB_GAS_PER_BLOCK에 추가될 예정이며, 자세한 내용은 EIP-4844^[32]:

TARGET_BLOB_GAS. 블록당 3개의 블롭(0.375MB)을 목표로 하고 최대 6개의 블롭(0.75MB)을 목표로 하도록 _PER_BLOCK 및 MAX_BLOB_GAS_PER_BLOCK 값이 선택됩니다. 이러한 작은 초기 제한은 이 EIP가 네트워크에 가하는 부담을 최소화하기 위한 것이며, 향후 업그레이드에서 더 큰 블록에서도 네트워크가 안정적으로 작동하도록 증가될 것으로 예상됩니다. *

실제로 이것은 사소한 코드 변경이며, txpool에서 실제 영향을 조사해야 하겠지만, EIP-4844의 스트레스 테스트 인프라를 재사용할 수 있을 것으로 생각합니다. 합의 계층에서 더 많은 블롭을 전파하는 데 문제가 있을 수 있으므로 CL 팀에 맡기도록 하겠습니다.

지원되지 않음

버클 시도^[33]

TL. DR: 2024년 말에서 2025년 초에 버클 트라이를 배포할 수 있는 방법은 보이지 않습니다. 2024년 2분기에 리소스를 할당하고 오사카 하드포크에서 2025년 2분기에서 3분기에 배포하는 것을 목표로 하는 것이 좋습니다.

이점:

저렴하고 가벼운 클라이언트와 더 작은 스토리지 증명을 가능하게 합니다.

블록 헤더에 읽기 전 상태를 포함시켜 상태 비저장 실행을 지원하며, 정적 상태 액세스로 인한 성능 향상으로 이어질 수 있습니다.

바이트코드를 청킹하고 부분 코드 로딩을 활성화하여 컨트랙트 크기 제한을 개선합니다.

상태 '부활' 비용이 낮아져 상태 만료가 더 매력적이 됩니다.

단점:

과중한 워크로드: 변경 사항의 영향, 구현해야 할 통합 작업 및 테스트.

가스 가격 변경: 버클은 가스 계산 기능에 증인 크기를 도입했습니다. 스토리지 가격 변동에 대한 검토가 아직 이루어지지 않아 우려스럽습니다(예: 버클 도입 후 상위 가스 소비자들의 비용은 어떻게 될까요?).

앱 통합: 오버레이 전환이 실행될 때 Merkle 패트리샤 트라이 검증자가 있는 앱은 어떻게 해야 하나요? eth_getProof 동작은 어떤 모습이어야 하나요?

버클 트라이의 장점은 이해하지만, 타사 도구/계약이 어떻게 적용되어야 하는지, 그리고 이러한 전환이 레이어 2 솔루션 등에 어떤 영향을 미칠지 이해하는 데 더 많은 고민이 필요하다고 생각합니다. 처음에는 기존 MPT에서 상태를 읽을 때 버클 트라이를 업데이트해야 한다는 마이그레이션 전략에 회의적이었지만, 지금은 그렇지 않은 것 같습니다. 따라서 저희는 오버레이 트리 접근 방식을 실행 가능한 마이그레이션 경로로 지원합니다.

버클 마이그레이션 전략에 대한 문서는 대체로 오래된 것으로 보이는데, 대부분의 리소스에서 여전히 MPT에서 상태를 읽을 때 버클 트라이를 업데이트해야 한다고 명시하고 있습니다(실제로는 그렇지 않음에도 불구하고). 이 훌륭한 문서 ^[34]와 같은 주요 전환 문서가 최신 방법론으로 업데이트되기를 바랍니다. 또한 전환 전략에 대한 EIP 초안도 보고 싶습니다.

따라서 2025년 Verkle의 출시는 여전히 지원하지만 프라하 업그레이드에 대한 배포 경로는 확인되지 않습니다.

L1 가스 한도

수요 촉발 관점에서 L1 가스 한도를 높이는 것은 실제로 큰 도움이 되지 않을 것으로 생각합니다. 또한 대부분의 고객이 평균 부하 증가를 감당할 수 있다고 생각하지만 최악의 시나리오에 대비하고 싶기 때문에 현재로서는 L1 가스 한도를 늘리지 않는 것이 좋습니다. 단기적으로는 블롭 가스 한도를 늘리는 것이 더 유망한 해결책이라고 생각합니다.

우리는 이 방향의 연구와 EVM에서 리소스를 계량하는 방식에서 벗어나는 것에 대한 모든 사람들의 협업을 초대합니다.^[35] 브로큰 미터 논문은 이 연구 방향의 좋은 출발점이 될 것입니다.

계정 추상화

우리는 이러한 EIP(또는 프로토콜 구현 ERC) 중 하나 이상을 포함할 의향이 있지만, 사용자 경험과 개발 경험을 더 많이 비교하여 개별 제안을 더 잘 이해할 수 있기를 원합니다. 제안의 절충 공간과 도구 통합 노력을 더 잘 이해하기 위해서입니다. 다음과 같은 EIP/ERC를 검토하고 있지만, 더 많은 제안을 자유롭게 해주시기 바랍니다:

EIP-3074: AUTH 및 AUTHCALL 옵코드^[36]

ERC-433;">ERC-433;[36]

ERC-433 왼쪽;">ERC-4337: 대체 멤풀을 사용한 계정 추상화^[37]

EIP-5806: 트랜잭션 위임^{[ 38]}

EIP-5920: PAY opcode^[39]

EIP-6913: SETCODE instruction^[40]

EIP-7377: 마이그레이션 트랜잭션^[41]

RIP-7560: 마이그레이션 트랜잭션^[41]

RIP-7560. ">RIP-7560: 네이티브 계정 추상화 - 핵심 EIP - 이더리움 매지션 펠로우십[42]

위에서 명확히 하고자 하는 것은 다음과 같습니다. 위의 맥락에서 "계정 추상화"는 "키 회전을 가능하게 하고, 다중 서명을 일류 기능으로 만들고, 자동화된 양자 저항 경로를 제공하는 것을 주요 목표로 검증 기능을 추상화하는 것"을 의미하며, 이는 4337과 7560에만 적용되는 반면, 다른 제안들은 두 가지 범주로 나뉩니다(h/t VB). 다른 제안은 가스 스폰서십과 운영 일괄 처리의 두 가지 범주로 나뉩니다.

저자: