イーサリアムプロトコルの可能な未来(六):繁栄

イーサリアムプロトコル設計中には、多くの「詳細」がその成功にとって重要です。約半分の内容は異なるタイプのEVM改善に関するもので、残りはさまざまなニッチなテーマで構成されており、これが「繁栄」の意味です。

繁栄:主要な目標

• EVMを高性能で安定した「最終状態」にする
• アカウントの抽象化をプロトコルに導入し、すべてのユーザーがより安全で便利なアカウントを享受できるようにします。
• 取引手数料の経済性を最適化し、スケーラビリティを向上させると同時にリスクを低減する
• 先進的な暗号学を探求し、イーサリアムを長期的に顕著に改善する

! イーサリアムの可能な未来についてのヴィタリック(6):散財

EVMの改善

どのような問題を解決しましたか？

現在、EVMは静的分析が難しく、効率的な実装の作成、正式な検証コード、およびさらなる拡張が困難になっています。また、EVMの効率が低く、多くの高度な暗号学を実現するのが難しいため、明示的なサポートがない限り、プレコンパイルを通じて実現する必要があります。

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

現在のEVM改善ロードマップの第一歩はEVMオブジェクトフォーマット(EOF)であり、次のハードフォークで取り入れる予定です。EOFは一連のEIPであり、新しいEVMコードバージョンを指定し、多くの独特な特徴を持っています。特に際立っているのは:

• コード(は実行可能ですが、EVMから)を読み取ることはできず、データ(は読み取ることができますが、実行できません)の分離
• 動的ジャンプは禁止されており、静的ジャンプのみが許可されています
• EVMコードは燃料に関連する情報を再び観察することができません
• 新しい明示的サブ例程メカニズムが追加されました

旧式契約は引き続き存在し、作成可能ですが、最終的には段階的に廃止される可能性があり(、さらにはEOFコード)に強制的に変換される可能性もあります。新式契約はEOFがもたらす効率の向上から恩恵を受けます——まずはサブルーチン機能によってわずかに小さくなったバイトコード、次にEOF特有の新機能や削減されたガスコストです。

EOFを導入した後、さらなるアップグレードが容易になり、現在最も発展しているのはEVMモジュールの算術拡張(EVM-MAX)です。EVM-MAXは、剰余演算専用の新しい命令セットを作成し、他のオペコードからアクセスできない新しいメモリ空間に配置しました。これにより、Montgomery乗法などの最適化を使用することが可能になりました。

! イーサリアムの可能な未来についてのヴィタリック(6):散財

新しいアイデアの一つは、EVM-MAXと単一命令多データ(SIMD)機能を組み合わせることである。SIMDはイーサリアムの理念の一つとして長い間存在しており、最初はGreg ColvinのEIP-616によって提案された。SIMDは、ハッシュ関数、32ビットSTARKs、格ベースの暗号学を含む多くの形式の暗号学を加速するのに使用でき、EVM-MAXとSIMDの組み合わせにより、これら二つの性能指向の拡張が自然なペアとなる。

実際の実装では、これは並行して処理されます。

残りの作業とトレードオフ

現在、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コードにすることができます。これにより、一連のアプリケーションを可能にします:

• 耐量子暗号への切り替え
• 古いキー(をローテーションすることは、推奨されるセキュリティプラクティスであると広く考えられています)
• マルチシグウォレットとソーシャルリカバリウォレット
• 低価値の操作には1つのキーを使用し、高価値の操作には別のキー(または一組のキー)を使用します。

中継なしでプライバシープロトコルが機能することを許可し、複雑さを大幅に低減し、重要な中央依存点を排除します。

2015年にアカウント抽象が提案されて以来、その目標は大量の「便利目標」を含むように拡張されました。例えば、ETHを持っていないがいくつかのERC20を持っているアカウントがERC20でガスを支払うことができるようになります。

MPC(マルチパーティ計算)は、鍵を複数の部分に分割して複数のデバイスに保存するために使用される、40年の歴史を持つ技術であり、暗号技術を利用して直接これらの鍵の部分を組み合わせることなく署名を生成します。

EIP-7702は次のハードフォークで導入される予定の提案であり、EIP-7702はすべてのユーザー(、EOAユーザー)に利益をもたらすアカウント抽象化の利便性を提供することへの認識の高まりの結果です。これは、短期間ですべてのユーザーの体験を改善し、2つのエコシステムに分裂するのを避けることを目的としています。

この作業はEIP-3074から始まり、最終的にEIP-7702が形成されました。EIP-7702は、アカウント抽象の「便利な機能」をすべてのユーザーに提供します。これには、今日のEOA(外部所有アカウント、つまりECDSA署名によって制御されるアカウント)が含まれます。

いくつかの課題(、特に「便利性」の課題)は、多方計算やEIP-7702のような漸進的技術によって解決できるが、アカウント抽象提案の主要な安全目標は、元の問題を遡って解決することでのみ達成可能である: スマートコントラクトコードが取引検証を制御できるようにすること。これまで実現されていない理由は、安全に実施することが挑戦であるからだ。

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

アカウントの抽象化の核心はシンプルです: スマートコントラクトが取引を開始できるようにすること、単なるEOAだけではありません。この全体の複雑さは、分散型ネットワークの維持に優しい方法でこれを実現し、サービス拒否攻撃を防ぐことから来ています。

一般的な主要な課題は、複数の障害の問題です。

