# イーサリアムの可能な未来：The Purgeイーサリアムが直面している課題の一つは、デフォルトで、あらゆるブロックチェーンプロトコルの膨張と複雑性が時間の経過とともに増加することです。これは二つの側面で発生します: 歴史的データとプロトコル機能。イーサリアムが長期的に維持できるようにするためには、これらの二つの傾向に対して強力な反圧を加え、時間の経過とともに複雑性と膨張を減少させる必要があります。しかし同時に、ブロックチェーンを偉大にする重要な属性の一つである持続性を保持する必要があります。パージの主な目的は次のとおりです。- クライアントのストレージ要件を低下させるために、各ノードがすべての履歴や最終状態を永続的に保存する必要性を減らすか排除します。- 不要な機能を排除することでプロトコルの複雑性を低減します。! [ヴィタリック:イーサリアムの未来の可能性、パージ](https://img-cdn.gateio.im/social/moments-4db9a670bb8e3d1c2de04e4c21cddae6)## 履歴の有効期限### は何の問題を解決しますか？この記事執筆時点で、完全に同期したイーサリアムノードは、クライアントを実行するために約1.1TBのディスクスペースを必要とし、さらに数百GBのディスクスペースがコンセンサスクライアントに必要です。その大部分は歴史的なもので、歴史的なブロック、トランザクション、レシートに関するデータであり、そのほとんどは数年前のものです。これは、ガス制限がまったく増加しなくても、ノードのサイズが毎年数百GB増加し続けることを意味します。### それは何ですか、それはどのように機能しますか?歴史的なストレージ問題の重要な簡略化された特徴は、各ブロックがハッシュでリンクされており(、他の構造)が前のブロックを指し示しているため、現在の合意に達することが歴史に対する合意に十分であるということです。ネットワークが最新のブロックに合意すれば、任意の歴史的ブロックや取引、または状態(のアカウント残高、ランダム数、コード、ストレージ)を任意の単一の参加者が提供し、Merkle証明を使用することができます。そして、その証明により他の誰もがその正確性を検証することができます。合意はN/2-of-N信頼モデルであり、歴史はN-of-N信頼モデルです。これは、私たちが歴史をどのように保存するかについて多くの選択肢を提供します。自然な選択肢の一つは、各ノードがデータの小さな部分のみを保存するネットワークです。これが、数十年にわたってシードネットワークが機能してきた方法です：ネットワーク全体で何百万ものファイルを保存し配布しているにもかかわらず、各参加者はその中の数ファイルのみを保存し配布します。直感に反するかもしれませんが、この方法はデータの堅牢性を必ずしも低下させるわけではありません。ノードをより経済的に稼働させることで、各ノードがランダムに10％の履歴を保存する100,000ノードのネットワークを構築できるなら、各データは10,000回複製されます – すべての内容を保存する各ノードを持つ10,000ノードのネットワークとまったく同じ複製係数です。現在、イーサリアムはすべてのノードがすべての履歴を永久に保存するモデルから脱却し始めています。コンセンサスブロック(は、ステークプルーフコンセンサスに関連する部分)が約6か月間保存されるだけです。Blobは約18日間保存されます。EIP-4444は、履歴ブロックとレシートに1年間の保存期間を導入することを目的としています。長期的な目標は、統一された期間を確立することで(は約18日間)であり、この期間中に各ノードがすべてのコンテンツを保存し、その後、イーサリアムノードで構成されるピアツーピアネットワークを構築して、古いデータを分散ネットワーク方式で保存することです。エラージャーコードは、同じレプリケーションファクターを維持しながら、堅牢性を向上させるために使用できます。実際、Blobはデータの可用性サンプリングをサポートするためにエラージャーコードを使用しています。最も簡単な解決策は、おそらくこのエラージャーコードを再利用し、実行とコンセンサスブロックデータもBlobに入れることです。! [Vitalik:イーサリアムの可能な未来、パージ](https://img-cdn.gateio.im/social/moments-b4e683a9e42e4b5bd6991a4cf6cf948e)### まだ何をする必要がありますか、何を考慮する必要がありますか？残りの主な作業は、履歴を保存するための具体的な分散ソリューションを構築および統合することです------少なくとも実行履歴ですが、最終的にはコンセンサスと blob も含まれます。最も簡単なソリューションは (i) 既存のトレントライブラリを単純に導入することと、(ii) と呼ばれるポータルネットワークのエーテルネイティブソリューションです。それらのいずれかを導入すれば、私たちは EIP-4444 を開くことができます。 EIP-4444 自体はハードフォークを必要としませんが、新しいネットワークプロトコルのバージョンが必要です。したがって、すべてのクライアントで同時にそれを有効にすることは価値があります。そうでないと、他のノードに接続して完全な履歴をダウンロードすることを期待しているが実際には取得できないためにクライアントが故障するリスクがあります。主要なトレードオフは、私たちが「古代」歴史データを提供するためにどのように努力するかに関係しています。最も簡単な解決策は、明日古代の歴史の保存を停止し、既存のアーカイブノードとさまざまな集中型プロバイダーに依存してコピーを行うことです。これは簡単ですが、エーテルが永久記録の場としての地位を弱めます。より困難ですが安全な方法は、まずトレントネットワークを構築し統合して、分散方式で歴史を保存することです。ここでの「私たちはどれだけ努力しているか」には2つの次元があります:- どのようにして最大のノードセットが実際にすべてのデータを保存していることを保証するために努力していますか？- プロトコルに統合された履歴ストレージの深さはどのくらいですか？(の極端な偏執的アプローチは、保管証明を含む: 実際に、各ステークプルーフ検証者が一定の割合の履歴を保存し、定期的にそれを暗号化してチェックすることを要求します。より穏やかなアプローチは、各クライアントが保存する履歴のパーセンテージに対して自主的な基準を設定することです。)2(について、基本的な実装は今日完了した作業にのみ関係しています: Portalは、全エーテルの歴史を含むERAファイルをすでに保存しています。より徹底した実装は、実際にそれを同期プロセスに接続することを含みます。これにより、誰かが完全な履歴を保存するノードまたはアーカイブノードを同期したい場合、他のアーカイブノードがオンラインで存在しなくても、ポータルネットワークから直接同期することで実現できます。) それはロードマップの他の部分とどのように相互作用しますか?ノードの運用や起動を非常に簡単にしたいのであれば、履歴ストレージの要求を減らすことは無状態性よりも重要だと言えます。ノードが必要とする1.1 TBのうち、約300 GBは状態で、残りの約800 GBは履歴となっています。無状態性とEIP-4444を実現することで、スマートウォッチ上でイーサリアムノードを運用し、数分で設定できるというビジョンを実現することができます。履歴の保存制限は、より新しいイーサリアムノードの実装をより実行可能にし、プロトコルの最新バージョンのみをサポートするため、これらをよりシンプルにします。たとえば、2016年のDoS攻撃中に作成された空のストレージスロットがすべて削除されたため、多くのコード行を安全に削除できるようになりました。プルーフ・オブ・ステークへの移行が歴史となった今、クライアントはプルーフ・オブ・ワークに関連するすべてのコードを安全に削除できます。! [Vitalik:イーサリアムの可能な未来、パージ]###https://img-cdn.gateio.im/social/moments-a97b8c7f7927e17a3ec0fa46a48c9f24(## ステートの有効期限) は何の問題を解決しますか？クライアントの履歴記録の保存の必要性を排除しても、クライアントのストレージの需要は毎年約50GB増加し続け、状態が持続的に増加するためです：アカウントの残高とランダム数、契約コードと契約ストレージ。ユーザーは一度の料金を支払うことで、現在と将来のイーサリアムクライアントに永遠に負担をもたらします。状態は歴史よりも"期限切れ"になることが難しい。なぜなら、EVMは根本的に、状態オブジェクトが一度作成されると常に存在し、いつでも任意のトランザクションから読み取れるという仮定のもとに設計されているからだ。無状態性を導入すると、この問題はそれほど悪くないかもしれないと考える人もいる。特定のブロックビルダータイプだけが実際に状態を保存する必要があり、###他のすべてのノード(は無状態で動作できる。しかし、無状態性に過度に依存したくないという見解もあり、最終的にはイーサリアムの分散化を維持するために状態を期限切れにすることを望むかもしれない。) それは何ですか、それはどのように機能しますか今日は、新しいステートオブジェクトを作成する際に###が以下の3つの方法のいずれかで発生する可能性があります:(i(新しいアカウントにETHを送信する,)ii(コードを使用して新しいアカウントを作成する,)iii(以前に触れられていないストレージスロットを設定する),このステートオブジェクトは永遠にその状態にあります。逆に、私たちが望むのは、オブジェクトが時間の経過とともに自動的に期限切れになることです。重要な課題は、3つの目標を達成する方法でこれを行うことです:- 効率:期限プロセスを実行するために大量の追加計算が必要ありません。- ユーザーフレンドリーさ: 誰かが洞窟に5年間入り、戻ってきた場合、彼らはETH、ERC20、NFT、CDPポジションへのアクセスを失うべきではない......- 開発者フレンドリー: 開発者は全く馴染みのない思考モデルに切り替える必要がありません。また、現在既に硬直化して更新されていないアプリケーションは正常に動作し続けるべきです。これらの目標を満たさないと、問題を解決するのが簡単になります。例えば、各状態オブジェクトに期限日カウンターを保存させることができ、)はETHを燃やすことで期限日を延長でき、これはいつでも読み書き時に自動的に発生する可能性があります(。そして、期限日を削除するために状態オブジェクトを循環して処理する必要があります。しかし、これにより追加の計算)やストレージの必要性が生じ(、ユーザーフレンドリー性の要件を満たすことは確実にできません。開発者は、ストレージ値が時折ゼロにリセットされるエッジケースを推論するのも難しいです。契約範囲内に期限タイマーを設定すると、技術的には開発者の生活が楽になりますが、経済的にはより困難になります: 開発者は持続的なストレージコストをどのようにユーザーに"転嫁"するかを考慮しなければなりません。これらはすべて、イーサリアムのコア開発コミュニティが長年にわたって解決に取り組んできた問題であり、「ブロックチェーンレンタル」や「再生」などの提案が含まれています。最終的に、私たちは提案の中で最も優れた部分を組み合わせ、2つの「知られている最も悪くない解決策」に集中しました。- 一部の状態の期限切れに関する解決策- アドレス周期に基づくステータスの期限に関する提案。! [ヴィタリック:イーサリアムの可能な未来、パージ] )https://img-cdn.gateio.im/social/moments-5cd0e9908a04986f83c85cabecd4a0ae()# パーシャルステートエクスピリー部分状態到期部分状態の期限切れ提案は、同じ原則に従います。我々は状態をブロックに分割します。誰もが"トップマッピング"を永久に保存し、そのブロックが空または非空であるかを記録します。データを最近アクセスした場合にのみ、各ブロック内のデータが保存されます。"復活"メカニズムが存在し、もし保存されなくなった場合には。これらの提案の主な違いは: ###i (「最近」をどのように定義するか、そして )ii (「ブロック」をどのように定義するかです。具体的な提案はEIP-7736であり、これはVerkleツリーのために導入された「茎葉」設計に基づいています )無状態の状態の任意の形式、例えば二分木に互換性があります (。この設計では、隣接するヘッダー、コード、およびストレージスロットが同じ「主幹」の下に保存されます。1つの茎の下に保存されるデータは最大で256 * 31 = 7,936バイトです。多くの場合、アカウントの全ヘッダーとコード、および多くのキーのストレージスロットが同じ主幹の下に保存されます。特定の主幹の下のデータが6か月間読み取られたり書き込まれたりしない場合、そのデータはもはや保存されず、そのデータの32バイトのコミットメント「ストッブ」)のみが保存されます。将来、そのデータにアクセスする取引は、データを「復活」させ、ストッブに基づいて確認する証明を提供する必要があります。他にも同様のアイデアを実現する方法があります。例えば、アカウントレベルの粒度が不十分な場合、ツリーの各1/232部分が類似の茎葉メカニズムによって制御されるような計画を策定することができます。インセンティブ要因のため、これはさらに厄介になります: 攻撃者は、大量のデータを単一のサブツリーに投入し、毎年単一のトランザクションを送信することで「ツリーを更新」し、クライアントに大量の状態を永続的に保存させることができます。もし更新コストをツリーのサイズに比例(させるか、更新の持続時間を反比例)させると、誰かが自分と同じサブツリーに大量のデータを投入することで他のユーザーに損害を与える可能性があります。人々は、サブツリーのサイズに基づいて粒度を動的に調整することで、これら二つの問題を制限しようとするかもしれません: 例えば、連続する 216= 65536 の状態オブジェクトは「グループ」と見なされることができます。しかし、これらのアイデアはより複雑です; 茎に基づくアプローチはシンプルであり、通常、茎の下でインセンティブを調整することができます。
イーサリアム未来の青写真：The Purgeはプロトコルをシンプルにし、ドロップ膨張を目指しています
イーサリアムの可能な未来：The Purge
イーサリアムが直面している課題の一つは、デフォルトで、あらゆるブロックチェーンプロトコルの膨張と複雑性が時間の経過とともに増加することです。これは二つの側面で発生します: 歴史的データとプロトコル機能。イーサリアムが長期的に維持できるようにするためには、これらの二つの傾向に対して強力な反圧を加え、時間の経過とともに複雑性と膨張を減少させる必要があります。しかし同時に、ブロックチェーンを偉大にする重要な属性の一つである持続性を保持する必要があります。
パージの主な目的は次のとおりです。
! ヴィタリック:イーサリアムの未来の可能性、パージ
履歴の有効期限
は何の問題を解決しますか？
この記事執筆時点で、完全に同期したイーサリアムノードは、クライアントを実行するために約1.1TBのディスクスペースを必要とし、さらに数百GBのディスクスペースがコンセンサスクライアントに必要です。その大部分は歴史的なもので、歴史的なブロック、トランザクション、レシートに関するデータであり、そのほとんどは数年前のものです。これは、ガス制限がまったく増加しなくても、ノードのサイズが毎年数百GB増加し続けることを意味します。
それは何ですか、それはどのように機能しますか?
歴史的なストレージ問題の重要な簡略化された特徴は、各ブロックがハッシュでリンクされており(、他の構造)が前のブロックを指し示しているため、現在の合意に達することが歴史に対する合意に十分であるということです。ネットワークが最新のブロックに合意すれば、任意の歴史的ブロックや取引、または状態(のアカウント残高、ランダム数、コード、ストレージ)を任意の単一の参加者が提供し、Merkle証明を使用することができます。そして、その証明により他の誰もがその正確性を検証することができます。合意はN/2-of-N信頼モデルであり、歴史はN-of-N信頼モデルです。
これは、私たちが歴史をどのように保存するかについて多くの選択肢を提供します。自然な選択肢の一つは、各ノードがデータの小さな部分のみを保存するネットワークです。これが、数十年にわたってシードネットワークが機能してきた方法です：ネットワーク全体で何百万ものファイルを保存し配布しているにもかかわらず、各参加者はその中の数ファイルのみを保存し配布します。直感に反するかもしれませんが、この方法はデータの堅牢性を必ずしも低下させるわけではありません。ノードをより経済的に稼働させることで、各ノードがランダムに10％の履歴を保存する100,000ノードのネットワークを構築できるなら、各データは10,000回複製されます – すべての内容を保存する各ノードを持つ10,000ノードのネットワークとまったく同じ複製係数です。
現在、イーサリアムはすべてのノードがすべての履歴を永久に保存するモデルから脱却し始めています。コンセンサスブロック(は、ステークプルーフコンセンサスに関連する部分)が約6か月間保存されるだけです。Blobは約18日間保存されます。EIP-4444は、履歴ブロックとレシートに1年間の保存期間を導入することを目的としています。長期的な目標は、統一された期間を確立することで(は約18日間)であり、この期間中に各ノードがすべてのコンテンツを保存し、その後、イーサリアムノードで構成されるピアツーピアネットワークを構築して、古いデータを分散ネットワーク方式で保存することです。
エラージャーコードは、同じレプリケーションファクターを維持しながら、堅牢性を向上させるために使用できます。実際、Blobはデータの可用性サンプリングをサポートするためにエラージャーコードを使用しています。最も簡単な解決策は、おそらくこのエラージャーコードを再利用し、実行とコンセンサスブロックデータもBlobに入れることです。
! Vitalik:イーサリアムの可能な未来、パージ
まだ何をする必要がありますか、何を考慮する必要がありますか？
残りの主な作業は、履歴を保存するための具体的な分散ソリューションを構築および統合することです------少なくとも実行履歴ですが、最終的にはコンセンサスと blob も含まれます。最も簡単なソリューションは (i) 既存のトレントライブラリを単純に導入することと、(ii) と呼ばれるポータルネットワークのエーテルネイティブソリューションです。それらのいずれかを導入すれば、私たちは EIP-4444 を開くことができます。 EIP-4444 自体はハードフォークを必要としませんが、新しいネットワークプロトコルのバージョンが必要です。したがって、すべてのクライアントで同時にそれを有効にすることは価値があります。そうでないと、他のノードに接続して完全な履歴をダウンロードすることを期待しているが実際には取得できないためにクライアントが故障するリスクがあります。
主要なトレードオフは、私たちが「古代」歴史データを提供するためにどのように努力するかに関係しています。最も簡単な解決策は、明日古代の歴史の保存を停止し、既存のアーカイブノードとさまざまな集中型プロバイダーに依存してコピーを行うことです。これは簡単ですが、エーテルが永久記録の場としての地位を弱めます。より困難ですが安全な方法は、まずトレントネットワークを構築し統合して、分散方式で歴史を保存することです。ここでの「私たちはどれだけ努力しているか」には2つの次元があります:
(の極端な偏執的アプローチは、保管証明を含む: 実際に、各ステークプルーフ検証者が一定の割合の履歴を保存し、定期的にそれを暗号化してチェックすることを要求します。より穏やかなアプローチは、各クライアントが保存する履歴のパーセンテージに対して自主的な基準を設定することです。
)2(について、基本的な実装は今日完了した作業にのみ関係しています: Portalは、全エーテルの歴史を含む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つの目標を達成する方法でこれを行うことです:
これらの目標を満たさないと、問題を解決するのが簡単になります。例えば、各状態オブジェクトに期限日カウンターを保存させることができ、)は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 の状態オブジェクトは「グループ」と見なされることができます。しかし、これらのアイデアはより複雑です; 茎に基づくアプローチはシンプルであり、通常、茎の下でインセンティブを調整することができます。