Ethereum — All Core Devs — Execution (ACDE), October 09 2025

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

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

1. Meeting Overview

이번 All Core Devs Execution회의는 Fusaka 진행 상황, blob proof 전환 정책, Holesky 리소스 이슈, Glamsterdam 준비 상태(BAL, ePBS), 대규모 gas repricing 제안군, state growth 제어 EIP, 그리고 결제 모델을 단순화하려는 GAS2ETH 제안을 중심으로 진행되었습니다.

2. Key Discussion Topics

2.1 Fusaka shadow fork 상태

Fusaka shadow fork가 Sepolia에서 안정적으로 동작했습니다. Fulu와 BPO1 구간을 이미 통과했고, 보고 시점 기준으로 BPO2는 약 30분 뒤에 활성화될 예정이라고 공유되었습니다. 지금까지 missed blocks나 눈에 띄는 오류는 관찰되지 않았습니다.

이번 라운드에서는 consolidation 테스트를 먼저 완료했습니다. 이어서 top-up과 exit 시나리오를 순차적으로 검증합니다.

• consolidation은 여러 validator를 하나로 합치거나 지분을 모아 관리 단위를 줄이는 Consensus Layer 작업을 뜻합니다.
• top-up은 기존 validator에 stake를 추가해 유효 지분을 늘리는 절차를 말합니다.
• exit은 validator가 자발적으로 검증을 중단하고 withdraw 단계로 넘어가는 절차를 의미합니다.

2.2 Blob schedule 표기 원칙 정리

genesis JSON의 blob schedule에 매번 named fork(예: Amsterdam, Bangkok)를 추가하는 방식은 불필요하게 복잡했습니다. CL은 변경이 없으면 이전 값을 그대로 재사용합니다. 최근 합의에 따르면 named fork에서는 blob 파라미터를 바꾸지 않습니다. 그래서 schedule에 항목을 계속 늘려도 실제 값은 달라지지 않았습니다.

이번 회의에서 원칙을 단순화했습니다. blob 파라미터 변경은 앞으로 BPO에서만 정의합니다. blob schedule에서는 named fork 전용 필드를 제거합니다. fork와 blob 파라미터 변경을 같은 시점에 적용하고 싶다면, 같은 epoch에 named fork와 별도의 BPO를 함께 스케줄합니다. 표현력은 유지하면서 규칙은 단순해집니다.

fork 이름이 schedule에 보이지 않으면 한눈에 이해하기 어렵다는 의견과, 미래에 named fork에서 blob을 바꾸기 힘들어지는 것 아니냐는 의견도 있었습니다. 이에 대해서는 필요하면 언제든 BPO를 추가하면 된다는 점을 확인했습니다. 문서에는 “blob 파라미터는 BPO로 관리한다”는 공통 규칙을 명시합니다. EL과 CL 모두 같은 규칙을 따릅니다.

결과적으로 genesis 생성 스크립트는 BPO 목록만 읽으면 됩니다. 설정 파일과 문서도 간결해집니다. Fusaka 범위에서 즉시 바뀌는 것은 없고, devnet·testnet 브랜치(BAL 관련 브랜치 포함) 정리만 진행하면 됩니다.

2.3 Holesky BPO1 이후 관찰

Holesky에서 BPO1이 활성화되었습니다. 네트워크는 전반적으로 안정적으로 동작했습니다.

Lighthouse에서는 BPO1 activation 전후로 P2P peers가 일시적으로 감소하는 현상이 관찰되었습니다. 해당 이슈는 재현·원인 파악이 끝났고, 수정 릴리스가 준비 중이라고 공유했습니다.

Nimbus는 low-core 머신에서 CPU 사용률이 급증하는 문제가 보고되었습니다. 특히 BPO 9~15 구간에서 라이브러리의 reconstruction 단계가 약 4초 소요되는 것으로 측정되었습니다. DevNet에서는 비교적 고사양을 사용해 드러나지 않았던 이슈였고, 현재 해결 방안을 모색 중이라고 밝혔습니다.

2.4 Blob submission API와 proof 전환 정책

fork 경계에서 legacy blob proof를 cell proof로 바꾸는 정책을 클라이언트별로 확인했습니다. 목적은 전환 시점의 혼선을 줄이고, 제출 지연을 방지하는 것입니다.

Geth는 mempool에 있는 legacy 형식을 백그라운드에서 cell proof로 변환합니다. RPC로 들어오는 트랜잭션도 노드가 즉시 cell proof로 바꿉니다. 네트워크에서 수신하는 legacy 형식은 짧은 유예 기간 이후 더 이상 받지 않습니다. 이 변환 기능은 최소 한두 릴리스 동안 유지합니다. 종료 시점은 L2와 협의해 정합니다. 포크 직후 mempool이 가득 찬 상황에서도 변환으로 인한 병목은 관찰되지 않았다고 보고했습니다.

