ステートトライ

暗号資産におけるステートトライとは？

ステートトライとは、ブロックチェーンの現在の状態を、効率的に更新・検証でき、1つのルートハッシュで要約できる形で保存する暗号学的データ構造です。

Ethereum系ブロックチェーンでは、ステートトライはアカウントアドレスを残高、nonce、スマートコントラクトのストレージルート、コードハッシュなどのアカウントデータに対応付ける構造です。

公式のEthereum Merkle Patricia Trie documentationでは、Ethereumにはグローバルなステートトライが1つ存在し、クライアントがブロックを処理するたびに更新されると説明されています。

このグローバルステートトライは、トランザクション適用後のネットワークの現在の状態を表すため、Ethereumの実行レイヤーにおける最も重要な構成要素の1つです。

ステートトライは、過去のトランザクションの一覧と同じものではありません。

トランザクションは何が起きたかを記述する一方、ステートトライは、それらのトランザクションによって残高、コントラクトストレージ、アカウントデータが変更された後の、現在のブロックチェーンの状態を記述します。

例えば、ユーザーがあるアカウントから別のアカウントへETHを送る場合、トランザクションはブロックに記録されますが、2つのアカウント残高が更新されるため、ステートトライも変化します。

ユーザーがスマートコントラクトを呼び出す場合も、トランザクションはブロックに記録されます。しかし、コントラクトストレージ、残高、アカウントnonceが更新される可能性があるため、ステートトライも変化する場合があります。

簡単に言えば、ステートトライはブロックチェーンの現在のアカウント状態を保存する、認証可能なデータベースです。

ステートトライが重要な理由

ステートトライが重要なのは、ブロックチェーンには現在の状態を安全に証明する仕組みが必要だからです。

ブロックチェーンの状態には、数百万のアカウント、スマートコントラクト、残高、ストレージエントリー、その他の値が含まれる場合があります。

ノードは、新しいトランザクションが有効かどうかを判断するため、この状態について合意する必要があります。

送信者の残高が不足している場合、トランザクションは失敗する必要があります。

コントラクトのストレージスロットが特定の値を持つ場合、スマートコントラクトの呼び出しは異なる動作をする可能性があります。

nonceがすでに使用されている場合、リプレイされたトランザクションは受け入れられるべきではありません。

ステートトライは、クライアントがこれらの値を保存・確認するための決定論的な構造を提供します。

また、ブロックヘッダーに格納できる単一のステートルートも生成します。

2つのクライアントが同じブロックを処理して同じステートルートに到達した場合、両者が結果として得られた状態に合意している強力な証拠となります。

このため、ステートトライはブロックチェーンのコンセンサス、検証、ライトクライアントの証明、ノード同期、スマートコントラクト実行、データ整合性の中心的な役割を果たします。

ステートトライとステートルート

ステートルートとは、ブロック内のすべてのトランザクションが処理された後のステートトライのルートハッシュです。

EthereumのブロックヘッダーにはstateRootが含まれており、そのブロック時点における完全なグローバル状態へのコミットメントとなります。

Ethereum Merkle Patricia Trie documentationでは、Ethereum実行レイヤーのブロックヘッダーには、ステートトライ、トランザクショントライ、レシートトライのルートが含まれると説明されています。

ステートルートが重要なのは、はるかに大きなデータベースに対するコンパクトな暗号学的コミットメントだからです。

有効な証明が利用可能であれば、ユーザーは特定の主張を検証するために、すべてのアカウントとコントラクトストレージの値をダウンロードする必要はありません。

代わりに、その値がステートルートによってコミットされた状態に属することを検証できます。

アカウント残高、コントラクトストレージルート、nonce、コードハッシュのいずれかが変化すると、ルートへ至るハッシュの経路も変化します。

これは、異なる状態からは異なるステートルートが生成されるべきことを意味します。

したがって、ステートルートは特定のブロックにおける完全なブロックチェーン状態のフィンガープリントです。

これにより、巨大な状態データベースを単一の検証可能な値に変換できます。

ステートトライの仕組み

Ethereumのステートトライには、変更されたMerkle Patricia Trieが使用されています。

Merkle Patricia Trieは、マークルツリー、基数トライ、Patriciaトライの考え方を組み合わせたものです。

トライは、ツリー内の経路がキーに基づいて決まる、ツリー状のキー・バリュー構造です。

Patriciaトライは経路を圧縮するため、空のノードが長く連なることでツリーの容量が無駄になるのを防ぎます。

マークルツリーは暗号学的ハッシュを追加し、ハッシュ経路によるデータ検証を可能にします。

Ethereumはこれらの特徴を組み合わせることで、クライアントがアカウント状態を保存し、効率的に更新し、ルートハッシュとマークル証明で検証できるようにしています。

Ethereumのステートトライでは、経路はアカウントアドレスのKeccak-256ハッシュに基づきます。

その経路に保存される値は、RLPエンコードされたアカウントオブジェクトです。

公式Ethereumドキュメントによると、Ethereumのアカウントオブジェクトはnonce、balance、storageRoot、codeHashを含む4要素の配列です。

この設計により、各アカウントには決定論的な暗号学的経路を通じてアクセスできます。

