ACDE #234 결과 — Engine API SSZ 통합 제안·History Pruning 표준화 논의 · PQTS Breakout #6 (4/15) · PQ Interop #34 Devnet 로드맵 플래닝 (4/22) · EIP-8189 RLP·GetBlockAccessLists 업데이트 · 신규 클라이언트 릴리즈 없음

핵심 요약

• HIGH ACDE #234 결과 — SSZ Engine API 통합 제안·History Pruning 표준화 논의 시작.

어제(4/9) 개최된 ACDE #234에서 SSZ(Simple Serialize) 기반 Engine API 통합 제안과 History Pruning(히스토리 데이터 정리) 표준화 논의가 주요 의제로 다뤄졌다. SSZ Engine API 통합은 현재 JSON 기반 Engine API 페이로드를 SSZ 인코딩으로 전환하는 방향으로, 직렬화 성능과 EL-CL 인터페이스 효율을 개선하는 것이 목표다. 이 변경은 EL·CL 클라이언트 양측의 Engine API 처리 코드에 영향을 주므로, 구현이 확정될 경우 EL-CL 쌍의 동기화된 업그레이드가 필수다. History Pruning 표준화는 EIP-4444 방향성의 연장선으로, 노드 운영자의 디스크 요구사항 감소와 연결된다.

• HIGH EIP-8189 업데이트 — RLP empty str placeholder 도입·GetBlockAccessLists bytes 파라미터 추가.

어제 EIP-8189(GetBlockAccessLists, Block-Level Access List 조회 Engine API 메서드) 스펙에 두 가지 변경이 반영됐다. (1) RLP empty string placeholder 도입으로 접근 목록(access list) 항목의 빈 값 표현 방식이 명시적으로 정의됐고, (2) GetBlockAccessLists 메서드에 bytes 파라미터가 추가됐다. 이 변경은 BAL(Block-Level Access Lists, EIP-7928) devnet 구현에 직접 영향을 주며, 해당 Engine API 메서드를 구현 중인 EL·CL 클라이언트 팀은 스펙 최신 버전을 반드시 반영해야 한다.

• MEDIUM PQTS Breakout #6 (4/15 13:00 UTC) · PQ Interop #34 Devnet 로드맵 플래닝 (4/22) — PQ 전환 인프라 일정 구체화.

4월 15일 13:00 UTC에 PQTS(Post-Quantum Transaction Signature) Breakout #6이 예정돼 있다. 60분 콜로, 포스트 퀀텀 트랜잭션 서명 체계의 구현 현황 및 스펙 논의가 이뤄질 전망이다. 이와 별개로, 4월 22일 14:00 UTC에는 PQ Interop 전용 Devnet 로드맵 플래닝 세션이 예정돼 있어 Devnet-3 이후 단계 우선순위와 클라이언트별 구현 일정이 구체화될 전망이다. 두 콜이 같은 주에 열리며 PQ 전환 로드맵의 핵심 분기점 역할을 한다.

• MEDIUM Separator-Based PQ Attestation Aggregation — leanXMSS 기반 집계 아키텍처 제안.

ethresear.ch에 "Separator-Based Participation Commitments for PQ Attestation Aggregation" 제안이 게시됐다. leanXMSS 해시 기반 서명과 proof 기반 집계를 결합하는 구조로, PQ 전환 시 attestation 집계 효율을 유지하기 위한 구체적 메커니즘을 제시한다. 현재 PQ Interop Devnet-3(aggregator role separation + subnet aggregation) 단계와 직접 연관되며, 4/15 PQTS Breakout #6과 4/22 로드맵 플래닝 세션에서 논의될 가능성이 있다.

• MEDIUM EIP-8007 업데이트 — EIP-7976·EIP-7981 최신 드래프트 동기화.

EIP-8007(복합 EIP 메타)의 설명이 최신 EIP-7976·EIP-7981 드래프트와 동기화됐다. EIP-7976은 EL-CL 클라이언트 간 통신 프로토콜 관련 사항을, EIP-7981은 실행 환경 관련 사항을 다룬다. 이번 동기화 커밋은 스펙 정합성 유지 성격이며, 해당 EIP를 구현 참조로 사용하는 클라이언트 팀은 최신 드래프트와의 정합성을 재확인해야 한다.

• MEDIUM EIP-8070 업데이트 — per-request column cap 제거 (PeerDAS 관련).

