Checkpoint #10 — Forkcast 5종 변동(EIP-6110 Pectra Included 제거·EIP-5920·6206·6404 Declined 확정) · EIP-8164 Ed25519→ML-DSA-44 교체 · DAS Reed-Solomon 대안 연구 · ACDE #235(4/23) 예고

주말(토요일) 업데이트. 신규 프로토콜 콜 없음. Forkcast 변동 5건 집중 분석 및 EIP 사양 업데이트 추적.

핵심 요약

• HIGH EIP-6110 Pectra Included 제거 — 공급자 검증 온체인화 상태 재조정.

4/12 Forkcast 데이터에서 EIP-6110(Supply validator deposits on chain)의 Pectra included 상태가 제거됐다. 4/11 기준 included: [2537, 2935, 6110]이었던 Pectra 요약이 included: [2537, 2935]로 줄어들었다. Pectra에서 이미 활성화된 EIP임을 감안하면 이는 forkcast 데이터 정제(소급 수정) 가능성이 높으나, 향후 ACDE #235(4/23)에서 공식 확인이 필요하다. 운영자는 EIP-6110 기능 자체의 비활성화가 아님을 확인해야 한다.

• HIGH EIP-8164 서명 알고리즘 Ed25519 → ML-DSA-44(FIPS 204) 교체 — PQ 표준 사양 수렴.

EIP-8164(계정 추상화 관련 PQ 서명) 초안이 4/11 커밋 3건을 통해 서명 알고리즘을 Ed25519에서 ML-DSA-44(FIPS 204, CRYSTALS-Dilithium 기반)로 전면 교체했다. ML-DSA-44는 NIST FIPS 204로 표준화된 격자 기반 디지털 서명 알고리즘으로, harvest-now-decrypt-later 공격에 대한 저항성을 갖춘다. 동일 날 EIP-7932(공개키/서명 분리) 업데이트도 병행되어, CL 및 EL PQ 전환 사양이 동시에 수렴하는 흐름이 감지된다. 4/15 PQ 콜 두 건과 연동해 모니터링이 필요하다.

• MEDIUM Forkcast Declined 4건 확정 — EIP-5920(PAY opcode)·6206(EOF-JUMPF)·6404(SSZ transactions) 탈락.

4/12 기준 Glamsterdam에서 EIP-5920(PAY opcode), EIP-6404(SSZ transactions)가, Fusaka·Pectra에서 EIP-6206(EOF - JUMPF and non-returning functions)이 Declined로 확정됐다. 특히 EIP-6206은 Pectra와 Fusaka 양쪽에서 동시 탈락 처리되어, EOF 번들의 추가 분해가 진행 중임을 시사한다. EIP-5920(PAY opcode)은 Glamsterdam/Fusaka 양쪽에서 Declined로, 별도 opcode 추가보다 기존 메커니즘 활용을 선호하는 방향이 반영됐다.

• MEDIUM DAS 2D Reed-Solomon 대안 연구 — ESP Grant FY24-1745, Dankrad Feist 공동 저술.

ethresear.ch에 2D Reed-Solomon 코드의 대안을 탐색하는 DAS(EIP-4844 이후 EIP-7594 PeerDAS 관련) 연구 논문이 공개됐다(4/11, Emanuele Viterbo·Dankrad Feist·ESP Grant FY24-1745). 기존 2D RS 코드 대비 재구성 효율·증명 크기·네트워크 오버헤드 관점의 대안 코딩 체계를 분석한다. PeerDAS devnet 실운영을 앞두고 인코딩 레이어 최적화 연구가 심화되고 있음을 보여주며, 클라이언트 구현 팀의 장기 로드맵에 영향을 미칠 수 있다.

• MEDIUM ACDE #235(4/23 14:00 UTC) 의제 — Glamsterdam + Hegotá 병렬 논의.

4/11에 ACDE #235 공식 예고가 게시됐다(90분, GitHub Issue 별도). 의제는 Glamsterdam과 Hegotá 두 업그레이드의 현황으로, ePBS(EIP-7732) 지연 현황 업데이트와 Hegotá non-headlining feature 선정 논의가 핵심이 될 것으로 예상된다. Glamsterdam devnet 타임라인 재조정이 이 콜에서 공식 수치로 제시될 가능성이 높다.

