# イーサリアムプロトコルの可能な未来(六):繁栄いくつかの事物は単一のカテゴリーに分類するのが難しいですが、イーサリアムプロトコルの設計において、多くの「詳細」がイーサリアムの成功にとって非常に重要です。実際、約半分の内容は異なるタイプのEVM改善に関するもので、残りはさまざまなニッチなテーマで構成されており、これが「繁栄」の意味です。! [イーサリアムの可能な未来についてのヴィタリック(6):散財](https://img-cdn.gateio.im/social/moments-c0ed34ee4adbb5c0bb752dcd01c1f7a7)## 繁栄:主要な目標* 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の組み合わせは、これらのパフォーマンス指向の拡張を自然なペアにします。! [イーサリアムの可能な未来についてのヴィタリック(6):散財](https://img-cdn.gateio.im/social/moments-e607936b4195e92945aa6ebd5f969276)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は次のハードフォークに組み込む予定です。最後の瞬間にそれを削除する可能性は常にありますが、以前のハードフォークでは機能が一時的に削除されたことがありましたが、そうすることは大きな課題に直面します。EOFを削除することは、将来のEVMに対するアップグレードがEOFなしで行われる必要があることを意味しますが、可能ではあるものの、より困難になる可能性があります。EVMの主なトレードオフはL1の複雑性とインフラストラクチャの複雑性であり、EOFはEVM実装に追加する必要がある大量のコードです。静的コードチェックも比較的複雑です。しかし、対価として、高級言語を簡素化し、EVM実装を簡素化し、その他の利点を得ることができます。言うまでもなく、イーサリアムL1の継続的な改善のロードマップは、EOFの上に構築されるべきです。必要な重要な作業は、EVM-MAXに似た機能をSIMDと共に実現し、さまざまな暗号操作のガス消費をベンチマークすることです。#### ルートマップの他の部分とどのようにインタラクトしますか?L1 はその EVM を調整して L2 もより簡単に対応できるようにします。もし両者が同期調整を行わなければ、互換性のない状態を引き起こし、不利益をもたらす可能性があります。さらに、EVM-MAX と SIMD は多くの証明システムのガスコストを削減できるため、L2 をより効率的にします。また、同じタスクを実行できる EVM コードでより多くのプレコンパイルを置き換えることが容易になり、効率に大きく影響を与えない可能性があります。### アカウント抽象#### 何の問題を解決しましたか?現在、取引は一つの方法でのみ検証されます: ECDSA署名。最初は、アカウントの抽象化はこれを超えることを目的としており、アカウントの検証ロジックを任意のEVMコードにすることを可能にします。これにより、一連のアプリケーションが有効になります:* 耐量子暗号への切り替え* 旧鍵のローテーション(は推奨されるセキュリティプラクティスと広く見なされています)* マルチシグウォレットとソーシャルリカバリウォレット* 低価値の操作には1つのキーを使用し、高価値の操作には別のキー(または一組のキー)を使用します。中継なしでプライバシープロトコルが機能することを許可し、その複雑さを大幅に低下させ、重要な中央依存点を排除する。2015年にアカウントの抽象化が提唱されて以来、その目標は多くの「便利な目的」を含むように拡大されました。たとえば、ETHを持っていないがいくつかのERC20を持っているアカウントがERC20でガスを支払うことができるようになります。MPC(マルチパーティ計算)は、鍵を複数の部分に分割し、複数のデバイスに保存するために使用される、40年の歴史を持つ技術です。暗号技術を利用して署名を生成し、これらの鍵部分を直接組み合わせることなく行います。EIP-7702は次のハードフォークで導入される予定の提案であり、EIP-7702はすべてのユーザー(、特にEOAユーザー)に利益をもたらすためのアカウント抽象化の利便性を提供することに対する認識の高まりの結果です。これは短期的にすべてのユーザーの体験を改善し、2つのエコシステムに分裂するのを避けることを目的としています。この作業はEIP-3074から始まり、最終的にEIP-7702が形成されました。EIP-7702はアカウント抽象の「便利な機能」をすべてのユーザーに提供します。これには、今日のEOA(、すなわちECDSA署名によって制御されるアカウント)が含まれます。! [イーサリアムの可能な未来についてのヴィタリック(6):散財](https://img-cdn.gateio.im/social/moments-8930b556d169a2bc7168ddc2e611d3df)グラフからわかるように、いくつかの課題(、特に「便利性」課題)は、マルチパーティ計算やEIP-7702のような漸進的技術によって解決できるが、最初にアカウント抽象化提案が提唱された主要なセキュリティ目標は、元の問題を遡って解決することによってのみ達成できる: スマートコントラクトコードが取引の検証を制御できるようにすること。これまで実現されていない理由は、安全に実装することであり、これは課題である。#### それは何ですか、どのように機能しますか？アカウント抽象の核心はシンプルです: スマートコントラクトが取引を開始できるようにすることで、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): 1つのアカウントが別のアカウントの費用を支払うことを許可する機能であり、これは検証段階で送信者のアカウント自体のみへのアクセスを許可するというルールに違反します。したがって、支払い代理メカニズムの安全性を確保するために特別な処理が導入されました。* アグリゲーター(Aggregators): BLSアグリゲーションやSNARKベースのアグリゲーションなど、署名アグリゲーション機能をサポートしています。これは、Rollup上で最高のデータ効率を実現するために必要です。#### 残りの作業と考慮すべきこと現在、主に解決すべきことは、どのようにアカウントの抽象を完全にプロトコルに導入するかです。最近人気のある書き込みプロトコルアカウント抽象 EIP は EIP-7701 であり、この提案は EOF の上にアカウントの抽象を実現します。アカウントは、検証用の独自のコード部分を持つことができ、そのアカウントがそのコード部分を設定している場合、そのコードはそのアカウントからの取引の検証ステップで実行されます。この方法の魅力は、ローカルアカウントの抽象化に関する二つの同等な視点を明確に示している点です。1. EIP-4337 をプロトコルの一部として扱う2. 新しいEOAタイプで、署名アルゴリズムはEVMコードの実行です。もし私たちが検証期間中の実行可能コードの複雑さに厳しい境界を設定し始めるなら——外部状態へのアクセスを許可せず、初期に設定されたガス制限が量子耐性やプライバシー保護アプリケーションには無効なほど低い場合——この方法の安全性は非常に明確です: ただ ECDSA 検証を類似の時間が必要な EVM コード実行に置き換えるだけです。しかし、時間の経過とともに、プライバシー保護アプリケーションをリレーなしで機能させることや量子耐性を許可することが非常に重要であるため、これらの限界を緩和する必要があります。そのためには、検証ステップが極めて簡素である必要がない方法で、サービス拒否(DoS)のリスクをより柔軟に解決する必要があります。ホスト
イーサリアムプロトコルの未来展望：EVMアップグレードとアカウントの抽象化のキーライン
イーサリアムプロトコルの可能な未来(六):繁栄
いくつかの事物は単一のカテゴリーに分類するのが難しいですが、イーサリアムプロトコルの設計において、多くの「詳細」がイーサリアムの成功にとって非常に重要です。実際、約半分の内容は異なるタイプのEVM改善に関するもので、残りはさまざまなニッチなテーマで構成されており、これが「繁栄」の意味です。
! イーサリアムの可能な未来についてのヴィタリック(6):散財
繁栄:主要な目標
EVMの改善
どのような問題を解決しましたか?
現在のEVMは静的解析が難しく、効率的な実装を作成したり、正式にコードを検証したり、さらなる拡張を行ったりすることが困難です。また、EVMの効率は低く、事前コンパイルによる明示的なサポートがない限り、多くの高度な暗号技術の形式を実現することが難しいです。
それは何ですか、どのように機能しますか？
現在のEVM改善ロードマップの第一歩はEVMオブジェクトフォーマット(EOF)であり、次のハードフォークでの導入が計画されています。EOFは一連のEIPであり、新しい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の組み合わせは、これらのパフォーマンス指向の拡張を自然なペアにします。
! イーサリアムの可能な未来についてのヴィタリック(6):散財
EIP の組み合わせの大まかな設計は EIP-6690 を出発点とし、その後:
range(count)のiの場合: mem[z_start + z_skip * カウント] = op( mem[x_start + x_skip * カウント], mem[y_start + y_skip * カウント] )
実際の実装では、これは並行して処理されます。
残りの作業とトレードオフ
現在、EOFは次のハードフォークに組み込む予定です。最後の瞬間にそれを削除する可能性は常にありますが、以前のハードフォークでは機能が一時的に削除されたことがありましたが、そうすることは大きな課題に直面します。EOFを削除することは、将来のEVMに対するアップグレードがEOFなしで行われる必要があることを意味しますが、可能ではあるものの、より困難になる可能性があります。
EVMの主なトレードオフはL1の複雑性とインフラストラクチャの複雑性であり、EOFはEVM実装に追加する必要がある大量のコードです。静的コードチェックも比較的複雑です。しかし、対価として、高級言語を簡素化し、EVM実装を簡素化し、その他の利点を得ることができます。言うまでもなく、イーサリアムL1の継続的な改善のロードマップは、EOFの上に構築されるべきです。
必要な重要な作業は、EVM-MAXに似た機能をSIMDと共に実現し、さまざまな暗号操作のガス消費をベンチマークすることです。
ルートマップの他の部分とどのようにインタラクトしますか?
L1 はその EVM を調整して L2 もより簡単に対応できるようにします。もし両者が同期調整を行わなければ、互換性のない状態を引き起こし、不利益をもたらす可能性があります。さらに、EVM-MAX と SIMD は多くの証明システムのガスコストを削減できるため、L2 をより効率的にします。また、同じタスクを実行できる EVM コードでより多くのプレコンパイルを置き換えることが容易になり、効率に大きく影響を与えない可能性があります。
アカウント抽象
何の問題を解決しましたか?
現在、取引は一つの方法でのみ検証されます: ECDSA署名。最初は、アカウントの抽象化はこれを超えることを目的としており、アカウントの検証ロジックを任意のEVMコードにすることを可能にします。これにより、一連のアプリケーションが有効になります:
中継なしでプライバシープロトコルが機能することを許可し、その複雑さを大幅に低下させ、重要な中央依存点を排除する。
2015年にアカウントの抽象化が提唱されて以来、その目標は多くの「便利な目的」を含むように拡大されました。たとえば、ETHを持っていないがいくつかのERC20を持っているアカウントがERC20でガスを支払うことができるようになります。
MPC(マルチパーティ計算)は、鍵を複数の部分に分割し、複数のデバイスに保存するために使用される、40年の歴史を持つ技術です。暗号技術を利用して署名を生成し、これらの鍵部分を直接組み合わせることなく行います。
EIP-7702は次のハードフォークで導入される予定の提案であり、EIP-7702はすべてのユーザー(、特にEOAユーザー)に利益をもたらすためのアカウント抽象化の利便性を提供することに対する認識の高まりの結果です。これは短期的にすべてのユーザーの体験を改善し、2つのエコシステムに分裂するのを避けることを目的としています。
この作業はEIP-3074から始まり、最終的にEIP-7702が形成されました。EIP-7702はアカウント抽象の「便利な機能」をすべてのユーザーに提供します。これには、今日のEOA(、すなわちECDSA署名によって制御されるアカウント)が含まれます。
! イーサリアムの可能な未来についてのヴィタリック(6):散財
グラフからわかるように、いくつかの課題(、特に「便利性」課題)は、マルチパーティ計算やEIP-7702のような漸進的技術によって解決できるが、最初にアカウント抽象化提案が提唱された主要なセキュリティ目標は、元の問題を遡って解決することによってのみ達成できる: スマートコントラクトコードが取引の検証を制御できるようにすること。これまで実現されていない理由は、安全に実装することであり、これは課題である。
それは何ですか、どのように機能しますか？
アカウント抽象の核心はシンプルです: スマートコントラクトが取引を開始できるようにすることで、EOAだけではありません。この全体の複雑さは、非中央集権ネットワークの維持に優しい方法でこれを実現し、サービス拒否攻撃を防ぐことから来ています。
一般的な主要な課題は、複数の障害の問題です。
もし 1000 のアカウントの検証関数がある単一の値 S に依存しており、現在の値 S がメモリプール内の取引をすべて有効にしている場合、単一の取引が S の値を反転させると、メモリプール内の他のすべての取引が無効になる可能性があります。これにより、攻撃者は非常に低コストでメモリプールにゴミ取引を送信し、ネットワークノードのリソースを塞ぐことができるのです。
多年の努力を経て、機能を拡張しながらサービス拒否(DoS)リスクを制限することを目指し、最終的に「理想的なアカウント抽象」を実現するためのソリューション、ERC-4337が得られました。
ERC-4337の動作原理は、ユーザー操作の処理を検証と実行の2つの段階に分けることです。すべての検証は最初に処理され、すべての実行はその後に処理されます。メモリプール内では、ユーザー操作の検証段階が自身のアカウントのみに関与し、環境変数を読み取らない場合にのみ受け入れられます。これにより、多重失効攻撃を防ぐことができます。さらに、検証ステップに対しても厳格なガス制限が強制的に適用されます。
ERC-4337は、追加のプロトコル標準(ERC)として設計されました。当時、イーサリアムのクライアント開発者は(Merge)に焦点を当てており、他の機能に対処するための追加のリソースを持っていませんでした。これが、ERC-4337が通常の取引ではなく、ユーザー操作と呼ばれるオブジェクトを使用している理由です。しかし最近、私たちはそのうちの少なくとも一部をプロトコルに書き込む必要があることに気付きました。
二つの重要な理由は以下の通りです:
さらに、ERC-4337は2つの機能を拡張しました:
残りの作業と考慮すべきこと
現在、主に解決すべきことは、どのようにアカウントの抽象を完全にプロトコルに導入するかです。最近人気のある書き込みプロトコルアカウント抽象 EIP は EIP-7701 であり、この提案は EOF の上にアカウントの抽象を実現します。アカウントは、検証用の独自のコード部分を持つことができ、そのアカウントがそのコード部分を設定している場合、そのコードはそのアカウントからの取引の検証ステップで実行されます。
この方法の魅力は、ローカルアカウントの抽象化に関する二つの同等な視点を明確に示している点です。
もし私たちが検証期間中の実行可能コードの複雑さに厳しい境界を設定し始めるなら——外部状態へのアクセスを許可せず、初期に設定されたガス制限が量子耐性やプライバシー保護アプリケーションには無効なほど低い場合——この方法の安全性は非常に明確です: ただ ECDSA 検証を類似の時間が必要な EVM コード実行に置き換えるだけです。
しかし、時間の経過とともに、プライバシー保護アプリケーションをリレーなしで機能させることや量子耐性を許可することが非常に重要であるため、これらの限界を緩和する必要があります。そのためには、検証ステップが極めて簡素である必要がない方法で、サービス拒否(DoS)のリスクをより柔軟に解決する必要があります。
ホスト