ステートトライにはどのようなデータが保存されるか？

ステートトライは、すべてのコントラクトストレージ値をメインのグローバルトライに直接保存するのではなく、アカウントオブジェクトを保存します。

各Ethereumアカウントオブジェクトにはnonceが含まれます。

各Ethereumアカウントオブジェクトには残高が含まれます。

各EthereumアカウントオブジェクトにはstorageRootが含まれます。

各EthereumアカウントオブジェクトにはcodeHashが含まれます。

nonceはトランザクションのリプレイを防ぎ、アカウントの活動を追跡するのに役立ちます。

残高は、そのアカウントが保有するネイティブ通貨の量を記録します。

storageRootは、そのアカウントのスマートコントラクトストレージを保存する別のトライを指します。

codeHashは、コントラクトアカウントに関連付けられたスマートコントラクトのバイトコードへのコミットメントです。

外部所有アカウントは通常、空のコードと空のコントラクトストレージを持ちます。

スマートコントラクトアカウントは、実行方法に影響するコードとストレージを持つことができます。

ステートトライとストレージトライ

ステートトライとストレージトライは関連していますが、異なるものです。

ステートトライは、アカウントアドレスをアカウントオブジェクトに対応付けるグローバルな構造です。

ストレージトライは、特定のスマートコントラクトアカウントのストレージに使用される独立したトライです。

Ethereumドキュメントでは、コントラクトストレージを持つアカウントごとに個別のストレージトライが存在すると説明されています。

ステートトライ内のアカウントオブジェクトには、そのアカウントのストレージトライのルートであるstorageRootが保存されています。

つまり、グローバルステートトライには、すべてのコントラクトのすべてのストレージスロットが直接含まれているわけではありません。

代わりに、アカウントオブジェクトが含まれ、各コントラクトアカウントは自身のストレージトライを参照できます。

例えば、トークンコントラクトはユーザー残高を自身のコントラクトストレージトライ内に保存する場合があります。

グローバルステートトライはトークンコントラクトのアカウントオブジェクトを保存し、そのオブジェクトはトークンコントラクトのストレージルートを指します。

この階層設計は、アカウントレベルの状態とコントラクトレベルのストレージを分離するのに役立ちます。

ステートトライとトランザクショントライ

ステートトライはトランザクショントライとは異なります。

ステートトライには、トランザクション実行後に得られるアカウント状態が保存されます。

トランザクショントライには、特定のブロックに含まれるトランザクションが保存されます。

各ブロックにはそれぞれ固有のトランザクショントライがあります。

トランザクショントライは、グローバルステートトライのようにブロックをまたいで継続的に更新されるものではありません。

ステートトライは、トランザクションがアカウント残高とコントラクトストレージを変更するたびに、ブロックごとに変化します。

トランザクションは命令として理解できます。

ステートトライは、その命令が適用された後の結果として理解できます。

ブロックチェーンは単なる順序付けられたトランザクションログではないため、この区別は重要です。

また、各有効なトランザクションによってシステムがある状態から次の状態へ移行するステートマシンでもあります。

ステートトライとレシートトライ

ステートトライはレシートトライとも異なります。

レシートトライには、ブロックのトランザクションレシートが保存されます。

レシートには、ステータス、使用ガス、ログ、イベントデータなどの実行結果が記録されます。

ステートトライには、実行後の最終的なアカウント状態が記録されます。

レシートは、トランザクション実行中に何が起きたかをアプリケーションが把握するのに役立ちます。

ステートトライは、実行後にブロックチェーンの状態がどうなったかをクライアントが検証するのに役立ちます。

例えば、スマートコントラクトのトランザクションは、レシートに記録されるイベントを発行する場合があります。

同じトランザクションは、ステートトライとストレージトライを通じて記録されるコントラクトストレージも変更する場合があります。

どちらの構造も重要ですが、答える問いは異なります。

レシートトライはトランザクションが何を生成したかを示し、ステートトライは現在のチェーン状態が何であるかを示します。

Merkle Patricia Trieのノード

Ethereumの変更版Merkle Patricia Trieはいくつかのノードタイプを使用します。

公式Ethereumドキュメントでは、ブランチノード、リーフノード、エクステンションノード、空ノードについて説明されています。

ブランチノードは最大16個の子経路を参照でき、値を保持することもあります。

リーフノードは最終的なエンコード済み経路と値を保存します。

エクステンションノードは共有される経路セグメントを圧縮し、トライが疎なノードの長い連鎖を避けられるようにします。

この設計が有用なのは、Ethereumのキーが長く、疎であるためです。

経路圧縮がなければ、多くの検索で空の経路や分岐しない経路に不要なステップを費やすことになります。

Ethereumはエクステンションノードとリーフノードを使用することで、基本的な基数トライよりコンパクトなトライを実現しています。

また、ハッシュを使用することで、トライを暗号学的に検証可能にしています。

この組み合わせにより、この構造は変更版Merkle Patricia Trieと呼ばれます。

RLPエンコーディングとハッシュ化

Ethereumは、実行レイヤーの多くのデータ構造をシリアライズするために、一般にRLPと呼ばれるRecursive Length Prefixエンコーディングを使用します。

