ヴィタリック：イーサリアムの可能な未来、The Purge

イーサリアムが直面する課題の一つは、デフォルトで、どのブロックチェーンプロトコルも時間の経過とともに膨張と複雑性が増加することです。これは二つの場所で発生します：

歴史データ：歴史上の任意の時点で行われた任意の取引および作成された任意のアカウントは、すべてのクライアントによって永久に保存され、新しいクライアントによってダウンロードされ、ネットワークと完全に同期される必要があります。これにより、クライアントの負荷と同期時間が時間の経過とともに増加し続け、チェーンの容量が変わらなくてもそうなります。

プロトコル機能：新しい機能を追加する方が古い機能を削除するよりもはるかに簡単であるため、時間の経過とともにコードの複雑性が増加します。

イーサリアムが長期的に維持されるためには、この2つのトレンドに対して強力な反圧をかけ、時間の経過とともに複雑さと膨張を減らす必要があります。しかし同時に、ブロックチェーンを偉大にする重要な属性の1つである持続性を保持する必要があります。NFT、取引通話データの中のラブレター、または100万ドルを含むスマートコントラクトをチェーン上に置いて、洞窟の中に10年入って出てきたとき、それがまだそこにあってあなたが読むことや相互作用することを待っていることを発見することができます。DAppが安心して完全に分散化し、アップグレードキーを削除するためには、彼らの依存関係が破壊的な方法でアップグレードされないことを確信する必要があります - 特にL1自体についてです。

もし私たちが決意し、この二つの需要の間でバランスを取り、連続性を保ちながら、肥大化、複雑性、そして衰退を最大限に減らすか、逆転させることができれば、それは絶対に可能です。生物はこれを実現できます：ほとんどの生物は時間とともに老化しますが、少数の幸運な者は老化しません。社会システムさえも非常に長い寿命を持つことができます。ある場合には、イーサリアムは成功を収めました：プルーフ・オブ・ワークは消え、SELFDESTRUCTオペコードはほとんど消え、ビーコンサインのノードは最大六ヶ月の古いデータを保存しています。イーサリアムにとって、この道をより一般的な方法で見つけ、長期的に安定した最終結果に向かうことは、イーサリアムの長期的なスケーラビリティ、技術的持続可能性、さらには安全性の究極の課題です。

! ヴィタリック:イーサリアムの未来の可能性、パージ

ザ・パージ：主要目標。

クライアントのストレージ要件を削減するために、各ノードがすべての履歴や最終状態を永久に保存する必要を減少または排除します。

不要な機能を排除することでプロトコルの複雑さを低減します。

目次:

履歴の有効期限

ステートエクスパイア（状態到期）

フィーチャークリーニング（特征清理）

履歴の有効期限

は何の問題を解決しますか？

この記事執筆時点で、完全に同期されたイーサリアムノードは、クライアントを実行するために約1.1 TBのディスクスペースを必要とし、さらにコンセンサスクライアント用に数百GBのディスクスペースが必要です。その大部分は履歴データであり、歴史的なブロック、取引、及びレシートに関するデータで、そのほとんどは何年も前のものです。これは、Gas制限がまったく増加しなくても、ノードのサイズが毎年数百GB増加し続けることを意味します。

それは何ですか、それはどのように機能しますか？

歴史的なストレージの問題の一つの重要な簡略化された特徴は、各ブロックがハッシュリンク（および他の構造）によって前のブロックを指しているため、現在の合意に達することが歴史的な合意に達するのに十分であるということです。ネットワークが最新のブロックに対して合意に達すれば、いかなる歴史的なブロックやトランザクション、または状態（アカウント残高、乱数、コード、ストレージ）は、任意の単一の参加者によって提供され、メルクル証明が行われ、その証明は他の誰でもその正確性を検証することを可能にします。合意はN/2-of-N信頼モデルであり、歴史はN-of-N信頼モデルです。

これにより、私たちは履歴を保存する方法について多くの選択肢を得ることができます。自然な選択肢の一つは、各ノードがデータのほんの一部だけを保存するネットワークです。これが数十年間にわたってシードネットワークが機能してきた方法です：ネットワーク全体が数百万のファイルを保存および配布しているにもかかわらず、各参加者はその中のいくつかのファイルだけを保存および配布します。直感に反するかもしれませんが、このアプローチはデータの堅牢性を必ずしも低下させるわけではありません。ノードをより経済的に運営することによって、各ノードがランダムに10％の履歴を保存する100,000のノードを持つネットワークを構築できれば、各データは10,000回複製されます - これは10,000のノードの複製係数とまったく同じです - 各ノードがすべての内容を保存するノードネットワークです。

