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

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

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

繁栄:主要な目標

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

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

EVM の改善

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

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

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

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

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

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

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

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

新しい考え方は、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の:
• EVM-MAX(エビーエムマックス):
• シムド:

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

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

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

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

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

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)として設計されました。なぜなら、その時点でイーサリアムのクライアント開発者は(Merge)に注力しており、他の機能に対処するための追加のエネルギーがなかったからです。これが、ERC-4337が従来の取引ではなく、ユーザー操作と呼ばれるオブジェクトを使用する理由です。しかし、最近ではその内容の少なくとも一部をプロトコルに書き込む必要があることを認識しました。

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

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

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

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

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

現在の研究リンク

• アカウント抽象の歴史に関する講演:
• ERC-4337:
• EIP-7702:
• BLSWalletコード(は、アグリゲーション機能)を使用します:
• EIP-7562(によるプロトコルのアカウント抽象):
• EIP-7701(に基づくEOFの書き込みプロトコルアカウント抽象):

残りの作業とバランス

現在主に解決すべきは、どのようにアカウント抽象をプロトコルに完全に導入するかです。最近注目を集めている書き込みプロトコルアカウント抽象EIPはEIP-7701であり、この提案はEOFの上にアカウント抽象を実装します。