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