이더리움 프로포저 룩어헤드: EIP-7917이 제안자 일정을 확정하는 법

이더리움은 슬롯마다 검증자 한 명을 블록 제안자(Proposer)로 고릅니다. 꽤 정밀해 보이지만, 과거에는 난수가 이미 정해진 뒤에도 다음 에포크(Epoch)의 전체 일정이 일부 경계 조건에서 달라질 수 있었어요. 이더리움 블록체인 기초에서 합의 구조의 큰 그림을 볼 수 있고, EIP-7917은 그중 제안자 일정이라는 좁은 문제를 결정론적 프로포저 룩어헤드(Deterministic Proposer Lookahead)로 해결합니다.

이 변경은 2025년 12월 3일 푸사카(Fusaka) 업그레이드에 포함돼 메인넷에 적용됐어요. 블록을 미리 만들거나 거래 포함을 보장하는 기능은 아닙니다. 앞으로 누가 블록을 제안할지 합의 상태에서 확정적으로 읽게 해 주는 기반 시설이에요.

이더리움 프로포저 룩어헤드란 무엇인가요?

이더리움은 시간을 12초 슬롯(Slot)으로 나누고, 32개 슬롯을 한 에포크로 묶어요. 슬롯마다 한 검증자가 블록을 제안합니다. EIP-7917 이전에도 현재 제안자는 계산할 수 있었지만, 현재 에포크 도중 다음 에포크의 전체 제안자 목록이 언제나 최종 확정된 것은 아니었어요.

다음 제안자와 미리 조율하려는 서비스에는 이 작은 차이가 중요합니다. 예를 들어 사전 확인(Preconfirmation) 서비스는 예정된 제안자에게 조건을 갖춘 거래를 블록에 포함하겠다는 약속을 요청할 수 있어요.

공항 출발 안내판에 비유해 볼게요. 항공편은 정해져 있지만 다음 시간대의 일부 탑승구가 막판에 바뀔 수 있었다고 생각해 보세요. EIP-7917은 공항 공식 시스템 안에 안정된 탑승구 표를 게시하는 것과 비슷합니다. 더 일찍 조율할 수 있지만, 날씨나 안전 점검 때문에 실제 출발이 어긋날 가능성까지 없애지는 않아요.

EIP-7917 공식 명세는 이 목록을 결정론적 프로포저 룩어헤드라고 부릅니다. 비콘 체인(Beacon Chain)은 에포크 경계마다 앞으로 보이는 기간의 제안자 인덱스를 계산해 비콘 상태(Beacon State)에 저장해요.

다음 에포크 일정은 왜 완전히 고정되지 않았나요?

제안자 선정에는 난수와 검증자의 유효 잔액(Effective Balance)이 함께 쓰입니다. 미래 에포크의 난수 시드가 정해졌더라도 활성 검증자의 유효 잔액은 일정이 실제로 사용되기 전에 달라질 수 있었어요. 페널티, 슬래싱(Slashing), 예치, 보상, 검증자 통합 등이 잔액을 바꿀 수 있습니다.

EIP-7251이 기존 32 ETH보다 높은 최대 유효 잔액을 허용하면서 이 문제는 더 중요해졌어요. 잔액이 1 ETH 단위를 넘나드는 경우가 늘어, 입력값이 고정됐다고 생각한 뒤 제안자 계산이 바뀌는 경계 사례가 생길 수 있었기 때문입니다.

EIP-7917은 유효 잔액 입력의 기준 시점을 이미 지연돼 있는 난수 입력과 맞춥니다. 변할 수 있는 잔액으로 필요할 때마다 계산하는 대신, 일정을 더 일찍 계산해 상태에 저장해요. 난수 결과를 본 뒤 유효 잔액을 조정해 일정에 영향을 줄 가능성도 없애 보안 분석을 단순하게 만듭니다.

검증자가 뽑히는 큰 구조는 합의 알고리즘 설명에서 확인하세요. 블록이 제안된 뒤 언제 되돌리기 어려워지는지는 블록체인 최종성 가이드가 제안, 확인, 정당화, 최종화를 구분해 설명합니다.

