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

著者：ヴィタリック・ブテリン

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

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

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

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

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

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

ザ・パージ：主要目標。

各ノードがすべての履歴や最終状態を永続的に保存する必要性を減らすことによって、クライアントのストレージ要件を低減します。

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

目次:

履歴の有効期限

州の有効期限

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

###履歴の有効期限

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

この記事を書いている時点で、完全に同期されたイーサリアムノードは、クライアントを実行するために約1.1 TBのディスクスペースを必要とし、さらにコンセンサスクライアント用に数百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；

ポータルネットワーク；

PortalネットワークとEIP-4444；

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

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

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

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

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

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

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

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

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

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

もし私たちがノードの実行や起動を非常に簡単にしたいのであれば、履歴ストレージの要求を減らすことは無状態性よりも重要だと言えるでしょう：ノードに必要な 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つのカテゴリに集中しました：

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

パーシャルステートエクスパイア部分状態到期

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

これらの提案の主な違いは：（i）私たちが