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

イーサリアムが直面している課題の一つは、デフォルトで、任意のブロックチェーンプロトコルの膨張と複雑性が時間とともに増加することです。これは2つの場所で発生します：歴史データとプロトコルの機能。イーサリアムが長期的に維持されるためには、これら2つの傾向に強力な反圧を加え、時間の経過とともに複雑性と膨張を減少させる必要があります。しかし同時に、ブロックチェーンを素晴らしいものにするキー属性の一つである持続性を保持する必要があります。

パージの主な目的は次のとおりです。

• クライアントのストレージ要件を削減するために、各ノードがすべての履歴または最終状態を永続的に保存する必要を減らすか、排除します。
• 不要な機能を排除することで、プロトコルの複雑性を低減する。

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

履歴の有効期限

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

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

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

歴史的なストレージ問題の重要な簡略化された特性は、各ブロックがハッシュでリンクされ、(や他の構造)によって前のブロックを指すため、現在の合意が歴史に対する合意を得るのに十分であるということです。ネットワークが最新のブロックに合意する限り、任意の歴史的なブロックやトランザクション、または状態(のアカウント残高、乱数、コード、ストレージ)は、任意の単一の参加者によって提供されることができ、またメルクル証明によって確認されます。この証明は、他の誰でもその正確性を検証することを許可します。合意は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:イーサリアムの可能な未来、パージ

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

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

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

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

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

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

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

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

ノードの実行または起動を非常に容易にしたい場合、履歴ストレージの要件を削減することは、無状態性よりも重要であると言えます。ノードに必要な1.1TBのうち、約300GBが状態で、残りの約800GBが履歴です。無状態性と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 を燃やすことで、これはいつでも読み書き時に自動的に発生する可能性があります(、また期限日の状態オブジェクトを削除するための状態をループして走査するプロセスがあります。しかし、これは追加の計算)やストレージの要求を引き起こします(、そして間違いなくユーザーフレンドリーさの要求を満たすことはできません。開発者は、時々ゼロにリセットされるストレージ値を含む境界条件を推論するのが難しいです。契約の範囲内で期限タイマーを設定すると、技術的には開発者の生活が楽になりますが、経済的にはより困難になります: 開発者は継続的なストレージコストをユーザーに"転嫁"する方法を考慮しなければなりません。

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

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

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

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

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

これらの提案の主な違いは、###i(「最近」をどのように定義するか、そして)ii(「ブロック」をどのように定義するかです。具体的な提案はEIP-7736で、これはVerkleツリーに導入された「茎葉」設計に基づいています)無状態の状態に互換性がある形式、例えば二分木(に対してです。この設計では、隣接するヘッダー、コード、およびストレージスロットが同じ「主幹」の下に保存されます。1つの茎の下に保存されるデータは最大で256 * 31 = 7,936バイトです。多くのケースでは、アカウントの全ヘッダーとコード、そして多くのキーのストレージスロットが同じ主幹の下に保存されます。与えられた主幹の下のデータが6ヶ月間読み取られたり書き込まれなかった場合、そのデータはもはや保存されず、そのデータの32バイトのコミットメント)「スナップショット」(のみが保存されます。将来、そのデータにアクセスするトランザクションは、データを「復活」させ、スナップショットに基づいてチェックする証明を提供する必要があります。

他にも類似のアイデアを実現する方法があります。例えば、アカウントレベルの粒度が不十分な場合、木の各1/232部分が類似の茎葉メカニズムによって制御されるスキームを策定することができます。

インセンティブ要因のため、これはより厄介になります：攻撃者は、単一のサブツリーに大量のデータを投入し、毎年単一のトランザクションを送信することで「ツリーを更新」し、クライアントに大量の状態を永続的に保存させることができます。もしあなたが更新コストをツリーのサイズに比例)させるか、更新の持続時間を反比例(させると、誰かが同じサブツリーに大量のデータを投入することで他のユーザーに損害を与える可能性があります。人々は、サブツリーのサイズに基づいて粒度を動的に制限することで、これらの二つの問題を制限しようとするかもしれません：例えば、連続する216=65536の状態オブジェクトを「グループ」として扱うことができます。しかし、これらのアイデアはより複雑です；茎に基づくアプローチは単純であり、インセンティブを調整することができるため、一般的に茎