Erigon과 Nethermind는 포크 시점부터 legacy blob proofs를 즉시 거부합니다. 같은 트랜잭션이 새 proof로 다시 들어오면 수용합니다. 포크 이후에는 gossip으로 새 proof만 전파합니다.

L2·rollup submitter는 cell proof를 자체 생성해 제출하는 것을 권장합니다. 노드 측 legacy→cell 변환에 의존하면 불필요한 재증명과 대기 시간이 발생합니다. 제출 단계에서 cell proof를 바로 생성하면 포크 경계의 지연과 mempool 혼잡을 줄일 수 있습니다. 이는 Geth의 임시 변환 유무와 관계없이 장기적으로 일관된 제출 경로를 확보하는 방법입니다.

2.5 Scaling 업데이트: state access benchmarks

Nethermind 팀이 mainnet snapshot 위에서 execution spec tests를 돌리는 툴링을 개발 중입니다. 목표는 느린 블록을 재현 가능하게 쪼개어 client bottleneck을 찾고, 최적화 지점을 도출하는 것입니다.

mainnet state를 snapshot으로 고정한 뒤, 느린 블록과 유사한 패턴을 isolated 실행으로 재현합니다. storage writes를 가득 채우는 synthetic 케이스를 만들어 최악 경로를 직접 자극합니다. gas limit 값을 변경해 실행 시간을 비교하고, state 크기가 성능에 미치는 영향도 함께 관찰합니다.

현재 isolated 재실행에서는 보고된 느린 블록이 그대로 나타나지 않는 사례가 있습니다. 이는 hardware specs, concurrent load, 디스크 I/O, 백그라운드 작업 같은 외생 요인이 결과에 영향을 주고 있음을 시사합니다. 운영 환경에서 수집한 telemetry와 동일한 스펙으로 테스트를 병행해 원인을 단계적으로 좁혀갑니다.

다음 단계로, 동일 하드웨어에서 운영과 같은 조건으로 느린 블록을 캡처해 같은 snapshot 위에서 반복 재실행하며 차이를 정량화합니다. 또한 데이터베이스에서 execution client 타입 정보를 추출해 결과 해석에 반영합니다.

2.6 Glamsterdam 준비: BAL, ePBS, 테스트 프로세스

BAL은 클라이언트 간 호환 동작이 빠르게 맞춰지고 있습니다. Besu, Geth, Reth, Nethermind는 거의 정렬되었고 Erigon도 따라오고 있습니다. 단일 클라이언트로는 안정적으로 구동됩니다. 혼합 조합에서는 genesis 설정과 관련된 작은 문제가 보고되어 수정 중입니다.

테스트 범위는 계속 확대되고 있습니다. 공개된 BAL 테스트 세트는 약 26개에서 시작해 50개 이상으로 늘고 있습니다. 변형을 포함하면 150개가 넘는 시나리오를 검증할 수 있습니다. 현재 주요 클라이언트는 대략 80% 수준을 통과하는 것으로 집계되었습니다. 각 팀은 BAL metrics 정의와 계측도 병행하고 있습니다. EIP-7702의 authority tracking 정합성 수정은 스펙 PR이 열려 있으며 곧 병합될 예정입니다.

ePBS는 별도 breakout에서 논의를 계속하기로 했습니다. unconditional payments 등 민감한 주제를 집중적으로 다루고, Execution Layer 관점에서 특별한 변경이 생기면 해당 콜에서 공유합니다.

2.7 Gas repricing 제안군 개요

EVM 연산 비용을 실제 자원 사용에 맞게 harmonize하는 방향을 논의했습니다. ePBS 이후의 환경을 가정해 자원 간 상대가격을 조정합니다. 목표는 compute의 여유를 넓히고, 비용을 올려 state·history·data가 쉽게 커지지 않도록 하는 것입니다.

• EIP-7904: opcode별 벤치마크를 바탕으로 compute gas를 재조정합니다. 대부분의 연산이 더 저렴해지며, 연산 간 가격 왜곡을 줄입니다. 일부 precompile은 예외가 될 수 있습니다.
• EIP-7923: quadratic memory를 paging model로 바꿉니다. 메모리를 페이지 단위로 관리해 heap과 stack을 독립적으로 배치할 수 있게 합니다. 최근 접근한 512개 페이지를 저비용으로 처리하는 LRU 유사 모델이 제안되어 있습니다. 개발자와 컴파일러가 더 예측 가능한 메모리 공간을 사용할 수 있습니다.
• EIP-8037 / EIP-8038: 8037은 state creation 비용을 크게 올리고(약 10배 제안), code deposit을 별도 계량으로 분리합니다. 8038은 state access 전반을 재가격해 접근 비용의 일관성을 맞춥니다. 두 제안은 함께 적용해도 되고, 각각 독립적으로 검토해도 됩니다.
• EIP-7981 / EIP-7976: access list에 floor를 두고, calldata 비용을 올립니다. 네트워크와 디스크에 가해지는 data-plane 부담을 낮추려는 의도입니다.
• EIP-2780 / EIP-7778: 2780은 intrinsic gas를 낮춰 단순 ETH transfer를 더 저렴하게 합니다. 대신 account creation에는 별도 비용을 붙여 전송과 계정 생성의 과금을 분리합니다. 7778은 refund는 그대로 지급하되, block gas limit 계산에서는 refund를 빼지 않습니다. 환급을 이용해 블록을 과도하게 채우는 패턴을 막습니다.