• MEDIUM EIP-7932 공개키/서명 분리(public key / signature separation) 지원 추가 — 다중 서명 체계 확장성.

EIP-7932(Account Abstraction 관련 서명 추상화 제안) 초안에 공개키와 서명을 별도 필드로 분리하는 지원이 4/11 커밋으로 추가됐다. 이는 단일 서명 알고리즘 의존에서 벗어나 다중 PQ 알고리즘 또는 멀티시그 체계를 동일 계정 구조 내에서 유연하게 처리할 수 있도록 하는 설계 변경이다. EIP-8164 ML-DSA-44 교체와 방향성이 일치한다.

• LOW EIP-8223 Contract Payer Transactions — sponsored transaction 새 EIP.

EIP-8223이 새로 게시됐다(4/11). EIP-2718 타입 트랜잭션 봉투(Typed Transaction Envelope)를 활용해 가스비를 실행자(sender)가 아닌 별도 컨트랙트 페이어(contract payer)에게 부과하는 스폰서드 트랜잭션 구조다. 계정 추상화 방향과 부분적으로 겹치나 독립적인 EIP로 제안됐다. 단기 인프라 영향 없음, 진행 추적 필요.

• LOW 신규 클라이언트 릴리즈 없음 — Geth v1.17.2·Lighthouse v8.1.3 즉시 업그레이드 권고 유효.

주말 기준 신규 클라이언트 릴리즈 없음 확인. Geth v1.17.2(2026-03-30) 및 Lighthouse v8.1.3(2026-03-26) 즉시 업그레이드 권고는 계속 유효하다.

상세 분석

1. Forkcast 변동 — 5건 상태 변화 (4/11 → 4/12)

출처: EIP Upgrade Snapshot (forkcast 데이터, 2026-04-12)

변동 상세

EIP-6110 Pectra Included 제거 분석

EIP-6110은 Pectra 업그레이드에서 이미 활성화되어 실운영 중인 EIP(Prague/Electra 하드포크 구성 요소 중 하나)다. forkcast의 Pectra included 목록에서 6110이 제거된 것은 두 가지 해석이 가능하다.

1. 데이터 정제(소급 수정): forkcast 운영 측이 "이미 활성화된 Pectra EIP"를 추적 대상 범위에서 분리하는 방식으로 데이터 구조를 조정한 것
2. 상태 재분류: 이미 배포된 업그레이드의 EIP를 별도 섹션으로 이동

어느 쪽이든 EIP-6110 기능 자체의 비활성화는 아니다. ACDE #235(4/23)에서 Pectra 현황 업데이트가 있을 경우 맥락이 확인될 예정이다.

EOF 번들 분해 흐름 — EIP-6206 양쪽 탈락

EIP-6206(EOF - JUMPF)이 Pectra와 Fusaka 양쪽에서 Declined 처리됐다. EOF(EVM Object Format) 번들은 EIP-3540, 3670, 4200, 4750, 5450 등 다수 EIP로 구성되어 있었는데, 이들 대부분이 이미 Pectra/Fusaka에서 Declined 상태다. 4/12 기준 두 업그레이드에서 EOF 관련으로 Declined된 EIP 목록:

EOF 번들 전체가 현재 업그레이드 경로에서 제외된 상태로, 향후 별도 번들 형태의 재제안 또는 단독 Considered 절차가 필요할 것으로 보인다.

2. EIP-8164 ML-DSA-44(FIPS 204) 교체 — PQ 표준 사양 수렴

출처: EIP-8164 커밋: Replace Ed25519 with ML-DSA-44

4/11에 EIP-8164 초안에 커밋 3건이 연속 제출됐다.

ML-DSA-44 (FIPS 204) 개요

Ed25519에서 ML-DSA-44로의 교체는 양자 컴퓨터 위협에 대한 선제적 대응으로, EIP-8164가 실제 표준화 완료된 NIST 알고리즘으로 수렴함을 의미한다. 다만 서명 크기가 수십 배 증가하는 특성상 트랜잭션 사이즈 및 블록 공간 효율 문제가 향후 EIP 논의의 쟁점이 될 수 있다.

EIP-7932 공개키/서명 분리 연동

동일 날(4/11) EIP-7932에 공개키와 서명 필드를 분리하는 지원이 추가됐다. EIP-8164(PQ 서명 알고리즘)와 EIP-7932(서명 추상화)는 상호 보완적인 방향으로 진화하고 있다.

