Vitalik氏の最新記事：ZK-EVMの将来と課題を探る

執筆：Vitalik Buterin

翻訳：1912212.eth、Foresight News

オプティミスティックロールアップやZKロールアップを含む、イーサリアム上のレイヤー2 EVMプロトコルはすべてEVM検証に依存しています。しかし、これはそれらが巨大なコードベースを信頼しなければならず、そのコードベースにバグがある場合、これらのVMがハッキングされるリスクがあります。さらに、L1 EVMと完全に同等であることを目指すZK-EVMでさえも、L1 EVMの変更を自らのEVM実装に複製するために何らかの形のガバナンスが必要になるということを意味します。

この状況は理想的ではありません。なぜなら、これらのプロジェクトはすでにイーサリアムプロトコル内に存在する機能を複製しており、イーサリアムのガバナンスがアップグレードやバグ修正を担当しているからです。実質的にZK-EVMは、第1層のイーサリアムブロックを検証する作業とまったく同じことをしているのです。さらに今後数年間で、ライトクライアントがますます強力になり、すぐにZK-SNARKsを使って第1層EVM実行を完全に検証できるようになると予想されています。その時点で、イーサリアムネットワークは事実上、組み込みのZK-EVMを構築することになります。したがって、疑問が生じます。なぜZK-EVM自体をロールアップにも適用させないのでしょうか？

本稿では、「組み込みZK-EVM」を実現するためのいくつかの可能な形態について紹介し、トレードオフや設計上の課題、および特定の方向性を選ばない理由について議論します。プロトコル機能を実装する利点は、エコシステムに任せて基盤プロトコルをシンプルに保つことの利点と慎重に比較されるべきです。

組み込みZK-EVMに期待される主要な特性とは？

• 基本機能：イーサリアムブロックの検証。プロトコル機能（現時点ではオペコード、プリコンパイル、あるいは他のメカニズムか未確定）は、少なくとも1つの事前ステートルート、1つのブロック、および事後ステートルートを入力として受け取り、事後ステートルートが実際にブロック実行後の結果であることを検証すべきです。

• 複数のイーサリアムクライアントとの互換性。つまり、単一の証明システムだけを採用するのではなく、異なるクライアントが異なる証明システムを使用できるようにすることを目指します。これにより以下の点が導かれます：

• データ可用性の要件：組み込みZK-EVMを使ってEVM実行に対する証明を行う場合、裏付けとなるデータの可用性を保証したいと考えます。これにより、異なる証明システムを使う証明者が再証明を行い、その証明システムに依存するクライアントが新たに生成された証明を検証できるようになります。

• 証明はEVMおよびブロックデータ構造の外部に存在する：組み込みZK-EVM機能は、SNARKをEVM内の入力として受け取るべきではありません。なぜなら、異なるクライアントは異なるタイプのSNARKを期待するからです。むしろ、blob検証のような形になるかもしれません。つまり、トランザクションには（事前ステート、ブロック本体、事後ステート）の証明対象となる宣言を含めることができ、オペコードまたはプリコンパイルによってこれらの宣言の内容にアクセスできます。クライアントの合意ルールは、それぞれの宣言に対するデータ可用性と証明の存在を個別にチェックします。

• 監査可能性。いかなる実行であっても証明された場合、問題が発生したときにユーザーと開発者がそれを調査できるように、裏付けとなるデータが利用可能であることが望まれます。実際、これがデータ可用性要件が非常に重要であるもう一つの理由です。

• アップグレード性。あるZK-EVM方式にバグが発見された場合、迅速に修正できることが望まれます。つまり、ハードフォークなしで修正できることです。これが、証明がEVMおよびブロックデータ構造の外部にあるべきであるもう一つの理由です。

• ほぼすべてのEVMをサポート。L2の魅力の一つは、実行層での革新とEVMの拡張です。あるL2のVMがEVMとわずかに異なる場合でも、そのL2がEVMと同じ部分についてはネイティブなプロトコル内ZK-EVMを使い、異なる部分については独自のコードに依存できるとよいでしょう。これは、呼び出し元がビットフィールドやオペコードリスト、アドレスを指定できるようにZK-EVM機能を設計することで実現可能です。これらは外部提供のテーブルによって処理され、EVM自体ではなくなります。また、ある程度ガスコストを編集可能にすることもできます。

「オープン」と「クローズド」のマルチクライアントシステム

「マルチクライアント理念」はおそらく、このリストの中で最も主観的な要件です。これをあきらめてZK-SNARK方式に集中すれば設計が簡素化されますが、その代償としてイーサリアムにおけるより大きな「哲学的転換点」（実質的に長年のマルチクライアント理念の放棄）となり、より大きなリスクを伴います。将来的に形式的検証技術がより優れたものになったときには、この道を選ぶ方が良いかもしれませんが、現時点ではリスクが大きすぎるように見えます。