EIP-7917은 어떻게 작동하나요?

비콘 상태에는 이제 proposer_lookahead 벡터가 들어갑니다. 쉽게 말하면 앞으로 올 슬롯과 검증자 인덱스를 순서대로 연결한 목록이에요.

1. 포크 전환 시점에 앞으로 보이는 제안자 일정을 초기화합니다.
2. 에포크 경계에서 현재 에포크 항목을 목록 밖으로 밀어냅니다.
3. 합의 로직이 고정된 난수와 검증자 입력으로 새 미래 에포크를 계산해요.
4. 새 검증자 인덱스를 저장된 룩어헤드 뒤에 붙입니다.
5. 클라이언트는 필요할 때 한 명씩 다시 계산하지 않고 상태 필드에서 슬롯 제안자를 읽습니다.

명세가 설명하는 현재 MIN_SEED_LOOKAHEAD 값에서는 현재와 다음 에포크, 총 64개 슬롯 항목을 담아요. 이 값은 합의 설정의 일부이므로 개발 도구는 숫자를 영원히 고정하기보다 최신 명세를 따라야 합니다.

저장된 필드는 비콘 상태 루트(Beacon State Root)를 통해 증명할 수도 있어요. 애플리케이션은 머클 증명(Merkle Proof)을 사용해 제안자 항목이 공식 합의 상태에 포함됐는지 확인할 수 있습니다. 제3자가 임의로 게시한 일정만 믿을 필요가 줄어드는 셈이에요.

무엇을 가능하게 하고, 무엇은 보장하지 않나요?

대표적인 활용처는 **기반형 사전 확인(Based Preconfirmation)**입니다. 이용자나 앱은 블록이 나올 때까지 기다리는 대신, 알려진 미래 제안자에게 유효한 거래를 정해진 조건으로 포함하겠다는 빠른 약속을 받고 싶을 수 있어요. 결정론적 일정은 상대를 찾고 그 정보를 온체인에서 검증하는 구조를 단순하게 만듭니다.

하지만 프로포저 룩어헤드는 배관이지, 완성된 서비스가 아니에요. 이더리움 공식 푸사카 가이드도 이 기능이 사전 확인을 가능하게 할 수 있다고 설명합니다. EIP-7917 자체가 거래 포함을 보장한다는 뜻은 아니에요. 별도의 사전 확인 시스템에는 규칙, 인센티브, 페널티, 네트워크, 실패 처리 방식이 필요합니다.

합의 클라이언트는 미래 임무를 더 일찍 준비할 수 있고 모니터링도 명확해집니다. 이더리움 공식 가이드에 따르면 검증자 클라이언트의 기본 동작이 바뀌는 것은 아니지만, 운영자는 새 가시성을 활용하도록 모니터링 도구를 갱신할 수 있어요.

다음은 보장하지 않습니다.

• 선택된 검증자가 온라인 상태로 유효한 블록을 만들 것
• 재구성(Reorg)을 막거나 이더리움 최종성 규칙을 대체할 것
• 거래 순서, 가격, 실행 성공 또는 포함을 보장할 것
• 서비스 거부 공격자로부터 미래 제안자의 신원을 숨길 것
• 모든 지갑 확인을 즉시 끝낼 것

마지막 보안 절충 때문에 비밀 단일 리더 선출(SSLE, Single Secret Leader Election) 연구가 여전히 중요해요. EIP-7917은 암호화된 룩어헤드 설계와의 호환 가능성을 논의하지만, 이는 현재 이 EIP가 제공하는 기능이 아니라 미래 설계입니다.

보안 리스크와 한계

알려진 제안자는 공격 표적이 될 수 있어요. 일찍 공개된 일정은 조율에 유용하지만, 공격자가 미래 제안자를 겨냥하는 데 쓸 수도 있습니다. EIP-7917은 비밀 리더 선출을 도입하지 않아요.

일정은 가동성을 보장하지 않아요. 검증자가 오프라인이거나 슬롯을 놓치고, 잘못된 소프트웨어를 실행하거나, 유효하지 않은 블록을 만들 수 있습니다. 이를 이용하는 시스템은 시간 초과와 대체 경로를 준비해야 해요.

