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

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

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

ブーム:重要な目標

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

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

EVMの改善

何を解決したのですか?

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

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

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

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

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

ブーム: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つのキーを使用し、高価値の操作には別のキー(または一組のキー)を使用します。

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

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

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

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

この作業は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ガスの固定コストがあり、さらに各ユーザー操作には数千ガスが追加されます。
2. イーサリアム属性の必要性を確認する: 含まれるリストが作成された含む保証はアカウント抽象ユーザーに移転する必要があります。

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

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

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

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

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

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

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

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

しかし、時間が経つにつれて、私たちはこれらの限界を緩和する必要があります。なぜなら、プライバシー保護アプリが中なしで許可されるからです。