# イーサリアムプロトコルの可能な未来（六）：繁栄イーサリアムプロトコルの設計には、その成功にとって重要な多くの「詳細」があります。実際、約半分の内容は異なるタイプのEVM改善に関するもので、残りはさまざまなニッチなテーマで構成されており、これが「繁荮」の意味です。## 繁栄:主要な目標- EVMを高性能で安定した"最終状態"にする- アカウントの抽象化をプロトコルに導入し、すべてのユーザーがより安全で便利なアカウントを享受できるようにします。- 取引コストの経済性を最適化し、スケーラビリティを向上させると同時にリスクを低減する- 先進的な暗号学を探求し、イーサリアムを長期的に大幅に改善する! [イーサリアムの可能な未来についてのヴィタリック(6):散財](https://img-cdn.gateio.im/social/moments-c0ed34ee4adbb5c0bb752dcd01c1f7a7)## 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の組み合わせは、これら二つの性能指向の拡張が自然にペアリングされることを意味する。! [イーサリアムの可能な未来についてのヴィタリック(6):散財](https://img-cdn.gateio.im/social/moments-8930b556d169a2bc7168ddc2e611d3df)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の上に構築し、これを優先すべきだと言えます。必要な作業の1つは、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の動作原理は、ユーザー操作の処理を2つの段階に分けることです: 検証と実行。すべての検証はまず処理され、すべての実行はその後に処理されます。メモリプール内では、ユーザー操作の検証段階が自身のアカウントのみを含み、環境変数を読み取らない場合にのみ受け入れられます。これにより、複数の失敗攻撃を防ぐことができます。また、検証ステップにも厳格なガス制限が強制的に実施されます。ERC-4337は、追加のプロトコル標準)ERC(として設計されました。なぜなら、その当時イーサリアムのクライアント開発者は)Merge(に集中していて、他の機能を処理するための追加のエネルギーを持っていなかったからです。これが、ERC-4337が通常の取引ではなく、ユーザー操作と呼ばれるオブジェクトを使用している理由です。しかし最近、私たちはその一部をプロトコルに書き込む必要性を認識しました。二つの重要な理由は以下の通りです:1. EntryPointは契約の固有の非効率性として: 各バンドルは約100,000ガスの固定コストを持ち、さらに各ユーザー操作に数千ガスの追加コストがかかります。2. イーサリアム属性の必要性を確認する: 作成された含むリストが、アカウント抽象ユーザーに転送されることを保証する必要があります。! [イーサリアムの可能な未来についてのヴィタリック(6):散財])https://img-cdn.gateio.im/social/moments-c0f722db75e53f4ff37ef40f5547dfc4(さらに、ERC-4337は2つの機能を拡張しました:- 支払い代理)Paymasters(: あるアカウントが別のアカウントの手数料を支払うことを許可する機能であり、これは検証段階では送信者のアカウント自体のみにアクセスできるというルールに違反するため、支払い代理メカニズムの安全性を確保するために特別な処理が導入されています。- アグリゲーター)Aggregators(: BLSアグリゲーションやSNARKベースのアグリゲーションなど、署名アグリゲーション機能をサポートします。これは、ロールアップ上で最高のデータ効率を実現するために必要です。) 現在の研究リンク- アカウント抽象の歴史に関する講演:- ERC-4337:- EIP-7702:- BLSWalletコード###は、アグリゲート機能(を使用します。- EIP-7562)によるプロトコルのアカウント抽象(:- EIP-7701)基于EOFの書き込みプロトコルアカウント抽象(:) 残りの作業とトレードオフ現時点で主に解決すべきは、どのようにアカウント抽象をプロトコルに完全に導入するかです。最近人気を集めている書き込みプロトコルアカウント抽象EIPはEIP-7701であり、この提案はEOFの上にアカウント抽象を実現します。アカウントは検証のために独自のコード部分を持つことができ、アカウントがそのコード部分を設定した場合、そのコードはそのアカウントからの取引の検証ステップで実行されます。この方法の魅力
イーサリアムの未来展望：EVMのアップグレードとアカウントの抽象化が繁栄の新しい段階を牽引する
イーサリアムプロトコルの可能な未来（六）：繁栄
イーサリアムプロトコルの設計には、その成功にとって重要な多くの「詳細」があります。実際、約半分の内容は異なるタイプの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の組み合わせは、これら二つの性能指向の拡張が自然にペアリングされることを意味する。
! イーサリアムの可能な未来についてのヴィタリック(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の上に構築し、これを優先すべきだと言えます。
必要な作業の1つは、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):散財])https://img-cdn.gateio.im/webp-social/moments-66bd22f0b53601d0976aa3a2b701c981.webp(
) それは何ですか、どのように機能しますか？
アカウント抽象の核心はシンプルです: スマートコントラクトが取引を開始できるようにすること、そしてそれは単なるEOAだけではありません。この全ての複雑さは、去中心化ネットワークを維持することに友好的な方法でこれを実現し、サービス拒否攻撃から守ることに起因しています。
一般的な主要な課題は、複数の障害の問題です。
もし1000のアカウントの検証関数が特定の単一の値Sに依存していて、現在の値Sがメモリプール内の取引をすべて有効にしている場合、単一の取引がSの値を反転させることでメモリプール内の他のすべての取引が無効になる可能性があります。これにより、攻撃者は非常に低コストでメモリプールにジャンク取引を送信し、ネットワークノードのリソースを塞ぐことができます。
数年の努力を経て、機能を拡張しつつサービス拒否###DoS(のリスクを制限することを目的とし、最終的に"理想的なアカウントの抽象化"を実現する解決策：ERC-4337が得られました。
ERC-4337の動作原理は、ユーザー操作の処理を2つの段階に分けることです: 検証と実行。すべての検証はまず処理され、すべての実行はその後に処理されます。メモリプール内では、ユーザー操作の検証段階が自身のアカウントのみを含み、環境変数を読み取らない場合にのみ受け入れられます。これにより、複数の失敗攻撃を防ぐことができます。また、検証ステップにも厳格なガス制限が強制的に実施されます。
ERC-4337は、追加のプロトコル標準)ERC(として設計されました。なぜなら、その当時イーサリアムのクライアント開発者は)Merge(に集中していて、他の機能を処理するための追加のエネルギーを持っていなかったからです。これが、ERC-4337が通常の取引ではなく、ユーザー操作と呼ばれるオブジェクトを使用している理由です。しかし最近、私たちはその一部をプロトコルに書き込む必要性を認識しました。
二つの重要な理由は以下の通りです:
! [イーサリアムの可能な未来についてのヴィタリック(6):散財])https://img-cdn.gateio.im/webp-social/moments-c0f722db75e53f4ff37ef40f5547dfc4.webp(
さらに、ERC-4337は2つの機能を拡張しました:
) 現在の研究リンク
) 残りの作業とトレードオフ
現時点で主に解決すべきは、どのようにアカウント抽象をプロトコルに完全に導入するかです。最近人気を集めている書き込みプロトコルアカウント抽象EIPはEIP-7701であり、この提案はEOFの上にアカウント抽象を実現します。アカウントは検証のために独自のコード部分を持つことができ、アカウントがそのコード部分を設定した場合、そのコードはそのアカウントからの取引の検証ステップで実行されます。
この方法の魅力