ステートトライでは、アカウントオブジェクトは値として配置される前にRLPエンコードされます。

トライノードも、ハッシュ化または保存される前にエンコードされます。

Ethereum Merkle Patricia Trie documentationでは、あるノードが別のノードを参照する場合、エンコードされた長さに応じて、その参照がRLPエンコード済みノードのKeccak-256ハッシュになる場合があると説明されています。

これは、すべてのノードを決定論的な方法でエンコードする必要があるため重要です。

2つのクライアントが同じ状態を異なる方法でエンコードすると、異なるルートを計算し、合意できなくなる可能性があります。

したがって、決定論的なエンコーディングはコンセンサスに不可欠な詳細です。

ハッシュ化により、値を変更するとノードハッシュとルートに戻るハッシュ経路が変化するため、改ざんも検出可能になります。

その結果、1つのルートハッシュが含まれるすべての値にコミットする、検証可能なキー・バリューデータベースが実現します。

これがステート証明を支える暗号学的基盤です。

ステート証明

ステート証明とは、特定のアカウントまたはストレージ値が、特定のステートルートにコミットされた状態に存在することを示す暗号学的証明です。

EIP-1186 eth_getProof proposalでは、Ethereumのマークルツリーベースの状態により、マークル証明を通じてアカウント値とストレージ値を検証できると説明されています。

証明には通常、対象の値からステートルートまでの経路を再構築するために必要なノードが含まれます。

再構築したハッシュが信頼できるステートルートと一致すれば、データ提供者を完全に信頼せずに値を検証できます。

これは、ライトクライアント、ブリッジ、クロスチェーンアプリケーション、モバイルウォレット、監査人、外部状態の検証が必要なスマートコントラクトシステムに有用です。

例えば、証明によって、あるアカウントが特定のブロック時点で特定の残高を持っていたことを示せます。

証明によって、コントラクトのストレージスロットが特定のブロック時点で特定の値を持っていたことも示せます。

ステート証明は、状態データベース全体をダウンロードするのではなく、選択的な検証を可能にするため強力です。

ステートトライはこれらの証明を可能にします。

認証可能な状態構造がなければ、ユーザーはRPCプロバイダーやインデクサーに対して、はるかに大きな信頼を置く必要があります。

eth_getProof

eth_getProofは、アカウント値とストレージ値をマークル証明とともに返すよう設計されたEthereum JSON-RPCメソッドです。

EIP-1186では、eth_getProofを、指定アカウントのアカウント値とストレージ値を証明データとともに返すメソッドとして定義しています。

証明には、ステートルートからの経路に従うaccountProofデータを含めることができます。

また、コントラクトストレージルートからの経路に従うstorageProofデータを含めることもできます。

このメソッドは、アプリケーションが単なる生のRPCレスポンスではなく、証拠を必要とする場合に有用です。

例えば、ウォレットやブリッジは、ブロックのステートルートに対してストレージスロットを検証したい場合があります。

単純な残高照会は値のみを報告します。

証明照会は、値と、その値を確認するために必要な暗号学的データを報告します。

RPCプロバイダーが誤っている、検閲している、不具合を起こしている、または悪意を持つ可能性があるため、この違いは重要です。

マークル証明により、ユーザーは信頼できるブロックヘッダーに対して証明を確認し、プロバイダーへの信頼を減らせます。

ステートトライとフルノード

フルノードは、新しいブロックとトランザクションを検証するために現在の状態を必要とします。

公式のEthereum archive node documentationでは、各アカウントとコントラクトに関するグローバルデータは、stateと呼ばれるトライデータベースに保存されると説明されています。

フルノードは、受信するブロックとトランザクションを検証できるよう、ネットワークの最新状態を追跡します。

フルノードは通常、すべての過去の状態を永久に保存するわけではありません。

チェーン再編成と通常のネットワーク運用に対応するため、最新の状態と十分な最近の状態データを保持する場合があります。

古い過去の状態は、最新チェーン先端の標準的な検証には不要なため、多くの場合プルーニングできます。

このため、通常のフルノードでは、過去の残高や過去のコントラクトストレージを照会することが困難な場合があります。

現在の状態はネットワーク運用に必要です。

すべての過去の中間状態は分析や証明に有用ですが、保存にははるかに多くの負荷がかかります。

したがって、ステートトライはノードのハードウェア、同期、ストレージ、分散化に影響します。

ステートトライとアーカイブノード

アーカイブノードは、現在の状態と最近の状態のみを保持するのではなく、過去の状態を保存します。

Ethereum archive node documentationでは、アーカイブノードは各ブロック後に生成されたすべての過去の状態を保存し、より大きなディスク要件と引き換えに高速な過去照会を実現すると説明されています。

これは、ブロックチェーンエクスプローラー、監査人、研究者、セキュリティチーム、税務ツール、分析プロバイダー、dApp開発者にとって重要です。

例えば、ユーザーは数年前のブロックにおけるアカウント残高を確認したい場合があります。

フルノードは、その状態を再構築するために過去のトランザクションを再実行する必要がある場合があります。

アーカイブノードは、多くの場合、ディスクから過去の状態に直接アクセスできます。

