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

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

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

協定機能：新機能を追加することは、古い機能を削除することよりもはるかに簡単であるため、コードの複雑さは時間とともに増加します。

イーサリアムが長期的に維持されるためには、これら二つのトレンドに対して強力な逆圧力を加え、時間の経過とともに複雑性と膨張を減少させる必要があります。しかし同時に、ブロックチェーンを偉大にする重要な属性の一つである持続性を保持する必要があります。NFT、一通の取引通話データに含まれるラブレター、あるいは100万ドルを含むスマートコントラクトをチェーン上に置き、洞窟に十年間入っていても、出てきたときにはまだそこにあり、あなたがそれを読み、相互作用するのを待っているのです。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に入れることだと思われます。

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

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

EIP-4444;

トレントとEIP-4444；

ポータルネットワーク；

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

Portal における SSZ オブジェクトの分散ストレージと検索；

ガス制限をどのように引き上げるか（パラダイム）。

まだ何をする必要がありますか、何を天秤にかける必要がありますか？

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

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

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

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

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

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

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

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

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

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

ステートの有効期限

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

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

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

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

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

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

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

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

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

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

*部分的なステータス有効期限ソリューション

• アドレス周期に基づく状態の期限の提案。

! [ヴィタリック:イーサリアムの可能な未来、パージ] (https://img-cdn.gateio.im/webp-social/moments-5cd0e9908a04986f83c85cabecd4a0ae.webp)

部分的な状態の有効期限

一部のステータス期限切れの提案は同じ原則に従います。私たちはステータスをブロックに分けます。誰もが"トップマッピング"を永久に保存します。