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

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

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

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

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

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

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

ザ・パージ：主要目標。

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

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

目次:

履歴expiry( 履歴の有効期限が切れる) ステートの期限(状態の期限) 機能クリーンアップ(特征清理)

###履歴の有効期限

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

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

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

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

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

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

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

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

)# 現在の研究とどのような関連がありますか?

EIP-4444;

トレントとEIP-4444;

ポータルネットワーク;

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

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

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

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

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

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

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

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

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

(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つのカテゴリに集中しました:

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

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

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

これらの提案の主な違いは:)i###「最近」をどのように定義するか、そして(ii)「ブロック」をどのように定義するかです。具体的な提案はEIP-7736で、これはVerkle木のために導入された「茎葉」デザインに基づいています(無状態の状態、例えば二分木に対しても互換性があります)。このデザインでは、お互いに隣接するヘッダー、コード、およびストレージスロットが同じ「幹」の下に保存されます。1つの茎の下に保存されるデータは最大で256 * 31 = 7,936です。