proposer lookahead는 왜 프리컨펌 UX보다 먼저 합의 상태 문제일까: EIP-7917로 보는 예측 가능한 제안자 일정

• 카테고리: blockchain_dev
• 예상 읽기 시간: 10분
• 오늘의 질문: 빠른 체감 확정을 만들려면 왜 “다음 블록 제안자가 누구인지”를 앱이 믿을 수 있는 상태로 만들어야 할까?
• 핵심 출처:
  • EIP-7917: Deterministic proposer lookahead - 생성일 2025-03-24, 확인일 2026-07-21
  • EIP-7607: Hardfork Meta - Fusaka - 생성일 2024-02-19, 확인일 2026-07-21
  • Fulu-Osaka (Fusaka) | ethereum.org - 최종 업데이트 2026-06-24, 확인일 2026-07-21
  • ethereum/consensus-specs PR #4190: EIP-7917 Deterministic proposer lookahead - 병합 2025-06-03, 확인일 2026-07-21
  • Ethereum Magicians: EIP-7917 discussion - 시작 2025-03-25, 확인일 2026-07-21

1. 왜 지금 봐야 하나

Ethereum Fusaka를 볼 때 개발자 눈에는 PeerDAS, blob, gas cap, P-256 precompile 같은 변화가 먼저 들어온다. 그런데 EIP-7917 Deterministic proposer lookahead는 겉으로는 더 작아 보이지만, 앞으로의 L2와 지갑 UX에서 중요한 질문을 건드린다.

사용자가 “곧 포함될 것”이라는 약속을 받을 때, 그 약속은 누구의 권한과 어떤 상태를 근거로 해야 할까?

프리컨펌(preconfirmation)은 사용자가 최종 블록 확정까지 기다리기 전에 “이 트랜잭션을 다음 내 블록에 넣겠다”는 약속을 받는 구조다. 특히 based rollup이나 native rollup 논의에서는 Ethereum L1 proposer가 L2 트랜잭션 포함 순서나 포함 여부에 대한 빠른 신호를 줄 수 있기를 기대한다. 하지만 이 구조가 작동하려면 최소한 다음 epoch의 proposer schedule이 안정적으로 알려져 있어야 한다.

EIP-7917은 이 문제를 합의 계층 상태로 끌어올린다. 매 epoch 시작 시점에 beacon_state 안에 앞으로 보이는 proposer 목록을 미리 계산해 저장한다. 핵심은 “다음 proposer를 빨리 계산한다”가 아니라, 앱과 프로토콜이 증명 가능한 상태를 기준으로 미래 권한자를 식별할 수 있게 만든다는 점이다.

2. 핵심 개념

Beacon Chain에서 block proposer는 slot마다 블록을 제안할 validator다. 기존에도 RANDAO seed 덕분에 미래 proposer를 어느 정도 예측할 수 있었다. 하지만 EIP-7917이 지적한 문제는 “seed는 알지만, proposer 선택에 들어가는 effective balance가 epoch 중에 바뀔 수 있다”는 점이다.

간단히 나누면 이렇다.

1. RANDAO seed: 무작위성의 입력이다. Ethereum 합의에서 proposer와 committee 선정에 쓰인다.
2. effective balance(EB): validator의 선택 가중치에 들어가는 잔액 표현이다.
3. proposer schedule: 특정 slot에 어느 validator가 proposer인지 나타내는 결과다.

문제는 epoch N 중에 slashing, penalty, reward 누적, deposit, consolidation 같은 이벤트가 effective balance를 바꿀 수 있고, 그 결과 epoch N+1의 proposer 계산 결과가 미묘하게 달라질 수 있다는 것이다. EIP-7917과 consensus-specs PR #4190은 EIP-7251로 validator의 최대 effective balance가 32 ETH보다 커진 뒤 이런 edge case가 더 중요해졌다고 설명한다.

EIP-7917의 해법은 BeaconState에 다음과 같은 필드를 추가하는 것이다.

proposer_lookahead: Vector[ValidatorIndex, (MIN_SEED_LOOKAHEAD + 1) * SLOTS_PER_EPOCH]

이 벡터는 현재 epoch부터 MIN_SEED_LOOKAHEAD만큼 앞으로 보이는 proposer index를 담는다. 그리고 get_beacon_proposer_index는 매번 즉석 계산을 하지 않고 state.proposer_lookahead[state.slot % SLOTS_PER_EPOCH]를 읽을 수 있다.

