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

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

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

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

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

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

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

ザ・パージ：主要目標。

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

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

目次:

履歴の有効期限

ステートの期限切れ（状態到期）

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

履歴の有効期限

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

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

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

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

これにより、私たちが歴史をどのように保存するかについて多くの選択肢が提供されます。自然な選択肢の一つは、各ノードがデータの小さな部分だけを保存するネットワークです。これがシードネットワークが数十年にわたって運用されてきた方法です：ネットワークは合計で数百万のファイルを保存および配布していますが、各参加者はその中のいくつかのファイルだけを保存および配布します。直感に反するかもしれませんが、この方法はデータの堅牢性を必ずしも低下させるわけではありません。ノードをより経済的に運営することによって、各ノードがランダムに10%の歴史を保存する100,000ノードのネットワークを構築できるとします。そうすれば、各データは10,000回コピーされ、10,000ノードのコピー因子とまったく同じになります - 各ノードがすべての内容を保存しているノードネットワークです。

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

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

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

は既存の研究とどのように関連していますか？

EIP-4444;

トレントとEIP-4444；

ポータルネットワーク；

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

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

ガス制限を引き上げるには（Paradigm）。

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

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

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

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

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

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

(2)に関して、基本的な実装は今日すでに完了した作業のみを含みます：Portalはイーサリアムの全歴史を含む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を燃焼させることで有効期限を延長でき、これはいつでも読み取ったり書き込んだりする際に自動的に発生する可能性があります）、そして有効期限を過ぎた状態オブジェクトを削除するために状態を反復処理するプロセスがあります。しかし、これにより追加の計算（さらにはストレージの要求）が発生し、ユーザーフレンドリー性の要件を満たすことは確実にできません。開発者は、ストレージ値が時々ゼロにリセットされるエッジケースを推論するのも難しいです。契約範囲内で有効期限タイマーを設定すると、技術的には開発者の生活は容易になりますが、経済的にはより困難になります：開発者は持続的なストレージコストをユーザーに"転嫁"する方法を考慮しなければなりません。

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

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

• アドレスサイクルに基づくステータスの期限切れ提案。

部分的な状態の有効期限

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

![ビタリック：イーサリアムの可能性のある未来、The Purge](https://