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.
イーサリアムThe Splurge段階: EVM最適化、アカウントの抽象化とEIP-1559アップグレードの展望
イーサリアムプロトコルの可能な未来(六):The Splurge
イーサリアムプロトコル設計中には多くの「詳細」がその成功にとって重要です。実際、約半分の内容は異なるタイプのEVM改善に関するもので、残りはさまざまなニッチなテーマから構成されており、これが「繁栄」の意味です。
! イーサリアムの可能な未来についてのヴィタリック(6):散財
繁栄:主要な目標
! イーサリアムの可能な未来についてのヴィタリック(6):散財
EVMの改善
どのような問題を解決しましたか?
現在のEVMは静的分析が困難であり、これにより効率的な実装の作成、正式なコードの検証、およびさらなる拡張が難しくなっています。また、EVMの効率は低く、多くの形式の高度な暗号学を実現することは困難であり、事前コンパイルによる明示的なサポートが必要です。
それは何ですか、どのように機能しますか？
現在のEVM改善ロードマップの第一歩はEVMオブジェクトフォーマット(EOF)で、次のハードフォークに組み込む予定です。EOFは一連のEIPで、新しいEVMコードバージョンを指定し、多くの独特な特徴を持っています。最も顕著な特徴は:
旧式合約は引き続き存在し、作成することができますが、最終的には旧式合約(が段階的に廃止される可能性があり、場合によってはEOFコード)に強制的に変換されることもあります。新式合約は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):散財
アカウントの抽象化
どのような問題を解決しましたか?
現在、取引は1つの方法でのみ検証できます: ECDSA署名。最初は、アカウントの抽象化がこれを超えることを目的としており、アカウントの検証ロジックが任意のEVMコードであることを許可します。これにより、一連のアプリケーションが有効になります:
中継なしでプライバシープロトコルを機能させることを許可し、その複雑さを大幅に軽減し、主要な中央依存点を排除します。
2015年にアカウント抽象が提案されて以来、その目標は多くの「便利な目標」を含むように拡張されました。例えば、ETHを持たないがいくつかのERC20を持っているアカウントがERC20を使ってガスを支払うことができるようになります。
MPC(マルチパーティ計算)は、40年の歴史を持つ技術であり、鍵を複数の部分に分割して複数のデバイスに保存し、暗号技術を利用して署名を生成することができ、これらの鍵の部分を直接組み合わせる必要がありません。
EIP-7702は、次のハードフォークで導入される予定の提案です。EIP-7702は、すべてのユーザー(、特にEOAユーザー)に利益をもたらすアカウント抽象化の利便性を提供することに対する認識の高まりの結果です。短期的にすべてのユーザーの体験を改善し、2つのエコシステムに分裂するのを避けることを目的としています。
この作業はEIP-3074から始まり、最終的にEIP-7702が形成されました。EIP-7702は、アカウントの抽象化の「便利機能」をすべてのユーザーに提供します。これには、今日のEOA(である外部所有アカウント、すなわちECDSA署名で制御されるアカウント)が含まれます。
! イーサリアムの可能な未来についてのヴィタリック(6):散財
それは何ですか、どのように機能しますか？
アカウントの抽象化の核心はシンプルです: スマートコントラクトが取引を開始できるようにすること、そしてそれは単なるEOAではありません。この全体の複雑さは、去中心化ネットワークの維持に優しい方法でこれを実現し、サービス拒否攻撃を防ぐことから来ています。
典型的な主要な課題は、複数の失敗の問題です:
もし1000のアカウントの検証関数がある単一の値Sに依存していて、現在の値Sがメモリプール内の取引をすべて有効にしている場合、単一の取引がSの値を反転させると、メモリプール内の他のすべての取引が無効になる可能性があります。これにより、攻撃者は非常に低コストでメモリプールにジャンク取引を送信し、ネットワークノードのリソースを塞ぐことができます。
多年の努力を経て、機能を拡張しつつDoS(リスクを制限することを目的とした結果、"理想的なアカウント抽象化"を実現する解決策が得られました:ERC-4337。
ERC-4337の動作原理は、ユーザー操作の処理を検証と実行の2つの段階に分けることです。すべての検証は最初に処理され、すべての実行はその後に処理されます。メモリプールでは、ユーザー操作の検証段階が自身のアカウントのみを含み、環境変数を読み取らない場合にのみ受け入れられます。これにより、複数の失敗攻撃を防ぐことができます。さらに、検証ステップには厳格なガス制限が強制的に適用されます。
ERC-4337は追加のプロトコル標準)ERC(として設計されました。その当時、イーサリアムのクライアント開発者は)Merge(の統合に集中しており、他の機能に対処するための余力がありませんでした。これが、ERC-4337が通常の取引ではなく、ユーザー操作と呼ばれるオブジェクトを使用する理由です。しかし最近、私たちはその内容の少なくとも一部をプロトコルに書き込む必要があることを認識しました。
二つの重要な理由は以下の通りです:
さらに、ERC-4337は2つの機能を拡張しました:
! [イーサリアムの可能な未来についてのヴィタリック(6):散財])https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
)# 現在の研究リンク
)# 残りの作業とトレードオフ
現在、主に解決すべきは、アカウント抽象をプロトコルに完全に導入する方法です。最近人気のあるアカウント抽象を書くプロトコルEIPはEIP-7701であり、この提案はEOFの上にアカウント抽象を実現します。アカウントは検証のための独自のコード部分を持つことができ、アカウントがそのコード部分を設定している場合、そのコードはそのアカウントからの取引の検証ステップで実行されます。
この方法の魅力は、ローカルアカウントの抽象化についての2つの同等の視点を明確に示していることです:
もし私たちが検証期間中の実行可能なコードの複雑さに厳格な境界を設定し始めるなら——外部状態へのアクセスを許可せず、初期設定のガス制限も量子耐性やプライバシー保護アプリケーションに対して無効なほど低い——この方法の安全性は非常に明確です: ただECDSA検証を、同様の時間を必要とするEVMコードの実行に置き換えるだけです。
しかし、時間が経つにつれて、これらの制限を緩和する必要があります。なぜなら、プライバシー保護アプリケーションが中継なしで機能することを許可し、量子耐性が非常に重要だからです。そのためには、検証ステップが極端に簡素化される必要がないままで、サービス拒否###DoS(のリスクをより柔軟に解決する方法を見つける必要があります。
主要なトレードオフは、「少ない人を満足させるために迅速に書き込むプラン」と「より理想的な解決策を得るために長く待つ」ようです。理想的な方法は、ある種のハイブリッドアプローチかもしれません。ハイブリッドアプローチの一つは、いくつかのユースケースをより早く書き込み、他のユースケースを探るためにもっと時間を確保することです。もう一つの方法は、最初にL2上でより野心的なアカウント抽象のバージョンを展開することです。しかし、これが直面する課題は、L2チームが提案を採用することに自信を持たなければならないため、実施を進める意欲が必要です。特に、L1や他の将来のL2が互換性のあるプランを採用できることを確保する必要があります。
私たちが明確に考慮する必要があるもう一つのアプリケーションは、キー保管アカウントです、これ