イーサリアムの可能な未来：The Purge

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

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

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

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

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

ザ・パージ：主な目標。

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

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

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

目次:

履歴の有効期限

州の有効期限

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

###履歴の有効期限

どのような問題を解決しますか？

この記事執筆時点では、完全に同期したイーサリアムノードにはクライアントを実行するために約1.1TBのディスクスペースが必要で、さらにコンセンサスクライアント用に数百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日間）を確立し、その後、古いデータを分散型ネットワーク方式で保存するイーサリアムノードからなるピアツーピアネットワークを構築することです。

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

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

現在の研究との関連性は何ですか？

EIP-4444;

トレントとEIP-4444；

ポータルネットワーク；

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

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

ガス制限をどうやって向上させるか（パラダイム）。

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

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

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

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

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

（1）に対する極端な偏執的アプローチの一つは、証明の保管を伴うものであり、実際には各プルーフ・オブ・ステーク検証者に対して、一定の割合の履歴を保存し、定期的にそれを暗号的にチェックすることを求めるものです。より穏やかなアプローチは、各クライアントが保存する履歴の割合に対して自発的な基準を設定することです。

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

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

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

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

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

ステート期限

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

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

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

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

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

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

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

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

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

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

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

部分的な状態の有効期限

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

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