2.8 EIP-8032: storage depth 기반 state growth 억제

EIP-8032는 계정별 storage tree의 최대 depth를 기록하고, activation depth를 넘는 SSTORE일수록 비용을 크게 올립니다. 목표는 단일 계약의 깊고 큰 storage가 네트워크 state를 과도하게 키우지 못하게 하는 것입니다.

전환은 완만하게 진행합니다. 블록 종료 시 해당 계정의 최대 depth 기록을 한 단계씩만 올려 갑작스러운 비용 급등을 피합니다.

악용 가능성은 낮습니다. storage key가 해시되어 있어 매우 깊은 경로를 인위적으로 만들려면 대량 키 생성이나 고비용 탐색이 필요합니다. 데이터를 여러 계약으로 쪼개는 우회는 추가 호출 비용이 붙어 자연스럽게 균형을 이룹니다.

변형안으로 total state size를 함께 반영해 네트워크 state가 빠르게 커질 때 비용이 자동 상승하도록 하는 아이디어가 제시되었습니다. 해당 EIP에는 아직 포함되지 않았습니다.

이 제안은 gas 상수값을 직접 정하지 않습니다. 8037/8038과 병행해 다뤄지며, code bloat나 account creation 같은 주제는 다른 EIP에서 별도로 다룹니다. Geth에는 초안 구현이 있고, activation 시점과 상수는 미정이며 repricing 논의와 함께 확정합니다.

2.9 기타 제안: 7903/7907, 5920, 7791

EIP-7907과 EIP-7903은 EIP-170의 24KB contract size 제한을 완화하려는 대안입니다. 7907은 상태 가정(state assumptions)을 건드려 Fusaka 단계에서는 제외되었습니다. 7903은 initcode 한도만 올려 상태 모델을 바꾸지 않는 보수적 접근입니다.

EIP-5920(PAY)은 execution context를 넘기지 않고 계약 간에 ETH를 직접 전송할 수 있게 합니다. 호출 흐름을 복잡하게 만들지 않고도 비용을 지불할 수 있어 결제 경로가 단순해집니다.

EIP-7791(GAS2ETH)은 TX origin의 gas를 결제 단위로 사용해 onchain 서비스에 수수료를 보내는 opcode를 제안합니다. basefee burn이나 블록 가스 한도 회계에 영향을 주지 않도록 별도의 gas-budget을 따로 추적합니다. griefing을 막기 위해 per-tx 상한(예: tx.gasLimit 수준)을 둡니다. 필요하면 향후 새 transaction type으로 상한을 명시하는 확장도 검토합니다. gas estimation, bundling, Account Abstraction과의 상호작용은 추가 정교화가 진행됩니다.

3. Decisions & Action Items

3.1 Blob schedule 운영 원칙

blob 파라미터 변경은 BPO로만 수행하고, blob schedule의 named fork 필드는 제거합니다. EL·CL 사이 표현 일관성을 확보합니다.

3.2 Fork 경계 전환 가이드

Geth는 RPC·mempool 변환 기능을 한두 릴리스 유지하며 L2와 종료 시점을 조율합니다. Erigon/Nethermind는 포크 시점부터 legacy proof를 즉시 거부합니다. L2·rollup은 cell proof를 자체 생성해 제출하도록 코드를 갱신합니다.

3.3 Glamsterdam 일정과 테스트 계획

Fusaka 메인넷 날짜가 정해지면 Glamsterdam non-headliner EIP 제안 창은 1주일만 운영합니다. BAL interoperability와 metrics 구현을 지속하고, 테스트 세트를 확대합니다.

3.4 Gas repricing 실행 계획

opcode 벤치마크를 바탕으로 파라미터를 고정하고, worst-case 재현 및 호환성 점검을 병행합니다. 중복 영역은 상호 보완 구조로 정리합니다.

3.5 GAS2ETH와 memory paging 모델

GAS2ETH와 7923 memory paging 모델은 영향 범위가 넓으므로 별도 스레드에서 사양을 구체화합니다.