もし1000のアカウントの検証関数がある単一の値Sに依存しており、現在の値Sがメモリプール内の取引をすべて有効にしている場合、単一の取引がSの値を反転させると、メモリプール内の他のすべての取引が無効になる可能性があります。これにより、攻撃者は非常に低コストでメモリプールにゴミ取引を送信し、ネットワークノードのリソースを塞ぐことができるのです。

長年の努力の結果、機能を拡張しつつ拒否サービス(DoS)のリスクを制限することを目的とした最終的な解決策が「理想的なアカウント抽象」を実現するためのERC-4337です。

ERC-4337の動作原理は、ユーザー操作の処理を2つの段階に分けることです: 検証と実行。すべての検証はまず処理され、その後すべての実行が処理されます。メモリプールでは、ユーザー操作の検証段階が自身のアカウントのみを含み、環境変数を読み取らない場合にのみ受け入れられます。これにより、多重失敗攻撃を防ぐことができます。さらに、検証ステップには厳格なガス制限も強制的に適用されます。

! イーサリアムの可能な未来についてのヴィタリック(6):散財

ERC-4337は追加のプロトコル標準(ERC)として設計されました。なぜなら、その当時イーサリアムクライアントの開発者はマージ(に集中しており、他の機能に取り組む余裕がなかったからです。これがERC-4337が通常の取引ではなくユーザー操作と呼ばれるオブジェクトを使用する理由です。しかし最近、私たちはその内容の少なくとも一部をプロトコルに書き込む必要があることを認識しました。

二つの重要な理由は以下の通りです:

1. EntryPointの契約としての固有の非効率性: 各バンドルには約100,000ガスの固定コストがあり、さらに各ユーザー操作には数千ガスが追加されます。
2. イーサリアム属性の必要性を確認する: 作成された包含保証に含まれるリストがアカウント抽象ユーザーに転送される必要があります。

さらに、ERC-4337は2つの機能を拡張しました:

• 支払い代理)Paymasters(: あるアカウントが別のアカウントの費用を支払うことを許可する機能であり、これは検証段階で送信者のアカウント自体のみへのアクセスが許可されるというルールに違反します。そのため、支払い代理メカニズムの安全性を確保するための特別な処理が導入されました。
• アグリゲーター)Aggregators(: BLSアグリゲーションやSNARKベースのアグリゲーションなど、署名アグリゲーション機能をサポートしています。これは、ロールアップ上で最高のデータ効率を実現するために必要です。

)# 残りの作業とトレードオフ

現在主に解決すべきは、どのようにアカウント抽象をプロトコルに完全に導入するかです。最近人気のある書き込みプロトコルアカウント抽象EIPはEIP-7701であり、この提案はEOFの上にアカウント抽象を実現しています。アカウントは、検証のための単独のコード部分を持つことができ、そのアカウントがそのコード部分を設定した場合、そのコードはそのアカウントからの取引の検証ステップで実行されます。

この方法の魅力は、ローカルアカウントの抽象化の2つの同等な視点を明確に示していることです:

1. EIP-4337をプロトコルの一部として
2. 新しいEOAタイプで、署名アルゴリズムはEVMコード実行です。

もし私たちが検証期間中の実行可能なコードの複雑性に厳しい制限を設け、外部状態へのアクセスを許可せず、初期に設定されたガス制限が量子耐性やプライバシー保護アプリケーションに対して無効となるほど低い場合、このアプローチの安全性は非常に明確です: ただECDSA検証を同じ時間を必要とするEVMコードの実行に置き換えるだけです。

しかし、時間の経過とともに、これらの限界を緩和する必要があります。なぜなら、プライバシー保護アプリケーションが中継なしで機能することを許可することや、量子耐性が非常に重要だからです。そのためには、検証ステップが極めて簡素である必要がないという条件のもとで、サービス拒否###DoS(のリスクをより柔軟に解決する方法を見つける必要があります。

主要なトレードオフは「少数の人を満足させるための迅速な書き込み」と「より理想的な解決策を得るために長く待つ」間にあるようです。理想的な方法は、何らかのハイブリッドアプローチかもしれません。ハイブリッドアプローチの一つは、いくつかのユースケースをより早く書き込み、他のユースケースを探求するためにより多くの時間を残すことです。もう一つの方法は、L2上にまずより野心的なアカウント抽象バージョンを展開することです。しかし、これが直面する課題は、L2チームが提案の採用に対して十分な自信を持つ必要があり、実施を進める意欲が必要だということです。特に、L1および/または将来の他のL2が互換性のあるソリューションを採用できることを確実にする必要があります。

! [イーサリアムの可能な未来についてのヴィタリック(6):散財])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(

私たちが明確に考慮する必要があるもう一つのアプリケーションは、鍵ストレージアカウントです。これらのアカウントはL1または専用L2上でアカウント関連の状態を保存しますが、L1および任意の互換性のあるL2で使用することができます。これを効果的に行うには、L2がL1SLOADやREMOTESTATICCALLのようなオペコードをサポートする必要があるかもしれませんが、これにはL2上のアカウント抽象実装がこれらの操作をサポートする必要もあります。

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

包含リストにはアカウント抽象トランザクションをサポートする必要があります。実際には、包含リストの要求は非中央集権メモリプールの要求と非常に似ていますが、包含リストの方が柔軟性がやや高いです。さらに、アカウント抽象の実装は、できるだけL1とL2の間で調整を実現するべきです。将来的に、ほとんどのユーザーがキー保管Rollupを使用することを期待する場合、アカウント抽象の設計は