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

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

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

繁栄:主要な目標

• EVMを高性能で安定した"最終状態"にする
• アカウントの抽象化をプロトコルに導入し、すべてのユーザーがより安全で便利なアカウントを楽しめるようにします。
• 取引コストの経済性を最適化し、拡張性を高めながらリスクを低減する
• 先進的な暗号学を探求し、イーサリアムを長期的に大幅に改善する

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

EVMの改善

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

現在のEVMは静的分析が難しく、効率的な実装の作成、形式的なコードの検証、さらなる拡張を行うことが困難です。さらに、EVMの効率は低く、多くの形式の高度な暗号学を実現することは難しいですが、事前コンパイルによる明示的なサポートがなければなりません。

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

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

• コード(は実行可能ですが、EVMから)を読み取ることはできません。また、データ(は読み取ることができますが、実行することはできません)の間の分離
• 動的ジャンプは禁止されており、静的ジャンプのみが許可されています
• 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の組み合わせは、これら二つの性能指向の拡張を自然なペアにします。

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は次のハードフォークに組み込まれる予定です。最終的に最後の瞬間にそれを削除する可能性は常にあります - 過去のハードフォークでは機能が一時的に削除されたことがありましたが、そうすることは大きな挑戦に直面します。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つのキーを使用し、もう1つのキー(またはキーのセット)を使用して高価値の操作を行います。

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

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

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

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

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

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

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

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

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

典型的な重要な課題は、マルチフェイル問題です:

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

多年の努力を経て、機能を拡張しながらサービス拒否(DoS)のリスクを制限することを目的とした結果、"理想的なアカウント抽象"を実現するためのソリューションが得られました: ERC-4337。

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

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

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

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

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

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

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

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

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

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

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

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

しかし、時間が経つにつれて、これらの限界を緩和する必要があります。なぜなら、リレーなしでプライバシー保護アプリケーションが機能することや、量子耐性が非常に重要だからです。そのためには、サービス拒否(DoS)の問題をより柔軟に解決する必要があります。