This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
イーサリアム浄化の道:ドロップストレージの必要性とプロトコルの複雑性の簡素化
イーサリアムの可能な未来:浄化
ヴィタリック・ブテリンは最近、イーサリアムの未来の発展に関する一連の議論記事を発表し、合併、急増、鞭打ち、エッジから最新の浄化段階までを探討しました。これらの記事は、ヴィタリックがイーサリアムメインネットの未来の発展についてのビジョンや、現在直面している問題をどのように解決するかを示しています。
浄化段階の主な目標は、各ノードがすべての履歴や最終状態を永続的に保存する必要性を減少または排除することによってクライアントのストレージ要件を低下させ、不要な機能を排除することによってプロトコルの複雑さを低下させることです。
! ヴィタリック:イーサリアムの未来の可能性、パージ
履歴の有効期限が切れます
履歴の期限切れは、完全に同期されたイーサリアムノードが大量のディスクスペースを必要とする問題を解決することを目的としています。現在、実行クライアントには約1.1 TBのディスクスペースが必要であり、コンセンサスクライアントには数百GBがさらに必要です。その大部分は数年前の履歴データです。
歴史の期限切れの鍵は、コンセンサスメカニズムの特性を利用することであり、最新のブロックに対してコンセンサスを達成するだけで十分に歴史データの正確性を検証できます。これにより、各ノードが部分的なデータのみを保存するなど、歴史記録を保存するためのさまざまな選択肢が提供されます。
現在、イーサリアムはすべてのノードがすべての履歴を永続的に保存するモデルから徐々に脱却し始めています。コンセンサスブロックは約6か月間保存され、Blobは約18日間保存されます。将来の目標は、統一された保存期間(が約18日間)であることを確立し、その後、分散ネットワークを通じて古いデータを保存することです。
歴史的な期限切れを実現するには、既存のトレントライブラリやエーテルのネイティブなポータルネットワークを導入するなど、具体的な分散ストレージソリューションを構築し、統合する必要があります。主なトレードオフは、"古代"の歴史データを提供するためにどのように努力するか、そして歴史ストレージをプロトコルに統合する深さです。
歴史的期限はノードの運用と起動の簡略化にとって重要であり、スマートウォッチ上でイーサリアムノードを実行するというビジョンの実現に役立ちます。また、最新のプロトコルバージョンのみをサポートすることで、より新しいイーサリアムノードの実現を可能にします。
! Vitalik:イーサリアムの可能な未来、パージ
ステータス期限切れ
状態の期限切れは、ストレージの履歴を保持する必要がなくなったとしても、クライアントのストレージのニーズが引き続き増加するという問題を解決することを目的としています。これは、状態(のアカウント残高、乱数、コントラクトコード、ストレージ)が継続的に増加し、ユーザーが一度の料金を支払うだけでクライアントに永続的なストレージ負担をもたらすためです。
状態の期限切れは、歴史的な期限切れよりも実現が難しい。なぜなら、EVMの設計は状態オブジェクトが一度作成されると永遠に存在することを前提としているからだ。現在、主に二つの解決策がある: 部分的な状態の期限切れとアドレス周期に基づく状態の期限切れ。
部分状態が期限切れになると、状態がブロックに分割され、最近アクセスされたデータのみが保存されます。EIP-7736は、Verkleツリーに導入された「茎葉」設計に基づく具体的な提案です。
アドレス周期に基づく設計は、増加し続ける状態ツリーリストを通じて復活衝突問題を解決します。各期間(では1年)ごとに新しい空の状態ツリーが追加され、完全なノードは最近の2つのツリーのみを保存します。
状態の期限切れを実現する主な課題は、アドレス空間の拡張または縮小であり、これには複雑な互換性と安全性の問題を解決する必要があります。状態の期限切れを実施するかどうかにかかわらず、最終的にはアドレス空間に関する問題を解決しなければなりません。
! Vitalik:イーサリアムの可能な未来、パージ
機能クリーニング
機能のクリーンアップは、プロトコルの複雑性を低下させ、安全性、アクセシビリティ、信頼性の中立性を高めることを目的としています。主な方法には、不必要な機能の削除、既存のメカニズムの簡素化、データフォーマットの統一などが含まれます。
いくつかの具体的な簡素化の機会には、
機能簡素化の主なトレードオフは、簡素化の程度と速度と後方互換性との間にあります。非緊急の後方互換性を破壊する変更を行うための標準化されたパイプラインを確立する必要があり、機能削除と保守の間でバランスを求める必要があります。
EVMオブジェクト形式(EOF)はEVMに提案された一連の主要な変更であり、EVMがより強力な属性を持つ方法でアップグレードを行えるようにすることを目的としています。その利点は、新しいEVM機能を追加する自然な道を作成することですが、プロトコルの複雑さも大幅に増加させます。
より過激な簡素化戦略は、プロトコルの大部分を契約コードに変換することです。たとえば、イーサリアムL1を信号チェーンだけに変え、最小限の仮想マシンを導入して集約を作成するか、EVMをその場で交換し、新しい「公式イーサリアムVM」を選択することです。
! [ヴィタリック:イーサリアムの可能な未来、パージ] (https://img-cdn.gateio.im/webp-social/moments-5cd0e9908a04986f83c85cabecd4a0ae.webp)
総じて、浄化段階は、歴史的な期限切れ、状態の期限切れ、および機能のクリーンアップを通じて、ストレージの要件とプロトコルの複雑さを低減し、イーサリアムの長期的なスケーラビリティと持続可能性の基盤を築くことを目的としています。これには、簡素化と互換性の間でのバランスを求める必要があり、プロトコルに対する深遠な変革が含まれる可能性があります。
! [Vitalik:イーサリアムの可能な未来、パージ] (https://img-cdn.gateio.im/webp-social/moments-dcbf40e0c1bc28d9082b35ed7741f911.webp0192837465674839201