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

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

繁栄:主要な目標

• 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の結合は、これら二つの性能指向の拡張が自然に組み合わさることを可能にする。

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

一つのEIPの大まかな設計はEIP-6690を出発点とし、その後:

• 任意の奇数または2の最大2768のべき乗をモジュラスとして許可(i)あるいは(ii)
• 各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コードでより多くのプレコンパイルを置き換えることが容易になり、効率に大幅な影響を与えない可能性があります。

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

アカウント抽象

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

包含リストはアカウント抽象取引をサポートする必要があり、実際には包含リストの要件と分散型メモリプールの要件は非常に似ていますが、包含リストの方が柔軟性がやや高いです。さらに、アカウント抽象の実装は、可能な限りL1とL2の間で調整を実現すべきです。将来的にほとんどのユーザーがキー保管Rollupを使用することを期待する場合、アカウント抽象の設計はこれを基にすべきです。

![ヴィタリックのイーサリアムの可能性について（