Paradigm: 캔쿤 업그레이드 이후 이더리움의 다음 단계는 무엇인가?

2024.01.19

Paradigm: 캔쿤 업그레이드 이후 이더리움의 다음 단계는 무엇인가?

유도 수요로 인해 L1 가스 한도를 높이는 것은 실제로 큰 효과를 거두지 못한다.

2024.01.19 - 02:12:37

以太坊坎昆升级

Web3 심층 보도에 집중하고 흐름을 통찰

유도 수요로 인해 L1 가스 한도를 높이는 것은 실제로 큰 효과를 거두지 못한다.

글: Georgios Konstantopoulos

번역: TechFlow

서론

이 글은 Paradigm Reth 팀이 프라하 컨퍼런스(칸쿤 이후의 다음 EL 하드포크)에 포함되어야 할 EIP(이더리움 개선 제안)와 2024년 "EL 코어 개발" 계획에 대한 견해를 개괄하는 것을 목적으로 한다. 이 글의 견해는 Reth 팀의 현재 관점을 반영하며, 반드시 전체 Paradigm 팀의 입장을 대표하지는 않는다.

요약

우리는 프라하 하드포크가 2024년 3분기에 이더리움 테스트넷에서 시행되고 연내 메인넷에 도입될 수 있다고 본다. 이 하드포크에는 다음 사항들이 포함되어야 한다:

EIP-7002와 같은 스테이킹 관련 EIP들로, 재스테이킹 및 트러스트리스 스테이킹 풀을 지원한다.
독립적인 EVM 변경사항.
프라하 또는 미래의 다른 EL 하드포크 관련 과제에 대해 어떤 팀과도 협력할 의사가 있으며, Reth 코드베이스 조정에 대한 지침이나 지원을 기꺼이 제공하겠다.

해야 할 일:

다음 EIP들을 우선적으로 고려해야 한다고 본다: 7002, 6110, 2537.
EOF(EVM 객체 형식)의 명세화를 지지하지만, 가능한 한 빨리 범위를 확정하고 이를 위한 메타-EIP(meta-EIP)를 만들어야 한다.
EIP-4844의 최대 Blob Gas 증가에 찬성한다. 정확한 숫자에 대한 구체적인 의견은 없지만, 데이터 전문가들과 함께 이 주제를 조사할 것을 초대한다.
검열 저항성을 강화하기 위해 EIP-7547의 버전(포함 리스트) 도입을 원한다.

하지 말아야 할 일:

프라하 하드포크에서 Verkle Tries 도입을 지지하지 않지만, 클라이언트 팀이 2024년 2분기부터 이를 구현하기 위해 노력하고 2025년 중반/후반 오사카 하드포크에서 출시하도록 약속하는 것은 지지한다.
L1 실행 Gas 상한선이나 계약 크기를 늘리는 것은 적절하지 않다고 본다. 하지만 데이터 전문가들과 함께 네트워크에 미치는 영향을 조사할 것을 초대한다. 과거 테스트 결과(Reth 노드가 증가된 부하를 감당 가능하다는 결과)를 바탕으로 입장을 재고할 의사가 있다.
지갑/계정 추상화 EIP들은 더 많은 실전 테스트를 통해 서로 간의 트레이드오프를 이해할 필요가 있다. 만약 상호 배타적이지 않다면, 앞으로 여러 개의 AA 관련 EIP를 배포할 의향이 있다.
커뮤니티가 소문난 NSA 백도어(NAS backdoor)를 받아들인다면, EIP-7212(secp256r1)에 대해 결정을 내릴 수 있다.
기타 로드맵 주제: CL EIP나 CL/EL 포크 결합에 직접적인 의견은 없으나, EIP 7549와 7251은 유망해 보인다. 또한 EL 측면에서 PeerDAS 작업에 기여할 의사가 있다. 현재로서는 SSZ 루트 도입(EIP 6404, 6465, 6466)은 피하고 싶다. 마지막으로, EIP-4844와 EIP-4444 모두 만료된 blob, 기록 및 상태에 대한 장기 데이터 아카이빙 솔루션을 명시하지 않았으며, 이더리움이 그러한 솔루션을 제공할 것인지 여부는 아직 불확실하다는 점에서 기회가 있음을 언급한다.

