# イーサリアムの可能な未来: The Purgeイーサリアムが直面している課題の一つは、デフォルトで、あらゆるブロックチェーンプロトコルの膨張と複雑性が時間とともに増加することである。これは二つの場所で発生する。履歴データ：歴史上のいかなる時点で行われた取引や作成されたアカウントは、すべてのクライアントによって永続的に保存され、新しいクライアントによってダウンロードされ、ネットワークに完全に同期される必要があります。これにより、クライアントの負荷と同期時間が時間の経過とともに増加し続け、チェーンの容量が変わらない場合でも影響を受けます。プロトコルの機能:新しい機能を追加することは古い機能を削除することよりもはるかに簡単であり、その結果、時間の経過とともにコードの複雑性が増加します。イーサリアムが長期的に維持されるためには、これら二つのトレンドに対して強力な反圧をかけ、時間の経過とともに複雑さと膨張を減少させる必要があります。しかし同時に、ブロックチェーンを素晴らしいものにする重要な特性の一つである持続性を保持する必要があります。あなたはNFT、取引通話データの中のラブレター、または100万ドルを含むスマートコントラクトをチェーン上に置くことができ、洞窟に10年間入って、出てきたときにはそれがまだあなたの読書とインタラクションを待っていることに気づくでしょう。DAppが安心して完全に非中央集権化し、アップグレードキーを削除するためには、彼らの依存関係が彼らを破壊する形でアップグレードされないことを確信する必要があります - 特にL1自体について。私たちが決意し、この二つの需要の間でバランスを取り、継続性を維持しつつ、肥大化、複雑性、そして衰退を最小限に抑えたり逆転させたりすることは、絶対に可能です。生物体はこれを実現できます。ほとんどの生物体は時間とともに老化しますが、幸運な少数はそうではありません。社会システムでさえ、非常に長い寿命を持つことができます。いくつかのケースでは、イーサリアムは成功を収めています。プルーフ・オブ・ワークは消え、SELFDESTRUCT オペコードの大部分が消失し、ビーコンサインノードは最大六ヶ月の古いデータを保存しています。より一般的な方法でイーサリアムのためのこの道を見つけ、長期的に安定した最終結果に向かうことは、イーサリアムの長期的なスケーラビリティ、技術的持続可能性、さらには安全性の究極の課題です。! [ヴィタリック:イーサリアムの可能な未来、パージ] (ian/2024/10/27/images/82bf476df163c6707fccf140ec382f88.jpg)ザ・パージ：主要目標。各ノードがすべての履歴や最終状態を永続的に保存する必要性を減らすか排除することで、クライアントのストレージ要件を低減します。不要な機能を排除することで、プロトコルの複雑さを低減します。目次:履歴expiry( 履歴の有効期限が切れる)状態expiry( ) 状態が期限切れになります機能クリーンアップ(特征清理)## 履歴の有効期限### は何の問題を解決しますか？本稿執筆時点で、完全同期のイーサリアムノードはクライアントを実行するために約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日間)であり、その期間中は各ノードがすべてのコンテンツを保存する責任を負い、その後、イーサリアムノードで構成されるピアツーピアネットワークを構築し、古いデータを分散ネットワーク方式で保存します。! [Vitalik: イーサリアムの未来の可能性、パージ] (ian/2024/10/27/images/f62684c615eed31373c7711933176f43.jpg)エラージャーコードは、ロバスト性を高めるために使用でき、同時にレプリケーションファクターを同じに保つことができます。実際、Blobはデータの可用性サンプリングをサポートするためにエラージャーコードを適用しています。最も簡単な解決策は、おそらくこのエラージャーコードを再利用し、実行とコンセンサスブロックデータもBlobに入れることです。### は既存の研究とどのような関係がありますか?EIP-4444;トレントとEIP-4444;ポータルネットワーク;ポータルネットワークと EIP-4444;Portal 中の SSZ オブジェクトの分散ストレージと検索;ガス制限をどのように引き上げる(Paradigm)。### まだ何をする必要があり、何を考慮する必要がありますか？残りの主な作業は、履歴を保存するための具体的な分散ソリューションを構築し統合することです------少なくとも実行履歴ですが、最終的には合意と blob も含まれます。最も簡単なソリューションは (i)、既存のトレントライブラリを単純に導入することと、(ii)、Portalネットワークと呼ばれるイーサリアムのネイティブソリューションです。これらのいずれかを導入すれば、EIP-4444を開くことができます。EIP-4444自体はハードフォークを必要としませんが、新しいネットワークプロトコルのバージョンが必要です。したがって、すべてのクライアントに同時に有効にすることが価値があります。そうしないと、他のノードに接続して完全な履歴をダウンロードすることを期待しているのに、実際には取得できないためにクライアントが故障するリスクが存在します。主なトレードオフは、私たちが「古代」の歴史データを提供するためにどのように努力しているかに関係しています。最も簡単な解決策は、明日古代の歴史の保存を停止し、既存のアーカイブノードとさまざまな集中型プロバイダーに依存して複製することです。これは簡単ですが、エーテルが永久記録の場としての地位を弱体化させます。より困難ですが安全なアプローチは、まずトレントネットワークを構築し統合して、分散方式で履歴を保存することです。ここで、「私たちはどれだけ努力するか」には2つの次元があります:私たちは、最大のノードセットが実際にすべてのデータを保存していることをどのように確保していますか?プロトコルに統合された歴史ストレージの深さはどのくらいですか?(1)に関する極端な偏執的アプローチは、保管証明を含む: 実際には、各ステークプルーフバリデーターに一定の割合の履歴を保存させ、それを定期的に暗号的に確認することを要求します。より穏やかなアプローチは、各クライアントが保存する履歴のパーセンテージに対して任意の基準を設定することです。(2)について、基本的な実装は今日すでに完了した作業にのみ関与しています: ポータルは、全エーテルの歴史を含むERAファイルを保存しています。より徹底的な実装は、実際にそれを同期プロセスに接続することを含みます。そうすることで、誰かが完全な履歴ストレージノードまたはアーカイブノードを同期したい場合、他のアーカイブノードがオンラインで存在しなくても、ポータルネットワークから直接同期することで実現できます。### それはロードマップの他の部分とどのように相互作用しますか?ノードの実行または起動を非常に簡単にしたい場合、履歴ストレージの要件を減らすことは無状態性よりも重要だと言えます：ノードが必要とする1.1 TBのうち、約300 GBは状態で、残りの約800 GBは履歴となっています。無状態性とEIP-4444を実現することで、スマートウォッチ上でイーサリアムノードを実行し、数分で設定するというビジョンを実現できます。履歴ストレージの制限は、より新しいイーサリアムノードの実装をより実行可能にし、プロトコルの最新バージョンのみをサポートすることで、これらをよりシンプルにします。例えば、2016年のDoS攻撃中に作成された空のストレージスロットがすべて削除されたため、多くのコード行を安全に削除できるようになりました。プルーフ・オブ・ステークへの移行が歴史となった今、クライアントはプルーフ・オブ・ワークに関連するすべてのコードを安全に削除できます。! [Vitalik: Ethereum's Possible Future, The Purge] (ian/2024/10/27/images/b3e2c5d4e7e1d40234643b84b51b43c1.jpg)## ステートの有効期限### は何の問題を解決しますか?クライアントの履歴を保存する必要がなくなったとしても、クライアントのストレージニーズは毎年約50GB増加し続けます。なぜなら、状態が継続的に増加するからです：アカウントの残高や乱数、契約コード、契約ストレージです。ユーザーは一度だけ料金を支払うことで、現在および将来のイーサリアムクライアントに永遠に負担をかけることになります。状態は歴史よりも「期限切れ」にするのが難しい。なぜなら、EVMは根本的にこの仮定に基づいて設計されているからだ: 一度状態オブジェクトが作成されると、それは常に存在し、いつでも任意のトランザクションによって読み取ることができる。もし無状態性を導入した場合、この問題はそれほど悪くないかもしれないと考える人もいる: 専門のブロックビルダークラスだけが実際に状態を保存する必要があり、他のすべてのノード(やリスト生成を含む)は無状態で動作できる。しかし、無状態性に過度に依存したくないという見解もあり、最終的にはイーサリアムの分散化を維持するために状態を期限切れにしたいと考えるかもしれない。### それは何ですか、それはどのように機能しますか今日、新しい状態オブジェクトを作成するとき(は次の3つの方法のいずれかで発生する可能性があります:(i)新しいアカウントにETHを送信する、(ii)コードを使用して新しいアカウントを作成する、(iii)以前に触れられていないストレージスロットを設定する)、状態オブジェクトはその状態のままになります。逆に、我々が望むのは、オブジェクトが時間とともに自動的に期限切れになることです。重要な課題は、3つの目標を達成する方法でこれを行うことです:効率:期限プロセスを実行するために大量の追加計算が必要ありません。ユーザーフレンドリー: 誰かが5年間洞窟に入って戻ってきた場合、彼らはETH、ERC20、NFT、CDPポジションへのアクセスを失うべきではありません......開発者の親しみやすさ: 開発者は全く不慣れな思考モデルに切り替える必要がありません。また、現在固まっていて更新されていないアプリケーションは、引き続き正常に動作するべきです。これらの目標を満たさないと、問題を解決するのが簡単になります。たとえば、各状態オブジェクトが有効期限カウンターを保持することができます。(はETHを燃焼させることで有効期限を延長でき、これはいつでも読み書きの際に自動的に発生する可能性があります)。そして、有効期限を過ぎた状態オブジェクトを削除するためのプロセス状態オブジェクトをループして遍歴する必要があります。しかし、これにより追加の計算(やストレージの要求が生じます)、そして確実にユーザーフレンドリーの要件を満たすことはできません。開発者は、ストレージ値が時折ゼロにリセットされるエッジケースを推論するのも難しいです。契約の範囲内に有効期限タイマーを設定すると、技術的には開発者の生活が楽になりますが、経済的にはより困難になります。開発者は、持続的なストレージコストをユーザーに"転嫁"する方法を考慮しなければなりません。これらはすべて、イーサリアムのコア開発コミュニティが長年にわたって解決に取り組んできた問題であり、「ブロックチェーンレンタル」や「再生」などの提案を含んでいます。最終的に、私たちは提案の中で最も良い部分を組み合わせ、2つの「最も悪くない解決策」に集中しました:* 一部のステータスの期限切れ解決策* アドレス周期に基づくステータスの期限推奨。### 部分的な状態の有効期限部分の状態が期限切れの提案は同じ原則に従います。我々は状態をブロックに分割します。誰もが"トップマッピング"を永久に保存し、ブロックが空であるかどうかを示します。最近そのデータにアクセスされていない場合、各ブロック内のデータは保存されません。"復活"メカニズムがあり、もはや保存されていない場合に働きます。! 【ヴィタリック:イーサリアムの可能な未来、パージ』(
イーサリアムThe Purge計画:ドロップストレージ要件とプロトコルの複雑さを簡素化する
イーサリアムの可能な未来: The Purge
イーサリアムが直面している課題の一つは、デフォルトで、あらゆるブロックチェーンプロトコルの膨張と複雑性が時間とともに増加することである。これは二つの場所で発生する。
履歴データ：歴史上のいかなる時点で行われた取引や作成されたアカウントは、すべてのクライアントによって永続的に保存され、新しいクライアントによってダウンロードされ、ネットワークに完全に同期される必要があります。これにより、クライアントの負荷と同期時間が時間の経過とともに増加し続け、チェーンの容量が変わらない場合でも影響を受けます。
プロトコルの機能:新しい機能を追加することは古い機能を削除することよりもはるかに簡単であり、その結果、時間の経過とともにコードの複雑性が増加します。
イーサリアムが長期的に維持されるためには、これら二つのトレンドに対して強力な反圧をかけ、時間の経過とともに複雑さと膨張を減少させる必要があります。しかし同時に、ブロックチェーンを素晴らしいものにする重要な特性の一つである持続性を保持する必要があります。あなたはNFT、取引通話データの中のラブレター、または100万ドルを含むスマートコントラクトをチェーン上に置くことができ、洞窟に10年間入って、出てきたときにはそれがまだあなたの読書とインタラクションを待っていることに気づくでしょう。DAppが安心して完全に非中央集権化し、アップグレードキーを削除するためには、彼らの依存関係が彼らを破壊する形でアップグレードされないことを確信する必要があります - 特にL1自体について。
私たちが決意し、この二つの需要の間でバランスを取り、継続性を維持しつつ、肥大化、複雑性、そして衰退を最小限に抑えたり逆転させたりすることは、絶対に可能です。生物体はこれを実現できます。ほとんどの生物体は時間とともに老化しますが、幸運な少数はそうではありません。社会システムでさえ、非常に長い寿命を持つことができます。いくつかのケースでは、イーサリアムは成功を収めています。プルーフ・オブ・ワークは消え、SELFDESTRUCT オペコードの大部分が消失し、ビーコンサインノードは最大六ヶ月の古いデータを保存しています。より一般的な方法でイーサリアムのためのこの道を見つけ、長期的に安定した最終結果に向かうことは、イーサリアムの長期的なスケーラビリティ、技術的持続可能性、さらには安全性の究極の課題です。
! [ヴィタリック:イーサリアムの可能な未来、パージ] (ian/2024/10/27/images/82bf476df163c6707fccf140ec382f88.jpg)
ザ・パージ：主要目標。
各ノードがすべての履歴や最終状態を永続的に保存する必要性を減らすか排除することで、クライアントのストレージ要件を低減します。
不要な機能を排除することで、プロトコルの複雑さを低減します。
目次:
履歴expiry( 履歴の有効期限が切れる)
状態expiry( ) 状態が期限切れになります
機能クリーンアップ(特征清理)
履歴の有効期限
は何の問題を解決しますか？
本稿執筆時点で、完全同期のイーサリアムノードはクライアントを実行するために約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日間)であり、その期間中は各ノードがすべてのコンテンツを保存する責任を負い、その後、イーサリアムノードで構成されるピアツーピアネットワークを構築し、古いデータを分散ネットワーク方式で保存します。
! [Vitalik: イーサリアムの未来の可能性、パージ] (ian/2024/10/27/images/f62684c615eed31373c7711933176f43.jpg)
エラージャーコードは、ロバスト性を高めるために使用でき、同時にレプリケーションファクターを同じに保つことができます。実際、Blobはデータの可用性サンプリングをサポートするためにエラージャーコードを適用しています。最も簡単な解決策は、おそらくこのエラージャーコードを再利用し、実行とコンセンサスブロックデータもBlobに入れることです。
は既存の研究とどのような関係がありますか?
EIP-4444;
トレントとEIP-4444;
ポータルネットワーク;
ポータルネットワークと EIP-4444;
Portal 中の SSZ オブジェクトの分散ストレージと検索;
ガス制限をどのように引き上げる(Paradigm)。
まだ何をする必要があり、何を考慮する必要がありますか？
残りの主な作業は、履歴を保存するための具体的な分散ソリューションを構築し統合することです------少なくとも実行履歴ですが、最終的には合意と blob も含まれます。最も簡単なソリューションは (i)、既存のトレントライブラリを単純に導入することと、(ii)、Portalネットワークと呼ばれるイーサリアムのネイティブソリューションです。これらのいずれかを導入すれば、EIP-4444を開くことができます。EIP-4444自体はハードフォークを必要としませんが、新しいネットワークプロトコルのバージョンが必要です。したがって、すべてのクライアントに同時に有効にすることが価値があります。そうしないと、他のノードに接続して完全な履歴をダウンロードすることを期待しているのに、実際には取得できないためにクライアントが故障するリスクが存在します。
主なトレードオフは、私たちが「古代」の歴史データを提供するためにどのように努力しているかに関係しています。最も簡単な解決策は、明日古代の歴史の保存を停止し、既存のアーカイブノードとさまざまな集中型プロバイダーに依存して複製することです。これは簡単ですが、エーテルが永久記録の場としての地位を弱体化させます。より困難ですが安全なアプローチは、まずトレントネットワークを構築し統合して、分散方式で履歴を保存することです。ここで、「私たちはどれだけ努力するか」には2つの次元があります:
私たちは、最大のノードセットが実際にすべてのデータを保存していることをどのように確保していますか?
プロトコルに統合された歴史ストレージの深さはどのくらいですか?
(1)に関する極端な偏執的アプローチは、保管証明を含む: 実際には、各ステークプルーフバリデーターに一定の割合の履歴を保存させ、それを定期的に暗号的に確認することを要求します。より穏やかなアプローチは、各クライアントが保存する履歴のパーセンテージに対して任意の基準を設定することです。
(2)について、基本的な実装は今日すでに完了した作業にのみ関与しています: ポータルは、全エーテルの歴史を含むERAファイルを保存しています。より徹底的な実装は、実際にそれを同期プロセスに接続することを含みます。そうすることで、誰かが完全な履歴ストレージノードまたはアーカイブノードを同期したい場合、他のアーカイブノードがオンラインで存在しなくても、ポータルネットワークから直接同期することで実現できます。
それはロードマップの他の部分とどのように相互作用しますか?
ノードの実行または起動を非常に簡単にしたい場合、履歴ストレージの要件を減らすことは無状態性よりも重要だと言えます：ノードが必要とする1.1 TBのうち、約300 GBは状態で、残りの約800 GBは履歴となっています。無状態性とEIP-4444を実現することで、スマートウォッチ上でイーサリアムノードを実行し、数分で設定するというビジョンを実現できます。
履歴ストレージの制限は、より新しいイーサリアムノードの実装をより実行可能にし、プロトコルの最新バージョンのみをサポートすることで、これらをよりシンプルにします。例えば、2016年のDoS攻撃中に作成された空のストレージスロットがすべて削除されたため、多くのコード行を安全に削除できるようになりました。プルーフ・オブ・ステークへの移行が歴史となった今、クライアントはプルーフ・オブ・ワークに関連するすべてのコードを安全に削除できます。
! [Vitalik: Ethereum's Possible Future, The Purge] (ian/2024/10/27/images/b3e2c5d4e7e1d40234643b84b51b43c1.jpg)
ステートの有効期限
は何の問題を解決しますか?
クライアントの履歴を保存する必要がなくなったとしても、クライアントのストレージニーズは毎年約50GB増加し続けます。なぜなら、状態が継続的に増加するからです：アカウントの残高や乱数、契約コード、契約ストレージです。ユーザーは一度だけ料金を支払うことで、現在および将来のイーサリアムクライアントに永遠に負担をかけることになります。
状態は歴史よりも「期限切れ」にするのが難しい。なぜなら、EVMは根本的にこの仮定に基づいて設計されているからだ: 一度状態オブジェクトが作成されると、それは常に存在し、いつでも任意のトランザクションによって読み取ることができる。もし無状態性を導入した場合、この問題はそれほど悪くないかもしれないと考える人もいる: 専門のブロックビルダークラスだけが実際に状態を保存する必要があり、他のすべてのノード(やリスト生成を含む)は無状態で動作できる。しかし、無状態性に過度に依存したくないという見解もあり、最終的にはイーサリアムの分散化を維持するために状態を期限切れにしたいと考えるかもしれない。
それは何ですか、それはどのように機能しますか
今日、新しい状態オブジェクトを作成するとき(は次の3つの方法のいずれかで発生する可能性があります:(i)新しいアカウントにETHを送信する、(ii)コードを使用して新しいアカウントを作成する、(iii)以前に触れられていないストレージスロットを設定する)、状態オブジェクトはその状態のままになります。逆に、我々が望むのは、オブジェクトが時間とともに自動的に期限切れになることです。重要な課題は、3つの目標を達成する方法でこれを行うことです:
効率:期限プロセスを実行するために大量の追加計算が必要ありません。
ユーザーフレンドリー: 誰かが5年間洞窟に入って戻ってきた場合、彼らはETH、ERC20、NFT、CDPポジションへのアクセスを失うべきではありません......
開発者の親しみやすさ: 開発者は全く不慣れな思考モデルに切り替える必要がありません。また、現在固まっていて更新されていないアプリケーションは、引き続き正常に動作するべきです。
これらの目標を満たさないと、問題を解決するのが簡単になります。たとえば、各状態オブジェクトが有効期限カウンターを保持することができます。(はETHを燃焼させることで有効期限を延長でき、これはいつでも読み書きの際に自動的に発生する可能性があります)。そして、有効期限を過ぎた状態オブジェクトを削除するためのプロセス状態オブジェクトをループして遍歴する必要があります。しかし、これにより追加の計算(やストレージの要求が生じます)、そして確実にユーザーフレンドリーの要件を満たすことはできません。開発者は、ストレージ値が時折ゼロにリセットされるエッジケースを推論するのも難しいです。契約の範囲内に有効期限タイマーを設定すると、技術的には開発者の生活が楽になりますが、経済的にはより困難になります。開発者は、持続的なストレージコストをユーザーに"転嫁"する方法を考慮しなければなりません。
これらはすべて、イーサリアムのコア開発コミュニティが長年にわたって解決に取り組んできた問題であり、「ブロックチェーンレンタル」や「再生」などの提案を含んでいます。最終的に、私たちは提案の中で最も良い部分を組み合わせ、2つの「最も悪くない解決策」に集中しました:
部分的な状態の有効期限
部分の状態が期限切れの提案は同じ原則に従います。我々は状態をブロックに分割します。誰もが"トップマッピング"を永久に保存し、ブロックが空であるかどうかを示します。最近そのデータにアクセスされていない場合、各ブロック内のデータは保存されません。"復活"メカニズムがあり、もはや保存されていない場合に働きます。
! 【ヴィタリック:イーサリアムの可能な未来、パージ』(