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

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

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

2025년 7월 21일에 열린 All Core Devs — Testing (ACDT) 미팅에서는 DevNet-3 출시 준비, getBlobs API 버전 조정, CLZ opcode 가스 비용 논의, safe block 처리 방식, 그리고 60M gas limit 사전 검토가 주요 안건으로 다뤄졌습니다.

1. DevNet-3 준비 상황

DevNet-3은 아직 출시되지 않았으며, 지난 금요일에 기능 업데이트가 배포되었습니다. 해당 업데이트에는 다음과 같은 변경 사항이 포함되어 있습니다.

• ModExp(modular exponentiation) 가스 비용 조정
• CLZ(Count Leading Zeros) opcode 업데이트
• EIP-7918 관련 blob base fee 및 가스 비용 변경
• EIP-7885에 따른 transaction gas limit 감소
• PeerDAS 관련 max blob per tx 테스트 추가
• EIP-7907 관련 테스트 제거

출시 전 해결이 필요한 주요 항목은 다음 두 가지입니다.

• Builder spec 변경 (https://github.com/ethereum/builder-specs/pull/123)
• Engine API 내 getBlobsV3 적용 여부

클라이언트 준비 상황.

• Execution Layer: Besu, Geth (config endpoint 제외), Nethermind, Reth는 준비 완료
• Consensus Layer: Lighthouse, Lodestar, Grandine 준비 완료 (Lodestar는 builder API 미완)

클라이언트별 최신 빌드 이미지가 확보되고 최종 테스트가 완료되면, DevNet-3는 2~3일 내로 출시될 수 있을 것으로 보입니다.

2. Gas Limit 테스트 진행

현재 모든 주요 클라이언트가 메인넷에서 45M gas limit 블록을 성공적으로 생성 중이며, Perf DevNet-2를 통해 관련 테스트가 진행되었습니다.

추가적으로 다음과 같은 Tool 들이 도입되었습니다.

• New sync testing tool: 노드 동기화 시간 측정을 위한 신규 Tool
• New RPC testing tool: 노드 워크로드 수집 및 벤치마크용 Tool로, 운영자들과 협업 예정

현재 Opcode 성능 측정 작업은 활발하게 진행 중이며, 계산 중심의 연산에 대한 벤치마크는 거의 완료된 상태입니다. 앞으로는 계산 결과가 상태(state)에 영향을 미치는 연산들을 테스트하는 stateful 테스트에 초점을 맞출 계획입니다.

3. BloatNet 상태 및 Metrics 수집

BloatNet은 메인넷 상태의 약 2배 규모에 도달했으며, 이는 향후 100M gas limit 테스트에 필수적인 기반입니다. 현재 compaction 테스트가 병행되고 있으며, 클라이언트별 sync 및 compaction 메트릭 수집이 요청되었습니다.

• Besu: 일부 메트릭(sync, compaction 등)이 비활성화되어 있거나, 노드 재시작 시 사라지는 문제가 있음
• Erigon: Grafana에 메트릭이 반영되어 있으며, compaction 관련 유사 메트릭도 포함되어 있음
• Nethermind: healing 관련 메트릭이 로그에만 존재하고, Grafana 등 외부 툴과 통합이 어려운 상태

4. Safe Block 처리 방식 (Engine API)

새로운 fast confirmation 알고리즘을 기반으로, Engine API의 safeBlockHash 필드에 더 빠르고 신뢰 가능한 블록 정보를 제공하자는 논의가 있었습니다. 두 가지 접근법이 검토되었습니다.

• 기존 safeBlockHash 필드를 fast-confirmed block을 나타내는 용도로 사용 방식 변경
• fast_confirmed와 같은 새로운 필드를 신설

이 필드는 일부 Rollup(Layer 2)에서 L1 블록을 신뢰할 수 있는 기준으로 사용되기 때문에, 도입 시에는 신중한 고려가 필요합니다. 그리고 이 주제는 Discord에서 논의가 계속될 예정이며, 향후 ACD 미팅에서도 다뤄질 예정입니다.

5. getBlobsV3 도입 여부

getBlobsV3는 Consensus Layer에서 사용할 수 있는 확장 API로, PeerDAS 최적화를 위해 준비 중인 기능입니다. 다만 이번 DevNet-3에 포함할지를 두고 논의가 이어졌고, 다음과 같은 우려와 상황이 공유되었습니다.

• 아직 충분한 테스트가 이루어지지 않은 상태에서 DevNet-3에 포함하는 것은 부담이 크다는 의견이 제기됨
• 현재 대부분의 CL 클라이언트는 getBlobsV2까지만 구현되어 있으며, V3는 아직 적용되지 않음
• 기존의 V3 적용을 위한 PR #671은 취소되었고, 대신 getBlobsV2를 all-or-nothing 방식으로 고정하는 새로운 PR이 제출됨(https://github.com/ethereum/execution-apis/pull/676)

결론적으로 DevNet-3에는 getBlobsV3를 포함하지 않기로 결정되었으며, getBlobsV2를 기준으로 통일하여 테스트가 진행될 예정입니다.

6. CLZ Opcode 가스 비용

CLZ(Count Leading Zeros) opcode의 가스 비용은 기존 3에서 5로 상향된 상태입니다. 이에 대해 성능 재평가가 이루어졌고, 클라이언트 간 의견 차이가 있었습니다.

• 일부 벤치마크에서는 CLZ가 다른 비트 연산 opcode들과 유사한 성능을 보여주므로, 3이 더 적절하다는 주장이 제기되었습니다.
• 반면, Geth 등 일부 클라이언트에서는 CLZ 연산이 상대적으로 무겁게 동작한다는 결과가 보고되었습니다.

결국, 아직 모든 클라이언트에 대한 벤치마크 데이터가 충분하지 않다는 점에서, DevNet-3에서는 5로 유지하고, 향후 Glamsterdam 포크 시점에서 다시 검토하기로 결정되었습니다.

7. 60M Gas Limit 사전 검토

현재 Ethereum 메인넷은 45M gas limit을 안정적으로 처리하고 있는 상황입니다. 이에 따라, 이를 60M 수준으로 확장할 수 있는지에 대한 논의가 진행되었습니다.

논의 과정에서 다음과 같은 주요 이슈들이 제기되었습니다.

• 일부 연산 모듈 최적화 필요: 특히 ModExp와 같은 연산은 gas 소비량이 크기 때문에 추가 최적화가 필요합니다.
• Refund 메커니즘 영향: 트랜잭션 처리 후 발생하는 가스 환급(refund)으로 인해, 실제 네트워크에 가해지는 가스 압력은 약 20% 낮아질 수 있습니다.
• Receipt 처리 병목: 트랜잭션 수가 증가함에 따라, 블록 처리 시 발생하는 receipt 기록이 병목 지점이 될 가능성이 있으며, 이는 100M gas limit을 고려할 때 중요한 기술적 과제가 됩니다.
• 측정 기반 접근 필요: 먼저 BloatNet을 통해 메인넷 상태 크기의 약 2배 규모를 달성한 뒤, 그 환경에서 정량적 성능 데이터를 확보하는 것이 우선이라는 의견이 제시되었습니다.

결론적으로, 60M gas limit 확장은 여전히 탐색 단계에 있으며, 충분한 테스트와 상태 증가 실험을 거쳐 향후 다시 논의될 예정입니다.

8. 향후 조치 및 합의된 사항

DevNet-3 출시를 앞두고, 다음과 같은 항목들이 최종적으로 정리되었습니다.

먼저, Builder API 관련 PR(#123)은 DevNet-3에 포함되며, getBlobsV3는 이번 릴리스에서 제외됩니다. 대신 getBlobsV2는 all-or-nothing 방식으로 유지되며 관련 PR이 대체되었습니다.

Engine API의 safe block 처리 방식에 대해서는 아직 결론이 나지 않았으며, Discord 및 향후 ACD 미팅에서 추가 논의가 이어질 예정입니다. CLZ opcode의 가스 비용은 현재와 같이 5로 유지하되, Glamsterdam 포크 시점에서 재검토하기로 합의했습니다.

또한, BloatNet을 활용한 메트릭 수집 및 성능 벤치마킹은 계속해서 진행되며, 60M gas limit 확대 여부는 장기적인 목표로 설정되어 있습니다. 이와 관련한 실험과 논의는 앞으로도 단계적으로 이어질 예정입니다.

1. ModExp (Modular Exponentiation)

ModExp는 EVM에서 제공하는 특수 연산으로, (base^exponent) mod modulus 형태의 모듈러 거듭제곱을 계산합니다. 이 연산은 zk-SNARKs에서의 trusted setup, RSA 기반 서명 검증, VDF 처리 등에 필수적이며, 복잡한 수학적 계산을 블록체인 위에서 효율적으로 수행할 수 있도록 돕습니다. 이 연산은 EIP-198에 따라 precompile 형태로 정의되어 있으며, 직접적인 opcode가 아닌 고정 주소의 precompiled contract를 통해 호출됩니다. 최근 Ethereum에서는 해당 연산의 성능 개선 및 최적화가 논의되고 있으며, gas cost 측정 및 상태 공간 부담에 대한 고려가 포함됩니다.

2. CLZ (Count Leading Zeros)

CLZ는 어떤 정수의 이진 표현에서 가장 앞쪽에 위치한 연속된 0의 개수를 계산하는 비트 연산입니다. 이는 polynomial 연산 최적화, 대수학적 순서 결정, cryptographic hashing 등에서 중요한 기초 연산으로 사용됩니다. Ethereum에서는 CLZ opcode 도입이 EIP-7939를 통해 논의되었고, 해당 opcode의 가스 비용이 초기에는 3으로 설정되었다가 클라이언트별 성능 벤치마크 결과를 기반으로 5로 일시 상향되었습니다. 일부 클라이언트(Geth 등)에서는 CLZ가 더 느리게 실행되며 리소스를 많이 소모한다는 분석이 있었고, 이에 따라 Glamsterdam 포크 전까지 재검토를 이어가기로 했습니다.

3. EIP-7918

EIP-7918은 “Blob base fee bounded by execution cost”라는 이름의 이더리움 개선 제안으로, 이더리움 덴쿤(Dencun) 업그레이드에서 도입된 블롭(Blob) 데이터의 수수료 체계를 개선하는 데 초점을 맞추고 있습니다. 이 제안의 주요 목적은 블롭의 기본 수수료가 트랜잭션의 실행 가스 비용에 비해 지나치게 낮아지는 상황을 방지하고, 이를 통해 블롭 시장의 효율성과 네트워크 자원의 공정성을 확보하는 것입니다.

4. EIP-7885

EIP-7885는 NTT 연산을 이더리움 가상 머신(EVM) 내에서 효율적으로 수행하기 위한 프리컴파일(Precompile)을 추가하는 것을 목표로 합니다. NTT는 격자 기반 암호화(post-quantum cryptography) 및 STARK 증명 시스템과 같은 현대 암호화 기술에서 핵심적으로 사용되는 수학 연산입니다. 이 프리컴파일이 도입되면 이러한 암호화 연산의 속도를 크게 향상시킬 수 있습니다.

5. getBlobsV3

getBlobsV3는 Ethereum Consensus Layer에서 사용되는 API로, PeerDAS 연동을 위한 blob 데이터를 보다 효율적으로 제공하기 위해 설계되었습니다. 기존 getBlobsV2가 “all-or-nothing” 방식으로 응답하는 반면, V3는 partial responses를 허용하여 네트워크 환경이 불안정한 상황에서도 일부 데이터를 수신할 수 있도록 유연성을 제공합니다. 하지만 현재까지 충분한 테스트가 이루어지지 않았고, 모든 CL 클라이언트가 이를 구현하지 않았기 때문에 DevNet-3에는 포함하지 않기로 결정되었습니다.

6. BloatNet

BloatNet은 Ethereum 메인넷 state size의 약 두 배에 해당하는 데이터를 가진 테스트 네트워크로, 대규모 state size가 클라이언트에 미치는 영향을 평가하기 위해 설계되었습니다. 이 네트워크는 주로 다음과 같은 목적을 위해 사용됩니다.

• Compaction 성능 측정: 클라이언트가 상태를 효율적으로 정리(compact)하여 디스크 공간을 절약할 수 있는지 확인
• State sync 안정성 확인: 새로 join한 노드가 거대한 상태를 빠르고 정확하게 동기화할 수 있는지 검증
• High gas limit block처리: 60M~100M 수준의 gas limit을 처리할 수 있는지 사전 실험

PerfNet(성능 측정 전용 DevNet) 및 BloatNet은 opcode 벤치마킹, 상태 성장 관리, 클라이언트 간 비교 등 다양한 테스트에서 함께 사용됩니다.

• 고가스 블록 처리: 60M~100M 수준의 gas limit을 처리할 수 있는지 사전 실험

PerfNet(성능 측정 전용 DevNet) 및 BloatNet은 opcode 벤치마킹, 상태 성장 관리, 클라이언트 간 비교 등 다양한 테스트에서 함께 사용됩니다.