[EIP7917] proposerの事前スケジュール仕組みを理解しよう！

はじめに

『DApps開発入門』という本や色々記事を書いているかるでねです。

今回は、次に誰がブロックを作るか（proposer）をあらかじめ一覧にして保存しておく仕組みを提案しているEIP7917についてまとめていきます！

以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。

EIP-7917: Deterministic proposer lookaheadPre-calculate and store a deterministic proposer lookahead in the beacon state at the start of every epochEthereum Improvement Proposals

他にも様々なEIPについてまとめています。

Notion | Where teams and agents work togetherMade in Notion, the connected workspace where AI agents and teams organize docs, projects and knowledge together.Notion

概要

Ethereumのビーコンチェーンでは、各エポック（約 6.4 分）ごとに「ブロック proposer（提案者）」の順番が決定されます。これまでは次のエポックのproposerスケジュールが完全には予測できませんでした。 EIP7917では、各エポック開始時に次の MIN_SEED_LOOKAHEAD + 1 エポック分（通常は 2 エポック先まで）のproposerスケジュールをあらかじめ計算し、beacon_state に保存します。これにより「次のエポックで誰がブロックを提案するか」がビーコンチェーンの状態だけで決定的に分かるようになります。

動機

現状の課題

RANDAO シード（ランダム値）は少なくとも 1 エポック先まで決定論的に分かりますが、proposerスケジュールはバリデータの実効残高（Effective Balance, EB）が変動すると不確定になります。

実効残高（EB: Effective Balance）とは、各バリデータの提案・投票における重み付けのために使用される残高です。これは実際のETH残高とは異なり、システムがバリデータごとの公正性と効率性を保つために丸め処理（通常は 1 ETH 単位）を行った擬似的な数値です。

実際のETH残高が 34.25 ETH のバリデータでも、EB は 34 ETH になる
EB は投票やproposer選出時にランダム性と重みの要素として使用される

スラッシング（不正行為に対する罰則）やペナルティで 1 ETH 以上 EB が減る、あるいは報酬・デポジット・バリデータ統合で 1 ETH 以上 EB が増えると、次エポックのproposer選出計算に影響が出ます。

ブロックproposer（提案者）は、各スロットごとに「アクティブなバリデータの集合」から RANDAO シードを用いた乱択アルゴリズムで選ばれます。このとき、各バリデータの EB が選出の重みに影響を与えます。

したがって、以下のような理由で EB が変動すると、同じ RANDAO シードであってもproposerの選出結果が変わる可能性があります。

罰則によって EB が減る（例：スラッシングで -1 ETH）
デポジットや報酬によって EB が増える（例：1 ETH 分報酬蓄積）
バリデータの統合によって EB が合算される

バリデータ統合（validator consolidation）とは、複数のバリデータが持つステークを1つのバリデータに統合する操作のことを指します。主に以下の目的で行われます。

ガス代の節約（管理アカウントの統合）
ステーキングサービスの最適化（例：1人のユーザーが持つ複数ノードの統合）

統合後のバリデータは EB が増加するため、次のproposer選出に影響を及ぼす可能性があります。

EIP7251（最大 EB を 32 ETH → $2^{32} - 1$ ETHまで拡張する提案）によりMaxEB（EB の上限）が 32 ETHを超えて拡大され、報酬加算でEBが増えやすくなったため、この不確定性がさらに大きくなります。

based preconfirmationプロトコルへの影響

これらのプロトコルは「次のエポックのproposerが誰か」をあらかじめ知っている前提で動作します。そのため、不確定要素があるとスムーズに機能しません。 proposerスケジュールを決定論的に固定することで、アプリケーション層はビーコンルート＋簡単なMerkle証明だけで次のproposerを取得でき、実装が大幅に簡易化されます。

セキュリティ面の改善

EB を操作してproposer順を有利に変える「グラインディング攻撃」を封じます。

