# [EIP7862] 1つ前のブロックの最終ステートを参照する仕組みを理解しよう！ > EIP7862は、各ブロックnのstate_rootを、ブロックnのExecutionPayload内ではなく、前のブロック（n-1）の後のステートを参照するようにする提案です。 - URL: https://cardene.dev/articles/5ea2b7975fc88353aa18 - 公開日: 2025-03-13 - 更新日: 2025-03-13 - トピック: Blockchain - タグ: ethereum, solidity, smartcontract, ブロックチェーン ## はじめに 『DApps開発入門』という本や色々記事を書いているかるでねです。 https://amzn.asia/d/gxvJ0Pw 今回は、１つ前のブロックの`state_root`を参照するようにしてバリデーターの検証を高速化させる仕組みを提案している**EIP7862**についてまとめていきます！ :::message 以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。 ::: https://eips.ethereum.org/EIPS/eip-7862 他にも様々なEIPについてまとめています。 https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4 ## 概要 **EIP7862**は、各ブロック`n`の`state_root`を、ブロック`n`の`ExecutionPayload`内ではなく、前のブロック（`n-1`）の後のステートを参照するようにする提案です。 これにより、ブロック`n`を作成する時に`state_root`を計算・検証する必要がなくなります。 結果として、ブロック作成の処理が軽くなり、レイテンシー（処理の遅延）が減少してスループット（処理能力）が向上する可能性があります。 ## 背景 今のEthereumブロックには、2つの`state_root`が含まれています。 - コンセンサス層（CL）の`state_root` これはBeaconBlockに含まれており、バリデーターの登録・削除などコンセンサス層の状態を管理しています。 - 実行層（EL）の`state_root` これは`ExecutionPayload`に含まれており、トランザクションの実行結果（アカウント残高、コントラクトのコード変更など）を追跡しています。 特に、ELの`state_root`はブロック作成者がリアルタイムで計算し、リレーやバリデーター、ライトクライアントが即座に検証する必要があります。 この計算負荷はブロック生成時間の大部分を占めており、MEV-Boost環境ではさらに大きな問題となります。 加えて、Ethereumのゼロ知識証明をリアルタイムで実行する時の障害にもなっています。 ### 提案のメリット このEIPでは、ELの`state_root`を1ブロック遅らせて参照することで、計算負荷をブロック生成の重要な処理フローから取り除きます。 具体的には、ブロック`n`を作成する時に、その`state_root`を計算せずに前のブロック（`n-1`）の`state_root`を参照するようにします。 これにより、ブロック生成の合間に（スロットの空き時間を使って）前のブロックの`state_root`を計算できるため、処理の流れを効率化できます。 この変更により、ブロックの最終決定が速くなり、スループットを増やしやすくなります。 また、ブロック作成の流れがシンプルになり、リアルタイムのZK-ProofによるEthereumの検証がより現実的になります。 ## 仕様 ### 実行層（Execution Layer）の変更 #### ExecutionPayloadのstateRootの変更 現在のEthereumのブロック設計では、各ブロックの`ExecutionPayload`には`stateRoot`が含まれており、そのブロックのトランザクション実行後のステートを示しています。 **EIP7862**では、この`stateRoot`の参照先を1ブロック前のものに変更します。 ##### 変更前（現在の設計） ```js struct ExecutionPayload { uint256 blockNumber; uint256 timestamp; bytes32 parentHash; address feeRecipient; bytes32 stateRoot; // このブロックのトランザクション後の状態を参照 } ``` ##### 変更後（提案後の設計） ```js struct ExecutionPayload { uint256 blockNumber; uint256 timestamp; bytes32 parentHash; address feeRecipient; bytes32 stateRoot; // 1つ前のブロックの最終状態（post-state）を参照 } ``` つまり、ブロック`n`の`ExecutionPayload.stateRoot`は、ブロック`n-1`の後のステートを参照するようになります。 これにより、ブロック`n`の生成時に新しい`stateRoot`を計算する必要がなくなります。 #### ブロックヘッダーの検証方法の変更 従来は、各ブロックの`stateRoot`が、そのブロックのトランザクションを適用した後のステートと一致している必要がありました。 しかし、**EIP7862**ではそのルールを変更し、ブロック`n`の`stateRoot`はブロック`n-1`の最終ステートと一致していることを求めるようになります。 ##### 変更前（現在の検証ルール） ```python # ブロックnのトランザクションを適用した後の状態とstateRootが一致することを検証 assert compute_state_root(transactions_of_block_n) == payload_n.stateRoot ``` ##### 変更後（新しい検証ルール） ```python # ブロックnのstateRootは、ブロックn-1の最終状態と一致することを検証 assert payload_n.stateRoot == post_state(n-1) ``` この変更により、ブロック`n`の`stateRoot`は`n-1`の最終ステートを示し、ブロック`n`自身のトランザクション実行後の状態は、ブロック`n+1`で参照されることになります。 #### 後の状態（Post-state Root）の事前計算 この変更を最大限活用するためには、ブロック`n-1`の後のステート（post-state root）を、ブロック`n`のスロットが始まる前のアイドル時間に計算するのが望ましいです。 具体的には以下のようになります。 1. ブロック`n-1`を受信・処理したら、その後すぐに`stateRoot`を計算しておく。 2. ブロック`n`が届いた時、既に計算済みの`stateRoot`と一致しているかをすぐに検証できるようにする。 もし、ブロック`n`が届いてからブロック`n-1`の`stateRoot`を計算する場合、従来と同じように計算時間が発生してしまいメリットが薄れてしまいます。 そのため、クライアント（ノード）は可能な限り事前に計算しておくことが推奨されます。 ### コンセンサス層（Consensus Layer）の影響 この変更は実行層（EL）のみに影響するため、コンセンサス層（CL）には特に変更はありません。 - `BeaconBlock`は、これまでと同じように各`ExecutionPayload`をラップしてブロックを作成します。 - 変更されるのは、ELの`stateRoot`の計算と検証方法だけです。 ### 移行方法（ハードフォーク時の動作） この提案がハードフォークで有効化される時の移行ルールは以下のようになります。 - **ハードフォークが適用されるブロックF** - `ExecutionPayload(F).stateRoot`は、ブロックF-1の最終ステートと一致するように設定される。 - **ブロックF+1以降** - `ExecutionPayload(F+1).stateRoot`は、ブロックFの最終ステートを参照する。 - 以降、この遅延した`stateRoot`参照の仕組みが適用される。 このように、フォークが適用されるブロックFで`stateRoot`の計算を1ブロック分ずらし、その後のブロックでは新しい仕様に従って処理を進めていきます。 ## 補足 ### レイテンシー（処理遅延）の削減 ブロック提案者（proposers）やビルダー（builders）は、同じスロット内で新しい`stateRoot`を計算・確定する必要がなくなります。 これにより、バリデーターはブロックの実行を確認し、その事前ステートの`stateRoot`が事前計算された期待値と一致しているかどうかをチェックするだけで署名できます。 その結果、ブロックの検証がスムーズになり、最終決定が速くなります。 ### スループットの向上 現在、各ブロックで`stateRoot`を計算するために使われている時間を、別の処理に割り当てられるようになります。 具体的には、以下のような改善が期待できます。 - **L1のブロック容量を増やす（ガス上限の引き上げ）** - **スロット時間を短縮しつつ、reorg（ブロックの再編成）リスクを抑える** これにより、Ethereum全体のスループットが向上します。 ### MEV-Boostとビルダーにとってのメリット 提案者とビルダーが分離されたProposer-Builder Separation（PBS）モデルでは、ブロック作成速度が競争の重要な要素になります。 この提案により、以下のような利点があります。 - **ビルダーの負担軽減** ビルダーは`stateRoot`計算の負担を減らし、より効率的なブロック作成に専念できます。 - **リレー（Relay）の負担軽減** リレーは、ブロックの遅延を引き起こす要因として`stateRoot`計算を考慮する必要がなくなります。 これにより、ブロック生産のパイプライン全体がスムーズになります。 ### リアルタイムZK-Proofの促進 ゼロ知識証明（ZK-Proof）では、`stateRoot`の計算が大きな課題になります。 特に、Ethereumが使用するKeccakハッシュ関数はZKに適したものではなく、計算コストが高くなります。 - **現在の問題点** もし`stateRoot`の遅延なしでリアルタイムSNARK証明を行う場合、ブロック提案者とビルダーは作成したブロックの`stateRoot`を1秒以内に証明する必要があります。 しかし、これは現実的に不可能です。 - **遅延`stateRoot`のメリット** この提案を導入すると、ZK-Proofの生成も1ブロック分遅延（パイプライン化）できます。 ネットワーク全体で約6秒の猶予が生まれ、現実的な証明時間を確保できます。 そのため、ZK-Proofを活用したEthereumの検証を本格的に進めるためには、`stateRoot`の遅延は不可欠な変更と言えます。 ## 互換性 **EIP7862**は、Ethereumのコンセンサスルールを変更するため、ハードフォークが必要になります。 メインネットやその他の対応ネットワークで一斉に適用されなければなりません。 ハードフォーク後も古いクライアント（従来の`stateRoot`の仕様に依存するノード）を使い続けると、ブロックの同期に失敗し、ネットワークと互換性がなくなります。 ## セキュリティ ### ライトクライアントへの影響 **EIP7862**が適用されると、ブロックの最終的な`stateRoot`が1ブロック遅れて公開されるようになります。 これにより、ライトクライアントは`stateRoot`を取得するまで最大1スロット（例：12秒）の遅延を受け入れる必要があります。 ただし、実際には多くのライトクライアントは証明（Proof）の取得に多少の遅延が発生することを想定しており、大きな問題にはならないと考えられます。 また、Ethereum以外のブロックチェーン、特にCosmosのようなマルチチェーンネットワークでは、すでに`stateRoot`が遅延する設計が一般的です。 それでも問題なく機能していることから、Ethereumでもこの変更に適応できると考えられます。 ### コントラクトへの影響 現在のところ、ブロック内で即時に`stateRoot`を参照するコントラクトは一般的ではないため、コントラクトの動作に直接影響を与えることはほとんどないと考えられます。 ## 引用 Charlie Noyes , Dan Robinson , Justin Drake , Toni Wahrstätter (@nerolation), "EIP-7862: Delayed Execution Layer State Root [DRAFT]," Ethereum Improvement Proposals, no. 7862, December 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7862. ## 最後に 今回は「１つ前のブロックの`state_root`を参照するようにしてバリデーターの検証を高速化させる仕組みを提案している**EIP7862**」についてまとめてきました！ いかがだったでしょうか？ 質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！ [Twitter @cardene777](https://twitter.com/cardene777) 他の媒体でも情報発信しているのでぜひ他も見ていってください！ https://chaldene.net/ https://zenn.dev/heku https://cardene.substack.com/ https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58 https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4