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

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

繁栄:主要な目標

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

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

EVMの改善

どのような問題を解決しましたか？

現在のEVMは静的分析が難しく、効率的な実装の作成、コードの正式な検証、さらなる拡張が困難になっています。さらに、EVMの効率は低く、多くの形式の高度な暗号学を実現することが難しいため、前もってコンパイルされた明示的なサポートを通じてのみ可能です。

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

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

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

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

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

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

最近のアイデアの一つは、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の: ※EVM-MAX:
• SIMD:

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

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

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

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

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

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

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

現在の研究リンク

• アカウントアブストラクションの歴史についての講演:
• ERC-4337:
• EIP-7702:
• BLSWalletコード(、次の)集約関数を使用します。
• EIP-7562(によるプロトコルのアカウントアブストラクション):
• EIP-7701(基于EOFの書き込みプロトコルアカウント抽象):

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

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

この方法