• EIP-7932: 어떤 알고리즘의 서명이든 공통 구조로 처리
• EIP-8164: ML-DSA-44 등 특정 PQ 알고리즘 사양 정의

두 EIP가 함께 채택될 경우 이더리움 계정이 미래에 PQ 알고리즘으로 전환하는 경로가 마련된다.

3. DAS 2D Reed-Solomon 대안 연구

출처: Alternatives to 2D Reed-Solomon Codes in DAS — ethresear.ch

Emanuele Viterbo, Dankrad Feist가 공동 저술하고 ESP Grant FY24-1745로 지원받은 DAS 코딩 개선 연구가 ethresear.ch에 공개됐다(4/11).

연구 배경

EIP-4844(Proto-Danksharding) 및 EIP-7594(PeerDAS)는 블롭(blob) 데이터 가용성 검증에 2D Reed-Solomon(RS) 코드를 활용한다. 2D RS는 행·열 방향 양방향 erasure coding을 통해 일부 샘플만으로 전체 데이터 가용성을 증명하는 구조다.

연구 핵심 주제

현재 2D RS 코드 대비 아래 측면에서 대안 코딩 체계를 분석한다.

인프라 관점 영향

단기 클라이언트 구현 변경은 없다. 그러나 PeerDAS(EIP-7594)가 Fusaka 업그레이드 후보로 논의되고 있는 상황에서, 인코딩 레이어의 알고리즘 선택은 CL/EL 클라이언트 구현 팀이 장기 설계에서 고려해야 할 기술적 선택지다. Dankrad Feist가 직접 공동 저술에 참여한 점에서 EF 연구 방향성과 연계된 작업임을 시사한다.

4. ACDE #235 (4/23 14:00 UTC) — Glamsterdam + Hegotá

출처: ACDE #235 — Ethereum Magicians

4월 11일에 ACDE #235 공식 예고 스레드가 게시됐다.

예상 주요 논의 항목

• ePBS(EIP-7732) devnet 현황 업데이트 — 복잡도 수준 및 수정된 타임라인 제시 여부
• BAL(EIP-7928) 구현 진행 상황 — Besu EIP-8037 재구현 차단 지속 여부
• Hegotá non-headlining feature CFI 목록 확정 — FOCIL(EIP-7805)과 함께 포함될 feature 결정
• PQ 관련 EIP(8164, 7932) 인클루전 논의 가능성

이 콜 이전인 4/15(PQ Interop #35 + PQTS Breakout #6)과 4/22(PQ Devnet 로드맵 플래닝)의 결과가 ACDE #235 의제에 반영될 것이다.

5. EIP-8223 Contract Payer Transactions — 스폰서드 트랜잭션 신규 제안

출처: EIP-8223 — Ethereum Magicians

EIP-2718(Typed Transaction Envelope) 확장 타입으로 가스비를 별도 컨트랙트 페이어에게 전가하는 스폰서드 트랜잭션 구조가 제안됐다.

구조 개요

기존: sender → gas fee + execution
EIP-8223: sender(execution) + contract payer(gas fee) 분리

계정 추상화(EIP-4337, RIP-7560) 방향과 부분적으로 기능이 중복되나, L1 프로토콜 레벨에서 native하게 처리하는 독립 EIP로 제안됐다. 인프라 직접 영향은 없으나, EIP-2718 타입 트랜잭션을 처리하는 EL 클라이언트의 트랜잭션 풀(txpool) 구현에 잠재적 변경이 필요할 수 있다.

6. PQ 준비 현황 (주말 업데이트)

4/15 콜 일정 재확인

EIP-8164(ML-DSA-44 교체)와 EIP-7932(공개키/서명 분리)가 4/11 업데이트된 직후에 이 콜들이 개최되므로, 해당 사양 변경에 대한 구현 피드백이 콜에서 직접 논의될 가능성이 높다.

PQ Devnet 진행 현황 (변동 없음)

7. 클라이언트 버전 현황 (2026-04-12 기준)

신규 클라이언트 릴리즈 없음 (주말).

8. 전일 대비 변화 사항 (4/11 → 4/12)

노드 운영자 액션 아이템

by @r2jamong — 2026-04-12