Ethereum — All Core Devs — Testing(ACDT), July 28 2025

Ethereum All Core Devs의 미팅 내용을 정리하고 공부해보자!

• All Core Devs repo: https://github.com/ethereum/pm/issues/1634
• https://www.youtube.com/watch?v=Xc0eg8s71c4
• 글의 하단에는 All Core Devs 미팅에 나온 여러 용어들에 대한 설명이 있습니다.

이번 이더리움 All Core Devs(ACDT) 미팅에서는 Fusaka Devnet 3의 초기 운영 결과와 함께, 메인넷의 주요 이슈, 그리고 다음 하드포크인 Glammsterdam을 위한 벤치마킹 및 표준화 작업이 논의되었습니다.

1. Fusaka DevNet-3: 현황과 기술적 난제

Fusaka Devnet 3는 지난주에 출시되어, 현재 블록당 18개의 Blob을 처리하며 네트워크의 안정성을 테스트하고 있습니다. 특히, 이번 Devnet은 노드의 30%를 고성능 기가비트 노드로 구성하여 실제 환경을 시뮬레이션하고 있습니다. 다음 단계에서는 Blob의 수를 줄여 다양한 워크플로우를 테스트할 예정입니다.

현재까지 발견된 주요 이슈는 다음과 같습니다.

• 클라이언트 호환성 문제: Nimbus EL/CL 클라이언트에서 피어링 문제로 부트 노드에 연결하지 못하는 현상이 발생했습니다. 이는 클라이언트 간의 연결 로직에 대한 심층적인 디버깅을 필요로 합니다.
• 높은 Orphaned Block 비율: 네트워크에서는 예상보다 많은 Orphaned Block이 발생하고 있습니다. 이는 블록에 포함되는 컬럼 데이터가 슬롯이 끝나기 직전(6~7초 지연)에 수신되기 때문으로 추정됩니다. Rate Limiting이 지연의 원인일 수 있어 관련 조사가 진행 중입니다.
• MEV-Boost Architecture Proposal (MAP) 워크플로우 문제:
• 검증자 등록 실패: 818개의 검증자 중 672개만 MEV 등록에 성공했으며, Lodestar에서 검증자 등록 시 타임스탬프 관련 오류가 발생하고 있어 원인을 파악 중입니다.
• 블록 게시 실패: Nimbus 클라이언트에서 state root mismatch 오류로 인해 블록 게시가 실패하는 문제가 보고되었습니다. 이 문제의 정확한 원인에 대해 추가적인 분석이 필요한 상황입니다.
• 새로운 테스트 환경: Private Blob Mempool 기능이 도입되어, Blob이 미리 전파되지 않은 상태에서 어떻게 블록이 생성되고 처리되는지 테스트할 수 있게 되었습니다.

2. 표준화 논의: EthConfig와 JSON-RPC

클라이언트 간의 일관성을 확보하기 위한 표준화 작업도 논의되었습니다.

• eth_config 검증: 클라이언트가 네트워크 구성을 제대로 로드했는지 확인하는 eth_config 검증 기능이 EEST(Execution Engine Spec Tests) 벤치마크에 포함되었습니다. 이를 특정 통합 환경에서 활성화하여 클라이언트의 설정 오류를 사전에 방지하자는 방안이 제안되었습니다.
• JSON-RPC 해싱 방식 재검토: 현재의 JSON-RPC 응답 해싱 방식은 응답의 모든 공백을 제거해야 하는 등 취약점이 많다는 지적이 있었습니다. 이에 따라 해시 방식을 제거하고 JSON diff를 사용하여 응답을 비교하는 방식으로 전환하기로 합의했습니다.
• Precompile 주소 표준화: Precompile과 시스템 컨트랙트의 주소를 precompile 이름: 주소 형식으로 통일하여, 모든 클라이언트가 일관된 방식으로 데이터를 처리할 수 있도록 표준화하기로 결정했습니다. 이 변경사항은 EIP와 Execution API에 반영될 예정입니다.

3. 메인넷 이슈 및 BloatNet 프로젝트 진척도

• 메인넷 피어링 문제: 메인넷에서 일부 노드의 피어 가시성이 낮아지는 현상이 보고되었습니다. 이는 최근 Geth에서 노드 연결 로직을 변경(DNS를 통해 enr 교환을 요청)한 것과 관련이 있을 수 있다는 가설이 제기되었습니다.
• BloatNet 프로젝트: 메인넷 상태 크기의 2배에 달하는 2X state landmark에 도달했습니다. 개발팀은 Reth의 prop posting 실패와 Geth의 트레이싱 관련 메모리 오류 등 발견된 문제를 해결하며 프로젝트를 진행하고 있습니다. 특히, 가스 벤치마크를 위해 특정 파일 시스템을 활용하여 스냅샷을 빠르게 복사하고 롤백하는 방법을 도입할 계획입니다.

