# イーサリアムプロトコルの可能な未来(六):繁栄イーサリアムプロトコル設計には、多くの「詳細」がその成功にとって重要です。実際、約半分の内容は異なるタイプのEVM改善に関するもので、残りの部分はさまざまなニッチなテーマで構成されており、これが「繁栄」の意味です。! [イーサリアムの可能な未来についてのヴィタリック(6):散財](https://img-cdn.gateio.im/social/moments-c0ed34ee4adbb5c0bb752dcd01c1f7a7)## 繁栄:主要な目標- EVMを高性能で安定した「最終状態」にする- アカウントの抽象化をプロトコルに導入し、すべてのユーザーがより安全で便利なアカウントを享受できるようにします。- 取引コストの経済性を最適化し、スケーラビリティを向上させると同時にリスクを低減する- 先進的な暗号学を探求し、イーサリアムを長期的に大幅に改善する! [イーサリアムの可能な未来についてのヴィタリック(6):散財](https://img-cdn.gateio.im/social/moments-e607936b4195e92945aa6ebd5f969276)### EVMの改善#### 何の問題を解決しましたか?現在のEVMは静的分析が難しく、高効率な実装、形式的なコード検証、さらなる拡張が困難になっています。また、EVMの効率が低く、明示的なサポートなしに多くの形式の高度な暗号学を実現することが難しいです。#### それは何ですか、どのように機能しますか?現在のEVM改善ロードマップの第一歩はEVMオブジェクトフォーマット(EOF)であり、次のハードフォークに組み込まれる予定です。EOFは一連のEIPであり、新しいEVMコードバージョンを指定し、多くの独特な特徴を持っています。最も顕著なのは:- コード(は実行可能ですが、EVMから)とデータ(の分離を読み取ることはできませんが、)の間で実行することはできません。- 動的ジャンプを禁止し、静的ジャンプのみを許可する- EVMコードは燃料に関連する情報をもはや観察できません- 新しい明示的サブ例程メカニズムを追加しました旧式合約は引き続き存在し、作成可能ですが、最終的には旧式合約(が段階的に廃止される可能性があり、場合によってはEOFコード)に強制的に変換されるかもしれません。新式合約はEOFによる効率の向上から利益を得ることになるでしょう。まずは、サブルーチン機能によってやや縮小されたバイトコード、次にEOF特有の新機能やガスコストの削減です。! [イーサリアムの可能な未来についてのヴィタリック(6):散財](https://img-cdn.gateio.im/social/moments-8930b556d169a2bc7168ddc2e611d3df)EOFを導入した後、さらなるアップグレードが容易になり、現在最も発展しているのはEVMモジュールの算術拡張(EVM-MAX)です。EVM-MAXは、剰余演算に特化した新しいオペレーションのセットを作成し、それを他のオペコードからアクセスできない新しいメモリ空間に配置しました。これにより、Montgomery乗算などの最適化の使用が可能になります。比較的新しいアイデアは、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アップグレードも実現可能ですが、これまでのところ注目度は低いです。#### 既存の研究リンク- 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):散財](https://img-cdn.gateio.im/social/moments-ec1638a809393a6ed42724fb08f534da)### アカウント抽象#### 何の問題を解決しましたか?現在、取引は一つの方法でのみ検証されます: ECDSA署名。最初は、アカウントの抽象化はこれを超えることを目的としており、アカウントの検証ロジックを任意のEVMコードにすることを許可します。これにより、一連のアプリケーションが可能になります:- 耐量子暗号への切り替え- 古いキー(をローテーションすることは、推奨されるセキュリティプラクティスであると広く考えられています)- マルチシグウォレットとソーシャルリカバリウォレット- 低価値の操作には1つのキーを使用し、高価値の操作には別のキー(または一組のキー)を使用します。リレーなしでプライバシープロトコルが機能することを許可し、複雑さを大幅に軽減するとともに、重要な中央依存ポイントを排除します。2015年にアカウント抽象が提案されて以来、その目標は大量の「便利目標」を含むように拡大されました。例えば、ETHを持っていないがいくつかのERC20を持っているアカウントがERC20でガスを支払うことができるようになります。MPC(マルチパーティ計算)は、鍵を複数の部分に分割し、複数のデバイスに保存するために使用される、40年の歴史を持つ技術です。暗号技術を利用して署名を生成することができ、これらの鍵の部分を直接組み合わせる必要はありません。EIP-7702は、次のハードフォークで導入される予定の提案です。EIP-7702は、すべてのユーザー(、特にEOAユーザー)に利益をもたらすアカウント抽象化の利便性を提供することへの認識の高まりの結果です。この提案は、短期的にすべてのユーザーの体験を改善し、2つのエコシステムに分裂するのを避けることを目的としています。この作業はEIP-3074から始まり、最終的にEIP-7702が形成されました。EIP-7702はアカウントの抽象化の「便利機能」をすべてのユーザーに提供し、今日のEOA(外部所有アカウント、すなわちECDSA署名によって制御されるアカウント)を含みます。いくつかの課題(、特に「便利性」の課題)は、多数派計算やEIP-7702のような漸進的技術によって解決できるかもしれませんが、アカウント抽象化提案の最初の主要な安全目標は、元の問題を振り返り解決することによってのみ達成できます: スマートコントラクトコードによる取引の検証を制御すること。この理由は、安全に実施することができていないためであり、これは挑戦です。! [イーサリアムの可能な未来についてのヴィタリック(6):散財](https://img-cdn.gateio.im/social/moments-66bd22f0b53601d0976aa3a2b701c981)#### それは何ですか、どのように機能しますか?アカウント抽象の核心はシンプルです: スマートコントラクトによるトランザクションの発起を可能にすることであり、単にEOAだけではありません。この全体の複雑さは、分散型ネットワークの維持に優しい方法でこれを実現し、サービス拒否攻撃に対抗することから来ています。典型的な重要な課題は、複数の障害の問題です:もし1000のアカウントの検証関数が単一の値Sに依存していて、現在の値Sがメモリプール内の取引をすべて有効にしている場合、単一の取引がSの値を反転させることでメモリプール内の他のすべての取引が無効になる可能性があります。これにより、攻撃者は非常に低コストでメモリプールにゴミ取引を送信し、ネットワークノードのリソースを詰まらせることができます。長年の努力を経て、機能を拡張しながらサービス拒否(DoS)のリスクを制限することを目指し、最終的に"理想的なアカウント抽象"を実現するためのソリューション: ERC-4337が得られました。ERC-4337の動作原理は、ユーザー操作の処理を検証と実行の二つの段階に分けることです。すべての検証は最初に処理され、すべての実行はその後に処理されます。メモリプール内では、ユーザー操作の検証段階が自身のアカウントのみを含み、環境変数を読み取らない場合にのみ受け入れられます。これにより、マルチ失敗攻撃を防ぐことができます。さらに、検証ステップには厳格なガス制限も強制的に適用されます。ERC-4337は、追加のプロトコル標準(ERC)として設計されました。なぜなら、当時イーサリアムのクライアント開発者は(Merge)に集中していたため、他の機能に対処する余力がなかったからです。これが、ERC-4337が通常の取引ではなく、ユーザー操作と呼ばれるオブジェクトを使用している理由です。しかし最近、私たちはその内容の少なくとも一部をプロトコルに書き込む必要があることを認識しました。二つの重要な理由は以下の通りです:1. EntryPointは契約の固有の非効率性: 各バンドルには約100,000ガスの固定コストがあり、さらに各ユーザー操作に数千ガスが追加される。2. イーサリアム属性の必要性を確認する: リストに含まれる項目は、アカウント抽象ユーザーに転送される必要があることを保証するために作成されます。さらに、ERC-4337は2つの機能を拡張しました:- 支払い代理(Paymasters): あるアカウントが別のアカウントの手数料を支払うことを許可する機能であり、これは検証段階で送信者アカウント自体のみがアクセスできるというルールに違反するため、支払い代理メカニズムの安全性を確保するために特別な処理が導入されています。- アグリゲーター(Aggregators): BLSアグリゲーションやSNARKベースのアグリゲーションなど、署名アグリゲーション機能をサポートしています。これは、ロールアップ上での最高のデータ効率を実現するために必要です。! [イーサリアムの可能な未来についてのヴィタリック(6):散財](https://img-cdn.gateio.im/social/moments-c0f722db75e53f4ff37ef40f5547dfc4)#### 既存の研究リンク- アカウントアブストラクションの歴史に関する講演:- ERC-4337:- EIP-7702:- BLSWalletコード(は、アグリゲーション機能)を使用しています:- EIP-7562(プロトコルのアカウント抽象):- EIP-7701(に基づくEOFの書き込みプロトコルアカウント抽象):#### 残りの作業とトレードオフ現在主に解決すべきは、どのようにアカウント抽象をプロトコルに完全に導入するかです。最近人気のある書き込みプロトコルアカウント抽象EIPはEIP-7701であり、この提案はEOFの上にアカウント抽象を実現しています。アカウントは、検証のために単独のコード部分を持つことができ、そのアカウントがそのコード部分を設定している場合、そのコードはそのアカウントからの取引の検証ステップで実行されます。この方法の
イーサリアムの未来の発展:EVMアップグレードとアカウントの抽象化がプロトコルの繁栄を牽引する
イーサリアムプロトコルの可能な未来(六):繁栄
イーサリアムプロトコル設計には、多くの「詳細」がその成功にとって重要です。実際、約半分の内容は異なるタイプのEVM改善に関するもので、残りの部分はさまざまなニッチなテーマで構成されており、これが「繁栄」の意味です。
! イーサリアムの可能な未来についてのヴィタリック(6):散財
繁栄:主要な目標
! イーサリアムの可能な未来についてのヴィタリック(6):散財
EVMの改善
何の問題を解決しましたか?
現在のEVMは静的分析が難しく、高効率な実装、形式的なコード検証、さらなる拡張が困難になっています。また、EVMの効率が低く、明示的なサポートなしに多くの形式の高度な暗号学を実現することが難しいです。
それは何ですか、どのように機能しますか?
現在のEVM改善ロードマップの第一歩はEVMオブジェクトフォーマット(EOF)であり、次のハードフォークに組み込まれる予定です。EOFは一連のEIPであり、新しいEVMコードバージョンを指定し、多くの独特な特徴を持っています。最も顕著なのは:
旧式合約は引き続き存在し、作成可能ですが、最終的には旧式合約(が段階的に廃止される可能性があり、場合によってはEOFコード)に強制的に変換されるかもしれません。新式合約はEOFによる効率の向上から利益を得ることになるでしょう。まずは、サブルーチン機能によってやや縮小されたバイトコード、次にEOF特有の新機能やガスコストの削減です。
! イーサリアムの可能な未来についてのヴィタリック(6):散財
EOFを導入した後、さらなるアップグレードが容易になり、現在最も発展しているのはEVMモジュールの算術拡張(EVM-MAX)です。EVM-MAXは、剰余演算に特化した新しいオペレーションのセットを作成し、それを他のオペコードからアクセスできない新しいメモリ空間に配置しました。これにより、Montgomery乗算などの最適化の使用が可能になります。
比較的新しいアイデアは、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 * カウント] )
実際の実装では、これが並行して処理されます。
既存の研究リンク
残りの作業とトレードオフ
現在、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でガスを支払うことができるようになります。
MPC(マルチパーティ計算)は、鍵を複数の部分に分割し、複数のデバイスに保存するために使用される、40年の歴史を持つ技術です。暗号技術を利用して署名を生成することができ、これらの鍵の部分を直接組み合わせる必要はありません。
EIP-7702は、次のハードフォークで導入される予定の提案です。EIP-7702は、すべてのユーザー(、特にEOAユーザー)に利益をもたらすアカウント抽象化の利便性を提供することへの認識の高まりの結果です。この提案は、短期的にすべてのユーザーの体験を改善し、2つのエコシステムに分裂するのを避けることを目的としています。
この作業はEIP-3074から始まり、最終的にEIP-7702が形成されました。EIP-7702はアカウントの抽象化の「便利機能」をすべてのユーザーに提供し、今日のEOA(外部所有アカウント、すなわちECDSA署名によって制御されるアカウント)を含みます。
いくつかの課題(、特に「便利性」の課題)は、多数派計算やEIP-7702のような漸進的技術によって解決できるかもしれませんが、アカウント抽象化提案の最初の主要な安全目標は、元の問題を振り返り解決することによってのみ達成できます: スマートコントラクトコードによる取引の検証を制御すること。この理由は、安全に実施することができていないためであり、これは挑戦です。
! イーサリアムの可能な未来についてのヴィタリック(6):散財
それは何ですか、どのように機能しますか?
アカウント抽象の核心はシンプルです: スマートコントラクトによるトランザクションの発起を可能にすることであり、単にEOAだけではありません。この全体の複雑さは、分散型ネットワークの維持に優しい方法でこれを実現し、サービス拒否攻撃に対抗することから来ています。
典型的な重要な課題は、複数の障害の問題です:
もし1000のアカウントの検証関数が単一の値Sに依存していて、現在の値Sがメモリプール内の取引をすべて有効にしている場合、単一の取引がSの値を反転させることでメモリプール内の他のすべての取引が無効になる可能性があります。これにより、攻撃者は非常に低コストでメモリプールにゴミ取引を送信し、ネットワークノードのリソースを詰まらせることができます。
長年の努力を経て、機能を拡張しながらサービス拒否(DoS)のリスクを制限することを目指し、最終的に"理想的なアカウント抽象"を実現するためのソリューション: ERC-4337が得られました。
ERC-4337の動作原理は、ユーザー操作の処理を検証と実行の二つの段階に分けることです。すべての検証は最初に処理され、すべての実行はその後に処理されます。メモリプール内では、ユーザー操作の検証段階が自身のアカウントのみを含み、環境変数を読み取らない場合にのみ受け入れられます。これにより、マルチ失敗攻撃を防ぐことができます。さらに、検証ステップには厳格なガス制限も強制的に適用されます。
ERC-4337は、追加のプロトコル標準(ERC)として設計されました。なぜなら、当時イーサリアムのクライアント開発者は(Merge)に集中していたため、他の機能に対処する余力がなかったからです。これが、ERC-4337が通常の取引ではなく、ユーザー操作と呼ばれるオブジェクトを使用している理由です。しかし最近、私たちはその内容の少なくとも一部をプロトコルに書き込む必要があることを認識しました。
二つの重要な理由は以下の通りです:
さらに、ERC-4337は2つの機能を拡張しました:
! イーサリアムの可能な未来についてのヴィタリック(6):散財
既存の研究リンク
残りの作業とトレードオフ
現在主に解決すべきは、どのようにアカウント抽象をプロトコルに完全に導入するかです。最近人気のある書き込みプロトコルアカウント抽象EIPはEIP-7701であり、この提案はEOFの上にアカウント抽象を実現しています。アカウントは、検証のために単独のコード部分を持つことができ、そのアカウントがそのコード部分を設定している場合、そのコードはそのアカウントからの取引の検証ステップで実行されます。
この方法の