! Vitalik:イーサリアムの可能な未来、パージ

今、イーサリアムはすべてのノードがすべての履歴を永久に保存するモデルから脱却し始めています。コンセンサスブロック（つまり、プルーフオブステークコンセンサスに関連する部分）は約6か月間のみ保存されます。Blobは約18日間のみ保存されます。EIP-4444は、履歴ブロックとレシートに1年間の保存期間を導入することを目的としています。長期的な目標は、すべてのノードがすべてのコンテンツを保存する責任を持つ統一された期間（おそらく約18日間）を確立し、その後、イーサリアムノードで構成されるピアツーピアネットワークを構築し、古いデータを分散型ネットワーク方式で保存することです。

Erasure codesは堅牢性を高めるために使用でき、同時にレプリケーションファクターを同じに保つことができます。実際、Blobはデータ可用性サンプリングをサポートするためにエラー訂正コードを使用しています。最も簡単な解決策は、これらのErasure codesを再利用し、実行とコンセンサスブロックデータもblobに含めることかもしれません。

と既存の研究にはどのような関連がありますか？

EIP-4444;

トレントとEIP-4444；

ポータルネットワーク；

ポータルネットワークと EIP-4444；

Portal 中の SSZ オブジェクトの分散ストレージと検索；

ガス制限を上げる方法（パラダイム）。

まだ何をする必要がありますか、何を考慮する必要がありますか？

残りの主要な作業には、実行履歴を少なくとも保持する具体的な分散ソリューションを構築および統合することが含まれますが、最終的にはコンセンサスとblobも含まれます。最も簡単なソリューションは(i)既存のtorrentライブラリを単に導入することと、(ii)ポータルネットワークと呼ばれるイーサリアムネイティブソリューションです。いずれかを導入すると、EIP-4444を開くことができます。EIP-4444自体はハードフォークを必要としませんが、新しいネットワークプロトコルバージョンが必要です。したがって、すべてのクライアントに同時にそれを有効にすることは価値があります。さもなければ、他のノードに接続して完全な履歴をダウンロードすることを期待しているクライアントが、実際には取得していないために故障するリスクがあります。

主要なトレードオフは、私たちが「古代」の歴史データを提供するためにどのように努力するかに関するものです。最も簡単な解決策は、明日「古代」の歴史の保存を停止し、既存のアーカイブノードとさまざまな集中型プロバイダーに依存して複製することです。これは簡単ですが、エーテルを永久記録の場としての地位を弱体化させます。より困難ですが、より安全な方法は、まずtorrentネットワークを構築し、統合して歴史を分散方式で保存することです。ここで、「私たちがどれだけ努力しているか」には二つの次元があります：

私たちはどのようにして最大のノードセットがすべてのデータを実際に保存していることを確実にするために努力していますか？

プロトコルに統合された歴史ストレージの深さはどのくらいですか？

（1）に対する極端な偏執的アプローチは、証明の保管を含むことになります：実際には、各ステークプルーフ検証者が一定の割合の履歴を保存し、定期的に暗号化された方法でそれを行っているかどうかを確認することが求められます。より穏やかなアプローチは、各クライアントが保存する履歴の割合に対して任意の基準を設定することです。

(2)に関して、基本的な実装は今日完了した作業のみを含んでいます：ポータルは、イーサリアムの全歴史を含むERAファイルを保存しました。より徹底的な実装は、実際にそれを同期プロセスに接続することを含み、誰かが完全な歴史記録ストレージノードまたはアーカイブノードを同期したい場合、他のアーカイブノードがオンラインで存在していなくても、ポータルネットワークから直接同期することによってそれを実現できます。

それはロードマップの他の部分とどのように相互作用しますか？

ノードの運用や起動を非常に簡単にしたいのであれば、履歴ストレージの要件を減らすことは無状態性よりも重要だと言える。ノードに必要な1.1 TBのうち、約300 GBが状態で、残りの約800 GBは履歴になっている。無状態性とEIP-4444を実現することで、スマートウォッチ上でイーサリアムノードを運営し、数分で設定できるというビジョンが実現できる。