사전 확인의 신뢰 모델은 별도예요. 서비스가 약속을 어길 수 있습니다. 누가 약속을 발행하는지, 어떤 담보나 페널티가 뒷받침하는지, 재구성 시 어떻게 처리되는지 확인해야 합니다.

에포크 경계의 계산이 늘어요. 클라이언트는 미래 에포크 전체의 제안자를 한 번에 계산합니다. 명세는 이 계산이 가볍다고 보지만 구현체의 테스트와 모니터링은 필요해요.

프로토콜 지식은 낡을 수 있어요. 매개변수와 로드맵은 발전합니다. 이더리움 재단의 푸사카 메인넷 공지는 EIP-7917이 푸사카에 포함됐음을 확인해 줍니다. 정확한 합의 동작은 최신 EIP 명세를 기준으로 보세요.

포함 목록(Inclusion List)은 다른 문제를 풉니다. 이더리움 FOCIL은 프로토콜 규칙으로 거래 검열을 어렵게 만드는 구상이에요. 다음 제안자가 누구인지 공개하는 데 그치지 않습니다.

개발자와 검증자 체크리스트

• 업데이트된 합의 클라이언트 또는 검증된 비콘 상태 증명에서 제안자 데이터를 읽으세요.
• 룩어헤드를 블록 생성 증명으로 해석하지 마세요.
• 사전 확인 설계에 슬롯 누락, 재구성, 상충하는 약속의 처리 규칙을 넣으세요.
• 화면에서 제안자의 약속과 이더리움 합의 최종성을 분리해 표시하세요.
• 슬롯 수 가정을 고정하지 말고 클라이언트 릴리스 노트와 합의 명세 변경을 확인하세요.
• 네트워크가 지원하는 포크 버전에 맞춰 검증자 소프트웨어를 최신으로 유지하세요.

FAQ

EIP-7917은 검증자를 뽑는 방법을 바꿨나요?

핵심적인 잔액 가중 제안자 선정 방식은 유지합니다. 중요한 변화는 입력값을 언제 고정하는지, 그리고 결과 일정을 미리 계산해 저장한다는 점이에요.

룩어헤드로 내 거래의 확정을 알 수 있나요?

아니요. 예정 제안자는 보여 주지만 미래 블록의 내용이나 유효성은 보여 주지 않습니다. 수수료, 논스(Nonce), 제안자 행동, 네트워크 상태, 재구성, 앱 규칙이 여전히 영향을 줘요.

EIP-7917이 적용됐으니 사전 확인도 완성됐나요?

아닙니다. EIP-7917은 유용한 프로토콜 기반을 제공합니다. 개별 사전 확인 시스템은 별도 구현과 보안 모델이 필요하므로 각각의 규칙을 따로 평가해야 해요.

프로포저 룩어헤드가 최종성을 대체하나요?

아니요. 룩어헤드는 누가 블록을 제안할 예정인지에 관한 정보입니다. 최종성은 합의가 블록을 되돌리기 경제적·절차적으로 어렵게 만드는 과정이에요. 서로 다른 질문에 답합니다.

마무리

EIP-7917은 거의 예측 가능했던 다음 에포크 제안자 계산을 명시적인 합의 상태로 바꿨어요. 유효 잔액의 경계 사례를 없애고, 클라이언트에 더 빠른 가시성을 주며, 사전 확인 개발자에게 검증 가능한 조율 지점을 제공합니다.

다만 기반 시설을 확실성으로 오해하면 안 됩니다. 지정된 제안자가 슬롯을 놓칠 수 있고, 사전 확인의 보장이 약할 수 있으며, 제안된 블록은 아직 최종화된 블록이 아니에요. 이 글은 교육 목적이며 재정·투자 조언이 아닙니다. 크립토 시스템과 자산에는 기술 및 시장 리스크가 있습니다. 최신 명세를 직접 확인하고, 잃어도 되는 금액만 사용하며 스스로 조사하세요(DYOR). NFA.