もう一つの選択肢は、プロトコル内で固定された一連の証明システムが定義されている「クローズド」マルチクライアントシステムです。例えば、PSE ZK-EVM、Polygon ZK-EVM、Kakarotの3つのZK-EVMを採用すると決め、ブロックが有効になるにはこのうち2つによる証明が必要とするようなものです。単一の証明システムよりは良いですが、適応性が低下します。なぜなら、ユーザーは存在するすべての証明システムに対して検証器を維持しなければならず、新しい証明システムを追加する際に避けられない政治的ガバナンスプロセスが発生するからです。

そのため、私は「オープン」マルチクライアントシステムを好む傾向があります。このシステムでは、証明は「ブロック外」に配置され、クライアントが個別に検証を行います。個人ユーザーは、任意のクライアントを使ってブロックを検証でき、その証明システム向けに証明を作成する証明者が一人以上いれば十分です。証明システムの影響力は、プロトコルのガバナンスプロセスを説得することではなく、ユーザーに自らのクライアントの使用を促すことによって得られます。ただし、このようなアプローチは、以下に示すように、より高い複雑性を伴います。

ZK-EVM実装に期待される主要な属性とは？

基本的な機能正しさと安全性保証に加えて、最も重要な属性はスピードです。プロトコル内ZK-EVM機能を非同期に設計し、Nスロットの遅延後に各宣言に対する答えを返すことも可能ですが、数秒以内に証明を確実に生成できれば、どのブロックでも自足的になり、問題ははるかに簡単になります。

現在、イーサリアムブロックの証明生成には数分から数時間かかるものの、大規模な並列化を妨げる理論的理由はありません。常に十分なGPUを組み合わせて、ブロック実行の各部分を個別に証明し、再帰的SNARKで証明を統合できます。また、FPGAやASICによるハードウェアアクセラレーションもさらなる最適化に貢献できます。しかし、実際にこの段階に到達することは決して軽視できない巨大な工学的挑戦です。

プロトコル内ZK-EVM機能の具体的な形態はどのようなものか？

EIP-4844のblobトランザクションと同様に、ZK-EVM宣言を含む新しいタイプのトランザクションを導入します。

class ZKEVMClaimTransaction(Container):pre_state_root: bytes32post_state_root: bytes32transaction_and_witness_blob_pointers: List[VersionedHash]

EIP-4844と同様に、メモリプール内で伝播されるオブジェクトは次のようなトランザクションの変形版です。

class ZKEvmClaimNetworkTransaction(Container):pre_state_root: bytes32post_state_root: bytes32proof: bytestransaction_and_witness_blobs: List[Bytes[FIELD_ELEMENTS_PER_BLOB * 31]]

後者は前者に変換可能ですが、逆はできません。また、ブロックスドロードオブジェクト（EIP-4844で導入）も拡張し、ブロック内の宣言に対する証明リストを含めるようにします。

実際には、スドロードを2つの独立したスドロードに分割することが望ましいかもしれません。1つはblobs用、もう1つは証明用です。さらに、各タイプの証明（およびblobsのサブネット）ごとに個別のサブネットを設定することも考えられます。

コンセンサス層では、クライアントがブロック内の各宣言に対して有効な証明を確認できた場合にのみ、そのブロックを受け入れるという検証ルールを追加します。証明はZK-SNARKであり、transaction_and_witness_blobsの連結が（Block, Witness）対の直列化であること、そしてWitness上でpre_state_rootを使ってブロックを実行した結果が

(i) 正当であり、

(ii) 正しいpost_state_rootを出力することを証明する必要があります。クライアントはM-of-N方式で複数種類の証明を待つこともできるでしょう。

ここで注意すべきは、ブロック実行自体もZKEVMClaimTransactionオブジェクトで提供される三つ組と一緒にチェックすべき三つ組の一つと見なせることです（σpre,σpost,Proof）。したがって、ユーザーのZK-EVM実装は実行クライアントを置き換えることができます。実行クライアントは依然として

(i) 証明者とブロックビルダー、および

(ii) ローカルでのインデックス作成やデータ保存を必要とするノードによって使用されます。

さらに、このアーキテクチャは実行と検証を分離するため、イーサリアムエコシステム内のさまざまな役割にさらなる柔軟性と効率性を提供する可能性があります。たとえば、証明者は実行の詳細を気にせず証明生成に集中でき、一方で実行クライアントは高速同期や高度なインデックス機能など、特定のユーザーのニーズに最適化できます。

検証と再証明

