イーサリアムの繁栄する未来：EVMの改善、アカウントの抽象化とプロトコルのアップグレード

2025-07-21 05:05:29

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

執筆：ヴィタリック・ブテリン

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

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

繁栄:主要な目標

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

EVMの改善

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

現在のEVMは静的解析が困難であり、高効率な実装、正式な検証コードの作成、およびさらなる拡張を行うことが難しくなっています。さらに、EVMの効率が低く、多くの形式の高度な暗号学を実現することが困難であり、明示的なサポートがない限り、プリコンパイルを通じてのみ可能です。

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

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

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

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

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 アップグレードも実現可能ですが、これまでのところ注目度は低いです。

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

現在の研究リンク

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

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

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

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

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

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

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