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

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

繁栄:主要な目標

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

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

EVM の改善

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

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

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

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

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

EOFコードの構造は、コードセクション、データセクション、および型情報セクションを含みます。

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

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

新しいアイデアの一つは、EVM-MAXを単一命令多データ(SIMD)機能と組み合わせることです。SIMDは、ハッシュ関数、32ビットSTARKs、格ベースの暗号など、さまざまな形式の暗号学を加速するために使用できます。EVM-MAXとSIMDの組み合わせは、これら二つのパフォーマンス指向の拡張が自然にペアになることを意味します。

現在の研究リンク

• 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):散財

アカウントアブストラクション

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

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

• 耐量子暗号への切り替え
• 古いキー(をローテーションすることは、推奨される安全な実践であると広く見なされています)
• マルチシグウォレットとソーシャルリカバリウォレット
• 低価値の操作には1つの鍵を使用し、高価値の操作には別の鍵(または一組の鍵)を使用します。

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

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

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

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

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

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

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

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

! イーサリアムの可能な未来についてのヴィタリック(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%の満ブロックを対象としており、これは分散(に依存します。これは数学者が呼ぶ「算術・幾何平均不等式」に関連しています)。
2. 極端な状況下での調整が不十分である。

後にblobsに使用される公式(EIP-4844)は、最初の問題を解決するために特別に設計されており、全体的にもより簡潔です。しかし、EIP-1559自体およびEIP-4844は第二の問題を解決しようとはしていません。したがって、現状は二つの異なるメカニズムに関わる混乱した中間状態であり、時間が経つにつれて両者とも改善が必要だという見方があります。

さらに、EIP-1559とは無関係なイーサリアムのリソース価格設定の弱点がいくつかありますが、EIP-1559の調整によって解決できます。その主要な問題の一つは、平均的な状況と最悪の状況の違いです: イーサリアムのリソース価格は、最悪の状況、つまり1つのブロックの全ガス消費が1つのリソースを占有することに対処できるように設定されなければなりませんが、実際の平均的な使用はこれよりもはるかに低いため、非効率が生じます。

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

多次元Gasとは何ですか、それはどのように機能しますか？

これらの非効率的な問題を解決するためのソリューションは、多次元ガスです：異なるリソースに異なる価格と制限を設定します。この概念は技術的にEIP-1559とは独立していますが、EIP-1