Ethereum — All Core Devs — Testing(ACDT), October 06 2025

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

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

1. Meeting Overview

이번 회의에서는 Holesky 포크 이후의 안정화 현황, BPO1 활성화 준비, blob 관련 HTTP endpoint 변경, MEV-Boost의 getPayload v2 전환 방식, 60M gas 리미트 및 MODEXP repricing 테스트, Glamsterdam 범위의 BAL(Block-level Access List) 진행 상황, ePBS DevNet-0 구현 현황, 그리고 RPC 테스트 리포팅이 논의되었습니다.

2. Key Discussion Topics

2.1 Holesky 포크 이후 안정화와 BPO1 준비

Holesky는 지난주 성공적으로 포크를 마쳤습니다. 첫날에는 한 노드에 너무 많은 validator 키가 로드되어 일시적인 오류가 발생했지만, 이는 운영상 실수로 추정되며 심각한 문제는 없었습니다.

포크 이후 Lighthouse 클라이언트에서 reorg(재조직) 비율이 다소 높게 관찰되었습니다. 조사 결과, attestation slashing을 중복 처리하던 코드가 원인으로 확인되었고, Lighthouse 팀은 이를 수정했습니다. 해당 패치는 다음 릴리스에 포함되어 배포될 예정입니다.

또한 BPO1은 회의 시점으로부터 약 하루 뒤 활성화를 목표로 준비 중이었습니다. 모든 클라이언트 팀은 대부분 준비를 마쳤으며, 활성화 이후에는 동일한 조건에서 네트워크 지표를 수집해 클라이언트 간 성능과 안정성을 공정하게 비교할 수 있도록 표준화된 측정 환경을 구축할 계획입니다.

2.2 getBlobSidecar / getBlobs와 KZG proof 필드 처리

Fusaka 업그레이드 이전까지는 getBlobSidecar endpoint가 blob 데이터와 함께 KZG proof를 반환했습니다. 이 proof는 blob 데이터가 올바르게 게시되었음을 검증하는 데 사용되었습니다.

Fusaka 이후 일부 클라이언트 구현에서는 KZG proof 필드를 형식상 유지하되 실제 데이터는 포함하지 않는 방식으로 변경되었습니다. 이런 방식을 개발에서는 “stub 처리(stub out)”라고 하며, 필드를 완전히 제거하지 않고도 API 호환성을 유지하기 위한 조치입니다.

이 변경으로 OP Stack 팀은 초기에 proof 검증 실패를 보고했지만, 이후 논의 결과 해당 endpoint에서는 proof가 더 이상 필요하지 않다는 점이 확인되었습니다. 다만 다른 rollup 팀들이 여전히 이 필드를 참조할 가능성이 있어, 전체 생태계의 요구를 다시 점검하기로 했습니다.

Arbitrum(Nitro) 팀은 getBlobSidecar 대신 getBlobs endpoint로 전환할 계획입니다. 이에 따라 attestations 라이브러리가 새로운 endpoint를 정상적으로 지원하는지 확인하고, 필요한 경우 코드를 업데이트해 호환성을 보장할 예정입니다.

모든 변경 사항은 공식 공지를 통해 사전에 안내되며, rollup과 indexer 같은 downstream 구성요소가 새로운 API 동작 방식에 안정적으로 적응할 수 있도록 지원할 예정입니다.

2.3 MEV-Boost getPayload v2 전환 시점

일부 CL은 Fusaka 이전부터 getPayload v2 API를 미리 적용해 테스트를 진행했습니다. 반면 다른 팀들은 포크 시점에 맞춰 v2로 전환했습니다.

이 API는 특정 포크에 의존하지 않지만, 실제 메인넷에서는 relay 구현 상태가 핵심 변수로 작용합니다. relay가 v2를 완전히 지원하지 않은 상태에서 조기에 전환하면, 블록 교환 과정에서 오류가 발생할 가능성이 높습니다. 이런 위험을 피하기 위해 대부분의 팀은 Fusaka 이후에 전환하는 것이 더 안전하다는 데 의견을 모았습니다.

클라이언트 팀들은 전환 시점을 표로 정리해 릴리스 간 일관성을 유지하기로 했습니다. 현재 Holesky에서는 여러 relay와 builder가 지원을 중단해 MEV 블록 생성이 거의 이루어지지 않고 있습니다. 그러나 Sepolia 테스트넷에서는 정상적으로 MEV 블록이 생성되고 있습니다.

참고로 Holesky는 이번 달 말 EOL(End of Life)이 예정되어 있으며, 이후 관련 테스트는 다른 네트워크에서 이어질 예정입니다.

2.4 Non-finality 및 Split-network 테스트