EIP-8070(PeerDAS 데이터 가용성 요청)에서 per-request column cap(요청당 컬럼 수 상한) 조항이 삭제됐다. 이는 EIP-7594(PeerDAS) 구현에서 데이터 샘플링 요청의 유연성을 높이는 방향이다. blob-devnet-0 준비 과정에서 PeerDAS 네트워크 레이어 구현 팀은 이 변경 사항을 반영해야 한다.

• LOW EIP-8175 업데이트 — TX_GAS_LIMIT opcode 추가.

EIP-8175에 TX_GAS_LIMIT opcode가 추가됐다. 트랜잭션의 가스 한도(gas limit)를 EVM 실행 중 직접 조회할 수 있는 새 opcode다. 현재 초안(Draft) 단계이며 메인넷 적용 일정은 미정이다. EVM 구현 팀의 장기 구현 계획에 포함할 사항으로 모니터링하면 된다.

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

오늘 신규 클라이언트 릴리즈는 확인되지 않았다. Geth v1.17.2(2026-03-30) 및 Lighthouse v8.1.3(2026-03-26)의 즉시 업그레이드 권고는 계속 유효하다.

상세 분석

1. ACDE #234 결과 — SSZ Engine API 통합·History Pruning 표준화

출처: ACDE #234, April 9, 2026 — ethereum/pm issue #2004

어제(4/9) 14:00 UTC에 개최된 ACDE #234의 인프라 관련 핵심 논의를 정리한다.

SSZ Engine API 통합 제안

현재 Engine API는 JSON 형식으로 execution payload와 blob sidecar 등을 EL-CL 간에 주고받는다. SSZ Engine API 통합 제안은 이 직렬화 방식을 SSZ(Simple Serialize)로 전환하는 것이다.

Breaking Change 가능성: SSZ Engine API 전환이 확정될 경우, EL과 CL 클라이언트의 Engine API 처리 코드 전반을 수정해야 한다. EL-CL 쌍을 운영하는 노드 운영자는 두 클라이언트를 반드시 동시에 업그레이드해야 하며, 단일 클라이언트만 업그레이드할 경우 EL-CL 통신 불능으로 노드가 정지한다. 콜 노트 게시 이후 확정 여부와 구현 일정을 추가 확인해야 한다.

History Pruning 표준화

History Pruning은 노드가 오래된 블록 히스토리 데이터를 로컬에서 삭제하는 기능이다. EIP-4444(Bound Historical Data in Execution Clients)의 방향성을 따르며, 클라이언트별로 구현 방식이 달라 상호운용성 및 네트워크 데이터 가용성 유지에 문제가 있었다. 표준화가 완료되면 노드 운영자의 디스크 요구사항이 장기적으로 감소할 수 있다.

현재 프루닝 지원 현황:

• Geth: v1.17.2에서 pre-Prague 체인 히스토리 pruning 지원
• Besu: 26.x 계열 chain pruning CLI 재설계 포함
• 기타 클라이언트: 지원 수준 상이 — 표준화 논의 결과 확인 필요

2. EIP-8189 — RLP empty str placeholder·GetBlockAccessLists bytes 파라미터

출처: Update EIP-8189 — ethereum/EIPs commit 3c8f89d

EIP-8189는 Block-Level Access Lists(BAL, EIP-7928)를 Engine API를 통해 조회하는 GetBlockAccessLists 메서드를 정의한다. 이번 커밋에서 두 가지 스펙 변경이 반영됐다.

변경 1 — RLP empty string placeholder 도입

Access list 항목에서 빈 값(empty value)의 RLP 인코딩 방식을 명시적으로 정의했다. 기존 스펙에서 빈 값 처리가 모호했던 부분을 해소하는 변경으로, 클라이언트 간 동작 불일치를 방지한다.

변경 2 — GetBlockAccessLists에 bytes 파라미터 추가

GetBlockAccessLists 메서드 시그니처에 bytes 파라미터가 추가됐다. 이는 요청 시 반환 형식이나 필터 조건을 bytes 형태로 전달할 수 있도록 하는 확장이다.