아래는 본문의 자세한 소개이다.

해야 할 일:

간단히 말해, 우리는 다음을 지지한다:

CL과 EL 사이의 격차를 더욱 좁히는 것.
개별 작업자에 의해 수행 가능한 EVM 수정사항이며, 독립적이고 병렬적으로 테스트할 수 있는 것.

EIP-7002

이 EIP는 EL 측의 스마트 계약이 CL 측의 하나 이상의 검증자를 제어할 수 있게 해주며, 이를 통해 트러스트리스 재스테이킹과 스테이킹 풀을 가능하게 한다. 기존 스테이킹 풀이 인출 기능을 가진 스마트 계약에서 중심화된 계층을 제거할 수 있기 때문에, 우리의 관점에서는 거의 무조건적인 선택지이다.

EVM에 상태를 갖는 프리컴파일을 도입하는 것은 우리가 EVM 구현에서 포착해야 할 새로운 추상 개념이지만, 그 외에는 바로 실행 가능한 EIP라고 본다.

EIP-6110

이 EIP는 EL 상태에 예금을 도입하여 CL에서 필요한 상태 관리를 단순화한다. 실제로는 CL 인출을 추적하는 것과 유사하므로 전반적으로 쉽게 독립적으로 구현 가능한 EIP라고 본다.

EIP-2537

현재 BLS12-381에 대한 다양한 구현이 이미 존재하며, 이는 많은 SNARKs, BLS 서명 알고리즘 및 EIP-4844에서 자주 사용되는 곡선이다. 사전 컴파일 인터페이스를 통해 곡선의 검증 알고리즘을 공개하는 것뿐이기 때문에 구현 복잡성은 낮다고 본다. 또한 BLS12-381 곡선 프리컴파일에 대한 해시 인터페이스가 추가로 필요할 수 있다.

EOF

간단히 요약하면: Solidity와 Vyper가 채택할 명확하게 정의된 버전을 지지한다. 코드 형식과 검증 조정은 분석을 용이하게 하는 데 분명한 장점이 있지만, 신중한 고려가 필요하다. 다음 EIP들의 채택을 제안하지만, 추가적인 축소에 열린 태도를 가지고 있다.

장점:

EVM 변경에만 관련되며 ethereum/tests로 테스트 가능하고 한 사람이 구현할 수 있다.
Vyper와 Solidity가 원하는 EVM 변경사항.
성능 향상과 계약 크기 상한 증가에 기여.
실행 시 바이트코드 분석의 필요성을 제거하며, 캐시 없이 분석 시간이 최대 50%까지 소요될 수 있고 계약 크기가 커질수록 증가하는 문제를 해결.
부분 코드 로딩을 지원하여 대규모 스마트 계약 실행에 도움.
개발 경험: dupN/swapN 및 기타 도구 개선을 통해 "스택이 너무 깊음" 문제 해결 가능.
미래 지향적: L2에서 새로운 기능을 안전하게 도입할 수 있으며 도구들이 호환 가능한 항목을 인식할 수 있음.

단점:

범위와 변화하는 목표.
채택을 추진할 강력한 주체 부족.
기존 코드는 계속 지원되어야 함.
채택 전까지 이더리움 메인넷과 다른 EVM 체인 간 일시적인 분기 발생.

다음 EOF 기능은 2024년에 배포해야 한다고 본다. 가능한 한 빨리 범위를 확정하고 약속해야 하며, 나머지는 후속 배포를 고려해야 한다. 우리의 제안은 다음과 같다:

