EIP-7917 결정론적 제안자 미리보기 (Deterministic proposer lookahead)
최종 확정 · 합의·스테이킹 · 원문 상태 Final · 2025-03-24 작성
매 에포크 시작 시점에 현재와 다음 에포크의 블록 제안자 목록을 미리 계산해 비콘 상태에 저장합니다. 다음 에포크에 누가 블록을 제안할지 미리 확정됩니다.
왜 필요한가
이더리움은 에포크(약 6.4분 단위의 시간 구간)마다 무작위 시드인 RANDAO로 블록 제안자를 뽑습니다. 시드 자체는 한 에포크 전에 미리 알 수 있지만 제안자 선출에는 각 검증자의 유효 잔고(effective balance)도 함께 쓰입니다. 그런데 슬래싱이나 페널티가 1 ETH 이상 쌓이면 에포크 도중에 유효 잔고가 바뀔 수 있고 EIP-7251로 최대 유효 잔고가 늘어난 뒤에는 보상 누적, 검증자 통합, 추가 입금으로도 잔고가 32 ETH를 넘어 변할 수 있습니다. 그 결과 다음 에포크의 제안자 일정이 미리 확정되지 않습니다. 제안자가 미리 정해져 있어야 돌아가는 기반(based) 사전확정 프로토콜에는 이것이 걸림돌이고 검증자가 유효 잔고를 일부러 조정해 제안자 일정을 흔들 가능성도 분석하기 까다로운 숙제로 남아 있었습니다. 이 EIP는 제안자 일정을 미리 계산해 상태에 저장하는 방식으로 이 오랜 설계 공백을 메웁니다.
무엇이 바뀌나
지금
- 다음 에포크 제안자 일정이 에포크 도중의 유효 잔고 변화로 바뀔 수 있습니다
- 클라이언트가 매 슬롯 제안자 인덱스를 그때그때 계산합니다
- 애플리케이션 레이어에서 다음 에포크 제안자를 확인할 표준 방법이 없습니다
- 유효 잔고 조작 가능성을 따지는 보안 분석이 복잡한 경우의 수 분석이 됩니다
EIP-7917 이후
- 에포크 시작 시점에 현재와 다음 에포크의 제안자 일정이 비콘 상태에 확정 저장됩니다
- 제안자 인덱스는 저장된 proposer_lookahead에서 바로 읽습니다
- 비콘 루트와 간단한 머클 증명으로 애플리케이션 레이어에서 제안자 일정을 조회할 수 있습니다
- RANDAO 결과를 본 뒤 유효 잔고를 조정하는 공격 경로가 사라져 보안 분석이 단순해집니다
누구에게 영향이 있나
- 사전확정 프로토콜·L2: 제안자 일정이 확정되고 온체인에서 머클 증명으로 검증할 수 있어 기반 사전확정 프로토콜의 온체인 구성 요소 구현이 크게 단순해집니다.
- 합의 클라이언트 팀: 비콘 상태에 proposer_lookahead 필드가 추가되고 매 슬롯 계산 대신 에포크 경계에서 한 에포크 분량의 일정을 계산하도록 로직이 바뀝니다.
- 검증자: 유효 잔고를 조정해 다음 에포크 제안자 일정에 영향을 줄 가능성이 사라지고 자신의 제안 차례를 더 일찍 확정적으로 알 수 있습니다.
심층 설명
proposer_lookahead 필드
BeaconState에 proposer_lookahead: Vector[ValidatorIndex, (MIN_SEED_LOOKAHEAD + 1) * SLOTS_PER_EPOCH] 필드를 추가합니다. 현재 에포크 시작부터 MIN_SEED_LOOKAHEAD 에포크 뒤까지, 보이는 전체 미리보기 구간의 제안자 인덱스를 담습니다. 예를 들어 proposer_lookahead[0]은 현재 에포크 첫 제안자, proposer_lookahead[SLOTS_PER_EPOCH + 4]는 다음 에포크 다섯 번째 제안자의 검증자 인덱스입니다.
get_beacon_proposer_index의 단순화
기존에는 제안자 인덱스를 슬롯마다 즉석에서 계산했지만 이제 get_beacon_proposer_index는 state.proposer_lookahead[state.slot % SLOTS_PER_EPOCH]를 반환하기만 합니다. 미리 계산된 값을 읽는 조회 연산이 되므로, 합의 클라이언트가 다음 제안자를 미리 파악하기 쉬워져 구현이 단순해질 수 있습니다.
에포크 경계 갱신 로직
process_epoch에 process_proposer_lookahead가 추가됩니다. 먼저 벡터에서 방금 지난 에포크 분량(SLOTS_PER_EPOCH개)을 앞으로 밀어내고 get_beacon_proposer_indices로 현재 에포크 + MIN_SEED_LOOKAHEAD + 1 에포크의 제안자 인덱스를 계산해 마지막 구간을 채웁니다. compute_proposer_indices는 에포크 시드에 슬롯 번호를 붙여 해시한 슬롯별 시드(hash(seed + uint_to_bytes(slot)))로 각 슬롯의 제안자를 뽑습니다. 포크 후 첫 블록은 MIN_SEED_LOOKAHEAD 에포크 뒤까지의 모든 미리보기를 계산해 필드를 초기화합니다.
검토된 대안: 유효 잔고 캐싱
에포크 N 시작 시점의 유효 잔고를 캐시해 두었다가 에포크 N + MIN_SEED_LOOKAHEAD 시작 시 미리보기 계산에 쓰는 대안도 검토됐습니다. 하지만 이 방식은 비콘 상태에 추가 저장 공간이 필요하고 비콘 루트를 거쳐 EVM에 제안자 미리보기를 제공할 수 없다는 한계가 있어 채택되지 않았습니다.
SSLE와의 호환성
앞으로 선출된 검증자만 자기 차례를 아는 단일 비밀 리더 선출(SSLE, Single Secret Leader Election)이 도입될 수 있습니다. 현재 SSLE 설계도 암호화된 형태의 미리보기를 쓰므로, 그 경우 proposer_lookahead의 타입을 List[EncryptedValidatorIndex] 같은 형태로 바꿔 재사용할 수 있습니다. 미리보기를 아예 없애는 설계라면 빈 리스트로 두면 되므로 이 EIP가 걸림돌이 되지 않습니다. 또한 APS(Attester Proposer Separation)는 DDoS에 더 강한 실행 제안자를 구상하고 있어 SSLE의 필요성 자체가 줄어들 수 있다고 원문은 설명합니다.
에포크 경계 계산 비용
기존에는 슬롯마다 제안자 한 명의 인덱스만 계산하면 됐지만 이 EIP 이후에는 에포크 시작 시 한 에포크 전체의 제안자 일정을 계산해야 합니다. 제안자 인덱스 계산은 충분한 유효 잔고를 가진 검증자가 뽑힐 때까지 샘플링하는 가벼운 연산이지만, 이 추가 계산이 실제로 병목이 되지 않는지는 테스트로 확인이 필요하다고 원문은 밝힙니다.
보안: 조작 가능성은 늘지 않고 줄어듭니다
미리보기에 쓰이는 RANDAO 지연은 바뀌지 않습니다. 에포크 N의 미리보기는 여전히 에포크 N - MIN_SEED_LOOKAHEAD - 1의 RANDAO로 정해집니다. 바뀌는 것은 유효 잔고의 기준 시점으로, 에포크 N 시작 시점 대신 에포크 N - MIN_SEED_LOOKAHEAD 시작 시점의 유효 잔고를 씁니다. RANDAO와 유효 잔고의 시점을 이렇게 맞추면 RANDAO 결과를 확인한 뒤 유효 잔고를 조정하는 공격 가능성이 원천적으로 사라집니다. 실제로 그런 공격이 발견된 적은 없지만 가능성 자체를 제거해 보안 분석이 단순해집니다.
상태와 스펙 반영
이 EIP는 Final 상태이며 합의 레이어 변경이므로 상세 명세는 consensus-specs의 Fulu 비콘 체인 스펙에 반영되어 있습니다. 스펙 테스트도 consensus-specs의 Fulu 테스트 디렉터리에 있습니다. 하위 호환성 문제는 발견되지 않았습니다.