Vitalikの新しい記事:ZK-EVMの未来と課題

原題:「"祀られたZK-EVM"とは?」

原作者:ヴィタリック

オリジナルコンピレーション:Luccy、BlockBeats

*編集者注:12月13日、ETH Placeの共同創設者であるVitalik Buterin氏は、「ZK-EVM」(ゼロ知識イーサリアム仮想マシン)の実装の可能性を掘り下げ、ZK-EVMのさまざまなバージョンの設計について議論した記事を公開しました。 *

*VitalikのZK-EVMコンセプトは、レイヤー2プロジェクトによるイーサリアムプロトコル機能の重複を減らし、レイヤー1イーサリアムブロックの検証効率を向上させることを目的としています。 この記事では、現在のレイヤ2 EVMプロトコル(オプティミスティックロールアップやZKロールアップなど)はEVM検証メカニズムに依存していますが、これは大規模なコードベースを信頼する必要があることも意味しています。 コードベースに脆弱性が発生すると、これらの仮想マシンは攻撃を受けるリスクにさらされる可能性があります。 *

*さらに、L2 VMがEVMとわずかな違いでプロトコル内でZK-EVMを使用できるようにすると同時に、EVMの一部のカスタマイズに柔軟性を提供する「ほぼEVM」のサポートについても言及しました。 *

演算ロールアップや ZK ロールアップなど、ETH上のレイヤ 2 EVM プロトコルは、EVM 検証に依存しています。 ただし、これには大規模なコードベースを信頼する必要があり、そのコードストックが抜け穴にある場合、これらのVMはハッキングされるリスクがあります。 さらに、L1 EVM と完全に同等にしたい ZK-EVM であっても、L1 EVM からの変更を独自の EVM 実装に複製するには、何らかのガバナンスが必要です。

これらのプロジェクトはETH Fangプロトコルにすでに存在する機能を複製しており、ETH Fangのガバナンスはすでにアップグレードとバグの修正を担当しているため、この状況は理想的ではありません。 ZK-EVMは基本的にL1 ETHブロックの検証と同じ作業を行います。 さらに、今後数年間で、ライトクライアントはますます強力になり、まもなくZK-SNARKを使用してL1 ETH Fangの実行を完全に検証するようになると予想されます。 この時点で、ETHネットワークには実質的にZK-EVMが組み込まれます。 そこで疑問が湧いてきますが、なぜこのZK-EVMのローカライゼーションをロールアップ・プロジェクトで利用できるようにしないのでしょうか?

本稿では、「ZK-EVM」のいくつかの可能なバージョンについて説明し、トレードオフと設計上の課題、および特定の方向性を選択しない理由を探ります。 プロトコル機能を実装する利点は、エコシステムに残された利点と、基盤となるプロトコルをシンプルに保つことの利点と比較検討する必要があります。

標準装備されているZK-EVMに期待できる主な特性とは?

基本機能:ETHブロックを検証します。 プロトコル機能 (それがオペコードなのか、プリコンパイルなのか、それとも他のメカニズムなのかはまだ不明です) は、少なくとも前状態ルート、ブロック、および後状態ルートを入力として受け入れ、後状態ルートが実際に前状態ルート上でブロックを実行した結果であることを確認する必要があります。

ETHマルチクライアントの概念との互換性。 つまり、1 つの構成証明システムを追求することは避け、代わりに、異なるクライアントが異なる構成証明システムを使用できるようにする必要があります。 これは、いくつかのポイントを意味します。

· データ可用性の要件:祀られているZK-EVMプルーフを使用するEVM実行では、別のアテステーションシステムを使用しているプルーバーが実行を再アテストでき、そのアテステーションシステムに依存するクライアントがこれらの新しく生成されたプルーフを検証できるように、基盤となるデータが使用可能であることを保証できるようにしたいと考えています。

· EVMおよびチャンク・データ構造の外部に証明が存在する:ZK-EVM機能は、クライアントごとに異なるタイプのSNARKを期待するため、EVM内の入力としてSNARKを直接使用しません。 代わりに、BLOB検証に似ているかもしれません:トランザクションには、証明する必要があるステートメント(事前状態、ブロック本体、事後状態)を含めることができ、その内容はオペコードまたはプリコンパイルによってアクセスでき、クライアント側のコンセンサスルールは、ブロックで行われた各クレームのデータの可用性と証明の存在をそれぞれチェックします。

監査可能性。 実行が証明された場合は、何か問題が発生した場合にユーザーや開発者が検査できるように、基になるデータを使用できるようにする必要があります。 実際には、これはデータ可用性要件の重要性を示す別の理由を追加します。