EIP-3540: EOF - EVM 객체 형식 v1: 코드와 데이터 컨테이너 도입, 이더리움 바이트코드에 구조와 버전 관리 추가.
EIP-3670: EOF - 코드 검증: EOF 형식을 따르지 않는 계약의 배포를 거부. 더 구조화된 코드를 적용하고 유효하지 않거나 정의되지 않은 명령어 비활성화.
EIP-663: 무제한 SWAP 및 DUP 명령어: 이는 Solidity의 "스택이 너무 깊음" 문제를 해결하며 즉각적인 가치를 지닌다. JUMPDEST 분석이 부작용을 일으킬 수 있으나 EVM 언어에 매우 매력적이다.
EIP-4200: EOF - 정적 상대 점프: 더 나은 정적 분석 제공, 불확실한 점프 없음. 상대 점프는 코드 재사용성을 높인다.
EIP-4750: EOF - 함수: 동적 점프 대신 정적 점프 사용 시 발생 가능한 하위 절차 문제 해결. 또한 부분 코드 로딩을 허용하여 Verkle와 잘 맞고 계약 크기 제한을 증가시킨다.
EIP-5450: EOF - 스택 검증: 코드와 스택 요구사항 검증. CALLF (EIP-4750) 명령어 외 모든 명령어의 런타임 스택 언더플로 및 오버플로 검사를 제거.
EIP-7480: EOF - 데이터 섹션 접근 명령어: 바이트코드의 데이터 섹션 접근 허용.
EIP-7069: 개선된 CALL 명령어: CALL에서 가스 관측 가능성 제거, 향후 가스 재정산을 더 쉽게 만든다. EOF와 독립적이지만 도입할 좋은 기회라고 본다.

EIP-6206: EOF - JUMPF 및 비반환 함수에 대해서는 확신이 덜하다. EOF 함수에서 꼬리 호출 최적화를 허용하지만 언어 측면에서 그 유용성을 분석해야 한다. 이것들이 없다면 범위에서 제외하고 향후 EOF 업데이트에 포함할 수 있다고 본다.

위 작업량을 전직원 1명 기준 1~2개월 정도로 예산 책정한다. momentum을 유지하기 위해 위 범위를 추가로 축소할 의사도 있다.

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

새로운 레거시/비-EOF 바이트코드의 배포는 금지할 수 있지만, 기존 레거시 바이트코드를 폐기할 수는 없으며, 이는 사실상 EOF의 "v0"이 된다. EOF 이후에도 레거시 바이트코드는 JUMPDEST 분석이 필요하며 Verkle Trie에 세그먼트화하기 위한 특수 코드 처리도 필요하다.
우리가 아는 한 소스 코드 없이 비-EOF 바이트코드를 EOF로 변환할 수 있는 검증 가능한 방법은 없지만, 이러한 변환을 촉진하는 메커니즘을 탐색할 의사가 있다.
또한 EOF로 상태 마이그레이션을 강제하는 만료 방안도 탐색할 의사가 있다.

EIP-4844 Blob 수 증가

이 수정에 대해 열린 태도를 가지며, EIP-4844 맥락에서 이것은 MAX_BLOB_GAS_PER_BLOCK 및 TARGET_BLOB_GAS_PER_BLOCK 증가와 동등하다:

TARGET_BLOB_GAS_PER_BLOCK과 MAX_BLOB_GAS_PER_BLOCK의 목표값은 각각 블록당 3개 Blob(0.375MB)과 최대 6개 Blob(0.75MB). 초기 제한을 작게 설정한 이유는 이 EIP가 네트워크에 미치는 부담을 최소화하기 위함이며, 더 큰 블록에서도 네트워크의 신뢰성이 입증되면 향후 업그레이드에서 제한을 늘릴 것으로 예상된다.
실제로는 작은 코드 변경이지만 txpool에서의 실제 영향을 조사해야 한다. 그러나 EIP-4844의 압력 테스트 인프라를 활용할 수 있을 것으로 본다. 다만 CL에서 더 많은 Blob을 전파하는 것이 더 어려울 수 있으므로 CL 팀의 의견을 존중한다.