あるイーサリアムクライアントがPSE ZK-EVMを使用し、もう一つがPolygon ZK-EVMを使用していると仮定します。どちらの実装も、イーサリアムブロック実行を5秒以内に証明できるレベルまで進化しており、それぞれの証明システムに対して十分な数の独立したボランティアが証明生成用ハードウェアを運用しているとします。

残念ながら、個々の証明システムが公式に承認されていないため、プロトコル内で報酬を得ることはできません。しかし、研究開発に比べて証明の実行コストは低いと予想されるため、公共財支援機関を通じて証明者に資金を提供するのは容易だと考えられます。

誰かがZKEvmClaimNetworkTransactionを送信したが、PSE ZK-EVM版の証明しか公開しなかったとします。Polygon ZK-EVMの証明ノードがこれを認識し、計算を行い、Polygon ZK-EVMの証明を添えてそのオブジェクトを再投稿します。

これにより、最初の誠実なノードがブロックを受け入れてから最後の誠実なノードが同じブロックを受け入れるまでの最大遅延がδから2δ+Tprove（ここでTprove<5sと仮定）に増加します。

しかし、幸運なことに、単一スロット最終性（SSF）を採用すれば、この余分な遅延をSSFに内在する多ラウンド合意遅延と「パイプライン化」できる可能性が非常に高いです。たとえば、この4つのサブスロット提案では、「ヘッド投票」ステップは基本ブロックの正当性だけをチェックするかもしれませんが、「フリーズと確定」ステップでは証明の存在が必要になります。

拡張：「almost-EVMs」のサポート

ZK-EVM機能の望ましい目標の一つは、「almost-EVMs」、つまり追加機能を持つEVMをサポートすることです。これには新しいプリコンパイル、新しいオペコード、Arbitrum StylusのようにEVMとは異なるVM（例：WASMなど）でコードを書ける契約、あるいは同期的クロス通信を持つ複数の並列EVMなどが含まれます。

一部の変更はシンプルな方法でサポート可能です。ZKEVMClaimTransactionが修正されたEVMルールの完全な記述を渡せる言語を定義できます。これは以下の場合に使用できます：

1. カスタムガス料金表（ユーザーはガスコストを減らすことは許可されませんが、増やすことは可能です）

2. 特定のオペコードの無効化

3. ブロック番号の設定（ハードフォークによって異なるルールを意味します）

4. フラグを設定し、L2利用のために標準化されているがL1では使えないEVM変更セットや、その他の簡単な変更を有効にする

新しいプリコンパイル（またはオペコード）などを通じて、より開放的な方法で新機能を追加できるようにするため、ZKEVMClaimNetworkTransactionのblob部分にプリコンパイルの入出力記録を含める仕組みを追加できます。

class PrecompileInputOutputTranscript(Container):used_precompile_addresses: List[Address]inputs_commitments: List[VersionedHash]outputs: List[Bytes]

EVM実行は以下のように変更されます。inputsという名前の配列が空で初期化されます。used_precompile_addresses内のアドレスが呼び出されるたびに、inputsにInputsRecord(callee_address, Gas, input_calldata)オブジェクトを追加し、呼び出しのRETURNDATAをoutputs[i]に設定します。最後に、used_precompile_addressesが合計len(outputs)回呼び出されたこと、およびinputs_commitmentsがinputsのSSZシリアライゼーションに対するコミットメントと一致することをチェックします。inputs_commitmentsを公開する目的は、外部のSNARKがinputsとoutputsの関係を証明できるようにするためです。

inputsとoutputsの間の非対称性に注意してください。inputsはハッシュ内に格納され、outputsは提供されるバイトとして完全に格納されます。これは、実行を理解しEVMだけを見ているクライアントによって実行される必要があるためです。EVM実行は既にinputsを生成しているため、生成されたinputsが宣言されたinputsと一致するかをチェックするだけでよく、これはハッシュチェックだけで済みます。しかし、outputsは完全に提供されなければならないため、データ可用性が確保されなければなりません。

もう一つ有用な機能は、「特権トランザクション」を任意の送信者アカウントから呼び出せるようにすることです。これらのトランザクションは、他の2つのトランザクションの間に実行されるか、あるいは別の（おそらくそれも特権的）トランザクション内でプリコンパイルを呼び出すことができます。これにより、非EVMメカニズムがEVMにコールバックできるようになります。

この設計は、新しいまたは変更されたオペコードだけでなく、新しいまたは変更されたプリコンパイルのサポートに修正できます。プリコンパイルだけでも、この設計は非常に強力です。たとえば：

used_precompile_addressesを、アカウントオブジェクトのステート内に特定のフラグが設定された通常のアカウントアドレスのリストに設定し、その正しく構築されたSNARKを生成することで、Arbitrum Stylusのように、契約がEVMまたはWASM（または他のVM）でコードを記述できる機能をサポートできます。特権トランザクションは、WASMアカウントがEVMにコールバックできるようにするために使用できます。