この速度には、はるかに大きなストレージ要件というコストが伴います。

したがって、ステートトライの履歴は価値がある一方で高コストです。

このため、多くのユーザーは過去の状態照会でインフラプロバイダーに依存しています。

ただし、プロバイダーへの依存は、信頼性、可用性、検閲に関するリスクを追加する可能性があります。

ステートトライとスマートコントラクト

スマートコントラクトはステートトライとストレージトライに大きく依存しています。

コントラクトのアカウントオブジェクトはグローバルステートトライに現れます。

コントラクトのコードはcodeHashを通じてコミットされます。

コントラクトの永続ストレージはstorageRootを通じてコミットされます。

スマートコントラクトの実行時には、ストレージスロットの読み取りと書き込みが行われる場合があります。

そのストレージ変更はコントラクトのストレージトライを更新します。

コントラクトの新しいstorageRootは、グローバルステートトライ内のアカウントオブジェクトを更新します。

更新されたアカウントオブジェクトは、グローバルステートルートを変更します。

つまり、小規模なコントラクトストレージ更新でも、ブロックの最終的なステートルートを変化させる可能性があります。

したがって、ステートトライはスマートコントラクトの結果をコンセンサス上で可視化する仕組みの一部です。

ステートトライとトークン残高

多くのトークン残高は、グローバルステートトライに直接保存されるのではなく、スマートコントラクトストレージ内に保存されます。

例えば、代替可能トークンのコントラクトは、ユーザーアドレスからトークン残高へのマッピングを保存する場合があります。

このマッピングはトークンコントラクトのストレージトライ内に存在します。

グローバルステートトライは、そのコントラクトのstorageRootを含むトークンコントラクトのアカウントオブジェクトを保存します。

つまり、ネイティブコインの残高とトークン残高は異なる方法で保存されます。

ネイティブコイン残高は、グローバルステートトライ内のアカウントオブジェクトの一部です。

トークン残高は通常、特定のトークンコントラクトのストレージトライ内にあるストレージ値です。

この区別は証明と監査において重要です。

ネイティブコインの残高を証明するには、通常、アカウント証明だけで十分です。

トークン残高を証明するには、トークンコントラクトのアカウント証明と、関連する残高スロットのストレージ証明の両方が必要になる場合があります。

ステートトライとライトクライアント

ライトクライアントとは、完全な状態を保存せずにブロックチェーンデータを検証するクライアントです。

ステートトライは、ブロックヘッダーに結び付いたコンパクトな証明を可能にするため、ライトクライアントに役立ちます。

ライトクライアントはブロックヘッダーを信頼または検証した後、マークル証明を使用して特定の状態値を確認できます。

これは完全な状態をローカルに保存するよりも大幅に低コストです。

例えば、モバイルウォレットは完全な実行ノードを実行せずに、コントラクトストレージ値が存在することを検証したい場合があります。

ブリッジは、出金イベントまたはアカウント状態が別のチェーンの状態に含まれていることを検証したい場合があります。

ステートトライは、これらのワークフローに必要な認証可能な構造を提供します。

ただし、証明サイズと証明生成コストは依然として大きくなる可能性があります。

これが、Ethereum研究者がVerkle treesなどの代替案を検討してきた理由の1つです。

目標は、時間とともに状態検証をより軽量かつスケーラブルにすることです。

ステートトライとステートレスクライアント

ステートレスクライアントは、バリデーターまたはユーザーが完全な状態をローカルに保存せずにブロックを検証できるようにする、長期的なブロックチェーンのスケーリング構想です。

すべてのバリデーターがすべての状態を保存する代わりに、ブロックまたはトランザクションに、それらが参照する状態を証明するウィットネスが含まれます。

現在のMerkle Patricia Trieのウィットネスは大きくなり得るため、ステートトライはこの点で関連します。

大きなウィットネスはステートレス検証を非効率にする可能性があります。

Ethereum FoundationのVerkle tree structure articleでは、Verkle treesはMerkle treesと同様に機能する一方、ベクトルコミットメントによってはるかに小さなウィットネスを生成できると説明されています。

このため、Verkle treesはEthereumの現在の状態コミットメント構造を置き換える候補として研究されてきました。

現在のステートトライは安全で実戦で検証されていますが、可能な限り小さなステートレスウィットネス向けに設計されたものではありません。

ステートレス化の研究は、ステートトライがノードに与える負担を軽減することにも関係しています。

ユーザーにとっての実用的な要点は、状態データ構造の設計が将来のスケーラビリティに影響するということです。

開発者にとっては、プロトコル研究の進展に伴い、状態アクセスパターンと証明システムが進化する可能性があることを意味します。

ステートトライとVerkle trees

Verkle treeは、ハッシュリンクだけでなくベクトルコミットメントを使用する、提案中の状態コミットメント構造です。

Ethereum.orgでは、プロトコルのタイムラインと実装詳細は変更される可能性があるものの、Ethereumは将来的にVerkle Tree構造へ移行する計画であるとしています。

Verkle treesは、Merkle Patricia Trieの証明よりも小さな証明を実現するよう設計されています。

Ethereum Foundationの記事では、Verkle treeの設計ではアカウントトライとストレージトライも異なるレイアウトで統合されると説明されています。

