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

イーサリアムプロトコル設計中には多くの「細部」がその成功にとって重要です。実際、約半分の内容は異なるタイプの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乗算などの最適化の利用が可能になりました。

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

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

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コードでより多くのプリコンパイルを置き換えることが容易になり、効率に大きな影響を与えることはないかもしれません。

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

アカウント抽象

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

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

• 耐量子暗号への切り替え
• 古いキー(をローテーションすることは、推奨されるセキュリティプラクティスとして広く認識されています)
• マルチシグウォレットとソーシャルリカバリウォレット
• 低価値の操作には1つのキーを使用し、高価値の操作には別のキー(または一組のキー)を使用します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

二つの重要な理由は次のとおりです:

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

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

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

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

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

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

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

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

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

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