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.
イーサリアムプロトコルの繁栄の道：EVMの改善、アカウントの抽象化と多次元Gas
イーサリアムプロトコルの可能な未来（六）：繁栄編
いくつかの事物は単一のカテゴリに分類するのが難しく、イーサリアムプロトコルの設計には、イーサリアムの成功にとって非常に重要な「詳細」が多数存在します。実際、内容の約半分は異なるタイプの EVM 改善に関するもので、残りはさまざまなニッチなテーマで構成されており、これが「繁栄」の意味です。
! イーサリアムの可能な未来についてのヴィタリック(6):散財
繁栄:主要な目標
! イーサリアムの可能な未来についてのヴィタリック(6):散財
EVMの改善
どのような問題を解決しましたか？
現在のEVMは静的解析を行うのが難しく、効率的な実装を作成し、形式的にコードを検証し、さらなる拡張を行うことが困難になっています。さらに、EVMの効率は低く、多くの形式の高度な暗号学を実現するのが難しいですが、プリコンパイルによる明示的なサポートがない限りはそうです。
それは何ですか、どのように機能しますか？
現在のEVM改善ロードマップの第一歩はEVMオブジェクトフォーマット（EOF）であり、次のハードフォークでの導入が計画されています。EOFは一連のEIPで、新しいEVMコードバージョンを指定し、多くの独自の特徴を持っています。最も顕著なのは：
旧式合約は引き続き存在し、作成可能ですが、最終的には旧式合約が段階的に廃止される可能性があり（場合によっては強制的に EOF コードに変換されることもあります）、新式合約は EOF による効率の向上の恩恵を受けることになります。
EOFを導入した後、さらなるアップグレードが容易になりました。現在最も発展しているのはEVMモジュール算術拡張（EVM-MAX）です。EVM-MAXはモジュロ演算に特化した新しい命令セットを作成し、それを他のオペコードからアクセスできない新しいメモリ空間に配置しました。これにより、Montgomery乗算などの最適化の使用が可能になりました。
新しいアイデアの一つは、EVM-MAX と単一命令多データ（SIMD）機能を組み合わせることです。SIMD はイーサリアムの理念の一つとして長い間存在しており、最初は Greg Colvin の EIP-616 によって提案されました。SIMD は、ハッシュ関数、32 ビット STARKs、および格ベースの暗号学を含む多くの形式の暗号学を加速するために使用できます。EVM-MAX と SIMD の組み合わせは、これら二つのパフォーマンス指向の拡張を自然な組み合わせにします。
! イーサリアムの可能な未来についてのヴィタリック(6):散財
現在の研究リンク
残りの作業とトレードオフ
現在、EOFは次のハードフォークに組み込まれる予定です。最後の瞬間にそれを削除する可能性は常にありますが、その場合は大きな課題に直面します。EOFを削除することは、将来のEVMに対するいかなるアップグレードもEOFなしで行う必要があることを意味しますが、それは可能であるものの、より困難になる可能性があります。
EVM の主なトレードオフは L1 の複雑性とインフラストラクチャの複雑性であり、EOF は EVM 実装に追加する必要がある大量のコードであり、静的コードチェックも相対的に複雑です。しかし、交換として、私たちは高級言語を簡素化し、EVM 実装を簡素化し、その他の利点を得ることができます。イーサリアム L1 の継続的な改善のロードマップは、EOF を含むべきであり、それに基づいて構築されるべきだと言えます。
必要な作業の一つは、EVM-MAXに似たSIMD機能を実現し、さまざまな暗号操作のガス消費をベンチマークすることです。
どのようにロードマップの他の部分と相互作用しますか？
L1はそのEVMを調整して、L2もより簡単に対応する調整を行えるようにします。もし両者が同期して調整しない場合、互換性が失われ、不利な影響をもたらす可能性があります。さらに、EVM-MAXとSIMDは多くの証明システムのガスコストを削減できるため、L2をより効率的にします。また、同じタスクを実行できるEVMコードでより多くのプレコンパイルを置き換えることが容易になり、効率に大きな影響を与えない可能性があります。
! イーサリアムの可能な未来についてのヴィタリック(6):散財
アカウント抽象
どのような問題を解決しましたか？
現在、取引は一つの方法でのみ検証できます：ECDSA署名。最初、アカウントの抽象化はこれを超えることを目指しており、アカウントの検証ロジックを任意のEVMコードにすることを可能にします。これにより、一連のアプリケーションが有効になります：
2015年にアカウント抽象が提案されて以来、その目標は大量の「便利目標」を含むように拡大されました。例えば、ETHを持っていないが、いくつかのERC20を持っているアカウントは、ERC20を使ってガスを支払うことができます。
それは何ですか、どのように機能しますか？
アカウント抽象の核心はシンプルです：スマートコントラクトがトランザクションを開始できるようにすること、EOAだけではありません。この全体の複雑さは、去中心化ネットワークの維持に優しい方法でこれを実現し、サービス拒否攻撃を防ぐことから来ています。
多年の努力の結果、機能を拡張しつつサービス拒否（DoS）リスクを制限することを目的とした、理想的なアカウント抽象を実現するためのソリューションが最終的に得られました：ERC-4337。
ERC-4337の動作原理は、ユーザー操作の処理を検証と実行の2つの段階に分けることです。すべての検証が最初に処理され、すべての実行がその後に処理されます。メモリプール内では、ユーザー操作の検証段階が自分のアカウントのみを関与し、環境変数を読み取らない場合にのみ受け入れられます。これにより、複数の失敗攻撃を防ぐことができます。さらに、検証ステップには厳格なガス制限も強制的に実施されます。
! イーサリアムの可能な未来についてのヴィタリック(6):散財
現在の研究リンク
残りの作業とバランス
現在主に解決すべき問題は、どのようにアカウント抽象をプロトコルに完全に導入するかです。最近人気のある書き込みプロトコルアカウント抽象 EIP は EIP-7701 で、この提案は EOF の上にアカウント抽象を実現します。アカウントは、検証のための個別のコード部分を持つことができ、そのコード部分が設定されている場合は、そのアカウントからの取引の検証ステップでそのコードが実行されます。
主要なトレードオフは「より少ない人々を満足させるための迅速なソリューションの作成」と「より理想的なソリューションを得るために長く待つこと」のようです。理想的な方法は、何らかのハイブリッドアプローチかもしれません。一つのハイブリッドアプローチは、いくつかのユースケースをより早く書き込み、他のユースケースを探索するためにより多くの時間を確保することです。もう一つのアプローチは、最初にL2上により野心的なアカウント抽象バージョンを展開することです。
それはロードマップの他の部分とどのように相互作用しますか？
包含リストはアカウント抽象トランザクションをサポートする必要があります。実際には、包含リストのニーズは分散型メモリプールのニーズと非常に似ていますが、包含リストにとっては柔軟性がやや高いです。さらに、アカウント抽象の実装は可能な限りL1とL2の間で調整を実現する必要があります。将来的に私たちがほとんどのユーザーがキー保存Rollupを使用することを期待するなら、アカウント抽象の設計はこれを基にする必要があります。
! イーサリアムの可能な未来についてのヴィタリック(6):散財
EIP-1559 の改良点
それはどのような問題を解決しましたか？
EIP-1559は2021年にイーサリアムで有効化され、平均ブロック包含時間を大幅に改善しました。
しかし、現在のEIP-1559の実施は多くの点で完璧ではありません：
後で blobs 用の公式（EIP-4844）は、最初の問題を解決するために特別に設計されており、全体的により簡潔です。しかし、EIP-1559 自体および EIP-4844 は、第二の問題を解決しようとはしていません。
さらに、EIP-1559 に関連しない他のイーサリアムリソースの価格設定の弱点がありますが、EIP-1559 の調整によって解決できます。主な問題の一つは、平均的な状況と最悪の状況の違いです：イーサリアムにおけるリソース価格は、最悪の状況に対処できるように設定する必要があります。つまり、1 ブロックの全ガス消費が1つのリソースを占有しますが、実際の平均使用量はこれを大きく下回るため、非効率が生じます。
多次元ガスとは何ですか、それはどのように機能しますか？
これらの非効率な問題を解決するためのソリューションは多次元ガスです：異なるリソースに異なる価格と制限を設定します。この概念は技術的にはEIP-1559から独立していますが、EIP-1559の存在によりこのソリューションの実現が容易になります。EIP-1559がなければ、さまざまなリソース制約を含むブロックを最適にパッキングすることは複雑な多次元ナップサック問題です。しかし、EIP-1559があることで、ほとんどのブロックはどのリソースでもフルロードには達しないため、「十分な料金を支払う取引はすべて受け入れる」というシンプルなアルゴリズムで十分です。
現在、私たちは実行とデータブロックのための多次元ガスを持っています；原則として、これをより多くの次元に拡張することができます：たとえば、calldata（取引データ）、状態の読み取り/書き込み、および状態サイズの拡張。
EIP-7706は、新しいガス次元を導入し、calldataに特化しています。同時に、3種類のガスを1つの（EIP-4844スタイルの）フレームワークに統一することで、多次元ガスメカニズムを簡素化し、EIP-1559の数学的欠陥も解決しました。EIP-7623は、平均的な状況と最悪の状況のリソース問題に対して、より正確な解決策であり、全体の新しい次元を導入することなく、最大calldataをより厳しく制限します。
! イーサリアムの可能な未来についてのヴィタリック(6):散財
現在の研究リンク