구현 영향: BAL devnet(bal-devnet-3·4)에 참여 중인 EL 클라이언트(Geth, Besu, Nethermind, Erigon)는 이번 스펙 변경을 즉시 반영해야 한다. 특히 Besu의 EIP-8037 재구현 공백(PR #9994 Stale Closed)이 지속되는 상황에서, EIP-8189 스펙 변경이 Besu 재구현 PR에 누적 적용되어야 하는 점에 주의가 필요하다.

3. PQTS Breakout #6 (4/15) · PQ Interop #34 Devnet 로드맵 플래닝 (4/22)

출처: PQTS Breakout #6 — Ethereum Magicians · PQ Interop #34 — Ethereum Magicians

PQTS Breakout #6 (4/15 13:00 UTC, 60분)

PQTS(Post-Quantum Transaction Signature, 포스트 퀀텀 트랜잭션 서명) 브레이크아웃 6번째 콜이다. PQTS는 ECDSA 기반 트랜잭션 서명을 포스트 퀀텀 안전 알고리즘(예: CRYSTALS-Dilithium, SPHINCS+)으로 교체하는 작업을 다룬다. CL의 PQ 서명 전환(PQ Interop)과 별도로 EL의 트랜잭션 서명 체계 전환을 다루는 워크스트림이다.

EL 클라이언트 관점에서 PQTS 전환은 다음 구성요소에 영향을 준다.

• 트랜잭션 서명 검증 로직 (EL 코어)
• mempool 구조 (PQ 서명 크기 증가 — ECDSA 64 bytes → PQ 알고리즘 1~2 KB 수준)
• P2P 트랜잭션 전파 대역폭 요구사항 변화

PQ Interop #34 4/22 Devnet 로드맵 플래닝 세션

4월 8일 개최된 PQ Interop #34에서 4월 22일 14:00 UTC에 특별 Devnet 로드맵 플래닝 세션을 개최하기로 예고됐다. 이 세션에서는 현재 진행 중인 Devnet-3(aggregator role separation + subnet aggregation) 이후 단계의 구현 우선순위와 클라이언트별 타임라인이 구체화된다.

4/22 플래닝 세션은 Devnet-3 이후의 일정과 참여 클라이언트 팀 확정이 핵심 목표다. EF는 L1 프로토콜 변경 완료 목표를 2029년으로 공식화하고 있으며, 각 단계별 구체 일정은 이 세션에서 초안이 제시될 전망이다.

4. Separator-Based PQ Attestation Aggregation — 기술 분석

출처: Separator-Based Participation Commitments for PQ Attestation Aggregation — ethresear.ch

어제(4/9) ethresear.ch에 게시된 이 제안은 현재 PQ Interop Devnet-3 단계(subnet aggregation)의 핵심 문제를 다룬다.

문제: leanXMSS 등 해시 기반 PQ 서명은 검증자별 서명 크기가 ECDSA 대비 수십 배 크다. 현재 BLS 기반 서명 집계 방식으로는 수만 명의 검증자 서명을 효율적으로 집계할 수 없어 PQ 전환 후 attestation 집계 레이어가 병목이 된다.

제안: "separator" 개념을 도입하여 검증자 참여(participation) 정보를 commitment 형태로 압축하고, proof 기반 집계와 결합하는 방식이다. 이 방식은 집계자(aggregator) 수를 줄이고 재귀 집계(recursive aggregation)를 효율적으로 구현하는 데 기여한다.

인프라 관점: 이 방식이 채택될 경우 CL 클라이언트의 attestation gossip sub-protocol과 aggregation 로직에 근본적인 변경이 필요하다. 단기 적용 가능성은 낮으나 4/22 로드맵 플래닝 세션 및 4/15 PQTS Breakout #6에서 참조될 가능성이 높다.

5. EIP 스펙 업데이트 (4/9)

출처: Update EIP-8007 · Update EIP-8175 · Update EIP-8070

EIP-8070 column cap 제거 상세: per-request column cap은 단일 PeerDAS 데이터 요청에서 가져올 수 있는 최대 컬럼 수를 제한하는 조항이었다. 이 제한을 제거하면 네트워크 요청 효율이 높아지지만, 악의적 피어가 과도한 데이터를 요청하는 시나리오에 대한 별도 보호 메커니즘이 필요하다. blob-devnet-0 참여 클라이언트(Lighthouse, Prysm 등)는 이 변경을 구현에 반영해야 한다.

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

출처: Geth Releases · Lighthouse Releases · Besu Releases

오늘 신규 클라이언트 릴리즈는 확인되지 않았다.

Besu EIP-8037 공백 상태 지속: Besu PR #9994(Stale Closed, 4/7)가 재개설되지 않은 것으로 보인다. ACDE #234 결과에서 Besu 측 재구현 계획이 공유됐는지 콜 노트 게시 후 확인이 필요하다. Besu EIP-8037 수정 미완료 상태가 지속될 경우 bal-devnet-3·4 진행이 계속 차단된다.

7. 이전 분석 대비 변화

[어제(4/8) 대비 업데이트 사항]

노드 운영자 액션 아이템