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