4. Analysis & Implications

4.1 BPO 정리 → 문서·툴체인 단순화

BPO 전용 원칙으로 blob schedule을 관리하면 genesis 구성과 사양 문서가 간결해집니다. 포크별로 값을 거슬러 올라가 확인하는 일이 줄고, 툴체인 구현·유지 부담도 낮아집니다.

4.2 proof 전환 차이 → L2 운영 팁

클라이언트별 전환 정책이 다릅니다. 운영자는 submitter·relayer·sequencer 설정을 미리 갱신해야 합니다. L2가 cell proof를 직접 생성해 제출하면 지연이 줄고, 노드 측 재증명으로 인한 중복 연산을 피할 수 있습니다.

4.3 Holesky 관찰 → 리소스 가이드라인

코어가 낮은 머신에서 CPU 급증이 확인되었습니다. 가스 한도 상향, DAS, ePBS 환경으로 갈수록 이런 병목이 두드러질 수 있습니다. 코어 수·저장장치·네트워크 대역폭의 최소 권장치를 운영 가이드에 명확히 제시할 필요가 있습니다.

4.4 BAL·ePBS → 추진 방향과 기대 효과

BAL은 interoperability·테스트·metrics가 자리 잡으면 접근 제어와 검증 비용을 블록 단위로 모델링할 수 있습니다. ePBS는 proposer·builder 분리를 프로토콜에 내장해 수수료 정산과 검증 신호 경로를 단순화합니다. 실행 계층 변경 사항이 생기면 해당 콜에서 공유합니다.

4.5 Repricing → 상태 부채 관리

compute는 완화하고, state·data는 비용을 올려 쉽게 커지지 않게 하는 방향은 장기적으로 상태 부채를 줄입니다. state-heavy 프로토콜은 storage 레이아웃과 access 패턴을 점검해야 합니다. EIP-8032처럼 depth-aware 과금은 단일 거대 계약의 무제한 성장을 억제하고, 데이터 분할·state expiry 전략과 어울립니다.

4.6 GAS2ETH → 결제 경로 단순화와 주의점

GAS2ETH는 계약 제작자에게 직접·미세·예측 가능한 지불 경로를 제공합니다. 별도 gas-budget을 써서 basefee burn과 블록 한도 회계를 건드리지 않도록 설계됩니다. 다만 gas estimation, bundling, AA와의 조합에서 새 모서리 케이스가 생길 수 있으므로, 사양과 클라이언트 구현을 단계적으로 정교화해야 합니다.

5. Glossary / Explanation of New Terms

Repricing EIPs opcode, memory, state access, calldata 등 자원별 비용을 실제 자원 사용량과 정책 목표에 맞춰 다시 책정하려는 제안 묶음입니다. compute는 상대적으로 저렴하게, state·data는 상대적으로 비싸게 조정해 확장성과 상태 부채의 균형을 맞춥니다. 적용 전에는 worst-case 재현과 backward compatibility 점검이 필수입니다.

GAS2ETH TX origin이 보유한 gas를 결제 단위로 사용해 onchain 서비스에 비용을 직접 지불하게 하는 opcode 제안입니다. 별도의 gas-budget을 써서 basefee burn과 블록 가스 한도 회계를 건드리지 않도록 설계합니다. per-tx 상한으로 남용을 막고, gas estimation·bundling·Account Abstraction과의 상호작용은 추가로 다듬습니다.

intrinsic gas 트랜잭션이 EVM 코드를 실행하기 전에 트랜잭션 자체에 대해 선징수되는 최소 gas입니다. 기본 비용, calldata 크기, access list, contract creation 여부 등이 포함됩니다. 이 금액을 먼저 차감하고 남은 gas로 실제 opcodes가 실행됩니다. EIP-2780은 이 비용을 낮춰 단순 ETH 전송을 가볍게 하고, 계정 생성 비용은 별도로 부과하자는 방향을 제안했습니다.

SSTORE 계약의 영구 저장소(storage)에 값을 쓰는 EVM opcode입니다. 상태 트리 갱신과 증명 경로 재계산이 필요해 SLOAD(읽기)보다 훨씬 비쌉니다. 값 변화 유형과 warm/cold 접근 여부에 따라 비용이 달라집니다. EIP-8032는 storage depth가 깊어질수록 SSTORE 비용을 더 올려 거대·심층 상태의 무한 성장을 억제하려 합니다.

quadratic memory 현재 EVM의 메모리 비용 모델로, 사용량이 늘어날수록 비용이 제곱적으로 증가합니다. 큰 배열·버퍼를 다루기 어렵고, heap/stack 분리가 불편합니다. paging model로 전환하면 개발자와 컴파일러가 더 예측 가능한 비용으로 메모리를 사용할 수 있습니다.