アップグレード性。 特定のZK-EVMソリューションに脆弱性が見つかった場合、迅速に修正できるようにしたいと考えています。 これは、それを修正するためにハードフォークの必要がないことを意味します。 これは、EVMとブロックのデータ構造の外部に存在することの重要性を証明する別の理由を追加します。

ほぼEVMをサポートするネットワーク。 L2 の魅力の 1 つは、実行レイヤーを革新し、EVM を拡張できることです。 特定の L2 の仮想マシン (VM) が EVM とわずかに異なる場合、L2 が EVM と同じネイティブのプロトコル内 ZK-EVM を引き続き使用でき、EVM の同じ部分には独自のコードのみを使用し、異なる部分には独自のコードのみに依存できると便利です。 これは、EVM 自体ではなく、外部から提供されたテーブルによって処理されるオペコード、アドレス、またはビットフィールドを呼び出し元が指定できる ZK-EVM 機能を設計することで実現できます。 また、ガス代を限られた範囲でカスタマイズできるようにすることもできます。

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

「マルチクライアントの概念」は、おそらくこのリストの中で最も主張されている要件です。 このアイデアを放棄し、ZK-SNARKソリューションに集中するという選択肢もあり、これにより設計が簡素化されますが、その代償として、ワークショップのより大きな「哲学的転換」ETH(これは実際にはワークショップの長期的なマルチクライアント哲学からの逸脱となるため)ETHより大きなリスクが導入されます。 長期的には、例えば形式的な検証技術が向上すれば、この道を選んだ方が良いのかもしれませんが、今のところはリスクが大きすぎるように思えます。

別のオプションは、プロトコル内で構成証明システムの固定セットが知られているクローズドなマルチクライアントシステムです。 たとえば、PSE ZK-EVM、Polygon ZK-EVM、Kakarot の 3 つの ZK-EVM を使用することにします。 ブロックが有効と見なされるためには、これら3つのうち2つの証明が必要です。 これは単一の証明システムよりはましですが、ユーザーは既知のすべての証明システムに対してバリデーターを維持しなければならず、新しい証明システムを組み込むための政治的ガバナンスプロセスが必要となるため、システムの適応性が低下します。

このため、私は、証明が「ブロックの外側」に配置され、クライアントによって個別に検証される、オープンなマルチクライアントシステムを好むようになりました。 個々のユーザーは、システムの証明を生成する証明者が少なくとも1人いる限り、必要なクライアントでブロックを検証できます。 構成証明システムは、プロトコル ガバナンス プロセスを納得させるのではなく、ユーザーに実行を納得させることで影響力を獲得します。 ただし、このアプローチには、より複雑なコストがかかります。

ZK-EVMの実装に求める主な機能は何ですか?

基本的な正しい機能と安全性の保証に加えて、最も重要な機能は速度です。 非同期で、N個のタイムスロットの遅延後に各クレームに対して1つの回答のみを返すプロトコル内でZK-EVM機能を設計することは可能ですが、各ブロックで発生するすべてのことが自己完結型であるという問題は、証明が数秒で生成されることを確実に保証できれば、より簡単になります。

現在、ETHブロックの証明を生成するには数分から数時間かかりますが、大量並列化を防ぐ理論的な理由はないことがわかっています:ブロック実行のさまざまな部分を個別に証明するのに十分なGPUをいつでも組み合わせて、再帰的なSNARKを使用してそれらの証明をまとめることができます。 さらに、FPGAとASICによるハードウェアアクセラレーションは、プルーフをさらに最適化するのに役立つ可能性があります。 しかし、実際にここまでたどり着くことは、過小評価してはならない重要なエンジニアリング上の課題です。

プロトコル内のZK-EVM機能はどのようなものですか?

EIP-4844 BLOB トランザクションと同様に、ZK-EVM クレームを含む新しいトランザクションの種類が導入されました。

EIP-4844と同様に、mempoolで渡されるオブジェクトは、トランザクションの修正バージョンになります。

後者は前者に変換できますが、その逆はできません。 また、ブロックサイドカーオブジェクト(EIP-4844で導入)を拡張し、ブロックで作成された証明のリストを含めました。

実際には、サイドカーを 2 つの別々のサイドカー (1 つは BLOB 用、もう 1 つは証明用) に分割し、証明の種類ごとに個別のサブネット (および BLOB 用の追加のサブネット) を設定することもできます。

コンセンサスレイヤーの上に、クライアントがブロック内の各クレームの有効な証拠を見た場合にのみブロックが受け入れられるという検証ルールを追加しました。 証明はZK-SNARK構成証明ステートメントである必要があります、つまり、トランザクション_and_witness_blobsの連結は(Block,Witness)ペアのシリアル化であり、実行ブロックはWitness(i)を使用してpre_state_rootで有効であり、(ii)正しいpost_state_rootを出力します。 場合によっては、クライアントは複数の構成証明の種類に対して M-of-N を待つことを選択できます。

