0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@cardene(かるでね)

[EIP7862] 1つ前のブロックの最終ステートを参照する仕組みを理解しよう！

0
Posted at

はじめに

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

今回は、１つ前のブロックのstate_rootを参照するようにしてバリデーターの検証を高速化させる仕組みを提案しているEIP7862についてまとめていきます！

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

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

概要

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ブロック前のものに変更します。

変更前（現在の設計）

struct ExecutionPayload {
  uint256 blockNumber;
  uint256 timestamp;
  bytes32 parentHash;
  address feeRecipient;
  bytes32 stateRoot;  // このブロックのトランザクション後の状態を参照
}

変更後（提案後の設計）

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の最終ステートと一致していることを求めるようになります。

変更前（現在の検証ルール）

# ブロックnのトランザクションを適用した後の状態とstateRootが一致することを検証
assert compute_state_root(transactions_of_block_n) == payload_n.stateRoot

変更後（新しい検証ルール）

# ブロック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 charlie@paradigm.xyz, Dan Robinson dan@paradigm.xyz, Justin Drake justin@ethereum.org, 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

他の媒体でも情報発信しているのでぜひ他も見ていってください！

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?