# イーサリアムプロトコルの可能な未来(六):繁栄イーサリアムのプロトコル設計には、イーサリアムの成功に非常に重要な多くの「詳細」があります。実際、約半分の内容は異なるタイプのEVMの改善に関するもので、残りはさまざまなニッチなテーマで構成されており、これが「繁荮」の意味です。## 繁栄:主要な目標* EVM を高性能で安定した"最終状態"にする* アカウントの抽象化をプロトコルに導入し、すべてのユーザーがより安全で便利なアカウントを享受できるようにします。* 取引コストの経済性を最適化し、スケーラビリティを向上させると同時にリスクを低減する* 先進的な暗号学を探求し、イーサリアムが長期的に大幅に改善されることを可能にする### EVMの改善#### 何の問題を解決しましたか？現在のEVMは静的分析が難しく、高効率の実装や形式的検証コードの作成、さらなる拡張が困難になっています。また、EVMの効率は低く、多くの形式の高度な暗号学を実現するのは難しく、明示的なサポートを通じてのみプリコンパイルを通じて可能です。#### それは何ですか、どのように機能しますか？現在のEVM改善ロードマップの第一歩はEVMオブジェクトフォーマット(EOF)であり、次のハードフォークで組み込まれる予定です。EOFは一連のEIPで、新しいEVMコードバージョンを指定しており、多くの独特な特徴を持っています。最も顕著な点は:* コード(は実行可能ですが、EVMから)とデータ(の間の分離を読み取ることはできませんが、)は読み取ることができますが、実行することはできません。* ダイナミックジャンプを禁止し、静的ジャンプのみを許可する* EVM コードは燃料に関連する情報を観察できなくなります* 明示的なサブ例程メカニズムが追加されました旧式コントラクトは引き続き存在し、作成可能ですが、最終的には旧式コントラクト(が段階的に廃止される可能性があり、さらにはEOFコード)に強制的に変換される可能性があります。新式コントラクトはEOFによる効率向上の恩恵を受けるでしょう。まずはサブルーチン機能によってわずかに縮小されたバイトコード、次にEOF特有の新機能やガスコストの削減が期待されます。EOFを導入した後、さらなるアップグレードがより容易になり、現在最も発展しているのはEVMモジュールの算術拡張(EVM-MAX)です。EVM-MAXは、モジュロ演算に特化した一連の新しい命令を作成し、それを他のオペコードからアクセスできない新しいメモリ空間に配置しました。これにより、モンゴメリ乗算などの最適化の使用が可能になります。新しいアイデアの一つは、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のアップグレードも実現可能ですが、これまでのところ注目度は低いです。! [イーサリアムの可能な未来についてのヴィタリック(6):散財](https://img-cdn.gateio.im/social/moments-c0ed34ee4adbb5c0bb752dcd01c1f7a7)#### 残りの作業とトレードオフ現在、EOFは次のハードフォークに組み込まれる予定です。最後の瞬間にそれを削除することは常に可能ですが、以前のハードフォークでは機能が一時的に削除されたことがありましたが、そうすることは大きな課題に直面します。EOFを削除することは、将来のEVMに対するアップグレードがEOFなしで行われる必要があることを意味しますが、可能ではありますが、より困難になるかもしれません。EVMの主要なトレードオフは、L1の複雑さとインフラの複雑さにあります。EOFはEVM実装に追加する必要がある大量のコードであり、静的コードチェックも比較的複雑です。しかし、その代わりに、高級言語を簡素化し、EVM実装を簡素化し、その他の利点を得ることができます。イーサリアム L1の継続的な改善のロードマップは、EOFの上に構築されるべきだと言えます。必要な重要な作業は、EVM-MAXのような機能をSIMDに実装し、さまざまな暗号操作のガス消費をベンチマークすることです。#### ルートマップの他の部分とどのように相互作用しますか?L1 はその EVM を調整し、L2 もより容易に対応する調整を行えるようにします。もし二者が同期して調整しない場合、互換性の問題を引き起こし、不利な影響をもたらす可能性があります。さらに、EVM-MAX と SIMD は多くの証明システムのガスコストを削減できるため、L2 をより効率的にします。また、同じタスクを実行できる EVM コードでより多くのプリコンパイルを置き換えることが容易になり、効率に大きな影響を与えることはないでしょう。! [イーサリアムの可能な未来についてのヴィタリック(6):散財](https://img-cdn.gateio.im/social/moments-e607936b4195e92945aa6ebd5f969276)### アカウント抽象#### 何の問題を解決しましたか？現在、取引は一つの方法でのみ検証できます: 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 gas の固定コストがあり、さらに各ユーザー操作に数千 gas の追加コストがかかります。2. イーサリアム属性の必要性を確認する: リストに含まれる保証を含む、アカウント抽象ユーザーに移転する必要があります。さらに、ERC-4337は2つの機能を拡張しました:* 支払い代理(Paymasters): あるアカウントが別のアカウントの費用を支払う機能を許可するもので、これは検証段階で送信者アカウント自体のみがアクセスできるというルールに違反します。そのため、支払い代理メカニズムの安全性を確保するために特別な処理が導入されています。* アグリゲーター(Aggregators): BLS アグリゲーションや SNARK ベースのアグリゲーションなど、署名アグリゲーション機能をサポートしています。これは、ロールアップ上で最高のデータ効率を実現するために必要です。! [イーサリアムの可能な未来についてのヴィタリック(6):散財](https://img-cdn.gateio.im/social/moments-8930b556d169a2bc7168ddc2e611d3df)#### 残りの作業とバランス現在主に解決すべきは、アカウントの抽象化をプロトコルに完全に導入する方法です。最近人気のあるアカウント抽象化のプロトコルの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 上のアカウント抽象化実装がこれらの操作をサポートする必要もあります。#### それはロードマップの他の部分とどのように相互作用しますか?包含リストはアカウント抽象トランザクションをサポートする必要があり、実際には、包含リストのニーズは分散型メモリプールのニーズと非常に似ているが、それにもかかわらず
イーサリアムプロトコルのアップグレードロードマップ：EVMの改善、アカウントの抽象化と1559の最適化
イーサリアムプロトコルの可能な未来(六):繁栄
イーサリアムのプロトコル設計には、イーサリアムの成功に非常に重要な多くの「詳細」があります。実際、約半分の内容は異なるタイプのEVMの改善に関するもので、残りはさまざまなニッチなテーマで構成されており、これが「繁荮」の意味です。
繁栄:主要な目標
EVMの改善
何の問題を解決しましたか？
現在のEVMは静的分析が難しく、高効率の実装や形式的検証コードの作成、さらなる拡張が困難になっています。また、EVMの効率は低く、多くの形式の高度な暗号学を実現するのは難しく、明示的なサポートを通じてのみプリコンパイルを通じて可能です。
それは何ですか、どのように機能しますか？
現在のEVM改善ロードマップの第一歩はEVMオブジェクトフォーマット(EOF)であり、次のハードフォークで組み込まれる予定です。EOFは一連のEIPで、新しいEVMコードバージョンを指定しており、多くの独特な特徴を持っています。最も顕著な点は:
旧式コントラクトは引き続き存在し、作成可能ですが、最終的には旧式コントラクト(が段階的に廃止される可能性があり、さらにはEOFコード)に強制的に変換される可能性があります。新式コントラクトはEOFによる効率向上の恩恵を受けるでしょう。まずはサブルーチン機能によってわずかに縮小されたバイトコード、次にEOF特有の新機能やガスコストの削減が期待されます。
EOFを導入した後、さらなるアップグレードがより容易になり、現在最も発展しているのはEVMモジュールの算術拡張(EVM-MAX)です。EVM-MAXは、モジュロ演算に特化した一連の新しい命令を作成し、それを他のオペコードからアクセスできない新しいメモリ空間に配置しました。これにより、モンゴメリ乗算などの最適化の使用が可能になります。
新しいアイデアの一つは、EVM-MAXを単一命令複数データ(SIMD)機能と組み合わせることです。SIMDはイーサリアムの理念として長い間存在しており、最初にGreg ColvinのEIP-616によって提案されました。SIMDは、ハッシュ関数、32ビットSTARKs、格ベースの暗号など、さまざまな形式の暗号を加速するために使用できます。EVM-MAXとSIMDの組み合わせにより、これら2つの性能指向の拡張は自然なペアリングとなります。
EIP の組み合わせの大まかな設計は EIP-6690 を出発点とし、その後:
range(count)のiの場合: mem[z_start + z_skip * カウント] = op( mem[x_start + x_skip * カウント], mem[y_start + y_skip * カウント] )
実際の実装では、これが並行して処理されます。
! イーサリアムの可能な未来についてのヴィタリック(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コードであることを可能にします。これにより、一連のアプリケーションが有効になります:
中継なしでプライバシープロトコルが機能することを許可し、その複雑性を大幅に削減し、重要な中央依存点を排除します。
2015年にアカウント抽象が提案されて以来、その目標は「便利な目的」を多く含むものに拡大されました。例えば、ETHを持っていないがいくつかのERC20を持っているアカウントがERC20を使ってガスを支払うことができるようになります。
それは何ですか、どのように機能しますか？
アカウント抽象の核心はシンプルです: スマートコントラクトがトランザクションを開始できるようにすること、ただしEOAだけではありません。この全体の複雑さは、非中央集権ネットワークを維持するのに優しい方法でこれを実現し、サービス拒否攻撃から防ぐことから来ています。
典型的な重要な課題は、複数の障害の問題です:
もし1000のアカウントの検証関数が特定の単一の値Sに依存していて、現在の値Sがメモリプール内の取引をすべて有効にしている場合、単一の取引がSの値を反転させることでメモリプール内の他のすべての取引が無効になる可能性があります。これにより、攻撃者は非常に低コストでメモリプールにゴミ取引を送信し、ネットワークノードのリソースを塞ぐことができるのです。
多年の努力を経て、機能を拡張しつつ拒否サービス(DoS)のリスクを制限することを目的とした結果、"理想的なアカウント抽象"を実現する解決策としてERC-4337が導き出されました。
ERC-4337の動作原理は、ユーザー操作の処理を検証と実行の2つの段階に分けることです。すべての検証は最初に処理され、すべての実行はその後に処理されます。メモリプール内では、ユーザー操作の検証段階が自身のアカウントのみに関与し、環境変数を読み取らない場合にのみ受け入れられます。これにより、多重失敗攻撃を防ぐことができます。さらに、検証ステップにも厳格なガス制限が強制的に実施されます。
ERC-4337は、追加のプロトコル標準(ERC)として設計されました。なぜなら、その当時、イーサリアムのクライアント開発者は(Merge)に集中しており、他の機能に対処するための追加のリソースがなかったからです。これが、ERC-4337が従来の取引ではなく、ユーザー操作と呼ばれるオブジェクトを使用している理由です。しかし最近、私たちはその中の少なくとも一部をプロトコルに書き込む必要があることに気付きました。
二つの重要な理由は次の通りです:
さらに、ERC-4337は2つの機能を拡張しました:
! イーサリアムの可能な未来についてのヴィタリック(6):散財
残りの作業とバランス
現在主に解決すべきは、アカウントの抽象化をプロトコルに完全に導入する方法です。最近人気のあるアカウント抽象化のプロトコルのEIPはEIP-7701であり、この提案はEOFの上にアカウント抽象化を実現します。アカウントは検証のための単独のコード部分を持つことができ、アカウントがそのコード部分を設定した場合、そのコードはそのアカウントからの取引の検証ステップで実行されます。
この方法の魅力は、ローカルアカウントの抽象化の2つの同等の視点を明確に示していることです:
検証期間中の実行可能なコードの複雑性に厳格な限界を設定し、外部状態へのアクセスを許可せず、初期設定のガス制限も量子耐性やプライバシー保護アプリケーションには無効なほど低い場合、このアプローチの安全性は非常に明確になります：単にECDSA検証を、同様の時間を必要とするEVMコードの実行に置き換えるだけです。
しかし、時間が経つにつれて、これらの制限を緩める必要があります。なぜなら、プライバシー保護アプリケーションが中継なしで機能することを許可し、量子耐性が非常に重要だからです。そのためには、サービス拒否(DoS)のリスクに柔軟に対処する方法を見つける必要があり、検証ステップが極端に簡素であることを要求しないようにする必要があります。
主なトレードオフは「少数の人を満足させるための迅速な実装」と「より理想的な解決策を得るために長く待つこと」にあるようです。理想的なアプローチは、何らかのハイブリッド方式かもしれません。一つのハイブリッド方式は、いくつかのユースケースをより迅速に実装し、他のユースケースを探求するためにより多くの時間を割くことです。もう一つの方法は、まずL2上により野心的なアカウント抽象化バージョンを展開することです。しかし、この課題は、L2チームが提案の採用に対して自信を持たなければ、実施する意欲がないことです。特に、L1および/または他のL2が将来的に互換性のあるソリューションを採用できることを確認する必要があります。
我々が明確に考慮する必要があるもう一つのアプリケーションは、キー ストレージ アカウントです。これらのアカウントは L1 または専用 L2 にアカウント関連の状態を格納しますが、L1 および任意の互換性のある L2 で使用できます。これを効果的に行うには、L2 が L1SLOAD や REMOTESTATICCALL のようなオペコードをサポートする必要があるかもしれませんが、これは L2 上のアカウント抽象化実装がこれらの操作をサポートする必要もあります。
それはロードマップの他の部分とどのように相互作用しますか?
包含リストはアカウント抽象トランザクションをサポートする必要があり、実際には、包含リストのニーズは分散型メモリプールのニーズと非常に似ているが、それにもかかわらず