イーサリアムの可能な未来：浄化

イーサリアムが直面している重要な課題の一つは、長期的に複雑性とストレージの要求を低下させながら、チェーンの持続性と非中央集権性を維持する方法です。イーサリアムが長期的に存続できるようにするためには、複雑性と膨張に強力な反圧をかけ、時間の経過とともに複雑性と膨張を低下させる必要があります。しかし同時に、ブロックチェーンの持続性という重要な特性を保持する必要があります。

浄化の主な目標には以下が含まれます:

1. 各ノードがすべての履歴や最終状態を永久に保存する必要を減らすか排除することで、クライアントのストレージ要件を軽減する。

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

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

履歴の有効期限が切れます

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

現在、完全同期のイーサリアムノードは、クライアントを実行するために約1.1 TBのディスクスペースを必要とし、さらに数百GBのコンセンサスクライアント用のスペースが必要です。その大部分は履歴データであり、ブロックサイズが変わらなくても、ノードのサイズは毎年数百GB増加し続けます。

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

歴史的なストレージ問題の重要な簡略化された特徴は、各ブロックがハッシュで前のブロックを指し示すため、現在の合意に達することが歴史に対する合意に達することに十分であるということです。これにより、私たちは歴史的な記録をどのように保存するかについて多くの選択肢を提供されます。自然な選択肢の一つは、各ノードがデータの小さな部分のみを保存するネットワークです。

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

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

残りの主な作業は、履歴を保存するための具体的な分散ソリューションを構築し、統合することです。最も簡単なソリューションは、既存のtorrentライブラリを導入するか、Portalネットワークと呼ばれるイーサリアムのネイティブソリューションを使用することです。主なトレードオフは、"古代"の履歴データを提供するために私たちがどのように努力するかに関わっています。最も簡単なソリューションは、明日から古代の履歴の保存を停止し、既存のアーカイブノードとさまざまな集中型プロバイダーに依存して複製することです。より困難ですが、より安全な方法は、まずtorrentネットワークを構築し、統合して、分散方式で履歴を保存することです。

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

ノードの運用や起動を非常に簡単にしたいのであれば、履歴の保存要件を削減することは、無状態性よりも重要であると言えます。無状態性とEIP-4444を実現することで、スマートウォッチ上でエーテルノードを運用し、数分で設定できるというビジョンを実現できます。

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

ステータスの期限

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

クライアントの履歴を保存する必要がなくなっても、クライアントのストレージの需要は毎年約50 GB増加し続けます。これは、状態が持続的に増加するためです。ユーザーは一度の料金を支払うことで、現在および将来のイーサリアムクライアントに永続的な負担をもたらします。

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

今日、新しいステートオブジェクトを作成すると、そのステートオブジェクトは常にその状態にあります。逆に、私たちが望むのは、オブジェクトが時間の経過とともに自動的に期限切れになることです。重要な課題は、効率性、ユーザーフレンドリーさ、開発者フレンドリーさという3つの目標を達成する方法でこれを行うことです。

現在、2種類の「知られている最悪ではない解決策」があります:

• 部分的な状態の有効期限の解決
• アドレス周期に基づく状態の期限に関する提案

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

アドレスサイクルに基づく設計は、増加し続ける状態ツリーのリストを使用し、読み取りまたは書き込みの状態はすべて最新の状態ツリーに保存されます。各期間(、例えば:1年)ごとに新しい空の状態ツリーが1つ追加されます。古いツリーはすべて凍結されます。完全なノードは最近の2つのツリーのみを保存します。

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

私は未来に4つの実行可能な道があると考えています:

1. 私たちはステートレスを実現し、状態の有効期限を決して導入しません。
2. 我々は一部の状態が期限切れになるのを行い、より低いが依然としてゼロではない永久的な状態サイズの成長率を受け入れます。
3. 私たちはアドレス空間の拡張を通じて状態の期限切れを行います。
4. 私たちはアドレス空間の縮小を通じて状態の期限切れを行います。

重要な点は、アドレス形式の変更に依存する状態期限方案が実施されるかどうかにかかわらず、最終的にはアドレス空間の拡張と収縮に関する課題を解決しなければならないということです。

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

機能クリーンアップ

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

安全性、可アクセス性と信頼できる中立性の重要な前提条件の1つは、シンプルさです。プロトコルが美しくシンプルであれば、エラーが発生する可能性が減ります。それは新しい開発者がその任意の部分に参加する機会を増やします。それは公平である可能性が高く、特定の利益に対してもより抵抗力があります。不幸なことに、プロトコルは他のソーシャルシステムと同様に、時間が経つにつれてデフォルトでより複雑になってしまいます。

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

重大な単一の修正でプロトコルの複雑さを低下させることはできません。この問題の本質は、多くの小さな解決策があることです。いくつかの重要な例は次のとおりです:

• RLP → SSZ 変換
• 古い取引タイプを削除する
• LOG改革
• 最終的なビーコンサインシンク委員会メカニズムの削除
• データ形式の統一
• ビーコンチェーン委員会の解任
• 混合バイト順を削除
• ガスメカニズムの簡略化
• プリコンパイルを削除
• ガスの可視性を削除
• 静解析の改善

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

この機能を簡素化する際の主なトレードオフは、簡素化の程度と速度と後方互換性のバランスです。より広範な社会的問題は、非緊急の後方互換性を破壊する変更を行うための標準化されたパイプラインを作成することです。

EVMオブジェクトフォーマット(EOF)は、EVMに提案された一連の主要な変更です。それの利点は、新しいEVM機能を追加するための自然な道を作成し、より強い保証を持つより厳格なEVMへの移行を促進することです。それの欠点は、旧いEVMを最終的に廃止して削除する方法を見つけない限り、プロトコルの複雑性が大幅に増加することです。

より過激なイーサリアムの簡素化戦略は、プロトコルを変えずに、その大部分をプロトコル機能からコントラクトコードに移すことです。最も極端なバージョンは、イーサリアムL1を「技術的に」単なるビーコーチェーンにし、他の人が自分のサマリーを作成できる最小限の仮想マシンを導入することです。そうすれば、EVMはこれらのサマリーの最初のものとなります。

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

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