Ethereum — All Core Devs — Execution (ACDE), August 14 2025

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

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

2025년 8월 14일 열린 Ethereum All Core Devs Execution(ACDE) 미팅에서는 Fusaka DevNet-4에서 드러난 문제와 Glamsterdam 업그레이드의 범위가 주요하게 논의되었습니다.

1. Fusaka: DevNet-4 이슈와 DevNet-5 계획

DevNet-4 이슈

DevNet-4는 BPO1·BPO2 전환까지는 성공했지만, BPO3 단계에서 문제가 발생했습니다.

• EL 클라이언트 불일치: Erigon이 blob fee 계산을 다른 방식으로 처리해 체인이 갈라졌습니다. Geth과 다른 클라이언트는 이미 수정 패치를 적용했지만, Erigon은 아직 원인을 조사 중입니다.
• 클라이언트 동기화 문제: Lighthouse와 Nimbus가 네트워크에서 새로운 피어를 찾는 과정(peer discovery)과 잘못된 피어를 걸러내는 과정에서 문제가 생겨 head까지 동기화하지 못했습니다. 초기 부트노드 구성이 대부분 Lighthouse–Geth 조합이라서 문제가 더 커졌고, 이후 절반을 Prysm–Geth로 교체했습니다.
• Slashing 위험 없음: 네트워크의 Super-node 구조가 메인넷과 비슷하게 구성되어 있어, 주요 클라이언트에 수정 패치가 적용되면 finality는 복구될 것으로 예상됩니다

DevNet-5 계획

• DevNet-5를 새로 시작해 fix가 정상적으로 작동하는지 확인합니다.
• Minority 클라이언트(Grandine, Erigon, Lodestar 등) 비중을 3–5%로 늘려 다양성을 확보합니다.
• Fusaka 관련 테스트넷 및 메인넷 일정은 DevNet-5가 안정화된 이후에 확정합니다.

2. BPO Update Fraction 계산 규칙

• Fork boundary(새로운 규칙이 적용되는 첫 block)에서 base fee 관련 update fraction을 계산할 때, 해당 block(현재 block)의 fork parameters를 사용하기로 합의했습니다.
• 이전에는 일부 클라이언트가 parent block의 parameters를 사용하고, 일부는 현재 block의 parameters를 사용해 계산 방식이 달랐습니다.
• 앞으로는 EIP 명세에 반드시 “current block vs parent block 중 어느 쪽 parameters를 사용할지”를 명시하도록 합니다.
• Testing 팀이 static tests를 제공해 모든 클라이언트가 동일한 동작을 보장합니다.

3. Glamsterdam: Headliners 확정

이번 회의에서 Glamsterdam 업그레이드의 headliner가 최종 확정되었습니다.

• Consensus Layer: ePBS (EIP-7732) — 블록 제안자와 빌더 역할을 프로토콜에서 직접 분리하는 방식
• Execution Layer: Block Access Lists (BALs, EIP-7928) — 블록에 어떤 상태와 계정이 접근되는지를 명확히 기록하는 방식

추가 결정 사항

• FOCIL(EIP-7702): 아직 CFI 상태로 유지하며, ePBS와 BALs가 충분히 안정화된 뒤 포함 여부를 다시 논의합니다.
• 6-second slots(EIP-7778): 슬롯 시간을 절반으로 줄이는 제안이었지만 BALs와의 복잡성 문제 때문에 제외되었습니다.
• 기타 EIP 제안: Fusaka mainnet releases 시점까지만 접수하며, 그 이후에는 업그레이드에 포함될 범위를 고정합니다.

4. Block Access Lists (BALs) 세부 논의

BALs 스펙에 대한 주요 논의 결과는 다음과 같습니다.

• State-read locations 포함: SLOAD, balance check, static call 등 읽기 전용 데이터 접근도 BAL에 기록하기로 했습니다.이로 인해 블록 크기는 다소 커지지만, 감사(Audit) 용도와 병렬 실행(parallel batch I/O) 가능성을 고려해 유지합니다.
• Serialization 포맷: 현재는 RLP를 사용합니다. SSZ는 증명(proof) 효율성이 더 좋지만, Go 언어용 라이브러리가 아직 성숙하지 않아 추후 다시 검토하기로 했습니다.
• System contracts 처리: 블록 실행 전(pre-execution)과 실행 후(post-execution)에 발생하는 상태 변경을 따로 기록합니다. 또한 기존의 transaction index와 헷갈리지 않도록, 새로운 명칭인 block-level access list index를 사용합니다.

5. Safe Head (Fast-Confirmed Block) 제안