ここには、ブロックの実行自体は、ZKEVMClaimTransactionオブジェクトで提供されるトリプル(σpre、σpost、Proof)の1つと一緒にチェックする必要があるものとして扱うことができるという哲学的な注意があります。 その結果、ユーザーのZK-EVM実装は、(i)プルーバーとブロックビルダー、および(ii)ローカルで使用するためのデータのインデックス作成と保存を重視するノードによって引き続き使用される実行クライアントを置き換えることができます。

検証と再構成証明

たとえば、2 つの ETH クライアントがあり、そのうちの 1 つが PSE ZK-EVM を使用し、もう 1 つが Polygon ZK-EVM を使用しているとします。 この時点までに、両方の実装が 5 秒未満でブロック実行ETH証明できるところまで進化し、各証明システムに対して、証明を生成するのに十分な独立したボランティアがハードウェアを実行しているとします。

残念ながら、個々の認証システムは形式化されていないため、プロトコルでインセンティブを与えることはできませんが、プルーフ・オブ・プルーフ・ノードの運用コストは研究開発のコストに比べて低くなると予想されるため、公共財のための共通団体の資金提供を通じてプルーフ・オブ・プルーフ・ノードに資金を提供するだけで済みます。

たとえば、PSE ZK-EVMバージョンの証明のみを公開しない限り、誰かがZKEvmClaimNetworkTransactionを公開したとします。 これを見て、Polygon ZK-EVMのProofノードは、Proof of Polygon ZK-EVMでオブジェクトを計算して再公開します。

これにより、ブロックを受け入れる最初の正直なノードと、同じブロックを受け入れる最新の正直なノードの間の合計最大レイテンシが δ から 2 δ+Tprove に増加します (ここでは Tprove < 5 秒と仮定します)。

しかし、良いニュースは、シングルスロットの決定論を採用すると、SSFに固有のマルチラウンドコンセンサスレイテンシーとともに、ほぼ確実にこの余分なレイテンシーを「パイプライン化」できることです。 例えば、この4スロットの提案では、「ヘッド投票」ステップは基本的なブロックの有効性をチェックするだけでよいかもしれませんが、「凍結して確認する」ステップでは証明の存在が必要になります。

拡張機能: “almost-EVM” をサポート

ZK-EVM機能の望ましい目標は、「ほぼEVM」、つまりいくつかの追加機能を備えたEVMをサポートすることです。 これには、新しいプリコンパイル、新しいオペコード、EVMまたは完全に異なるVM(Arbitrum Stylusなど)でのコントラクトの記述、さらには同期クロスコミュニケーションを備えた複数の並列EVMなどが含まれます。

いくつかの変更は簡単な方法でサポートできます:ZKEVMClaimTransactionが修正されたEVMルールの完全な記述を渡すことを可能にする言語を定義することができます。 これは、次の目的で使用できます。

· カスタムガスコストテーブル(ユーザーはガスコストを削減することはできませんが、増やすことはできます)

· 特定のオペコードを無効にする

· ブロック番号を設定します(これは、ハードフォークによって異なるルールがあることを意味します)

· L1 ではなく L2 用に標準化された EVM 変更のフルセット、またはその他のより単純な変更をアクティブ化するフラグを設定します

新しいプリコンパイル済み(またはオペコード)をよりオープンな方法で導入することで、ユーザーが新しい機能を追加できるようにするために、プリコンパイルされた入力/出力トランスクリプトを含むコンテンツをZKEVMClaimNetworkTransactionのBLOBの一部に追加できます。

EVM の実行は次のように変更されます。 配列の入力は空として初期化されます。 used_precompile_addresses のアドレスが呼び出されるたびに、InputsRecord(callee_address, gas, input_calldata) オブジェクトを入力に追加し、呼び出しの RETURNDATA を出力に設定します[i]。 最後に、used_precompile_addresses が合計で len(outputs) 呼び出されたこと、および inputs_commitments が、生成された BLOB コミットメントの SSZ シリアル化の結果と入力と一致することを確認します。 inputs_commitments を公開する目的は、外部 SNARK が入力と出力の関係を証明しやすくすることです。

入力と出力の非対称性に注意し、入力はハッシュに格納され、出力は指定する必要があるバイトに格納されます。 これは、入力のみを見てEVMを理解するクライアントが実行する必要があるためです。 EVMの実行では、すでに入力が生成されているため、生成された入力が宣言された入力と一致するかどうかをチェックするだけでよく、ハッシュチェックのみが必要です。 ただし、出力は完全な形式で提供する必要があるため、データが使用可能である必要があります。

