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

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

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

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

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

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

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

ザ・パージ：主要目標。

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

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

目次:

履歴の有効期限

ステートエクスパイア（状態到期）

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

###履歴の有効期限

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

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

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

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

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

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

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

エラージャコードはロバスト性を向上させながら、レプリケーションファクターを同じに保つために使用できます。実際、Blobはデータ可用性サンプリングをサポートするためにエラージャコードを適用しています。最も簡単な解決策は、このエラージャコードを再利用し、実行とコンセンサスブロックデータもBlobに入れることかもしれません。

現在の研究とどのように関連していますか？

EIP-4444;

トレントとEIP-4444；

ポータルネットワーク；

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

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

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

何をしなければならないか、何を考慮しなければならないか？

残りの主要な作業は、履歴を保存するための具体的な分散ソリューションを構築し統合することです------少なくとも実行履歴ですが、最終的にはコンセンサスとblobも含まれます。最も簡単な解決策は(i)既存のtorrentライブラリを単純に導入することと、(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を燃焼させることで期限を延長でき、これはいつでも読み書きの際に自動的に行われる可能性があります）、期限切れの日付を削除するプロセス状態オブジェクトを巡回するループを持つことができます。しかし、これにより追加の計算（さらにはストレージの要求）が導入され、ユーザーフレンドリーさの要件を満たすことは確実にできなくなります。開発者は、ストレージ値が時々ゼロにリセットされるエッジケースを推論するのも難しいです。契約の範囲内で期限カウントタイマーを設定すると、技術的には開発者の生活を楽にしますが、経済的にはより困難になります：開発者は持続的なストレージコストをユーザーに「転嫁」する方法を考慮する必要があります。

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

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

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

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

部分的な状態の有効期限

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

これらの提案の主な違いは、（i）"最近"をどのように定義するか、そして（ii）私たちがどのようにするかです。