グラインディング攻撃（grinding attack）とは、ブロックチェーンがランダム性や擬似乱数に基づいて意思決定を行う部分に対して、攻撃者（多くの場合バリデータ）が自分に有利な結果が出るまで試行錯誤を繰り返すことでシステムを操作しようとする手法を指します。 Ethereumのビーコンチェーンでは、以下のような形で発生する可能性があります。

ブロックproposerに選ばれる頻度を高めて報酬を得る
投票（アテステーション）の影響力を増やして合意形成を左右する
MEV（最大実行可能価値）を獲得しやすいスロットを引き当てる

これによりセキュリティ解析も単純化され、クライアント実装は次のproposerを事前に把握できるため運用も容易になります。

設計上の是正

Danny Ryanが以前指摘していた「次エポックproposerが非決定的である」という設計上の欠点を解消します。

仕様

`proposer_lookahead` の導入

ビーコンチェーンにおいて、各スロットでどのバリデータがブロック提案（proposer）を担当するかを事前に決定しておくため、BeaconState に新しく proposer_lookahead フィールドが追加されます。

このフィールドは、現在のエポックの先頭スロットから MIN_SEED_LOOKAHEAD エポック分先までのproposerをあらかじめ決定して格納するベクトルです。

python

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

例えば、以下のようにスロットとproposerの関係が決定論的に記録されます。

proposer_lookahead[0] は現在のエポックの最初のproposerのインデックス
proposer_lookahead[SLOTS_PER_EPOCH + 4] は次のエポックで5番目のproposerに相当します。

proposerの取得方法の変更

従来は各スロットごとにproposerを動的に計算していましたが、今後は proposer_lookahead を用いて高速に取得できるようになります。これによりproposer選出の決定性とパフォーマンスが向上します。

python

def get_beacon_proposer_index(state: BeaconState) -> ValidatorIndex:
    return state.proposer_lookahead[state.slot % SLOTS_PER_EPOCH]

ここでは、現在のスロット番号に応じて proposer_lookahead の対応する要素を参照するだけでproposerを得られます。

`proposer_lookahead` の更新処理

新しいエポックが始まるたびに、proposer_lookahead を以下のように更新します。

現在のエポック分の proposer を削除（シフト）
MIN_SEED_LOOKAHEAD 先のエポックのproposerを計算して追加

この処理は process_epoch 関数内で呼ばれます。

python

def process_epoch(state: BeaconState) -> None:
    ...
    process_proposer_lookahead(state)

具体的な更新処理は以下のようになります。

python

def process_proposer_lookahead(state: BeaconState) -> None:
    last_epoch_start = len(state.proposer_lookahead) - SLOTS_PER_EPOCH

    # 過去分（現在のエポック）を前に詰める
    state.proposer_lookahead[:last_epoch_start] = state.proposer_lookahead[SLOTS_PER_EPOCH:]

    # 新しい proposer を計算して末尾に追加
    last_epoch_proposers = compute_proposer_indices(
        state,
        Epoch(get_current_epoch(state) + MIN_SEED_LOOKAHEAD)
    )
    state.proposer_lookahead[last_epoch_start:] = last_epoch_proposers

このように、常に現在から先読み範囲のproposer一覧が proposer_lookahead に保持される構造になっています。

フォーク後の初期化処理

この仕様が有効になるフォーク直後の最初のブロックでは、 MIN_SEED_LOOKAHEAD + 1 エポック分のproposerを一括で計算し、proposer_lookahead を初期化します。これにより新しい仕様に即座に適応可能な状態となります。

実装の位置付け

この変更はビーコンチェーンのコンセンサス仕様に組み込まれ、各クライアント実装に反映されます。 proposer_lookahead を導入することで、ベースドプロトコルやブロック提案戦略における実装が簡素化され、セキュリティ解析も明確になります。

補足

採用されなかった代替案