現在のEthereumはグローバルステートトライに加え、アカウントごとのストレージトライを使用しているため、これは大きな変更となります。

Verkleベースの状態モデルにより、ステートレスクライアントがより実用的になる可能性があります。

ただし、長期にわたり運用されてきたステートトライから新しいコミットメント構造への移行は複雑です。

これはクライアント、証明、ウォレット、ノード、実行ルール、ストレージレイアウト、開発者の前提に影響します。

したがって、ステートトライは現在の基盤であると同時に、継続的なプロトコル研究の主要分野でもあります。

ステートトライを理解することは、Verkle研究が重要である理由を理解するのに役立ちます。

ステートトライとステートブロート

ステートブロートとは、ブロックチェーンのアクティブな状態が大きくなり、維持が困難になることを指します。

アカウント、コントラクト、ストレージスロット、アプリケーションデータがより多くアクティブなまま残ると、ステートトライは拡大します。

大規模な状態は、ディスク使用量、同期時間、データベース負荷、ハードウェア要件を増加させます。

ノードの実行コストが高くなりすぎると、独立してネットワークを検証できるユーザーが減少する可能性があります。

これは分散化を弱める可能性があります。

アクティブな状態は新しいトランザクションの処理に必要であるため、ステートブロートはブロックチェーン履歴の増大とは異なります。

過去のトランザクションは重要ですが、古い中間状態はプルーニングまたは再生成できる場合があります。

現在の状態は検証のために利用可能でなければなりません。

このため、状態の増大はスマートコントラクトブロックチェーンにおける最も難しいスケーリング問題の1つです。

ステートトライは、その増大がクライアントに可視化されるデータ構造です。

ステートトライとガスコスト

ガスコストは、計算と状態アクセスに価格を付ける目的で一部設計されています。

永続ストレージへの書き込みは、ノードが維持しなければならない状態を増加または変更するため、高コストです。

状態への読み取りも、状態アクセスが実行パフォーマンスに影響するため、コストを伴う場合があります。

スマートコントラクトが新しいストレージを作成すると、ストレージトライとグローバルステートルートの更新が必要になる場合があります。

スマートコントラクトがストレージを削除する場合、現在のプロトコルルールに応じて、ガスルールは払い戻しまたはインセンティブを提供する場合があります。

永続的な状態は共有ネットワークリソースであるため、これらのガスの仕組みはステートトライに関連します。

ストレージへの書き込みが安すぎると、アプリケーションは低価値データでステートトライを肥大化させる可能性があります。

ストレージへの書き込みが高すぎると、有用なアプリケーションの構築が難しくなる可能性があります。

プロトコル設計者は、使いやすさ、セキュリティ、状態の持続可能性のバランスを取る必要があります。

ステートトライは、この経済的トレードオフの中心にあります。

ステートトライとRPCプロバイダー

RPCプロバイダーは、ウォレットやアプリケーションがブロックチェーン状態を読み取れるようにするメソッドを提供します。

一般的な状態メソッドには、残高照会、ストレージ照会、コード照会、トランザクション数照会、コントラクト呼び出しが含まれます。

公式のEthereum JSON-RPC documentationでは、状態メソッドはアカウント残高、コントラクトデータ、ガス見積もりなど、現在保存されているデータを報告するメソッドとして説明されています。

ウォレットがアカウント残高を要求すると、RPCプロバイダーはノードから状態データを読み取ります。

dAppがコントラクト値を要求すると、RPCプロバイダーはストレージスロットを読み取るか、現在の状態に対して呼び出しをシミュレーションする場合があります。

ユーザーは、多くの場合、レスポンスの背後にあるステートトライを意識せずにRPCプロバイダーを利用します。

しかし、これらの値を検証可能なブロックチェーン状態の一部にしているのはステートトライです。

高い信頼性が求められるアプリケーションでは、生のRPCレスポンスだけでは不十分な場合があります。

対応しており適切に検証される場合、ステート証明はより強い保証を提供できます。

これはブリッジ、監査、コンプライアンスツール、クロスチェーンシステムで重要です。

ステートトライとブロックチェーンエクスプローラー

ブロックチェーンエクスプローラーは、状態データを利用して、残高、トークン保有、コントラクトストレージ、トランザクションの影響、過去のアカウント情報を表示します。

エクスプローラーは、多くの場合、直接的なステートトライ照会だけでなく、インデックス化されたデータに依存します。

インデックス化により、検索は高速になり、ユーザーインターフェースも構築しやすくなります。

ただし、インデックス化されたデータは最終的に、ブロックチェーン状態、トランザクション、ログ、レシート、実行結果に由来します。

エクスプローラーが特定のブロックにおけるアカウント残高を表示する場合、その情報はそのブロックの状態に結び付いています。

エクスプローラーがトークン残高を表示する場合、多くはコントラクトストレージの変更とイベントから導出されます。

アーカイブノードは、エクスプローラーが過去の状態に関する質問へ迅速に答えるのに役立ちます。

過去の状態にアクセスできなければ、エクスプローラーはトランザクション履歴から古い状態を再構築する必要がある場合があります。

通常、ステートトライはエクスプローラーの一般ユーザーには見えません。

それでも、プロトコルレベルでエクスプローラーデータを検証可能にする中核構造の1つです。

ステートトライとブリッジ

ブリッジでは、別のブロックチェーン環境の状態またはイベントを検証する必要がある場合が多くあります。

ステートトライとマークル証明は、この検証を支援できます。

例えば、ブリッジは、メッセージ、ストレージ値、またはアカウント状態が特定のブロックに存在したことの証明を必要とする場合があります。

ブリッジがブロックヘッダーを信頼し、証明を検証できれば、中央集権的なデータプロバイダーへの依存を減らせます。

このため、EIP-1186ではマークル証明がLayer 2技術にとって重要であるとされています。

ステート証明は、残高、ストレージスロット、コントラクト状態に関する主張をシステムが検証するのに役立ちます。

ただし、ブリッジのセキュリティは証明構造だけに依存するものではありません。

ヘッダー検証、ファイナリティの前提、不正証明、有効性証明、マルチシグ制御、スマートコントラクトセキュリティ、運用設計にも依存します。

正しいステートトライ証明は強力ですが、ブリッジセキュリティの一部にすぎません。

ユーザーは、マークル証明に言及しているからといってブリッジが安全であると考えるべきではありません。

ステートトライとLayer 2ネットワーク

Layer 2ネットワークでは、オフチェーンまたは別チェーンでの実行を要約するために、ステートルート、証明、コミットメント構造がよく使用されます。

Layer 2は、Layer 1チェーンにステートルートを公開する場合があります。

状態遷移が有効であることを証明するために、不正証明、有効性証明、データ可用性メカニズムを使用する場合があります。

正確な設計はLayer 2のアーキテクチャによって異なります。

Ethereumのステートトライは、ブロックチェーンがコンパクトなルートを通じて大規模な状態にコミットする方法を示すため、重要な背景知識です。

Layer 2システムは異なるデータ構造を使用する場合がありますが、概念は類似しています。

大規模な実行状態はコミットメントによって要約されます。

その後、ユーザーとコントラクトはそのコミットメントに対して主張を検証します。

このため、ステートトライは単なる低レベルのクライアントトピックではありません。

スケーリング、ロールアップ設計、クロスチェーン検証にも関係します。

ステートトライとセキュリティ

ステートトライは、状態の改ざんを検出可能にすることでセキュリティを向上させます。

ノードが有効なトランザクションルールに従わずにアカウント残高を変更した場合、結果のステートルートは受け入れられたブロックヘッダーと一致しません。

プロバイダーがストレージ値について虚偽を述べた場合、有効なマークル証明は信頼できるステートルートに対して失敗するはずです。

2つのクライアントが状態遷移ルールで一致しない場合、異なるステートルートを計算し、互いのブロックを拒否する可能性があります。

このため、ステートトライはコンセンサスに不可欠です。

ステートトライ実装のバグは、クライアント間の不一致や誤った状態検証につながる可能性があるため、深刻になり得ます。

このため、実行クライアントはトライロジック、エンコーディング、ハッシュ化、状態更新を慎重に実装する必要があります。

ステートトライのセキュリティは、暗号学的ハッシュの耐衝突性にも依存します。

攻撃者が同じルートを持つ2つの異なる状態を作成できれば、証明の完全性を損なう可能性があります。

現代のブロックチェーンのステートトライは、現在の条件下でこれを実用的に不可能にする暗号学的前提に依存しています。

ステートトライとクライアント実装

異なるEthereum実行クライアントは同じ状態ルールを実装しますが、異なる内部データベースや最適化を使用する場合があります。

コンセンサス上重要な結果は同じステートルートでなければなりません。

クライアントがトライノードをディスクに保存する方法は異なる場合があります。

クライアントが状態をキャッシュする方法も異なる場合があります。

クライアントが古い状態をプルーニングする方法も異なる場合があります。

クライアントが過去照会を提供する方法も異なる場合があります。

つまり、ステートトライはプロトコルの概念であると同時に、実装上の課題でもあります。

プロトコルレベルでは、クライアントはルートと遷移ルールについて合意する必要があります。

データベースレベルでは、クライアントチームはストレージレイアウト、アクセス速度、プルーニング、スナップショット、同期動作を最適化できます。

ユーザーは通常、これらの違いをノード性能、ディスク使用量、同期時間、RPC信頼性として体験します。

ステートトライと開発者デバッグ

開発者は、ストレージスロット、アカウント証明、過去の状態照会を通じて、間接的にステートトライに接することがよくあります。

スマートコントラクト開発者は、マッピングがコントラクトストレージにどのように保存されるかを知る必要がある場合があります。

セキュリティ研究者は、あるストレージスロットが特定のブロックで特定の値を持っていたことを証明する必要がある場合があります。

ブリッジ開発者は、別環境のコントラクト状態値を検証する必要がある場合があります。

ウォレット開発者は、残高照会がlatestやfinalizedなどのブロックタグに依存する理由を説明する必要がある場合があります。

dApp開発者は、古いコントラクト状態をデバッグする際にアーカイブノードを必要とする場合があります。