DevNet-3에서는 약 2~3일 동안 non-finality 테스트가 진행되었습니다. 이 테스트의 목적은 네트워크가 일시적으로 finality를 잃었을 때, 각 클라이언트가 얼마나 안정적으로 복구되는지를 검증하는 것이었습니다. 실험 결과, 네트워크는 문제없이 정상적인 finality를 회복했습니다.

다만 일부 노드에서 디스크 용량 고갈(disk exhaustion) 문제가 다시 발생했습니다. 이 현상은 데이터 저장 구조나 로그 관리 방식에 따라 반복될 수 있어, 향후에는 모니터링을 강화하고 디스크 사용량을 사전에 점검하기로 했습니다.

이번 주에는 Sunnyside Labs가 개발한 chaos testing 프레임워크를 활용해 의도적으로 네트워크를 분할(split)하는 split-network 테스트가 추가로 진행될 예정입니다. 이 테스트는 네트워크가 여러 그룹으로 나뉘었을 때, 각 클라이언트가 얼마나 빠르게 재동기화되는지를 관찰하기 위한 것입니다.

BPO관련 지표들은 ethPandaOps 대시보드를 통해 실시간으로 시각화되고 있습니다. 이를 통해 개발자와 운영자는 테스트 진행 상황과 네트워크 복구 속도를 한눈에 확인할 수 있습니다.

2.5 L1 스케일링: 60M Gas, MODEXP Repricing, Stateful Tests

Besu 클라이언트는 60M gas 리미트 구현을 완료했습니다. 현재 코드는 동결(freeze) 상태로 전환되었으며, 곧 fuzzing과 통합 테스트가 시작될 예정입니다. 보안 팀과 테스트 팀 간의 협업 채널도 이미 열려 있어, 테스트는 수일 내 본격적으로 진행될 계획입니다.

Nethermind 팀은 stateful test 프레임워크를 Ethereum의 표준 state test 실행 방식에 맞게 조정하고 있습니다. 로컬 환경에서는 대부분의 테스트가 성공적으로 통과했지만, Hive 테스트 환경에서는 여전히 몇 가지 설정 수정이 필요합니다. 이 조정이 완료되면 클라이언트 간 상호 운용성(interoperability) 검증이 한층 수월해질 것으로 예상됩니다.

MODEXP repricing 작업도 병행되고 있습니다. 이 분석은 네트워크 레벨과 애플리케이션 레벨 양쪽 데이터를 기반으로 진행되며, 주요 목표는 DoS(서비스 거부 공격) 저항성과 실행 효율 사이의 균형점을 찾는 것입니다.

즉, 연산 비용을 과도하게 낮춰 네트워크를 위험에 노출시키지 않으면서도, 사용자와 애플리케이션이 합리적인 비용으로 트랜잭션을 처리할 수 있도록 가스비 구조를 재설계하려는 시도입니다.

2.6 Glamsterdam 범위: BAL(Block-level Access List)

execution-apis 저장소의 BAL 관련 PR이 병합되면서 스펙의 완성도가 한층 높아졌습니다. 이번 업데이트에서는 EIP-7702, reverted transaction 등 그동안 문제로 지적되던 여러 edge case가 해결되어, 테스트 환경에서도 안정적인 동작이 확인되었습니다.

테스트 결과도 긍정적입니다. Reth와 Geth는 대부분의 테스트를 통과했으며, Nethermind 역시 로컬 환경에서는 정상 작동하고 있습니다. 다만 Hive 테스트 구성에 일부 조정이 필요해, 해당 수정이 완료되면 전체 테스트 호환성이 확보될 것으로 보입니다.

3개 이상의 EL 클라이언트가 완전히 동작하게 되면, BAL DevNet이 공식적으로 공개될 예정입니다. 이 DevNet은 BAL 기능의 상호운용성과 실제 네트워크에서의 성능을 검증하기 위한 테스트망 역할을 하게 됩니다.

자동화된 테스트 환경을 원활하게 구축하기 위해, 모든 클라이언트 팀은 메인 리포지토리에 bal-devnet-0라는 이름의 브랜치를 생성해야 합니다. 이 통일된 네이밍 규칙은 자동 빌더가 각 클라이언트의 변경 사항을 쉽게 추적하고, Hive 및 KTOS 테스트 시스템이 최신 코드를 자동으로 가져올 수 있게 해줍니다.

이번 주 예정된 BAL 브레이크아웃 콜에서는 BAL을 hash 형태로 표현할지, 또는 root 구조로 표현할지를 두고 최종 결정을 내릴 예정입니다. 이 선택은 데이터 검증 방식과 구현 복잡도 모두에 영향을 미치는 중요한 기술적 분기점이 될 것입니다.