ある代替案として、「エポックNの開始時点の EB をキャッシュしておき、N + MIN_SEED_LOOKAHEAD のproposer選出に使う」という方法が検討されました。この方法であれば、proposerスケジュールの非決定性を避けられます。

しかし、この方法には以下の欠点があります。

beacon_state に追加の記憶領域が必要になる
キャッシュされた EB に基づいて計算されるproposerスケジュールは、アプリケーション層やスマートコントラクトから直接参照できない（beacon root を経由できない）

そのため、EIP7917ではこの方法は採用せず、proposer_lookahead フィールドの導入という現在の仕様が選ばれました。

SSLE（Single Secret Leader Election）との互換性

将来的に単一の秘密リーダー選出（SSLE）が導入される可能性があります。これは、ブロックproposerが誰かをスロット開始前に誰も知らないようにする方式で、DDoS対策として有効です。

ただし、現在検討されているSSLEの設計でも、暗号化されたproposerスケジュール（lookahead）を前提としています。そのため、以下のように proposer_lookahead は将来のSSLE導入においても支障にはなりません。

現行の proposer_lookahead フィールドは、List[EncryptedValidatorIndex] のような型に変えることで再利用可能
仮に完全に lookahead を廃止する設計が登場しても、proposer_lookahead を空リストにすれば対応可能

なお、より高度なproposerセパレーション（Attester Proposer Separation, APS）設計が進めば、SSLEの必要性自体が下がる可能性もあります。

エポック境界での計算負荷の増加

EIP7917の適用前は、各スロットで現在のproposerを1件ずつ動的に計算すれば済んでいました。

一方、EIP7917導入後は、エポックの開始時にそのエポック全体のproposerスケジュール（約32件）を一括で計算する必要があります。

ただし、proposer選出自体は負荷の軽い処理です。具体的には、有効な `EB を持つバリデータが見つかるまで、ランダムにバリデータをサンプリングするだけです。理論上の計算量は増えますが、実際のパフォーマンス上の問題がないかは今後の実装と検証で確認する必要があります。

セキュリティ

proposerスケジュールの改ざん防止

ブロックproposerの選出において重要なのは、バリデータがproposerスケジュール（lookahead）を不正に操作して自分に有利な立場を得ることを防ぐことです。

EIP7917（proposer_lookahead の導入）は、この攻撃のリスクを増加させることはありません。なぜなら、以下の点が現在の仕様と変わらないためです。

proposerスケジュールを決定する乱数の元（RANDAO）は、依然として epoch N - MIN_SEED_LOOKAHEAD - 1 であり、 epoch N - MIN_SEED_LOOKAHEAD の開始時点でしか決まりません。

つまり、proposerが選ばれる時点で使用されるランダム性（RANDAO）はバリデータにとって操作不能なタイミングで固定されます。

実効残高の参照タイミングの変更

唯一の違いは、有効残高（Effective Balance, EB）をいつのタイミングで参照するかです。

旧仕様
- epoch N のproposerを決めるとき、epoch N の開始時点の EB を使用
新仕様
- epoch N のproposerを決めるとき、epoch N - MIN_SEED_LOOKAHEAD の EB を使用

これにより、バリデータが RANDAO を見た後に EB を変動させてproposerスケジュールに影響を与えるといった攻撃が不可能になります。

攻撃実例はまだないが、理論的リスクを排除

これまでに EB グラインディングを利用してproposerを操作する攻撃が実際に報告されたわけではありませんが、理論的には攻撃が成立する可能性があると指摘されてきました。

この提案により、RANDAO と EB の参照タイミングが一致し、proposerスケジュールの計算が完全に決定論的に固定されることで、この攻撃経路自体が排除されてセキュリティ分析がより単純になります。

引用

Lin Oshitani (@linoscope) lin@nethermind.io, Justin Drake (@JustinDrake) justin@ethereum.org, "EIP-7917: Deterministic proposer lookahead [DRAFT]," Ethereum Improvement Proposals, no. 7917, March 2025. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7917.