もう一つの便利な機能は、「特権トランザクション」、つまり、任意の送信者アカウントから呼び出しを開始するトランザクションを許可することです。 これらのトランザクションは、他の 2 つのトランザクション間で実行することも、別の (場合によっては特権のある) トランザクションでプリコンパイルを呼び出すときに実行することもできます。 これを使用して、非EVMメカニズムがEVMにコールバックできるようにすることができます。

このデザインは、新規または変更されたプリコンパイルに加えて、新規または変更されたオペコードをサポートするように変更できます。 プリコンパイルのみでも、この設計は非常に強力です。 例えば：

· used_precompile_addresses を設定し、その状態のアカウントオブジェクトに特定のフラグが設定された通常のアカウントアドレスのリストを含め、正しく構築されたことを証明する SNARK を作成することで、コントラクトのコードを EVM または WASM(または他の VM)で記述できる Arbitrum Stylus スタイルの機能をサポートできます。 特権トランザクションを使用して、WASMアカウントをEVMにコールバックできます。

· 複数のEVMによって実行される入力/出力トランスクリプションと特権トランザクションが正しく一致していることを確認するための外部チェックを追加することで、複数のEVMが同期チャネルを介して相互に通信する並列システムを実証できます。

· 4つ目のタイプのZK-EVMは、Solidityなどの高級言語をSNARKに適したVMに直接変換するものと、それをEVMコードにコンパイルしてZK-EVMで実行するものなど、複数の実装を持つことで機能します。 2 番目の (必然的に遅くなる) 実装は、エラー証明者がエラーがあることを示すトランザクションを送信し、2 つによって異なる処理のトランザクションを提供できる場合にのみ実行されます。

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

拡張機能: ステートフル構成証明者のサポート

上記の設計の課題の 1 つは、完全にステートレスであるため、データ利用の点で効率が低下することです。 ステートフル圧縮をサポートすることで、ERC 20送信は、理想的なデータ圧縮を使用して、ステートレス圧縮のみを使用する場合よりも最大3倍のスペースを節約できます。

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

ZK-EVM 機能をステートフルにするには、次の 2 つのオプションがあります。

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

2. ブロックで生成されたレシート R の BLOB コミットメントを (σpre,σpost, Proof) タプルに追加します。 ブロック、証人、レシート、または通常の EIP-4844 BLOB トランザクションを表すものを含む、以前に生成または使用された BLOB Promise は、ZKEVMClaimTransaction で参照し、その実行中にアクセスできます (おそらく一連の命令を介して: "コミット i のバイト N をブロック + witness データの位置 j に挿入します… N+k− 1 ")。

(1) 基本的には、ステートレスなEVM検証を固めるのではなく、EVMの子チェーンを固めるということです。 (2) 基本的に、以前に使用または生成された BLOB をディクショナリとして使用する組み込みの最小限のステートフル圧縮アルゴリズムを作成します。 いずれも、プルーフノードのみであるプルーフノードにより多くの情報を格納する負担が加わり、(2)の場合、(1)の場合よりもこの負担を一定時間に制限しやすくなります。

クローズド・マルチプルーフ・システムとオフチェーン・データの議論

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

しかし、クローズドなマルチプルーバーシステムは、ガバナンスの複雑さを増し、監査可能性を低下させるため、高コストとこれらのメリットのトレードオフになります。

ZK-EVMをプロトコル機能として確立した場合、「L2プロジェクト」の継続的な役割はどのようなものになるのでしょうか。

このプロトコルは、L2チームが現在実装しているEVM検証機能を処理しますが、L2プロジェクトは引き続き多くの重要な機能を担当します。

迅速な事前確認:単一スロットのファイナリティはL1スロットの速度を低下させる可能性があり、L2プロジェクトではすでに、L2独自のセキュリティに裏打ちされた「事前確認」を、1スロットよりもはるかに低いレイテンシーでユーザーに提供しています。 このサービスは、引き続き純粋なL2責任となります。

MEV軽減戦略:これには、暗号化されたmempool、レピュテーションベースのシーケンシャル選択、およびL1が実装に消極的なその他の機能が含まれる場合があります。

EVM の拡張: L2 プロジェクトでは、EVM の大幅な拡張を組み込んで、ユーザーに大きな価値を提供することができます。 これには、「ほぼEVM」と、Arbitrum StylusのWASMサポートやSNARKの親しみやすいカイロ言語など、根本的に異なるアプローチの両方が含まれます。

ユーザーと開発者の利便性:L2チームは、ユーザーやプロジェクトをエコシステムに引き付け、歓迎されていると感じてもらうために多くの作業を行い、ネットワーク内でMEVと輻輳料金を取得することで報酬を得ています。 この関係はこれからも続くでしょう。

元の記事へのリンク