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

10月14日以降、イーサリアムの創設者ヴィタリック・ブテリンは、イーサリアムの将来の発展に関する一連の議論記事を次々と発表しました。《The Merge》から最新の《The Purge》まで、彼のイーサリアムメインネットの将来の発展に対する構想と現在の問題を解決するための提案が示されています。

《The Purge》記事では、イーサリアムが長期的に複雑さとストレージの要件をどのように削減し、同時にチェーンの持続性と分散化を維持するかを探討しています。主な措置には、「履歴の期限切れ」および「状態の期限切れ」によってクライアントのストレージ負担を軽減し、「特徴のクリーニング」によってプロトコルを簡素化し、ネットワークの持続可能性とスケーラビリティを確保することが含まれています。

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

履歴の有効期限

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

現在、完全に同期されたイーサリアムノードは、クライアントを実行するために約1.1TBのディスクスペースを必要とし、さらに数百GBがコンセンサスクライアントに必要です。ほとんどが履歴データであり、Gas制限が変わらなくても、ノードのサイズは毎年数百GB増加します。

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

歴史の保存における重要な特徴は、現在の合意があれば歴史に対する合意も十分であるということです。これにより、各ノードが一部のデータのみを保存するネットワークなど、歴史記録を保存するためのさまざまな選択肢が提供されます。

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

エラージャーコードは、同じレプリケーションファクターを維持しながら、ロバスト性を向上させるために使用できます。最も簡単な解決策は、Blobの既存のエラージャーコードを再利用し、実行およびコンセンサスブロックデータもBlobに入れることかもしれません。

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

まだ何をする必要がありますか？何を天秤にかける必要がありますか？

主な作業は、履歴を保存するための具体的な分散ソリューションを構築および統合することです。最も簡単なソリューションは、既存のtorrentライブラリを導入するか、Portalネットワークと呼ばれるイーサリアムのネイティブソリューションを使用することです。

主なトレードオフは、"古代"の履歴データをどのように提供するかに関係しています。最も簡単な解決策は、すぐに古代の履歴の保存を停止し、既存のアーカイブノードに依存することです。より安全ですが、より困難な解決策は、まずトレントネットワークを構築し統合することです。

とロードマップの他の部分との相互作用

歴史的なストレージの要求を減少させることは、ノードの運用を非常に容易にするために極めて重要です。無状態性とEIP-4444を実現することで、スマートウォッチ上でエーテルノードを運用するというビジョンを実現できます。

履歴ストレージの制限は、最新のプロトコルバージョンのみをサポートする新しいイーサリアムノードの実装をより実行可能にし、クライアントを簡素化します。

状態の有効期限が切れる

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

履歴ストレージの要求を排除しても、クライアントのストレージ要求は毎年約50GB増加し続けます。なぜなら、状態(のアカウント残高、契約コードなどの)が継続的に増加するからです。ユーザーは一度の支払いで、現在および将来の顧客に永続的な負担をもたらすことができます。

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

状態は歴史よりも"期限切れ"になるのが難しい。なぜなら、EVMは状態オブジェクトが一度作成されると永遠に存在すると仮定しているからだ。目標は、効率性、ユーザーフレンドリーさ、開発者フレンドリーさを維持しながら、時間とともにオブジェクトを自動的に期限切れにすることだ。

主要には二つのタイプのプランがあります:

1. 一部の状態が期限切れ: 状態をブロックに分割し、最近アクセスされたデータのみを保存します。EIP-7736はVerkleツリーに基づくソリューションを提案しており、6か月間アクセスされていないデータはわずか32バイトのスナップショットのみを保存します。

2. アドレスサイクルに基づく状態の期限切れ: 増加し続ける状態ツリーリストを使用し、毎年新しい空のツリーを追加します。フルノードは最近の2つのツリーのみを保持します。期限切れのデータは、読み書きするための証明を提供する必要があります。

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

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

未来の可能な道には次のものが含まれます:

1. ステートレスを実現し、状態の期限を導入しない。状態は持続的に増加するが、特別なユーザーのストレージのみが必要。

2. 一部の状態の期限が切れることを実現し、低いがゼロでない永続的な状態の成長率を受け入れる。

3. アドレス空間の拡張を通じて状態の期限切れを実現します。アドレス形式の変換を安全かつ効果的に行うためには、数年のプロセスが必要です。

4. アドレス空間の縮小によって状態の期限切れを実現します。すべてのセキュリティリスクを解決するために、数年のプロセスが必要です。

どのようなソリューションを採用しても、アドレス空間の拡張と収縮の課題を解決する必要があります。なぜなら、将来的にはアドレスの衝突攻撃がより容易になるからです。

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

機能クリーンアップ 特徴クリーニング

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

プロトコルの単純さは、安全性、アクセス可能性、信頼できる中立性の鍵です。しかし、プロトコルは時間とともに複雑になるのがデフォルトです。私たちは機能を削除し、複雑さを減少させる能力を必要としています。

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

単一の重大な修正でプロトコルの複雑さを低下させることはできず、多くの小さな解決策が必要です。いくつかの重要な例には、次のものが含まれます:

• RLP → SSZ変換: より良いSSZでRLPエンコーディングを置き換える
• 古い取引タイプを削除する
• LOG改革:未使用のブルームフィルターなどの機能を削除
• 信標チェーン同期委員会メカニズムを削除する
• データフォーマットの統一
• ビーコンチェーン委員会の解任
• ミックスバイトオーダーを除去する

EVMのいくつかの例:

• ガス機構の簡素化
• プリコンパイルを削除
• ガスの可観測性を除去する
• 静的分析の改善: 動的ジャンプの削除

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

主なトレードオフは、単純さと速度と後方互換性です。影響分析、正式なEIPの廃止、最終的な削除などのステップを含む、非緊急の後方互換性の破壊的変更を行うための標準化されたプロセスを作成する必要があります。

EVMオブジェクト形式(EOF)は、一連のEVM変更を提案し、より多くのアップグレードを可能にすることを目的としています。追加される複雑さとEVM全体を簡素化する目標とのバランスを取る必要があります。

より過激なアプローチは、プロトコルの大部分をコントラクトコードに変換することであり、例えばEVMをサマリーに変えたり、新しいVMでEVMを置き換えたりします。これによりプロトコルが大幅に簡素化されますが、互換性のバランスを取る必要があります。

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