外部チェックを追加することで、複数のEVM実行の入出力記録と特権トランザクションが正しい方法で一致していることを保証し、同期チャンネルで相互に通信する複数のEVMの並列システムを証明できます。

タイプ4のZK-EVMは、複数の実装を持つことで動作できます。一つはSolidityまたは他の高レベル言語を直接SNARKフレンドリーなVMに変換する実装、もう一つはそれをEVMコードにコンパイルして規定のZK-EVMで実行する実装です。後者の（必然的に遅くなる）実装は、誤り証明者がエラーがあると主張するトランザクションを送信した場合にのみ実行され、両者が異なる処理をするトランザクションを提供できた場合に報奨金を得られます。

すべての呼び出しをゼロで返し、呼び出しをブロック末尾に追加される特権トランザクションにマッピングすることで、純粋な非同期VMを実現できます。

拡張：ステート証明者のサポート

上記の設計の課題は、それが完全にステートレスであるため、データ効率が劣る点です。理想的なデータ圧縮を用いる場合、ステートレス圧縮のみを使用する場合と比較して、ステートフル圧縮はERC20送信においてスペース利用効率を最大で3倍向上させることができます。

さらに、ステートフルなEVMは証人データを提供する必要がありません。いずれの場合も、原則は同じです。EVMの以前の実行によって入力または生成されたデータであることが既にわかっている場合、データ可用性を要求するのは無駄です。

もしZK-EVM機能をステートフルにしたい場合、2つの選択肢があります：

σpreは空であるか、データ可用な事前宣言のキーと値のリスト、または以前の実行のσpostのいずれかである必要があります。

ブロック生成のレシートRにblobコミットメントを(σpre, σpost, Proof)タプルに追加します。ZKEVMClaimTransaction内で参照され、実行中にアクセス可能なのは、以前に生成または使用されたblobコミットメント（ブロック、証人、レシート、または通常のEIP-4844 blobトランザクションを表すコミットメントを含む）です（時間制限があるかもしれません。一連の命令で参照可能：「j番目のブロック＋証人データ位置に、コミットメントiのN...N+k-1バイトを挿入」）。

（1）の基本的な意味は、ステートレスEVM検証を確立するのではなく、EVMサブチェーンを確立するということです。

（2）は、以前に使用または生成されたblobを辞書として使う最小限の組み込みステートフル圧縮アルゴリズムを本質的に作成することです。どちらのケースも、証明者ノードにのみ、より多くの情報を保存する負担がかかります。

（2）の場合、この負担に時間制限をかけるのは比較的容易ですが、（1）の場合は困難です。

クローズドマルチプローバーシステムとオンチェーン外データに関する議論

M-of-N構造で固定数の証明システムを持つクローズドマルチプローバーシステムは、上記の多くの複雑性を回避できます。特に、クローズドマルチプローバーシステムでは、データがオンチェーンに存在することを保証する必要がありません。さらに、クローズドマルチプローバーシステムは、ZK-EVMがオンチェーン外実行を証明できるようにし、EVM Plasmaソリューションとの互換性を持たせます。

しかし、クローズドマルチプローバーシステムはガバナンスの複雑性を増し、監査可能性を弱めるという代償があり、これらの利点と比較して高いコストとなります。

もし我々がZK-EVMを組み込み、プロトコル機能として採用した場合、L2プロジェクトの継続的な役割は何でしょうか？

現在、L2チームが独自に実装しているEVM検証機能はプロトコルが処理することになりますが、L2プロジェクトは依然として多くの重要な機能を担当します：

• 高速プリコンファーム：単一スロット最終性によりL1スロットが遅くなる可能性がありますが、L2は既に自身のセキュリティにより、スロット未満の遅延でプリコンファームを提供するサービスをユーザーに提供しています。このサービスは引き続き完全にL2が責任を持ちます。

• MEV緩和戦略：暗号化メモリプール、評判に基づく順序選択などの機能は、L1が実装をためらうものです。

• EVMの拡張：第2層プロジェクトはEVMに重要な拡張を導入し、ユーザーに顕著な価値を提供できます。これには「almost-EVMs」や、Arbitrum StylusのWASMサポートやSNARKフレンドリーなCairo言語といった全く異なるアプローチが含まれます。

• ユーザーと開発者の利便性：第2層チームは、ユーザーとプロジェクトを自らのエコシステムに惹きつけ、居心地の良さを感じさせるために多くの努力を払っています。彼らはネットワーク内で捕獲したMEVや混雑料金によって報酬を得ています。この関係は今後も続くでしょう。