Ethereum에서는 거래가 빠르게 확인되었지만 아직 최종 확정(finalized)은 안 된 블록을 어떻게 표시할지가 논의되었습니다. 이를 Fast-Confirmed Block이라고 부릅니다.

• **기존 safe block tag를 그대로 사용
• **장점: 새로운 API 변경이 필요 없음.
• 단점: 지금까지 safe block은 “justified block”을 의미해왔기 때문에 의미가 바뀌면 혼란이 생길 수 있음.
• **새로운 fastConfirmedBlock tag/hash를 추가
• **장점: 의미가 명확하고 혼동이 없음.
• 단점: Engine API와 JSON-RPC에 새로운 항목을 추가해야 해서 구현 변경이 필요함.
• **safe block 의미를 클라이언트 설정(runtime config)에 따라 다르게 해
• **장점: 유연성 제공.
• 단점: 클라이언트별로 설정이 다르면 혼선과 오용 가능성이 있음.

결론은 아직 나지 않았으며, 블록 탐색기(explorer), 인덱서(indexer) 등 데이터를 소비하는 쪽의 의견을 더 모은 뒤 결정하기로 했습니다.

6. Testing 프로세스 개선

• Static tests 준비: Testing 팀은 업그레이드에서 중요한 변경사항(예: fork-parameter 계산, MODEXP 가스 비용 변경 등)에 대해 모든 클라이언트가 같은 결과를 내는지 확인할 수 있는 static tests를 마련하고 있습니다.
• 사전 협의 의무화: 앞으로 EIP 제안자는 ACD 미팅에 오기 전에 Testing 팀과 미리 논의해, 어떤 테스트가 필요한지와 복잡도를 확인해야 합니다.
• 좋은 사례: BALs 제안팀은 이 과정을 선제적으로 Testing 팀과 협업했고, 이것이 모범적인 사례로 언급되었습니다.

요약

ACDE (2025–08–14)에서 핵심적으로 정리된 내용은 다음과 같습니다.

• Fusaka: DevNet-5를 통해 bug fix를 검증하고, 안정화 후 일정 확정

• BPO update fraction: 현재 block 기준으로 계산하는 규칙 합의

• Glamsterdam: ePBS와 BALs를 headliner로 확정, Fossil은 CFI 유지

• BALs: read locations 포함, RLP 유지, pre/post 분리 기록

• Safe Head: 노출 방식은 추가 논의 필요

• Testing: 모든 EIP는 사전 테스트 협업을 의무화

Ethereum은 DevNet 안정성과 테스트를 기반으로 Fusaka 이후 Glamsterdam 업그레이드를 준비해 나갑니다.

1. EIP-7732

• 개념: enshrined Proposer-Builder Separation (ePBS).
• 목적: 블록 제안자(Proposer)와 블록 빌더(Builder)의 역할을 프로토콜 레벨에서 분리.
• 배경: 현재는 MEV-Boost 같은 외부 소프트웨어를 통해 PBS가 운영되고 있음. 이는 중앙화 위험과 복잡성을 초래할 수 있음.
• 의의: ePBS는 이를 Ethereum 프로토콜에 직접 통합해, 더 안정적이고 표준화된 방식으로 PBS를 지원하려는 제안.

2 . EIP-7928

• 개념: 블록 단위로 어떤 상태(state)와 계정(account)이 접근되는지를 명시하는 리스트를 추가.
• 목적:
• 클라이언트가 미리 어떤 상태를 로드해야 하는지 알 수 있어 성능 최적화 가능.
• 병렬 실행(parallel execution) 및 데이터 접근 효율화 지원.
• 블록 감사(audit)와 분석에도 활용 가치가 있음.
• 현재 논의: state-read 포함 여부, RLP vs SSZ 인코딩, system contract 처리 방식 등이 조율 중.

3. EIP-7702 (FOCIL)

• 개념: 기존 EOA(Externally Owned Account)를 스마트 컨트랙트처럼 동작하게 만드는 새로운 account abstraction 제안.
• 목적:
• 지갑 업그레이드 가능성 제공
• 사용자가 EOA를 계약 계정처럼 활용할 수 있게 하여 계정 추상화(account abstraction)를 단순화.
• 현황: 아직 CFI 상태. ePBS와 BALs가 안정화된 뒤 Glamsterdam 포함 여부 결정 예정.

4. EIP-7778 (6-second slots)

• 개념: 현재 12초인 슬롯 타임(slot time)을 6초로 줄이는 제안.
• 목적: 블록 시간 단축으로 거래 확정(latency) 개선.
• 문제점:
• Execution Layer에서 BALs와의 복잡성 증가.
• 네트워크 및 클라이언트 성능 요구사항 급증.
• 결론: Glamsterdam에서는 제외되었음.