하지 말아야 할 일

Verkle Tries

간단히 말해, Verkle tries가 2024년 말/2025년 초에 배포될 경로는 보이지 않는다. 팀이 2024년 2분기에 자원을 배정하고 2025년 2분기~3분기 오사카 하드포크에서 배포를 약속할 것을 제안한다.

장점:

더 작은 저장 증명을 통해 더 저렴한 라이트 클라이언트 구현.
블록 헤더에 사전 상태 읽기를 포함함으로써 무상태 실행 가능, 정적 상태 접근을 통해 성능 향상.
바이트코드를 청크화하고 부분 코드 로딩을 활성화하여 계약 크기 제한 증가.
상태 복구 비용이 낮아져 상태 만료가 더 수용 가능해짐.

단점:

변경의 영향 및 구현과 테스트 통합 작업량.
가스 산정 변화: Verkle Tries는 증명(witness)의 크기를 가스 계산 함수에 도입한다. 저장 가격 변화가 아직 충분히 탐구되지 않았다(예: Verkle 이후 최상위 가스 소비자의 비용은 얼마가 될까?).
애플리케이션 통합: 오버레이 전환 중 Merkle Patricia Trie 검증기를 사용하는 애플리케이션은 어떻게 처리해야 하나? eth_getProof는 어떻게 동작해야 하나?

Verkle Tries의 이점은 이해하지만, 제3자 도구/계약이 어떻게 조정되어야 하는지, 2계층 솔루션 등에 미치는 전환 영향 등을 더 깊이 고려해야 한다고 본다. 처음에는 기존 MPT(Merkle Patricia Trie)에서 상태를 읽을 때 Verkle 트리를 업데이트하는 마이그레이션 전략에 회의적이었지만, 이제는 상황이 달라진 듯하다. 따라서 오버레이 트리 방식을 현실적인 마이그레이션 경로로 지지한다.

Verkle 트리 마이그레이션 전략에 관한 문서는 일반적으로 오래되었으며, 대부분의 자료는 여전히 MPT에서 상태를 읽을 때 Verkle 트리를 업데이트해야 한다고 주장하지만 실제로는 그렇지 않다. 예를 들어 이 훌륭한 문서처럼 핵심 전이 문서가 최신 방법으로 업데이트되길 바란다. 또한 마이그레이션 전략에 대한 초안 EIP(Ethereum Improvement Proposal)를 보기 원한다.

따라서 여전히 2025년 출시를 지지하지만, 프라하에서 이 시스템을 배포할 가능성은 없다고 본다.

L1 가스 제한

유도 수요(induced demand) 때문에 L1 가스 제한을 높이는 것은 실제로 큰 효과가 없다고 본다. 또한 대부분의 클라이언트가 평균 부하 증가는 처리할 수 있다고 생각하지만, 최악의 경우에 대해 경계해야 하므로 현재로서는 L1 가스 제한 증가를 권장할 수 없다. 단기적으로는 blob 가스 제한 증가가 더 유망한 해결책이라고 본다.

이 분야 연구를 위해 협력할 사람들을 초대하며, 일반적으로 EVM의 리소스 계량을 깨뜨리는 연구를 중심으로 한다. Broken Metre 논문은 이러한 연구 방향의 좋은 시작점이다.

계정 추상화

이러한 EIP들 중 하나 이상(또는 ERC 포함)을 포함할 의사가 있지만, 이상적으로는 각 제안의 사용자 경험과 개발자 경험에 대한 더 많은 비교를 통해 도구 통합의 트레이드오프 공간과 작업량을 더 잘 이해하고 싶다. 다음 EIP/ERC를 주목하고 있지만, 더 많은 제안을 추천해주길 환영한다: