--- title: "ステートレス性、ステート失効、履歴の失効" description: "履歴の失効とステートレスなイーサリアムについての解説" lang: ja template: roadmap --- 一般的なハードウェアで[イーサリアム](/)のノードを実行できることは、真の分散化にとって不可欠です。なぜなら、ノードを実行することで、ユーザーはサードパーティから提供されるデータを信頼するのではなく、独立して暗号技術によるチェックを実行し、情報を検証できるようになるからです。ノードを実行すれば、仲介者を信頼することなく、イーサリアムのピア・ツー・ピアネットワークに直接トランザクションを送信できます。これらのメリットが高価なハードウェアを持つユーザーにしか得られない場合、分散化は不可能です。そうではなく、携帯電話やマイクロコンピューター、あるいは家庭用コンピューターのバックグラウンドで実行できるように、ノードは極めて控えめな処理能力とメモリ要件で実行できるべきです。 現在、ノードへの普遍的なアクセスを妨げている主な障壁は、ディスク容量の要件が高いことです。これは主に、イーサリアムの大量の状態データを保存する必要があるためです。この状態データには、新しいブロックやトランザクションを正しく処理するために必要な重要な情報が含まれています。執筆時点では、イーサリアムのフルノードを実行するには、高速な2TBのSSDが推奨されています。古いデータを一切プルーニング（削除）しないノードの場合、ストレージ要件は週に約14GBのペースで増加し、ジェネシス・ブロック以降のすべてのデータを保存するアーカイブノードは12TBに近づいています（2023年2月の執筆時点）。 古いデータを保存するために安価なハードドライブを使用することもできますが、それでは新しく入ってくるブロックに追いつくには遅すぎます。データをより安価で保存しやすくしつつ、クライアントの現在のストレージモデルを維持することは、一時的かつ部分的な解決策にすぎません。なぜなら、イーサリアムの状態の増加は「無制限」であり、ストレージ要件は常に増加し続けるため、技術の進歩は継続的な状態の増加に常に追いつかなければならないからです。その代わりに、クライアントはローカルデータベースからのデータ検索に依存しない、ブロックとトランザクションを検証する新しい方法を見つける必要があります。 ## ノードのストレージ削減 {#reducing-storage-for-nodes} 各ノードが保存しなければならないデータ量を削減する方法はいくつかあり、それぞれイーサリアムのコアプロトコルを異なる程度で更新する必要があります。 - **履歴の失効**: ノードがXブロックより古い状態データを破棄できるようにしますが、イーサリアムクライアントの状態データの処理方法は変更しません。 - **ステート失効**: 頻繁に使用されない状態データを非アクティブにできるようにします。非アクティブなデータは、復活するまでクライアントによって無視されます。 - **弱いステートレス性**: ブロック生成者のみが完全な状態データにアクセスする必要があり、他のノードはローカルの状態データベースなしでブロックを検証できます。 - **強いステートレス性**: どのノードも完全な状態データにアクセスする必要がありません。 ## データの失効 {#data-expiry} ### 履歴の失効 {#history-expiry} 履歴の失効とは、クライアントが必要とする可能性の低い古いデータをプルーニングし、少量の履歴データのみを保存して、新しいデータが到着したときに古いデータを破棄することを指します。クライアントが履歴データを必要とする理由は2つあります。同期とデータリクエストへの対応です。当初、クライアントはジェネシス・ブロックから同期し、チェーンの先頭に至るまで、連続する各ブロックが正しいことを検証する必要がありました。現在、クライアントはチェーンの先頭に到達するために「弱い主観性チェックポイント」を使用しています。これらのチェックポイントは信頼できる開始点であり、イーサリアムの最初ではなく、現在に近いジェネシス・ブロックを持つようなものです。つまり、クライアントはチェーンの先頭に同期する能力を失うことなく、最新の弱い主観性チェックポイントより前のすべての情報を破棄できます。クライアントは現在、ローカルデータベースからデータを取得することで、履歴データに対するリクエスト（JSON-RPC経由で到着）に対応しています。しかし、履歴の失効が導入されると、リクエストされたデータがプルーニングされている場合、これが不可能になります。この履歴データを提供するために、いくつかの革新的なソリューションが必要になります。 1つの選択肢は、クライアントがポータル・ネットワークなどのソリューションを使用して、ピアに履歴データをリクエストすることです。ポータル・ネットワークは、履歴データを提供するために開発中のピア・ツー・ピアネットワークであり、各ノードがイーサリアムの履歴の小さな断片を保存することで、履歴全体がネットワーク全体に分散して存在するようにします。関連するデータを保存しているピアを探し出し、そのピアにリクエストすることで、リクエストに対応します。あるいは、履歴データへのアクセスを必要とするのは一般的にアプリであるため、アプリが履歴データを保存する責任を負うことも考えられます。また、イーサリアムの領域には、履歴アーカイブを喜んで維持する利他的なアクターが十分に存在する可能性もあります。履歴データのストレージを管理するために立ち上げられたDAO（分散型自律組織）である可能性もありますし、理想的にはこれらすべての選択肢の組み合わせになるでしょう。これらのプロバイダーは、トレント、FTP、ファイルコイン、IPFSなど、さまざまな方法でデータを提供できます。 これまでイーサリアムは常にすべての履歴データの可用性を暗黙的に保証してきたため、履歴の失効にはいくらかの議論があります。スナップショットから一部の古いデータを再構築することに依存している場合でも、ジェネシス・ブロックからの完全な同期は常に標準として可能でした。履歴の失効は、この保証を提供する責任をイーサリアムのコアプロトコルの外に移します。最終的に履歴データを提供するために介入するのが中央集権的な組織である場合、新たな検閲リスクをもたらす可能性があります。 EIP-4444はまだリリースの準備ができていませんが、活発に議論されています。興味深いことに、EIP-4444の課題は技術的なものではなく、主にコミュニティ管理に関するものです。これをリリースするには、単なる合意だけでなく、信頼できるエンティティから履歴データを保存および提供するというコミットメントを含む、コミュニティの賛同が必要です。 このアップグレードは、イーサリアムノードが状態データを処理する方法を根本的に変更するものではなく、履歴データへのアクセス方法を変更するだけです。 ### ステート失効 {#state-expiry} ステート失効とは、最近アクセスされていない状態を個々のノードから削除することを指します。これを実装するには、以下のような複数の方法があります。 - **レントによる失効**: アカウントに「レント（家賃）」を請求し、レントがゼロになったときに失効させます。 - **時間による失効**: 一定期間、そのアカウントに対する読み取り/書き込みがない場合、アカウントを非アクティブにします。 レントによる失効は、アカウントをアクティブな状態データベースに保持するために、アカウントに直接レントを請求するものになる可能性があります。時間による失効は、最後のアカウントのやり取りからのカウントダウンによるものか、すべてのアカウントの定期的な失効によるものになる可能性があります。また、時間ベースとレントベースのモデルの両方の要素を組み合わせたメカニズムも考えられます。たとえば、時間ベースの失効の前に少額の手数料を支払えば、個々のアカウントがアクティブな状態を維持するといったものです。ステート失効において重要なのは、非アクティブな状態は**削除されるわけではなく**、アクティブな状態とは別に保存されるだけだという点です。非アクティブな状態は、アクティブな状態に復活させることができます。 これが機能する方法としては、おそらく特定の期間（おそらく約1年）ごとの状態ツリーを持つことになります。新しい期間が始まるたびに、完全に新しい状態ツリーも始まります。現在の状態ツリーのみが変更可能であり、他のすべてのツリーはイミュータブルです。イーサリアムノードは、現在の状態ツリーと、その次に新しい状態ツリーのみを保持することが期待されます。これには、アドレスが存在する期間のタイムスタンプをアドレスに付与する方法が必要です。これを行うには[いくつかの可能な方法](https://ethereum-magicians.org/t/types-of-resurrection-metadata-in-state-expiry/6607)がありますが、有力な選択肢では、追加情報を収容するために[アドレスを長くする](https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485)必要があり、アドレスが長くなることでセキュリティが大幅に向上するという追加のメリットもあります。これを行うロードマップの項目は、[アドレス空間の拡張](https://ethereum-magicians.org/t/increasing-address-size-from-20-to-32-bytes/5485)と呼ばれます。 履歴の失効と同様に、ステート失効の下では、古い状態データを保存する責任は個々のユーザーから取り除かれ、中央集権的なプロバイダー、利他的なコミュニティメンバー、またはポータル・ネットワークのようなより未来的な分散型ソリューションなどの他のエンティティに押し付けられます。 ステート失効はまだ研究段階にあり、リリースの準備はできていません。ステートレスクライアントや履歴の失効といったアップグレードにより、大多数のバリデーターにとって大きな状態サイズを簡単に管理できるようになるため、ステート失効はそれらよりも後に実施される可能性が高いです。 ## ステートレス性 {#statelessness-2} ステートレス性という言葉は少し誤解を招く表現です。なぜなら、「状態」の概念が排除されるわけではなく、イーサリアムノードが状態データを処理する方法の変更を伴うものだからです。ステートレス性自体には、弱いステートレス性と強いステートレス性の2種類があります。弱いステートレス性は、状態ストレージの責任を少数のノードに負わせることで、ほとんどのノードがステートレスになることを可能にします。強いステートレス性は、どのノードも完全な状態データを保存する必要性を完全に排除します。弱いステートレス性と強いステートレス性の両方が、通常のバリデーターに以下のメリットをもたらします。 - ほぼ瞬時の同期 - 順不同でブロックを検証する機能 - 非常に低いハードウェア要件でノードを実行可能（例：携帯電話など） - ディスクの読み書きが不要なため、安価なハードドライブ上でノードを実行可能 - イーサリアムの暗号技術の将来のアップグレードとの互換性 ### 弱いステートレス性 {#weak-statelessness} 弱いステートレス性は、イーサリアムノードが状態の変更を検証する方法の変更を伴いますが、ネットワーク上のすべてのノードで状態ストレージの必要性を完全に排除するわけではありません。その代わりに、弱いステートレス性は状態ストレージの責任をブロック提案者に負わせ、ネットワーク上の他のすべてのノードは完全な状態データを保存せずにブロックを検証します。 **弱いステートレス性では、ブロックの提案には完全な状態データへのアクセスが必要ですが、ブロックの検証には状態データは必要ありません。** これを実現するには、イーサリアムクライアントに[ヴァークル・ツリー](/roadmap/verkle-trees/)がすでに実装されている必要があります。ヴァークル・ツリーは、イーサリアムの状態データを保存するための代替データ構造であり、ローカルデータベースと照合してブロックを検証する代わりに、データの小さく固定サイズの「ウィットネス」をピア間で渡し、ブロックの検証に使用できるようにします。また、[プロポーザー・ビルダー分離 (PBS)](/roadmap/pbs/)も必要です。これにより、ブロックビルダーはより強力なハードウェアを備えた特化型ノードになることができ、完全な状態データへのアクセスを必要とするのはこれらのノードだからです。 ステートレス性は、ブロックビルダーが完全な状態データのコピーを維持し、ブロックの検証に使用できるウィットネスを生成できるようにすることに依存しています。他のノードは状態データにアクセスする必要はなく、ブロックの検証に必要なすべての情報はウィットネスで利用可能です。これにより、ブロックの提案にはコストがかかるが、ブロックの検証は安価であるという状況が生まれ、ブロック提案ノードを実行するオペレーターが少なくなることを意味します。しかし、できるだけ多くの参加者が提案されたブロックが有効であることを独立して検証できる限り、ブロック提案者の分散化は重要ではありません。 Dankradのノートで詳細を読む ブロック提案者は状態データを使用して「ウィットネス」を作成します。これは、ブロック内のトランザクションによって変更される状態の値を証明する最小限のデータセットです。他のバリデーターは状態を保持せず、状態ルート（状態全体のハッシュ）のみを保存します。バリデーターはブロックとウィットネスを受け取り、それらを使用して状態ルートを更新します。これにより、検証ノードは非常に軽量になります。 弱いステートレス性は研究が進んだ段階にありますが、小さなウィットネスをピア間で渡せるようにするために、プロポーザー・ビルダー分離とヴァークル・ツリーが実装されていることに依存しています。つまり、弱いステートレス性がイーサリアム・メインネットに導入されるのは、おそらく数年先になるでしょう。 [L1検証のためのzkEVM](/roadmap/zkevm/)は、ステートレスな検証をさらに強化できる補完的な技術です。バリデーターは単にウィットネスをチェックするだけでなく、ブロック全体が正しく実行されたというゼロ知識証明を検証できるようになり、トランザクションを再実行することなく暗号技術による確実性を提供します。 ### 強いステートレス性 {#strong-statelessness} 強いステートレス性は、どのノードも状態データを保存する必要性を排除します。その代わりに、トランザクションはブロック生成者によって集約できるウィットネスとともに送信されます。その後、ブロック生成者は、関連するアカウントのウィットネスを生成するために必要な状態のみを保存する責任を負います。ユーザーがウィットネスと「アクセスリスト」を送信して、どのアカウントとストレージキーとやり取りしているかを宣言するため、状態に対する責任はほぼ完全にユーザーに移ります。これにより非常に軽量なノードが可能になりますが、スマートコントラクトとのトランザクションがより困難になるなどのトレードオフがあります。 強いステートレス性は研究者によって調査されてきましたが、現在のところイーサリアムのロードマップの一部になるとは予想されていません。イーサリアムのスケーリングのニーズには、弱いステートレス性で十分である可能性が高いです。 ## 現在の進捗 {#current-progress} 弱いステートレス性、履歴の失効、ステート失効はすべて研究段階にあり、数年後にリリースされる予定です。これらの提案がすべて実装されるという保証はありません。たとえば、ステート失効が先に実装された場合、履歴の失効も実装する必要はなくなるかもしれません。また、[ヴァークル・ツリー](/roadmap/verkle-trees)や[プロポーザー・ビルダー分離 (PBS)](/roadmap/pbs)など、先に完了させる必要のある他のロードマップ項目もあります。 ## 参考文献 {#further-reading} - [ステートレスなイーサリアムとは？](https://stateless.fyi/) - [ヴィタリックのステートレス性に関するAMA](https://www.reddit.com/r/ethereum/comments/o9s15i/impromptu_technical_ama_on_statelessness_and/) - [状態サイズ管理の理論](https://hackmd.io/@vbuterin/state_size_management) - [復活の競合を最小限に抑えた状態の境界設定](https://ethresear.ch/t/resurrection-conflict-minimized-state-bounding-take-2/8739) - [ステートレス性とステート失効への道](https://hackmd.io/@vbuterin/state_expiry_paths) - [EIP-4444の仕様](https://eips.ethereum.org/EIPS/eip-4444) - [Alex StokesによるEIP-4444の解説](https://youtu.be/SfDC_qUZaos) - [ステートレス化が非常に重要である理由](https://dankradfeist.de/ethereum/2021/02/14/why-stateless.html) - [オリジナルのステートレスクライアントのコンセプトノート](https://ethresear.ch/t/the-stateless-client-concept/172) - [ステート失効に関する詳細](https://hackmd.io/@vbuterin/state_size_management#A-more-moderate-solution-state-expiry) - [ステート失効に関するさらなる詳細](https://hackmd.io/@vbuterin/state_expiry_paths#Option-2-per-epoch-state-expiry) - [ステートレスなイーサリアムの情報ページ](https://stateless.fyi)