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

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

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

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

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

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

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

ザ・パージ：主要な目標。

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

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

目次:

履歴の有効期限

ステートエクスピレーション（状態到期）

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

ヒストリーの有効期限

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

この記事を書いている時点で、完全に同期したイーサリアムノードはクライアントを実行するために約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日間）を確立し、その後、イーサリアムノードで構成されるP2Pネットワークを構築して、古いデータを分散ネットワーク方式で保存することです。

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

Erasure codesは、ロバスト性を向上させるために使用でき、同時にレプリケーションファクターを保持します。実際、Blobはデータ可用性サンプリングをサポートするためにエラー訂正コードをすでに実行しています。最も簡単な解決策は、このErasure codesを再利用し、実行およびコンセンサスブロックデータもblobに入れることになるでしょう。

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

EIP-4444;

トレントとEIP-4444；

ポータルネットワーク；

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

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

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

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

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

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

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

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

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

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

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

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

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

ステートの有効期限

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

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

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

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

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

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

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

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

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

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

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

部分的な状態の有効期限

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

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

これらの提案間の主な違いは：（i）私たちが「どのように定義するか