# イーサリアムの可能な未来：The Purge作者：ヴィタリック・ブテリンイーサリアムが直面している課題は、デフォルトでどのブロックチェーンプロトコルも膨張と複雑性が時間とともに増加することです。これは2つの側面で発生します:1. 歴史データ:歴史上の任意の時点で行われた取引および作成されたアカウントは、すべてのクライアントによって永久に保存され、新しいクライアントがネットワークに完全に同期するためにダウンロードされる必要があります。これにより、クライアントの負荷および同期時間が増加し続けますが、チェーンの容量は変わりません。2. プロトコルの機能: 新しい機能を追加することは古い機能を削除することよりもはるかに簡単であり、時間の経過とともにコードの複雑性が増加します。イーサリアムが長期的に維持できるようにするためには、これら2つのトレンドに対して強力な逆圧力をかけ、時間とともに複雑性と膨張を減少させる必要があります。同時に、ブロックチェーンを偉大にするための重要な属性の1つである持続性を保持する必要があります。あなたはNFT、取引記録の中のラブレター、または100万ドルを含むスマートコントラクトをチェーン上に置くことができ、10年後にはそれがあなたの読み取りとインタラクションを待っているのです。DAppが安心して完全に非中央集権化し、アップグレードキーを削除するためには、彼らは依存関係が彼らを破壊する方法でアップグレードされることはないと確信する必要があります - 特にL1自体についてです。もし私たちが決意し、この2つのニーズの間でバランスを取り、連続性を維持しながら、膨張、複雑性、衰退を最小限に抑えるか逆転させることができるなら、それは絶対に可能です。生物体はこれを実現できます：ほとんどの生物体は時間と共に老化しますが、少数の幸運な者はそうではありません。社会システムでさえ非常に長い寿命を持つことができます。ある場合には、イーサリアムは成功を収めています：プルーフ・オブ・ワークは消え、SELFDESTRUCT操作コードの大部分が消え、ビーコーンチェーンノードは最大6か月の古いデータを保存しています。イーサリアムのためにこの道をより一般的な方法で見つけ、長期的に安定した最終結果に向かうことが、イーサリアムの長期的なスケーラビリティ、技術的持続可能性、さらには安全性の究極の課題です。ザ・パージの主な目標:- クライアントのストレージ要件を低下させるために、各ノードがすべての履歴や最終状態を永久に保存する必要を減らすか排除することによって- 不要な機能を排除することでプロトコルの複雑さを低減する! [ヴィタリック:イーサリアムの未来の可能性、パージ](https://img-cdn.gateio.im/social/moments-4db9a670bb8e3d1c2de04e4c21cddae6)## 履歴の有効期限### は何の問題を解決しますか？この記事を書いている時点で、完全同期のイーサリアムノードはクライアントを実行するために約1.1 TBのディスクスペースを必要とし、さらにコンセンサスクライアント用に数百GBのディスクスペースが必要です。そのほとんどは履歴に関するものであり、歴史的なブロック、取引、領収書に関するデータが含まれており、そのほとんどは数年前のものです。これは、Gas制限が全く増加しなくても、ノードのサイズは毎年数百GB増加し続けることを意味します。### それは何ですか、それはどのように機能しますか？歴史的なストレージの問題の重要な簡略化された特徴は、各ブロックがハッシュでリンクされているため(、そして他の構造)が前のブロックを指しているため、現在の合意に達することが歴史に対する合意に十分であるということです。ネットワークが最新のブロックに合意すれば、任意の歴史的ブロックやトランザクション、または状態(のアカウント残高、乱数、コード、ストレージ)は、任意の単一の参加者によって提供され、マークル証明によって提供されることができます。そして、その証明は他の誰でもその正確性を検証できることを許します。合意はN/2-of-Nの信頼モデルであり、歴史はN-of-Nの信頼モデルです。これは、私たちが履歴をどのように保存するかについて、多くの選択肢を提供します。自然な選択肢の一つは、各ノードがデータの小さな部分のみを保存するネットワークです。これが、数十年間にわたってシードネットワークが機能してきた方法です: ネットワーク全体では数百万のファイルを保存および配布していますが、各参加者はその中の数ファイルのみを保存および配布しています。直感に反して、このアプローチはデータの堅牢性を低下させるわけではないかもしれません。もし、ノードをより経済的に運営することで、各ノードがランダムに10％の履歴を保存する100,000のノードを持つネットワークを構築できるなら、各データは10,000回コピーされることになります - これは、すべての内容を保存する各ノードを持つ10,000ノードのネットワークとまったく同じコピー因子です。現在、イーサリアムは全ノードがすべての履歴を永久に保存するモデルから脱却し始めています。コンセンサスブロック(は、ステークプルーフコンセンサスに関連する部分)が約6ヶ月間のみ保存されます。Blobは約18日間のみ保存されます。EIP-4444は、履歴ブロックとレシートに1年の保存期間を導入することを目的としています。長期的な目標は、統一された期間(が約18日間)であり、この期間中に各ノードがすべてのコンテンツを保存し、その後、イーサリアムノードからなるピアツーピアネットワークを構築し、古いデータを分散ネットワーク方式で保存することです。エラージャーコードは、ロバスト性を向上させながら、レプリケーションファクターを同じに保つために使用できます。実際、Blobはデータの可用性サンプリングをサポートするためにエラージャーコードを使用しています。最も簡単な解決策は、おそらくこのエラージャーコードを再利用し、実行とコンセンサスブロックデータもBlobに入れることです。### は既存の研究とどのような関連がありますか?- EIP-4444 (英語)- トレントとEIP-4444- ポータルネットワーク- ポータルネットワークとEIP-4444- PortalにおけるSSZオブジェクトの分散ストレージと検索- ガスリミット(Paradigm)を上げる方法### まだ何をする必要がありますか、何を天秤にかける必要がありますか？残りの主な作業には、履歴を保存するための具体的な分散ソリューションの構築と統合が含まれます——少なくとも実行履歴ですが、最終的にはコンセンサスとblobも含まれます。最も簡単なソリューションは(i)既存のtorrentライブラリを導入することと、(ii)エーテルのネイティブソリューションであるPortalネットワークを導入することです。どちらかを導入すれば、EIP-4444を開くことができます。EIP-4444自体はハードフォークを必要としませんが、新しいネットワークプロトコルのバージョンが必要です。したがって、すべてのクライアントで同時に有効にすることが価値があります。そうしないと、他のノードに接続して完全な履歴をダウンロードすることを期待しているが、実際には取得できていないためにクライアントが故障するリスクがあります。主要なトレードオフは、私たちが「古代」の歴史データを提供するためにどのように努力するかに関わっています。最も簡単な解決策は、明日古代の歴史の保存を停止し、既存のアーカイブノードとさまざまな集中型プロバイダーに依存して複製することです。これは簡単ですが、エーテルが永久的な記録の場所としての地位を弱めます。より困難ですが、より安全な方法は、まずトレントネットワークを構築し統合して、分散型で歴史を保存することです。ここで、「私たちはどれだけ努力するか」には2つの次元があります:1. 私たちはどのようにして最大のノードセットが実際にすべてのデータを保存していることを確保するために努力していますか?2. 我々は履歴ストレージをプロトコルに統合する深さはどのくらいですか?(に対する極端な偏執的アプローチは、証拠の保管を含むことになります: 実際には、各プルーフ・オブ・ステークのバリデーターに一定の割合の履歴を保存し、定期的にそれを暗号的に確認することを要求します。より穏やかなアプローチは、各クライアントが保存する履歴の割合に対して任意の基準を設定することです。)2(に関して、基本的な実装は今日完了した作業にのみ関わっています: ポータルは全てのイーサリアムの歴史を含むERAファイルを保存しています。より徹底的な実装は、実際にそれを同期プロセスに接続することを含みます。これにより、誰かが完全な歴史を保存するノードやアーカイブノードを同期したい場合、他のアーカイブノードがオンラインに存在しなくても、ポータルネットワークから直接同期することで実現できます。) それはロードマップの他の部分とどのように相互作用しますか?ノードの実行または起動を非常に簡単にしたい場合、履歴ストレージの要件を減らすことは、無状態性よりも重要だと言えます。ノードが必要とする1.1 TBのうち、約300 GBが状態で、残りの約800 GBは履歴となっています。無状態性とEIP-4444を実現することで、スマートウォッチ上でイーサリアムノードを実行し、わずか数分で設定できるというビジョンを実現できます。履歴ストレージの制限は、新しいイーサリアムノードの実装をより実現可能にし、プロトコルの最新バージョンのみをサポートすることで、これらをよりシンプルにします。例えば、2016年のDoS攻撃中に作成された空のストレージスロットがすべて削除されたため、多くのコード行を安全に削除できるようになりました。プルーフ・オブ・ステークへの移行が歴史となった今、クライアントはプルーフ・オブ・ワークに関連するすべてのコードを安全に削除できます。! [Vitalik:イーサリアムの可能な未来、パージ]###https://img-cdn.gateio.im/social/moments-b4e683a9e42e4b5bd6991a4cf6cf948e(## ステートの有効期限) は何の問題を解決しますか？クライアントが履歴を保存する必要がなくなったとしても、クライアントのストレージ需要は毎年約50GB増加し続けます。なぜなら、状態が持続的に増加するからです：アカウントの残高やランダム数、コントラクトコードやコントラクトストレージです。ユーザーは一度の費用を支払うことで、現在および将来のイーサリアムクライアントに永遠に負担をかけることになります。状態は歴史よりも"期限切れ"になるのが難しい。なぜなら、EVMは基本的にこうした仮定を元に設計されているからだ: 一度状態オブジェクトが作成されると、それは常に存在し、いつでも任意のトランザクションによって読み取られることができる。もし無状態性を導入すれば、この問題はそれほど悪くないかもしれないと考える人もいる: 専用のブロックビルダークラスだけが実際に状態を保存する必要があり、### などの他のすべてのノードは無状態で動作できる。しかし、無状態性に過度に依存したくないという意見もあり、最終的にはイーサリアムの分散化を維持するために状態を期限切れにすることを望むかもしれない。( それは何ですか、それはどのように機能しますか今日、新しいステートオブジェクトを作成するとき)は以下の3つの方法のいずれかで発生する可能性があります:###i( ETHを新しいアカウントに送信する、(ii) コードを使用して新しいアカウントを作成する、(iii) 以前に触れられていないストレージスロットを設定する(、このステートオブジェクトは常にその状態にあります。逆に、私たちが望むのは、オブジェクトが時間と共に自動的に期限切れになることです。重要な課題は、3つの目標を達成する方法でこれを行うことです:1. 効率:期限プロセスを実行するために大量の追加計算が必要ありません。2. ユーザーフレンドリー: 誰かが洞窟に5年間入って戻ってきた場合、彼らはETH、ERC20、NFT、CDPポジションへのアクセスを失うべきではない……3. 開発者の親しみやすさ: 開発者は全く慣れていない思考モデルに切り替える必要はありません。さらに、現在すでに硬直化していて更新されていないアプリケーションは、引き続き正常に動作する必要があります。これらの目標を満たさないと問題を解決するのが容易になります。たとえば、各状態オブジェクトに期限日カウンターを保存させることができます)はETHを燃やすことで期限を延ばすことができ、これはいつでも読み書き時に自動的に発生する可能性があります)、そして期限の過ぎた状態オブジェクトを削除するためのループを持つプロセスがあります。しかし、これにより追加の計算(およびストレージの要求が発生し)、ユーザーフレンドリーな要件を満たすことは確実にできません。開発者も、ストレージ値が時々ゼロにリセットされるエッジケースを推論するのが難しいです。契約の範囲内で期限タイマーを設定することは、技術的には開発者の生活を楽にしますが、経済的にはより困難になります：開発者は継続的なストレージコストをユーザーに"転嫁"する方法を考慮しなければなりません。これらはすべて、イーサリアムのコア開発コミュニティが長年にわたって取り組んできた問題であり、「ブロックチェーンの家賃」や「再生」といった提案が含まれています。最終的に、私たちは提案の中で最も良い部分を組み合わせ、「最も悪くない解決策」として知られる2つのカテゴリーに集中しました:- 部分的なステータスの古いソリューション- アドレス周期に基づく状態の期限切れ提案( 部分的な状態の有効期限一部の状態期限切れの提案は、同じ原則に従います。私たちは状態をブロックに分けます。すべての人は"トップマッピング"を永続的に保存します。そこではブロックが空であるか非空であるかです。各ブロック内のデータは、最近そのデータにアクセスされた場合にのみ保存されます。"復活"メカニズムがあり、もはや保存されない場合もあります。これらの提案の主な違いは:)i###「最近」をどのように定義するか、そして(ii)「ブロック」をどのように定義するかです。具体的な提案はEIP-7736であり、これはVerkleツリーに導入された「茎葉」デザインに基づいています(無状態状態のあらゆる形式、例えばバイナリツリーと互換性があります)。このデザインでは、隣接するヘッダー、コード、ストレージスロットが同じ「幹」の下に格納されます。一つの茎の下に格納されるデータの最大量は256 * 31 = 7,936バイトです。多くの場合、アカウントの全ヘッダーとコード、そして多数のキーのストレージスロットが同じ幹の下に格納されます。特定の幹の下のデータが6ヶ月間読み取られたり書き込まれたりしなかった場合、そのデータはもはや保存されず、そのデータの32バイトのみが保存されます。
イーサリアムThe Purge:ドロップ歴史ストレージ 簡素化プロトコル 持続可能性の向上
イーサリアムの可能な未来：The Purge
作者：ヴィタリック・ブテリン
イーサリアムが直面している課題は、デフォルトでどのブロックチェーンプロトコルも膨張と複雑性が時間とともに増加することです。これは2つの側面で発生します:
歴史データ:歴史上の任意の時点で行われた取引および作成されたアカウントは、すべてのクライアントによって永久に保存され、新しいクライアントがネットワークに完全に同期するためにダウンロードされる必要があります。これにより、クライアントの負荷および同期時間が増加し続けますが、チェーンの容量は変わりません。
プロトコルの機能: 新しい機能を追加することは古い機能を削除することよりもはるかに簡単であり、時間の経過とともにコードの複雑性が増加します。
イーサリアムが長期的に維持できるようにするためには、これら2つのトレンドに対して強力な逆圧力をかけ、時間とともに複雑性と膨張を減少させる必要があります。同時に、ブロックチェーンを偉大にするための重要な属性の1つである持続性を保持する必要があります。あなたはNFT、取引記録の中のラブレター、または100万ドルを含むスマートコントラクトをチェーン上に置くことができ、10年後にはそれがあなたの読み取りとインタラクションを待っているのです。DAppが安心して完全に非中央集権化し、アップグレードキーを削除するためには、彼らは依存関係が彼らを破壊する方法でアップグレードされることはないと確信する必要があります - 特にL1自体についてです。
もし私たちが決意し、この2つのニーズの間でバランスを取り、連続性を維持しながら、膨張、複雑性、衰退を最小限に抑えるか逆転させることができるなら、それは絶対に可能です。生物体はこれを実現できます：ほとんどの生物体は時間と共に老化しますが、少数の幸運な者はそうではありません。社会システムでさえ非常に長い寿命を持つことができます。ある場合には、イーサリアムは成功を収めています：プルーフ・オブ・ワークは消え、SELFDESTRUCT操作コードの大部分が消え、ビーコーンチェーンノードは最大6か月の古いデータを保存しています。イーサリアムのためにこの道をより一般的な方法で見つけ、長期的に安定した最終結果に向かうことが、イーサリアムの長期的なスケーラビリティ、技術的持続可能性、さらには安全性の究極の課題です。
ザ・パージの主な目標:
! ヴィタリック:イーサリアムの未来の可能性、パージ
履歴の有効期限
は何の問題を解決しますか？
この記事を書いている時点で、完全同期のイーサリアムノードはクライアントを実行するために約1.1 TBのディスクスペースを必要とし、さらにコンセンサスクライアント用に数百GBのディスクスペースが必要です。そのほとんどは履歴に関するものであり、歴史的なブロック、取引、領収書に関するデータが含まれており、そのほとんどは数年前のものです。これは、Gas制限が全く増加しなくても、ノードのサイズは毎年数百GB増加し続けることを意味します。
それは何ですか、それはどのように機能しますか？
歴史的なストレージの問題の重要な簡略化された特徴は、各ブロックがハッシュでリンクされているため(、そして他の構造)が前のブロックを指しているため、現在の合意に達することが歴史に対する合意に十分であるということです。ネットワークが最新のブロックに合意すれば、任意の歴史的ブロックやトランザクション、または状態(のアカウント残高、乱数、コード、ストレージ)は、任意の単一の参加者によって提供され、マークル証明によって提供されることができます。そして、その証明は他の誰でもその正確性を検証できることを許します。合意はN/2-of-Nの信頼モデルであり、歴史はN-of-Nの信頼モデルです。
これは、私たちが履歴をどのように保存するかについて、多くの選択肢を提供します。自然な選択肢の一つは、各ノードがデータの小さな部分のみを保存するネットワークです。これが、数十年間にわたってシードネットワークが機能してきた方法です: ネットワーク全体では数百万のファイルを保存および配布していますが、各参加者はその中の数ファイルのみを保存および配布しています。直感に反して、このアプローチはデータの堅牢性を低下させるわけではないかもしれません。もし、ノードをより経済的に運営することで、各ノードがランダムに10％の履歴を保存する100,000のノードを持つネットワークを構築できるなら、各データは10,000回コピーされることになります - これは、すべての内容を保存する各ノードを持つ10,000ノードのネットワークとまったく同じコピー因子です。
現在、イーサリアムは全ノードがすべての履歴を永久に保存するモデルから脱却し始めています。コンセンサスブロック(は、ステークプルーフコンセンサスに関連する部分)が約6ヶ月間のみ保存されます。Blobは約18日間のみ保存されます。EIP-4444は、履歴ブロックとレシートに1年の保存期間を導入することを目的としています。長期的な目標は、統一された期間(が約18日間)であり、この期間中に各ノードがすべてのコンテンツを保存し、その後、イーサリアムノードからなるピアツーピアネットワークを構築し、古いデータを分散ネットワーク方式で保存することです。
エラージャーコードは、ロバスト性を向上させながら、レプリケーションファクターを同じに保つために使用できます。実際、Blobはデータの可用性サンプリングをサポートするためにエラージャーコードを使用しています。最も簡単な解決策は、おそらくこのエラージャーコードを再利用し、実行とコンセンサスブロックデータもBlobに入れることです。
は既存の研究とどのような関連がありますか?
まだ何をする必要がありますか、何を天秤にかける必要がありますか？
残りの主な作業には、履歴を保存するための具体的な分散ソリューションの構築と統合が含まれます——少なくとも実行履歴ですが、最終的にはコンセンサスとblobも含まれます。最も簡単なソリューションは(i)既存のtorrentライブラリを導入することと、(ii)エーテルのネイティブソリューションであるPortalネットワークを導入することです。どちらかを導入すれば、EIP-4444を開くことができます。EIP-4444自体はハードフォークを必要としませんが、新しいネットワークプロトコルのバージョンが必要です。したがって、すべてのクライアントで同時に有効にすることが価値があります。そうしないと、他のノードに接続して完全な履歴をダウンロードすることを期待しているが、実際には取得できていないためにクライアントが故障するリスクがあります。
主要なトレードオフは、私たちが「古代」の歴史データを提供するためにどのように努力するかに関わっています。最も簡単な解決策は、明日古代の歴史の保存を停止し、既存のアーカイブノードとさまざまな集中型プロバイダーに依存して複製することです。これは簡単ですが、エーテルが永久的な記録の場所としての地位を弱めます。より困難ですが、より安全な方法は、まずトレントネットワークを構築し統合して、分散型で歴史を保存することです。ここで、「私たちはどれだけ努力するか」には2つの次元があります:
私たちはどのようにして最大のノードセットが実際にすべてのデータを保存していることを確保するために努力していますか?
我々は履歴ストレージをプロトコルに統合する深さはどのくらいですか?
(に対する極端な偏執的アプローチは、証拠の保管を含むことになります: 実際には、各プルーフ・オブ・ステークのバリデーターに一定の割合の履歴を保存し、定期的にそれを暗号的に確認することを要求します。より穏やかなアプローチは、各クライアントが保存する履歴の割合に対して任意の基準を設定することです。
)2(に関して、基本的な実装は今日完了した作業にのみ関わっています: ポータルは全てのイーサリアムの歴史を含むERAファイルを保存しています。より徹底的な実装は、実際にそれを同期プロセスに接続することを含みます。これにより、誰かが完全な歴史を保存するノードやアーカイブノードを同期したい場合、他のアーカイブノードがオンラインに存在しなくても、ポータルネットワークから直接同期することで実現できます。
) それはロードマップの他の部分とどのように相互作用しますか?
ノードの実行または起動を非常に簡単にしたい場合、履歴ストレージの要件を減らすことは、無状態性よりも重要だと言えます。ノードが必要とする1.1 TBのうち、約300 GBが状態で、残りの約800 GBは履歴となっています。無状態性とEIP-4444を実現することで、スマートウォッチ上でイーサリアムノードを実行し、わずか数分で設定できるというビジョンを実現できます。
履歴ストレージの制限は、新しいイーサリアムノードの実装をより実現可能にし、プロトコルの最新バージョンのみをサポートすることで、これらをよりシンプルにします。例えば、2016年のDoS攻撃中に作成された空のストレージスロットがすべて削除されたため、多くのコード行を安全に削除できるようになりました。プルーフ・オブ・ステークへの移行が歴史となった今、クライアントはプルーフ・オブ・ワークに関連するすべてのコードを安全に削除できます。
! [Vitalik:イーサリアムの可能な未来、パージ]###https://img-cdn.gateio.im/webp-social/moments-b4e683a9e42e4b5bd6991a4cf6cf948e.webp(
ステートの有効期限
) は何の問題を解決しますか？
クライアントが履歴を保存する必要がなくなったとしても、クライアントのストレージ需要は毎年約50GB増加し続けます。なぜなら、状態が持続的に増加するからです：アカウントの残高やランダム数、コントラクトコードやコントラクトストレージです。ユーザーは一度の費用を支払うことで、現在および将来のイーサリアムクライアントに永遠に負担をかけることになります。
状態は歴史よりも"期限切れ"になるのが難しい。なぜなら、EVMは基本的にこうした仮定を元に設計されているからだ: 一度状態オブジェクトが作成されると、それは常に存在し、いつでも任意のトランザクションによって読み取られることができる。もし無状態性を導入すれば、この問題はそれほど悪くないかもしれないと考える人もいる: 専用のブロックビルダークラスだけが実際に状態を保存する必要があり、### などの他のすべてのノードは無状態で動作できる。しかし、無状態性に過度に依存したくないという意見もあり、最終的にはイーサリアムの分散化を維持するために状態を期限切れにすることを望むかもしれない。
( それは何ですか、それはどのように機能しますか
今日、新しいステートオブジェクトを作成するとき)は以下の3つの方法のいずれかで発生する可能性があります:###i( ETHを新しいアカウントに送信する、(ii) コードを使用して新しいアカウントを作成する、(iii) 以前に触れられていないストレージスロットを設定する(、このステートオブジェクトは常にその状態にあります。逆に、私たちが望むのは、オブジェクトが時間と共に自動的に期限切れになることです。重要な課題は、3つの目標を達成する方法でこれを行うことです:
効率:期限プロセスを実行するために大量の追加計算が必要ありません。
ユーザーフレンドリー: 誰かが洞窟に5年間入って戻ってきた場合、彼らはETH、ERC20、NFT、CDPポジションへのアクセスを失うべきではない……
開発者の親しみやすさ: 開発者は全く慣れていない思考モデルに切り替える必要はありません。さらに、現在すでに硬直化していて更新されていないアプリケーションは、引き続き正常に動作する必要があります。
これらの目標を満たさないと問題を解決するのが容易になります。たとえば、各状態オブジェクトに期限日カウンターを保存させることができます)はETHを燃やすことで期限を延ばすことができ、これはいつでも読み書き時に自動的に発生する可能性があります)、そして期限の過ぎた状態オブジェクトを削除するためのループを持つプロセスがあります。しかし、これにより追加の計算(およびストレージの要求が発生し)、ユーザーフレンドリーな要件を満たすことは確実にできません。開発者も、ストレージ値が時々ゼロにリセットされるエッジケースを推論するのが難しいです。契約の範囲内で期限タイマーを設定することは、技術的には開発者の生活を楽にしますが、経済的にはより困難になります：開発者は継続的なストレージコストをユーザーに"転嫁"する方法を考慮しなければなりません。
これらはすべて、イーサリアムのコア開発コミュニティが長年にわたって取り組んできた問題であり、「ブロックチェーンの家賃」や「再生」といった提案が含まれています。最終的に、私たちは提案の中で最も良い部分を組み合わせ、「最も悪くない解決策」として知られる2つのカテゴリーに集中しました:
( 部分的な状態の有効期限
一部の状態期限切れの提案は、同じ原則に従います。私たちは状態をブロックに分けます。すべての人は"トップマッピング"を永続的に保存します。そこではブロックが空であるか非空であるかです。各ブロック内のデータは、最近そのデータにアクセスされた場合にのみ保存されます。"復活"メカニズムがあり、もはや保存されない場合もあります。
これらの提案の主な違いは:)i###「最近」をどのように定義するか、そして(ii)「ブロック」をどのように定義するかです。具体的な提案はEIP-7736であり、これはVerkleツリーに導入された「茎葉」デザインに基づいています(無状態状態のあらゆる形式、例えばバイナリツリーと互換性があります)。このデザインでは、隣接するヘッダー、コード、ストレージスロットが同じ「幹」の下に格納されます。一つの茎の下に格納されるデータの最大量は256 * 31 = 7,936バイトです。多くの場合、アカウントの全ヘッダーとコード、そして多数のキーのストレージスロットが同じ幹の下に格納されます。特定の幹の下のデータが6ヶ月間読み取られたり書き込まれたりしなかった場合、そのデータはもはや保存されず、そのデータの32バイトのみが保存されます。