더 중요한 변화는 epoch boundary 처리다. 새 epoch가 시작되면 이전 epoch 분량을 밀어내고, 새로 보이게 된 미래 epoch의 proposer 목록을 계산해 뒤에 붙인다. 이때 lookahead의 RANDAO delay는 유지하지만 effective balance 기준 시점을 더 앞당겨 RANDAO와 맞춘다. 그래서 validator가 RANDAO 결과를 본 뒤 effective balance를 조정해 다음 proposer schedule을 흔드는 분석 영역을 줄인다.

3. 최신 이슈와 연결

EIP-7607은 EIP-7917을 Fusaka의 Core EIP 중 하나로 포함한다. 같은 Fusaka 묶음에는 PeerDAS, transaction gas cap, MODEXP 제한과 repricing, blob base fee reserve, RLP execution block size limit, CLZ opcode, P-256 precompile 등이 같이 들어 있다. 이 조합을 보면 Fusaka의 방향은 단순한 성능 개선이 아니라 “자원 경계와 미래 상태를 더 명시적으로 만들기”에 가깝다.

ethereum.org Fusaka 페이지도 EIP-7917을 UX 개선 항목으로 설명한다. Beacon Chain이 앞으로의 block proposer를 알 수 있게 되면 based preconfirmation 같은 구조가 가능해지고, validator duty 모니터링도 더 명확해진다는 취지다.

GitHub ethereum/consensus-specs PR #4190은 더 구현적인 맥락을 보여준다. 이 PR은 Fulu target으로 병합되었고, proposer lookahead를 beacon state에 저장하고 테스트와 fork boundary 동작을 추가했다. PR 설명에서 특히 중요한 부분은 “proposer lookahead가 beacon state에 들어가면 beacon root와 Merkle proof로 EVM 안에서도 조회할 수 있다”는 점이다. 즉 EIP-7917은 합의 클라이언트 내부 최적화만이 아니라, 스마트컨트랙트가 future proposer에 대한 증명을 검증하는 설계 재료가 된다.

Ethereum Magicians 논의에서는 현실적인 질문도 나왔다. 예를 들어 effective balance 변화로 실제 proposer가 달라질 확률이 매우 낮다면 굳이 프로토콜을 바꿀 필요가 있느냐는 의문이다. 이에 대한 핵심 반론은 preconfirmation protocol에서는 “낮은 확률”도 설계 복잡도를 남긴다는 것이다. 사용자에게 빠른 포함 약속을 팔려면, 예외가 드물다는 설명보다 예외를 상태 규칙에서 제거하는 편이 낫다.

4. 개발자 관점 해석

EIP-7917을 개발자가 배워야 하는 이유는 프리컨펌이라는 유행어 때문만은 아니다. 더 일반적인 원리는 다음이다.

권한을 미리 위임하거나 약속하려면, 미래 권한자 목록이 재현 가능하고 증명 가능해야 한다.

웹앱으로 비유하면 “내일 배포 승인자가 누군지 대충 Slack에서 알 수 있다”와 “승인자 목록이 DB에 고정되고 서명 검증으로 확인된다”는 전혀 다르다. 전자는 운영 관행이고, 후자는 프로토콜이다. 블록체인에서는 이 차이가 더 커진다. 왜냐하면 잘못된 proposer에게 받은 preconfirmation은 사용자에게 빠른 UX를 주는 것이 아니라 잘못된 신뢰를 주는 일이 되기 때문이다.

개발자가 봐야 할 포인트는 네 가지다.

첫째, 프리컨펌은 finality가 아니다. proposer가 “내 블록에 넣겠다”고 약속해도 그것은 합의 finality와 다르다. slot이 missed 될 수 있고, proposer가 약속을 어길 수 있고, reorg와 fork choice 문제가 남는다. EIP-7917은 “누가 약속할 권한이 있는가”를 더 안정화할 뿐, 약속 불이행의 경제적 페널티나 사용자 보상 규칙까지 정의하지 않는다.

둘째, 상태에 들어간다는 것은 증명 가능해진다는 뜻이다. proposer lookahead가 beacon state에 있으면 light client, bridge, rollup contract, preconf contract가 beacon root 기반 Merkle proof를 통해 해당 proposer 목록을 검증하는 설계를 할 수 있다. 물론 실제 제품에서는 proof cost, beacon root 접근 방식, chain별 precompile/contract 지원, stale proof 처리까지 따져야 한다.