2.7 ePBS DevNet-0 구현 현황

ePBS DevNet-0의 스펙은 이미 완성 단계에 도달했으며, 여러 클라이언트 팀이 동시에 구현을 진행하고 있습니다. 이 DevNet은 enshrined Proposer-Builder Separation(ePBS) 구조를 실제 환경에서 검증하기 위한 첫 테스트망으로, 클라이언트 간 통합과 프로토콜 동작을 조기에 점검하는 목적을 가지고 있습니다.

아직 몇 가지 세부적인 항목이 남아 있습니다. 특히 trusted payments와 관련된 경제적·운영적 설계는 이번 주 금요일 예정된 ePBS 브레이크아웃 콜에서 논의될 예정입니다. 이 부분은 relay와 builder 간 결제 흐름의 투명성과 보안성을 결정짓는 핵심 요소이기 때문에, 여러 팀의 의견을 모아 명확한 합의안을 마련할 계획입니다.

테스트 자동화를 위한 준비도 병행되고 있습니다. 모든 클라이언트 리포지토리는 epbs-devnet-0라는 브랜치 이름을 공통으로 사용할 것이 권장되었으며, 이 규칙을 따르면 이미지 빌드와 테스트 실행 파이프라인을 단순화할 수 있습니다. 결과적으로 클라이언트 간 코드 변경을 더 빠르게 동기화하고, DevNet 운영 효율을 높일 수 있을 것으로 기대됩니다.

2.8 RPC 테스트 리포팅과 품질 알림

Hive 기반 RPC 테스트 리포트가 매주 Discord에 게시되고 있습니다. 이 리포트는 단순히 테스트의 통과 여부(pass/fail)만을 보여주는 것이 아니라, 이전 주와 비교한 성능 변화 추이도 함께 제공합니다. 이를 통해 각 클라이언트 팀은 RPC 동작 품질이 개선되고 있는지, 혹은 특정 릴리스 이후 문제가 발생했는지를 한눈에 파악할 수 있습니다.

또한 Ethereum Research 포럼에서는 RPC 테스트를 단순 기능 검증 수준에서 넘어, 애플리케이션 중심테스트로 확장하자는 제안이 논의되고 있습니다. 이는 실제 사용자 환경에서 RPC가 어떻게 동작하는지를 더 현실적으로 검증하기 위한 방향입니다.

각 클라이언트 팀은 이 논의에 참여해 새로운 테스트 케이스를 제안하거나 개선 아이디어를 공유할 수 있습니다. 원한다면 Discord 내에서 알림 역할(role)을 부여받아, 새로운 리포트가 게시될 때마다 자동으로 업데이트를 받을 수도 있습니다.

이러한 절차는 RPC 품질 향상뿐 아니라, 클라이언트 간 개발 피드백 루프를 빠르게 형성하는 기반이 될 것으로 기대됩니다.

3. Decisions & Action Items

이번 회의에서 합의된 주요 결정과 후속 조치는 다음과 같습니다.

• Holesky 및 BPO 관련: Lighthouse의 slashing 처리 오류 수정 패치를 배포하고, Holesky 네트워크는 이달 말 EOL로 종료합니다. BPO1 활성화를 통해 표준화된 지표를 수집하며, 클라이언트 간 성능 비교 환경을 구축합니다.
• Blob API / KZG Proof: 각 rollup 팀의 요구를 다시 검토해 endpoint 명세를 확정합니다. 변경 사항은 공식 공지를 통해 안내하고, attestations 라이브러리의 호환성을 점검합니다.
• MEV-Boost 전환 시점: 모든 클라이언트가 getPayload v2 전환 시점을 표준화하기로 합의했습니다. 메인넷에서는 relay 안정성을 고려해 Fusaka 이후 전환이 권장됩니다.
• 테스트 및 스케일링: DevNet-3의 non-finality 테스트를 확대하고, Sunnyside Labs의 chaos 프레임워크를 활용한 split-network 테스트를 이어갑니다. Besu는 60M gas 리미트 테스트를 시작하며, MODEXP repricing 분석을 통해 DoS 저항성과 실행 효율의 균형을 검증합니다.
• Glamsterdam / BAL: 모든 클라이언트는 자동화 환경을 위해 bal-devnet-0 브랜치를 생성합니다. BAL의 hash vs root 표현 방식은 이번 주 breakout 콜에서 최종 확정하며, 3개 EL 클라이언트 확보 후 BAL DevNet을 출시합니다.
• ePBS DevNet-0: 클라이언트 구현을 지속하며, trusted payments 설계는 이번 금요일 breakout 콜에서 논의합니다. 테스트 자동화를 위해 epbs-devnet-0 브랜치 구조를 통일합니다.
• RPC 리포팅: Hive 기반 RPC 품질 리포트를 주간 단위로 게시하고, 애플리케이션 중심의 테스트 논의에 참여할 팀에는 Discord 알림 역할을 부여합니다.

