--- title: "ステートルート" description: "ステートルートは、ブロック実行後のワールドステートに対するイーサリアムの簡潔なコミットメントです。計算方法、アカウント・ストレージ証明が示すこと、保証しないことを解説します。" image: "https://wiki.fcontext.com/og.png" --- > Documentation Index > Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt > Use this file to discover all available pages before exploring further. # ステートルート > 教育目的の参考情報であり、投資助言ではありません。投資により損失が生じる可能性があります。 ## 直接の答え ステートルートは、ブロック処理後のワールドステートに対する、イーサリアムのブロックヘッダー内の 32 バイトの暗号学的コミットメントです。ワールドステートはアドレスをアカウントに対応付けます。各アカウントは nonce、残高、ストレージルート、コードハッシュにコミットし、各コントラクトのストレージルートはそのアカウントのストレージスロットにコミットします。 ルートはダイジェストであり、ダウンロード可能なスナップショットではありません。ノードは独立に計算した結果を比較でき、検証者は信頼できるブロックに対してアカウント証明やストレージ証明を検査できます。ルートだけでは状態を復元できず、状態データの可用性、ブロックのファイナリティ、コントラクトの経済的安全性も証明できません。 「ステートルート」はプロトコル固有です。イーサリアムは現在、変更版 Merkle-Patricia trie で実行レイヤーの状態にコミットします。他のネットワークは異なる状態モデル、エンコード、ハッシュ関数、認証済みデータ構造を使うことがあるため、同じ用語でもルートや証明に互換性があるとは限りません。 ## 仕組み 実行クライアントは親ブロックの状態から始め、有効なプロトコル規則に従って新しいブロックを検証・実行し、その結果生じるアカウントとストレージの変更を適用します。概略は次のとおりです。 `S_n = Υ(S_(n-1), B_n)` ここで `S_(n-1)` は親の状態、`B_n` は新しいブロックについてプロトコルが定めるすべての処理、`S_n` は結果の状態です。クライアントは状態をステートトライに決定論的にエンコードしてルートハッシュを計算します。有効なブロックヘッダーには同じ結果が必要で、一致しなければそのクライアントにとってブロックは無効です。 イーサリアムのステートトライでは、アカウントのパスはアドレスから導かれ、エンコードされたアカウントには nonce、残高、ストレージルート、コードハッシュが含まれます。コントラクトコードはハッシュで参照され、各コントラクトには別個のストレージトライがあります。この入れ子構造により、ストレージスロットの変更はコントラクトのストレージルート、エンコード済みアカウント、最終的にはグローバルステートルートを変更し得ます。 ステートルートは、同じブロックヘッダーのトランザクションルートやレシートルートとは別物です。トランザクションルートは順序付きトランザクションデータに、レシートルートは実行レシートにコミットし、相互に代用できません。 EIP-1186 は `eth_getProof` を定義し、指定ブロックのアカウント証明と要求されたストレージ証明を返せます。検証者には、認証済みのブロックハッシュまたはステートルート、正しい trie とエンコード規則、適切な承認またはファイナリティ方針が依然として必要です。 ## 例 あるトランザクションで Alice から Bob へ ETH を送るとします。正しい実行により、Alice の nonce と残高、Bob の残高、手数料受取人の残高が変わる可能性があります。コントラクトを呼び出す場合は、ストレージスロットとコントラクトのストレージルートも変わり得ます。大半のアカウントに触れなくても、これらの更新は新しいグローバルステートルートにつながります。 同じ親状態から始め、同じ規則で同じ有効なブロックを処理する誠実なクライアントは、同じルートを計算するはずです。クライアントが誤った金額を記帳したり、誤った trie エンコードを使ったりすれば、ルートはヘッダーと異なり、ローカル状態を黙って受け入れずにブロックを拒否しなければなりません。 ワールドステート全体をダウンロードせずに Bob の残高を確認するには、ブロックヘッダーとアカウント証明を取得します。証明パスを再計算すれば、エンコード済みアカウントがヘッダーのステートルートと整合するか分かります。選択したヘッダーが正規チェーン上にあることや確定済みであることは証明しません。それらは検証者のチェーン選択とファイナリティ検査によります。 ## リスク - **信頼できないルート：** 攻撃者が選んだルートや古いルートに対する有効な証明は、誤った基準点を証明します。ルートを検証済みブロックハッシュ、チェーン ID、ブロック番号に結び付けます。 - **再編成とファイナリティ：** 後で正規チェーンから外れるブロックに対して、証明が正しい場合があります。承認深度やファイナリティをアプリケーションの損失許容度に合わせます。 - **エンコードの誤り：** アドレスのハッシュ化、RLP エンコード、nibble パス、埋め込みノード、ストレージキー処理は厳密なプロトコル規則に従う必要があります。汎用の二分 Merkle 証明ライブラリだけでは足りません。 - **データ不足：** ルートは状態にコミットしますが、trie ノード、履歴状態、証明生成サービスを利用可能にはしません。プルーニングされたノードは古い証明を提供できない場合があります。 - **保証の誇張：** ルートの一致は実行結果の不一致を検出しますが、コントラクトロジックの監査、オラクル入力の認証、RPC エンドポイントの保護、資産価値の保証、侵害された鍵による取引の防止は行いません。 ## よくある誤解 - **ステートルートには全アカウントの残高が保存されている。** これはエンコード済み trie への固定長コミットメントであり、基礎となる trie データは別途取得します。 - **同じステートルートなら二つのノードのデータベースも同一である。** プロトコル規則上の同じ論理ワールドステートにコミットしますが、保存、索引、プルーニング、キャッシュ方法はクライアントごとに異なり得ます。 - **異なるステートルートなら問題のトランザクションが分かる。** 最終的なコミット済み状態の不一致は示しますが、分岐の開始点は示しません。診断には実行の追跡が必要です。 - **有効なアカウント証明はファイナリティと安全性も証明する。** 一つのルートとの整合性だけを証明します。チェーン選択、ファイナリティ、データの鮮度、コントラクト動作、経済的リスクは別の問題です。 ## 関連トピック - [アカウントベースモデル](/ja/crypto/account-based-model/) - [マークルツリー](/ja/crypto/merkle-tree/) - [フルノード](/ja/crypto/full-node/) - [ライトクライアント](/ja/crypto/light-client/) - [ブロック承認](/ja/crypto/block-confirmation/) ## 出典 - [Ethereum Execution Specifications: Block Header](https://ethereum.github.io/execution-specs/src/ethereum/forks/frontier/blocks.py.html) - Ethereum Foundation（参照日：2026-08-21） - [Merkle Patricia Trie](https://ethereum.org/developers/docs/data-structures-and-encoding/patricia-merkle-trie/) - Ethereum Foundation（参照日：2026-08-21） - [EIP-1186: RPC-Method to get Merkle Proofs](https://eips.ethereum.org/EIPS/eip-1186) - Ethereum Improvement Proposals（参照日：2026-08-21） Source: https://wiki.fcontext.com/ja/crypto/state-root/index.mdx