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

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

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

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

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

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

ザ・パージ：主要目標。

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

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

目次:

履歴の有効期限

州の有効期限

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

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

履歴の有効期限

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

この記事執筆時点で、完全に同期したイーサリアムノードは、クライアントを実行するために約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) 既存のトレントライブラリを単純に導入することと、(ii) エーテルのネイティブソリューションであるPortalネットワークを呼ぶことです。これらのいずれかを導入したら、EIP-4444を開くことができます。EIP-4444自体はハードフォークを必要としませんが、新しいネットワークプロトコルバージョンが必要です。したがって、すべてのクライアントで同時にそれを有効にすることは価値があります。そうしないと、他のノードに接続して完全な履歴をダウンロードすることを期待しているが、実際には取得できないためにクライアントが失敗するリスクがあります。

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

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

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

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

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

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

ノードの実行や起動を非常に簡単にしたいのであれば、履歴ストレージの要件を減らすことは、無状態性よりも重要だと言える。ノードに必要な 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)

部分的な状態の有効期限

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