ステートトライを理解することは、開発者がこれらの問題を正確に解釈するのに役立ちます。

また、トランザクション履歴と現在の状態を混同することを避けるのにも役立ちます。

イベント、ストレージ、残高、アカウント状態が同じものだと仮定することから、多くのバグが生じます。

ステートトライは、各データがどこに存在するかを明確にします。

ステートトライと一般的なユーザー体験

ほとんどの暗号資産ユーザーがステートトライを直接操作することはありません。

ユーザーが操作するのは、ウォレット、dApp、エクスプローラー、RPCプロバイダーです。

ウォレットが残高を表示するとき、状態を読み取っています。

dAppがユーザーによるトークン承認の有無を確認するとき、コントラクトストレージの状態を読み取っています。

スマートコントラクト呼び出しの成功または失敗は、現在の状態に依存します。

エクスプローラーがあるブロック時点のコントラクト値を表示する場合、状態アクセスまたは状態から導出されたインデックス化データに依存します。

ステートトライは隠れたインフラですが、日常のユーザー活動に影響します。

状態へのアクセスが遅いと、dAppの動作も遅く感じられる場合があります。

RPCプロバイダーが誤った状態を提供すると、ユーザーに誤った残高や失敗したトランザクションが表示される可能性があります。

過去の状態が利用できない場合、ユーザーは古い活動を監査しにくくなる可能性があります。

ステートトライに関するよくある誤解

よくある誤解の1つは、ステートトライがすべてのトランザクションを保存しているというものです。

ステートトライは現在のアカウント状態を保存し、トランザクションはブロックとトランザクショントライに別途保存されます。

もう1つの誤解は、スマートコントラクトストレージがグローバルステートトライに直接保存されているというものです。

グローバルステートトライはアカウントオブジェクトを保存し、コントラクトストレージはstorageRoot値で参照される個別のストレージトライに保存されます。

3つ目の誤解は、フルノードが常にすべての過去の状態を保存しているというものです。

多くのフルノードは現在と最近の状態を維持しつつ、古い中間状態をプルーニングします。

4つ目の誤解は、ステートルートが状態そのものであるというものです。

ステートルートは状態へのコンパクトな暗号学的コミットメントであり、完全な状態データベースではありません。

5つ目の誤解は、マークル証明がコントラクトに関するあらゆる事実を証明するというものです。

マークル証明は、特定のルートに対する特定のアカウントまたはストレージ値を証明するものであり、その値の完全なビジネス上の意味を証明するものではありません。

ステートトライの利点

ステートトライの第1の利点は検証可能性です。

ユーザーとクライアントは、ステートルートに結び付いた証明を通じて状態値を検証できます。

第2の利点は決定性です。

同じ有効なブロックを処理するクライアントは、同じステートルートに到達する必要があります。

第3の利点は効率的な検索です。

トライの経路により、クライアントは決定論的なキーを通じてアカウントとストレージデータを見つけられます。

第4の利点は改ざんの痕跡が残ることです。

1つの値を変更すると、ハッシュの経路と最終ルートが変化します。

第5の利点はライトクライアントのサポートです。

選択的な証明により、完全な状態をダウンロードせずにデータを検証できます。

第6の利点は明確な状態遷移構造です。

各ブロックは前の状態を新しいルートを持つ新しい状態へ変えます。

これらの利点により、ステートトライはアカウントベースのスマートコントラクトブロックチェーンの基盤となっています。

ステートトライの制約

第1の制約はストレージの増大です。

アカウントとコントラクトストレージ値が蓄積するほど、ノードにとって状態はより重くなります。

第2の制約は証明サイズです。

Merkle Patricia Trieの証明は、ステートレスクライアントや大規模検証にとって望ましいサイズより大きくなる場合があります。

第3の制約は実装の複雑さです。

トライのエンコーディング、ハッシュ化、プルーニング、キャッシュ、データベース保存を正しく実装することは困難です。

第4の制約は過去の状態のコストです。

すべての過去の状態を維持するには、通常のフルノード運用よりはるかに多くのディスク容量が必要です。

第5の制約は開発者の混乱です。

多くの開発者は、状態、ストレージ、トランザクション、レシート、ログ、インデックス化データの違いを誤解しています。

これらの制約は、状態管理が依然として活発な研究・エンジニアリング分野である理由を示しています。

ステートトライは機能しますが、実際のスケーリングおよびユーザビリティ上の課題も生み出します。

開発者向けベストプラクティス

証明ベースのシステムを構築する前に、アカウント状態とコントラクトストレージの違いを理解してください。

Merkle Patricia Trieの仕組みを学ぶ際は、公式Ethereumドキュメントを使用してください。

アカウントまたはストレージ証明が必要なシステムを構築する際は、eth_getProofを慎重に使用してください。

RPCレスポンスを盲目的に信頼するのではなく、信頼できるブロックヘッダーに対して証明を検証してください。

トークン残高は通常、グローバルステートトライに直接存在するのではなく、コントラクトストレージ内に存在することを忘れないでください。

古い過去の状態へ高速にアクセスする必要がある場合は、アーカイブノードまたはアーカイブデータプロバイダーを使用してください。

不要な永続ストレージを最小限に抑えるようスマートコントラクトを設計してください。

