イーサリアム遠景計画：The Purgeが持続性と複雑性をどのようにバランスさせるか

2025-07-18 01:42:00

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

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

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

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

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

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

ザ・パージ：主要目標。

クライアントのストレージ要件を減少または排除することで、各ノードがすべての履歴や最終状態を永続的に保存する必要を減らします。
不要な機能を排除することでプロトコルの複雑さを減らす。

履歴の有効期限
ステートの期限（状態到期）
フィーチャークリーンアップ（特征清理）

履歴の有効期限

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

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

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

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

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

これにより、私たちが歴史的記録をどのように保存するかに多くの選択肢が提供されます。自然な選択肢の1つは、各ノードがデータの小さな部分のみを保存するネットワークです。これが、数十年にわたってシードネットワークが機能してきた方法です：ネットワークは合計で数百万のファイルを保存および配布していますが、各参加者はその中のいくつかのファイルのみを保存および配布します。直感に反するかもしれませんが、このアプローチはデータの堅牢性を必ずしも低下させるわけではありません。ノードの運用をより経済的にすることで、各ノードがランダムに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)に関して、基本的な実装は今日完了した作業のみを含みます：ポータルは、全てのエーテルの歴史を含む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を燃焼させることで有効期限を延長でき、これはいつでも読み書きの際に自動的に発生する可能性があります）、期限切れの日付を削除するために状態をループ処理するプロセスがあります。しかし、これにより追加の計算（さらにはストレージの要件）が発生し、ユーザーフレンドリー性の要件を満たすことは確実にできません。開発者は、ストレージ値が時々ゼロにリセットされるエッジケースに関して推論するのが難しいです。契約の範囲内で期限カウントダウンタイマーを設定すると、技術的には開発者の生活を楽にしますが、経済的には難しくなります：開発者は継続的なストレージコストをユーザーに"転嫁"する方法を考慮しなければなりません。

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