4. CLZ Opcode 벤치마크와 다음 하드포크

COUNT_LEADING_ZEROS (CLZ) Opcode의 벤치마크 결과가 공유되었습니다. 가스 비용이 5일 때, 7,200만 가스 및 1억 가스 한도 모두에서 모든 클라이언트의 실행 시간이 4초 미만으로 매우 안정적인 성능을 보였습니다. 현재의 가스 비용은 다소 보수적일 수 있지만, 이는 향후 Glammsterdam 하드포크에서 가격 재조정의 근거가 될 것입니다.

Sunnyside Labs 팀은 정규 거래와 Blob 거래를 혼합한 Devnet을 운영하며, 블록 크기 증가가 Blob 데이터 전파에 미치는 영향을 모니터링하고 있습니다. 또한, Teku 클라이언트의 백필(Backfill) 구현을 테스트하며 발견된 문제들을 해결해 나가고 있습니다.

1. prop posting

Prop posting은 ‘proposal posting’의 줄임말로, 블록 제안자가 블록을 생성해 네트워크에 전파하는 과정입니다. 이더리움 합의 계층의 검증인이 다음 블록 제안자로 선정되면, EL에서 처리된 거래를 담은 페이로드와 합의 정보를 결합하여 블록을 만듭니다. 이렇게 완성된 블록을 네트워크에 전파하는 것이 바로 prop posting입니다. 이 과정은 블록이 얼마나 빠르게, 그리고 안정적으로 전파되는지 결정하는 중요한 단계입니다.

2. EEST

EEST는 ‘Execution Engine Spec Tests’의 줄임말로, 이더리움 클라이언트의 실행 엔진이 프로토콜 스펙을 정확히 따르는지 검증하는 테스트 모음입니다. 이더리움 클라이언트의 EL은 이 테스트를 통과해야 네트워크에 참여할 수 있습니다. EEST는 새로운 하드포크나 EIP가 도입될 때, 모든 클라이언트가 동일하게 작동하는지 확인하여 클라이언트 간의 호환성을 보장하고 네트워크 안정성을 유지하는 핵심적인 역할을 합니다.

3. Private Blob Mempool

Private Blob Mempool은 MEV와 관련된 개념으로, 일반적인 Public mempool과 분리된 비공개 거래 풀입니다. 여기서 ‘blob’은 EIP-4844에서 도입된 데이터 저장 방식입니다. 거래는 Private Blob Mempool에 먼저 제출되어 MEV 빌더에게 직접 전달됩니다. 이를 통해 특정 거래가 블록에 포함될 때까지 공개되지 않도록 보호할 수 있습니다. Private Blob Mempool은 프런트러닝 같은 공격을 방지하고, 특정 참여자들 사이에서 최적화된 블록 생성을 가능하게 합니다.

4. Orphaned Block

Orphaned Block은 ‘고아 블록’이라고도 불리며, 여러 검증인이 거의 동시에 블록을 제안했을 때 발생하는 현상입니다. 이더리움 네트워크는 가장 먼저 수신된 유효한 블록을 채택하고, 다른 유효한 블록은 버립니다. 이때 버려진 블록이 바로 Orphaned Block입니다. 이 블록은 체인에 연결되지 못하고 사라지기 때문에, 포함된 거래는 다른 블록에 다시 포함될 때까지 처리되지 않습니다. 이더리움의 합의 메커니즘은 Orphaned Block 발생을 최소화하도록 설계되었지만, 네트워크 지연으로 인해 드물게 발생할 수 있습니다.

5. Backfill

Backfill은 CL에서 주로 사용되는 용어로, 노드가 네트워크에 새로 참여하거나 재시작했을 때 누락된 과거 데이터를 채워 넣는 과정입니다. 특히 샤딩 환경에서는 특정 샤드의 데이터를 처리하는 노드가 해당 샤드의 모든 과거 데이터를 저장하고 있지 않을 수 있습니다. 이 경우, 노드는 다른 노드로부터 필요한 과거 데이터를 요청하여 블록체인 전체의 히스토리를 동기화합니다. Backfill은 노드의 데이터 무결성을 유지하고 네트워크 전체의 데이터 가용성을 높이는 데 필수적인 작업입니다.