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

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

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

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

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

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

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

ザ・パージ：主要な目標。

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

不要な機能を排除することで、プロトコルの複雑性を低下させる。

目次:

履歴expiry( 履歴の有効期限が切れる)

状態expiry( ) 状態が期限切れになります

フィーチャークリンアップ(特徴クリーニング)

###履歴の有効期限

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

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

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

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

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

これにより、私たちが歴史をどのように保存するかについて多くの選択肢が提供されます。自然な選択肢の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) 既存のトレントライブラリを単に導入することと、(ii) ポータルネットワークと呼ばれるイーサリアムのネイティブソリューションです。どちらかの導入が完了すれば、EIP-4444を開くことができます。EIP-4444自体はハードフォークを必要としませんが、新しいネットワークプロトコルのバージョンが必要です。したがって、すべてのクライアントで同時に有効にすることは価値があります。そうでないと、他のノードに接続して完全な履歴をダウンロードすることを期待しているクライアントが実際には取得できずに故障するリスクがあります。

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

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

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

(に対する極端な偏執的アプローチは、証明の保管を伴います: 実際には、各ステークプルーフバリデーターが一定の割合の履歴を保存し、定期的に暗号的にそれを確認することを要求します。より穏やかなアプローチは、各クライアントが保存する履歴の割合に対して自発的な基準を設定することです。

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

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

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

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

ステートの有効期限

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

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

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

! [Vitalik:イーサリアムの可能な未来、パージ])https://img-cdn.gateio.im/webp-social/moments-a97b8c7f7927e17a3ec0fa46a48c9f24.webp(

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

今日、新しい状態オブジェクトを作成する際に###は以下の三つの方法のいずれかで発生する可能性があります:(i(ETHを新しいアカウントに送信すること, )ii(コードを使用して新しいアカウントを作成すること, )iii(以前に触れたことのないストレージスロットを設定すること) ,その状態オブジェクトは永遠にその状態にあります。逆に、私たちが望むのは、オブジェクトが時間とともに自動的に期限切れになることです。重要な課題は、三つの目標を達成する方法でこれを行うことです:

効率:期限プロセスを実行するために大量の追加計算は不要です。

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

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

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

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

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

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

)# 部分的な状態の有効期限

一部の状態期限切れ提案は同じ原則に従います。私たちは状態をブロックに分割します。誰もが"トップマッピング"を永続的に保存し、そのブロックが空であるか非空であるかを示します。最初にのみ