4. Analysis & Implications

• 운영 안정성 강화: Lighthouse의 slashing 처리 패치와 BPO1 활성화는 테스트넷 안정성을 크게 높일 것으로 예상됩니다. 표준화된 지표 수집 체계가 구축되면, 클라이언트 간 성능 편차를 조기에 파악하고 대응할 수 있습니다.
• 인터페이스 호환성 유지: getBlobs와 getBlobSidecar API는 rollup과 indexer의 핵심 인터페이스입니다. KZG proof 필드 처리 방식이 바뀔 경우, 이를 참조하는 시스템이 오류를 일으킬 수 있으므로 모든 변경은 사전 공지와 테스트 환경 제공을 통해 점진적으로 적용해야 합니다.
• Relay 의존성 관리: getPayload v2는 포크와 직접적인 연관은 없지만, relay의 구현 상태에 따라 실제 전환 시점이 달라집니다. 각 클라이언트 팀의 전환 타이밍을 일치시키면 디버깅과 릴리스 관리가 훨씬 단순해지고, 네트워크 레벨에서의 불일치를 최소화할 수 있습니다.
• 성능과 보안의 균형 확보: 60M gas 리미트와 MODEXP repricing 논의는 Ethereum L1 확장성과 DoS 저항성 사이의 균형점을 찾는 과정입니다. 조기 fuzzing과 stateful 테스트를 병행함으로써, 릴리스 전 잠재적인 리스크를 최소화할 수 있습니다.
• Glamsterdam과 ePBS의 추진력: BAL 스펙의 병합과 높은 테스트 통과율은 Glamsterdam 업그레이드가 DevNet 단계로 진입했음을 의미합니다. BAL을 hash로 표현할지 root로 표현할지는 추적성·복잡도·합의 비용에 모두 영향을 주기 때문에 이번 주 브레이크아웃 콜의 결정이 중요합니다. ePBS는 이미 구현 단계에 들어섰으며, trusted payments 설계 방향이 relay/builder 생태계의 구조적 변화를 이끌 것으로 보입니다.

5. Glossary / Explanation of New Terms

getBlobSidecar / getBlobs 이 두 endpoint는 blob 데이터 조회용 API입니다. rollup과 indexer가 데이터를 복원하거나 검증할 때 사용됩니다. Fusaka 이후 일부 구현에서 KZG proof 필드가 제거되며, 이는 downstream 호환성 논의의 핵심 주제가 되었습니다.

KZG Proof KZG proof는 다항식 커밋먼트를 통해 blob 데이터의 무결성을 효율적으로 증명하는 기법입니다. 데이터 전체를 받지 않고도 검증이 가능하다는 점에서 확장성 측면에서 중요합니다. proof 필드의 형식 변경이나 누락은 verifier의 오류를 초래할 수 있으므로 신중한 조정이 필요합니다.

MEV-Boost getPayload v2 getPayload v2는 proposer와 relay가 블록 페이로드를 교환하는 최신 API 버전입니다. 포크에 종속되지 않지만 relay 구현 상태가 불완전할 경우 문제가 발생할 수 있습니다. Fusaka 이후 사용을 권장한 이유는 이러한 위험을 최소화하기 위함입니다.

BAL (Block-level Access List) BAL은 블록 단위로 access list를 정의해 가스 비용을 절감하고 실행 효율을 높이는 메커니즘입니다. 트랜잭션 단위보다 범위가 넓어, 대규모 연산을 수행하는 클라이언트에 유리합니다. 표현을 hash로 둘지 root로 둘지의 선택은 추적성, 복잡도, 합의 비용 모두에 영향을 줍니다.

ePBS (enshrined Proposer-Builder Separation) ePBS는 proposer와 builder 역할을 프로토콜 수준에서 분리하여 블록 생산의 투명성과 효율을 높이려는 설계입니다. 외부 relay 의존도를 줄이고, 인센티브를 합의 구조 안에서 정렬하는 목적을 가집니다. DevNet-0 스펙은 완성되었고, trusted payments 설계가 핵심 논의 주제입니다.

MODEXP Repricing MODEXP repricing은 EVM의 modular exponentiation 연산에 필요한 가스비를 현실화해, 네트워크 안정성과 성능을 동시에 확보하려는 작업입니다. 이 조정은 L2 및 애플리케이션의 실행 비용 구조에도 영향을 미치므로, 세밀한 분석이 필요합니다.