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

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

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

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

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

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

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

ザ・パージ:主な目標。

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

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

目次:

履歴の有効期限

州の有効期限

フィーチャーのクリーンアップ

履歴の有効期限

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

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

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

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

これは、私たちがいかに歴史的記録を保存するかについて多くの選択肢を提供します。自然な選択肢の1つは、各ノードがデータの小さな部分のみを保存するネットワークです。これが数十年にわたってシードネットワークが機能してきた方法です：ネットワークは合計で何百万ものファイルを保存および配布していますが、各参加者はその中のいくつかのファイルのみを保存および配布します。直感に反するかもしれませんが、この方法はデータの堅牢性を必ずしも低下させるわけではありません。もし、ノードをより経済的に運営することで、各ノードがランダムに10%の歴史的記録を保存する100,000のノードを持つネットワークを構築できるなら、各データは10,000回複製されます - これは、各ノードがすべてのコンテンツを保存する10,000のノードの複製係数とまったく同じです。

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

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

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

は既存の研究とどのような関係がありますか？

EIP-4444;

トレントとEIP-4444;

ポータルネットワーク;

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

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

ガス制限をどのように引き上げるか。

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

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

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

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

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

(に対する極端な偏執的アプローチは、プルーフ・オブ・ステークを含むことになります: 実際には、各ステーキング検証者に一定割合の履歴を保存させ、それを定期的に暗号化してチェックすることを要求します。より穏健なアプローチは、各クライアントが保存する履歴のパーセンテージに対してボランタリーな基準を設定することです。

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

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

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

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

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

ステートの有効期限

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

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

状態は歴史よりも"期限切れ"にすることが難しい。なぜなら、EVMは根本的に、状態オブジェクトが作成されるとそれは常に存在し、いつでも任意のトランザクションによって読み取られるという仮定の周りに設計されているからです。もし無状態性を導入するなら、この問題はそれほど悪くないと考える人もいます。実際に状態を保存する必要があるのは特定のブロックビルダークラスだけであり、###を含むすべての他のノードやリスト生成(は無状態で動作できると言われています。しかし、私たちは無状態性に過度に依存したくないという見解もあります。最終的には、イーサリアムの非中央集権性を維持するために状態を期限切れにすることを望むかもしれません。

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

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

効率:期限プロセスを実行するために大量の追加計算は必要ありません。

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

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

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

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

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

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

• アドレスサイクルに基づく状態期限の提案。

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

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