셋째, 낮은 확률의 비결정성도 프로토콜 경계에서는 부채다. 앱 레벨에서는 “가끔 실패하면 retry”가 가능하지만, 포함 약속을 거래 UX나 결제 UX에 붙이면 예외 케이스가 바로 사용자 손실과 dispute로 이어질 수 있다. EIP-7917은 rare edge case를 없애서 상위 프로토콜의 예외 처리를 단순하게 만든다.

넷째, future proposer를 안다는 것은 MEV·검열·사전 거래 시장과도 연결된다. 미래 proposer schedule이 더 명확해지면 preconfirmation 시장은 만들기 쉬워진다. 동시에 특정 proposer에게 orderflow가 집중되거나, proposer가 오프체인 약속 시장에서 과도한 권한을 가질 위험도 커진다. 따라서 제품 개발자는 빠른 UX만 보지 말고 slashing, collateral, monitoring, fallback, censorship handling을 같이 설계해야 한다.

5. 내 프로젝트에 적용할 체크포인트

preconfirmation, rollup sequencing, bridge, wallet UX, validator monitoring을 다루는 팀이라면 아래를 점검해보자.

• 내 시스템은 “미래 proposer”를 어디서 얻는가? 로컬 CL API, indexer, beacon root proof, 제3자 relayer 중 무엇인가?
• proposer schedule이 바뀌거나 slot이 missed 되었을 때 사용자에게 어떤 상태를 보여주는가? confirmed, preconfirmed, included, finalized를 구분하는가?
• preconfirmation을 finality처럼 표현하지 않는가? UI 문구와 API 필드에 soft commitment와 finality 차이가 남아 있는가?
• proposer의 약속 불이행을 어떻게 탐지하는가? block contents, missed slot, delayed inclusion, conflicting promise를 별도 이벤트로 기록하는가?
• EVM에서 proposer lookahead proof를 검증해야 한다면 beacon root freshness, Merkle proof path, gas cost, chain별 지원 상태를 계산했는가?
• based rollup이나 shared sequencing을 검토한다면, proposer 권한과 L2 sequencer 권한이 어디서 만나는지 threat model에 적었는가?
• private orderflow, MEV auction, preconf market이 붙을 때 사용자 트랜잭션이 특정 proposer에게 과도하게 노출되는 경로를 점검했는가?

6. 오늘 10분 액션

오늘 바로 할 수 있는 작은 실험은 “내가 쓰는 explorer/API가 proposer schedule을 어떻게 보여주는지 확인하기”다.

1. beaconcha.in, beacon node API, 또는 내가 운영하는 consensus client에서 현재 epoch와 다음 epoch proposer 목록을 확인한다.
2. 같은 slot에 대해 proposed, missed, orphaned 같은 상태가 어떻게 표시되는지 본다.
3. 내 앱의 트랜잭션 상태 모델에 submitted → preconfirmed → included → finalized 같은 중간 상태가 필요한지 적어본다.
4. 만약 L2나 bridge를 만들고 있다면 “이 상태는 L1 finality인가, sequencer promise인가, proposer promise인가?”를 API 응답 필드 옆에 주석으로 붙여본다.

10분 안에 코드를 바꾸지 않아도 된다. 오늘의 목표는 “빠른 확정처럼 보이는 UX” 뒤에 여러 단계의 신뢰 상태가 있다는 것을 분리해서 보는 것이다.

7. 더 볼 자료

• EIP-7917: Deterministic proposer lookahead
• EIP-7607: Hardfork Meta - Fusaka
• Fulu-Osaka (Fusaka) | ethereum.org
• ethereum/consensus-specs PR #4190
• Ethereum Magicians: EIP-7917 discussion

중복 회피 메모

로컬 content/generated와 Supabase의 최근 blockchain_dev 글을 확인했다. 최근 글은 EIP-7939 CLZ opcode, EIP-7907 contract code size gas, Solana Alpenglow finality, Taiko bridge message-origin verification, OP Stack fault proof soundness, ERC-4626 NAV manipulation, P-256/passkey precompile, MODEXP repricing, EIP-7825 transaction gas cap, PeerDAS/blob fee reserve, ePBS를 다뤘다. 이번 글은 gas/DA/bridge/프리컴파일/MEV-Boost 구조가 아니라 EIP-7917을 통해 “미래 proposer 권한을 합의 상태에 저장하고 증명 가능하게 만드는 이유”에 집중해 중복을 피했다.