イーサリアムThe Purge：複雑さを減らし、持続可能性と安全性を向上させる

2025-07-26 19:04:13

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

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

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

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

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

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

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

ザ・パージ:主要目標。

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

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

履歴の有効期限

州の有効期限

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

###履歴の有効期限

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

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

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

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

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

これは、私たちが歴史をどのように保存するかについて多くの選択肢を提供しています。一つの自然な選択肢は、各ノードがデータの小さな部分だけを保存するネットワークです。これが、数十年にわたってシードネットワークが機能してきた方法です：ネットワークは合計で数百万のファイルを保存し配布していますが、各参加者はその中のいくつかのファイルだけを保存し配布しています。直感に反するかもしれませんが、このアプローチは必ずしもデータの堅牢性を低下させるわけではありません。もしノードの運用をより経済的にすることで、各ノードがランダムに歴史の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)、既存のトレントライブラリを単純に導入することと、(ii)、Portal ネットワークと呼ばれるイーサリアムのネイティブソリューションです。これらのいずれかを導入すれば、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を燃焼させることで期限日を延長でき、これはいつでも読み書きされるたびに自動的に発生する可能性があります）、期限日を削除するプロセス状態オブジェクトを巡回するループがあるとします。しかし、これにより追加の計算（さらにはストレージの要求）が発生し、ユーザーフレンドリーさの要件を満たすことは確実にできません。開発者は、ストレージ値が時々ゼロにリセットされるエッジケースについて推論するのが難しいです。契約の範囲内で期限タイマーを設定すると、技術的には開発者の生活を楽にしますが、経済的にはより困難になります：開発者は、継続的なストレージコストをユーザーに「転嫁」する方法を考慮しなければなりません。

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

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