永続状態にはコストがかかるため、ストレージへ書き込む際はガスコストを考慮してください。

システムがステート証明に大きく依存する場合は、Verkle treesなどのプロトコル研究を追跡してください。

将来のプロトコルアップグレードにおいて、現在の証明フォーマットが永遠に変わらないとは考えないでください。

ユーザー向けベストプラクティス

信頼できるウォレットとエクスプローラーを使用してください。ただし、表示内容は状態照会とインデックス化データに由来することを忘れないでください。

異なるツール間で残高やコントラクト値を比較する場合は、ブロック番号を確認してください。

現在の残高と過去の残高では、必要なデータアクセスが異なる場合があることを理解してください。

高い保証が必要で、ツールが対応している場合は、証明ベースの検証を使用してください。

単純なRPCレスポンスが暗号学的証明と同じものだと考えないでください。

別チェーンの状態を検証すると主張するブリッジやアプリケーションを利用する際は注意してください。

アプリケーションが現在の状態、過去の状態、ログ、オフチェーンインデックスのどれを使用しているかを確認してください。

トークン送転が明らかでない場合でも、スマートコントラクトストレージの変更がアプリケーションの動作に影響することを理解してください。

ブロックチェーンの透明性は、ステートトライのようなデータ構造に依存していることを覚えておいてください。

ステートトライはほとんどのユーザーには見えませんが、パブリックチェーンのデータを検証可能にするのに役立ちます。

FAQ

ステートトライとは何ですか？

ステートトライとは、現在のブロックチェーン状態を保存し、その状態にコミットするルートハッシュを生成する暗号学的キー・バリューツリーです。

Ethereumのステートトライとは何ですか？

Ethereumのステートトライは、ハッシュ化されたアカウントアドレスをRLPエンコードされたアカウントオブジェクトに対応付ける、グローバルな変更版Merkle Patricia Trieです。

Ethereumのアカウントオブジェクトには何が保存されていますか？

Ethereumのアカウントオブジェクトには、nonce、balance、storageRoot、codeHashが含まれます。

ステートルートとは何ですか？

ステートルートとは、ブロック内のトランザクション実行後のステートトライのルートハッシュです。

ステートトライとストレージトライは同じものですか？

いいえ。ステートトライはアカウントオブジェクトを保存し、ストレージトライは個々のコントラクトアカウントのコントラクトストレージを保存します。

ステートトライはトランザクション履歴と同じですか？

いいえ。ステートトライは現在のアカウント状態を保存し、トランザクション履歴はブロックに含まれる順序付けられたトランザクションを記録します。

マークル証明とは何ですか？

マークル証明とは、特定の値がルートハッシュによってコミットされた状態に含まれることを証明できる、トライノードの集合です。

eth_getProofとは何ですか？

eth_getProofは、アカウント値とストレージ値をマークル証明データとともに返すEthereum JSON-RPCメソッドです。

ステートトライにおいてアーカイブノードが重要な理由は？

アーカイブノードは過去の状態を保存するため、通常のフルノードよりも古い状態の照会に迅速に回答できる点で重要です。

Ethereumは常に現在のステートトライを使用しますか？

Ethereumは現在、実行レイヤーでMerkle Patricia Triesを使用していますが、Ethereum研究では将来の状態コミットメント構造としてVerkle treesが検討されています。

結論

ステートトライは、アカウントベースのスマートコントラクトブロックチェーンを支える中核的なデータ構造の1つです。

アカウントの現在の状態を保存し、クライアントは単一の暗号学的ルートを通じてその状態を要約できます。

Ethereumでは、グローバルステートトライがハッシュ化されたアカウントアドレスを、nonce、balance、storageRoot、codeHashを含むアカウントオブジェクトに対応付けます。

各コントラクトは独自のストレージトライを持つことができ、そのルートはコントラクトアカウントオブジェクト内に保存されます。

各ブロックヘッダーのステートルートは、そのブロック内のすべてのトランザクション処理後の完全な結果状態にコミットします。

このため、ステートトライはコンセンサス、検証、ライトクライアント、証明、ノード同期、スマートコントラクト実行、ブロックチェーンデータの完全性に不可欠です。

また、アクティブな状態の増大はノードストレージ、証明サイズ、同期の複雑さ、過去データのコストを増加させるため、ステートトライは課題も生み出します。

これらの課題により、アーカイブノード、状態プルーニング、ガスコスト、ストレージ設計、eth_getProof、Verkle tree研究はすべて同じテーマに結び付いています。

ユーザーにとって、ステートトライは主にウォレット、エクスプローラー、dAppの背後に隠れています。

開発者とインフラチームにとっては、残高、コントラクトストレージ、証明、過去照会、スケーリング上限を理解するための重要な概念です。

暗号資産用語集において、State Trieは、現在のアカウント状態を記録し、その状態を検証するためのステートルートを生成する、認証可能なブロックチェーン状態データベースを意味します。

重要なポイントは、ステートトライが巨大かつ絶えず変化するブロックチェーン状態を、ノード、アプリケーション、ユーザーが暗号学的ルートと証明を通じて信頼できる検証可能な構造に変換することです。