履歴ストレージの制限により、より新しいイーサリアムノードが実現可能になり、プロトコルの最新バージョンのみをサポートするため、これらはよりシンプルになります。例えば、2016年のDoS攻撃の際に作成された空のストレージスロットがすべて削除されたため、多くのコード行を安全に削除できるようになりました。プルーフ・オブ・ステークへの移行が歴史となった今、クライアントはプルーフ・オブ・ワークに関連するすべてのコードを安全に削除できます。

ステートの有効期限

は何の問題を解決しますか？

クライアントが履歴を保存する必要がなくなったとしても、クライアントのストレージ需要は毎年約50GB増加し続けるでしょう。これは状態が持続的に増加するためです：アカウントの残高や乱数、契約コードおよび契約ストレージ。ユーザーは一度の料金を支払うことで、現在および将来のイーサリアムクライアントに永遠に負担をかけることになります。

状態は歴史よりも「期限切れ」になることが難しい。なぜなら、EVMは根本的に、状態オブジェクトが一度作成されると常に存在し、いつでも任意のトランザクションによって読み取られるという前提に基づいて設計されているからだ。無状態性を導入する場合、この問題はそれほど悪くないかもしれないと考える人もいる：特定のブロックビルダーのみが実際に状態を保存する必要があり、他のすべてのノード（リスト生成を含む！）は無状態で動作できる。しかし、無状態性に過度に依存したくないという見解もあり、最終的にはイーサリアムの分散化を維持するために状態を期限切れにすることを望むかもしれない。

! Vitalik:イーサリアムの可能な未来、パージ

それは何ですか、どのように機能しますか

今日、新しい状態オブジェクトを作成するとき（以下の3つの方法のいずれかで発生します：（i）新しいアカウントにETHを送信する、（ii）コードを使用して新しいアカウントを作成する、（iii）以前に触れていないストレージスロットを設定する）、その状態オブジェクトは永遠にその状態にあります。逆に、私たちが望むのは、オブジェクトが時間の経過とともに自動的に期限切れになることです。重要な課題は、3つの目標を達成する方法でこれを行うことです：

効率：期限プロセスを実行するために大量の追加計算は必要ありません。

ユーザーフレンドリー：誰かが5年間洞窟に入って戻ってきた場合、彼らはETH、ERC20、NFT、CDPポジションへのアクセスを失ってはいけません......

開発者の親しみやすさ：開発者は全く知らない思考モデルに切り替える必要はありません。また、現在すでに硬直し、更新されていないアプリケーションは引き続き正常に動作する必要があります。

これらの目標を満たさないと、問題を解決するのは非常に簡単です。たとえば、各状態オブジェクトが有効期限のカウンターも保存するようにし（ETHを燃焼させることで有効期限を延長でき、これはいつでも読み書き時に自動的に発生する可能性があります）、有効期限を過ぎた状態オブジェクトを削除するプロセスを状態をループして実行するという方法があります。しかし、これにより追加の計算（さらにはストレージの要求）が発生し、確実にユーザーフレンドリーさの要件を満たすことはできません。開発者は、値のストレージが時折ゼロにリセットされるエッジケースを推論するのも難しいです。契約の範囲内で有効期限タイマーを設定すると、技術的には開発者の生活が容易になりますが、経済的にはより困難になります：開発者は継続的なストレージコストをどのようにユーザーに"転嫁"するかを考慮しなければなりません。

これらはすべて、イーサリアムのコア開発コミュニティが長年取り組んできた問題であり、"ブロックチェーンレンタル"や"再生"といった提案が含まれています。最終的に、私たちは提案の中で最も良い部分を組み合わせ、"知られている最も悪くない解決策"の2つのカテゴリーに集中しました：

一部のステータスの期限切れの解決策 アドレス周期に基づく状態期限の提案。

部分的な状態の有効期限

一部のステータス期限切れの提案は同じ原則に従います。私たちはステータスをブロックに分けます。すべての人は"トップマッピング"を永続的に保存し、そこにブロックが空であるか非空であるかが示されます。最近そのデータにアクセスされた場合のみ、各ブロック内のデータが保存されます。"復活"メカニズムがあり、もはや保存されていない場合には、

これらの提案の主な違いは：（i）"最近"をどのように定義するか、