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

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

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

繁栄:主要な目標

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

EVMの改善

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

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

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

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

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

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

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

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

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

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は次のハードフォークに組み込まれる予定です。最後の瞬間に削除される可能性が常にありますが、以前のハードフォークでは機能が一時的に削除されたこともありましたが、そうすることは大きな挑戦に直面します。EOFを削除することは、将来のEVMに対するアップグレードがEOFなしで行われる必要があることを意味しますが、それは可能ですが、より困難になる可能性があります。

EVM の主なトレードオフは L1 の複雑さとインフラストラクチャの複雑さにあり、EOF は EVM 実装に追加する必要がある大量のコードであり、静的コードチェックも比較的複雑です。しかし、その代わりに、高級言語の簡素化、EVM 実装の簡素化、およびその他の利点を得ることができます。言い換えれば、イーサリアム L1 の継続的な改善のロードマップは EOF を考慮し、基にすべきだと言えます。

必要な作業の一つは、EVM-MAXに類似したSIMD機能を実現し、さまざまな暗号操作のガス消費をベンチマークすることです。

ルートマップの他の部分とどのように相互作用しますか?

L1はそのEVMを調整してL2がより簡単に対応する調整を行えるようにします。もし両者が同期調整を行わない場合、互換性が失われ、不利な影響をもたらす可能性があります。さらに、EVM-MAXとSIMDは多くの証明システムのガスコストを削減できるため、L2をより効率的にします。また、同じタスクを実行できるEVMコードでより多くのプリコンパイルを置き換えることが容易になり、効率に大きく影響することはないでしょう。

アカウント抽象

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

現在、取引は1つの方法でのみ検証できます: ECDSA署名。最初、アカウント抽象はこれを超えることを目的としており、アカウントの検証ロジックを任意のEVMコードにすることを可能にします。これにより、さまざまなアプリケーションが可能になります:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

この方法の魅力は、ローカルアカウントの抽象の二つの同等の視点を明確に示すことにあります。

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

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

しかし、時間が経つにつれて、プライバシー保護アプリが中継なしで機能することを許可することや、量子耐性が非常に重要であるため、これらの制限を緩和する必要があります。そのためには、検証ステップが極端に簡素でなければならないという要求をせずに、サービス拒否(DoS)リスクに柔軟に対処する方法を見つける必要があります。

主要のトレードオフは「少数の人を満足させるための迅速な書き込み」と「より長い時間待つ」ようです。