イーサリアムプロトコルの未来の可能な発展方向：繁栄篇

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

繁栄:主要な目標

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

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の組み合わせにより、これら2つのパフォーマンス指向の拡張が自然なペアとなります。

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

現在の研究リンク

• 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でガスを支払うことができるようになります。

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

アカウントの抽象化の核心はシンプルです: スマートコントラクトが取引を開始できるようにすること、ただし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): あるアカウントが別のアカウントの手数料を支払う機能を許可するもので、これは検証段階で送信者のアカウント自体のみがアクセスできるというルールに違反します。そのため、支払い代理メカニズムの安全性を確保するために特別な処理が導入されました。
• アグリゲーター(Aggregators): BLSアグリゲーションやSNARKベースのアグリゲーションなど、署名アグリゲーション機能をサポートしています。これは、ロールアップ上で最高のデータ効率を実現するために必要です。

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

現在の研究リンク

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

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

現在、主に解決する必要があるのは、アカウントの抽象化をプロトコルに完全に導入する方法です。最近人気のある書き込みプロトコルアカウント抽象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を使用することを期待する場合、アカウント抽象の設計はこれを基にすべきです。

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

EIP-1559 の改良点

それはどのような問題を解決しましたか?

EIP-1559は2021年にイーサリアムでアクティブになり、平均ブロック包含時間を大幅に改善しました。

しかし、現在のEIP-1559の実施は複数の点で完璧ではありません：

1. 公式には若干の欠陥があります: それは50%のブロックを目標としているのではなく、約50-53%の満ブロックを対象としており、これは分散(と関連しています。これは数学者が言う「算術-幾何平均不等式」と関係があります。