イーサリアムプロトコルの可能な未来（六）：繁栄

著者：ヴィタリック・ブテリン

いくつかの事物は単一のカテゴリーに分類するのが難しく、イーサリアムプロトコルの設計において、多くの「詳細」がイーサリアムの成功にとって非常に重要です。実際、内容の約半分は異なるタイプのEVMの改善に関するものであり、残りはさまざまなマイナーなテーマで構成されており、これが「繁栄」の意味です。

繁栄:主要な目標

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

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

EVMの改善

何の問題を解決しましたか？

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

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

現在のEVM改善ロードマップの第一歩はEVMオブジェクトフォーマット（EOF）であり、次のハードフォークで組み込まれる予定です。EOFは一連のEIPで、新しいEVMコードバージョンを指定しており、多くの独自の特徴があります。最も顕著なのは：

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

従来のコントラクトは引き続き存在し、作成可能ですが、最終的には従来のコントラクトが段階的に廃止される可能性があり（場合によっては強制的に EOF コードに変換されることもあります）。新しいコントラクトは、EOF による効率の向上から恩恵を受けます。最初はサブルーチン機能によってわずかに縮小されたバイトコード、次に EOF 特有の新機能やガスコストの削減です。

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

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

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

EIP の組み合わせの大まかな設計は EIP-6690 を出発点として、次に：

• (i) の任意の奇数または (ii) の最大2768の2の累乗を法として許可します
• 各 EVM-MAX オペコード（加算、減算、乗算）に対して、3 つの即値 x、y、z を使用するのではなく、7 つの即値：x_start、x_skip、y_start、y_skip、z_start、z_skip、count を使用するバージョンを追加します。Python コードにおいて、これらのオペコードの動作は以下のようになります：

range(count)のiの場合: mem[z_start + z_skip * カウント] = op( mem[x_start + x_skip * カウント], mem[y_start + y_skip * カウント] )

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

• XOR、AND、OR、NOT、および SHIFT（ループおよび非ループを含む）を追加する可能性があり、少なくとも 2 の累乗のモジュラスに対して行われます。同時に ISZERO（出力を EVM メインスタックにプッシュする）を追加します。これにより、楕円曲線暗号、低域暗号（Poseidon、Circle STARKs など）、従来のハッシュ関数（SHA256、KECCAK、BLAKE など）、格ベースの暗号を実現するのに十分な強力さを持つでしょう。他の EVM アップグレードも実現可能ですが、これまでのところ注目度は低いです。

現在の研究リンク

• EOFの: ※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でガスを支払うことができます。以下はこれらの目標の概要グラフです：

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

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つの段階に分けることです。すべての検証は最初に処理され、すべての実行はその後に処理されます。メモリプール内では、ユーザー操作の検証段階が自身のアカウントのみを含み、環境変数を読み取らない場合にのみ受け入れられます。これにより、多重失効攻撃を防ぐことができます。さらに、検証ステップにも厳格なガス制限が強制されます。

ERC-4337 は、当時イーサリアムのクライアント開発者がマージ（Merge）に集中しており、他の機能に対応するための追加のエネルギーを持っていなかったため、追加のプロトコル標準（ERC）として設計されました。これが、ERC-4337 が通常の取引ではなく、ユーザー操作と呼ばれるオブジェクトを使用している理由です。しかし最近、私たちはその一部をプロトコルに書き込む必要があることに気づきました。

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

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

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

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

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

現在の研究リンク

• アカウント抽象の歴史に関する講演：
• ERC-4337:
• EIP-7702:
• BLSWallet コード（アグリゲーション機能を使用）：
• EIP-7562（プロトコルのアカウント抽象）：
• EIP-7701（EOFに基づく書き込みプロトコルアカウント抽象）：