文:ヴィタリック・ブテリンコンピレーション:1912212.eth、Foresight Newsオプティミスティック・ロールアップやZKロールアップなど、ETH上のレイヤー2 EVMプロトコルは、EVM検証に依存しています。 ただし、これには巨大なコードベースを信頼する必要があり、そのコードベースにバグがある場合、これらのVMはハッキングされるリスクがあります。 さらに、これは、L1 EVMと完全に同等にしたいZK-EVMでさえ、L1 EVMへの変更を独自のEVMプラクティスに複製するために、何らかの形のガバナンスが必要であることを意味します。これらのプロジェクトはETH Workshopプロトコルにすでに存在する機能を複製しており、ETHガバナンスはすでにアップグレードとバグの修正を担当しているため、この状況は理想的ではありません。 ZK-EVMは、レイヤー1 ETHワークショップブロックの検証と本質的に同じジョブです!さらに、今後数年間で、ライトクライアントはますます強力になり、まもなくZK-SNARKを使用してレイヤー1 EVMの実行を完全に検証する段階に達すると予想されます。 その時点で、ETHネットワークは内蔵のZK-EVMを効果的に構築します。 そこで疑問が湧いてくるのが、ZK-EVM自体もロールアップに適したものにしてはどうかということです。本稿では、実装可能な「ビルトインZK-EVM」バージョンをいくつか紹介し、トレードオフと設計上の課題、および特定の方向に進まない理由について説明します。 プロトコル機能を実装する利点は、エコシステムに任せて基盤となるプロトコルをシンプルに保つことの利点と比較検討する必要があります。### 内蔵のZK-EVMに求める主な機能は何ですか?*基本機能:ETHブロックを検証します。 プロトコル関数 (オペコード、プリコンパイル、またはその他のメカニズムのいずれであるかはまだ明確ではありません) は、少なくとも 1 つの事前状態ルート、1 つのブロック、および 1 つの状態後ルートを入力として受け入れ、状態後ルートが実際にブロックの実行結果であることを確認する必要があります。* ETH Squareの複数のクライアントと互換性があります。 つまり、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 自体ではなく、外部から提供されたテーブルによって処理されるビット・フィールド、オペコード・リスト、またはアドレスを呼び出し側が指定できる ZK-EVM 関数を設計することで実現できます。 また、ガス代をある程度編集できるようにすることもできます。### 「オープン」と「クローズド」のマルチクライアントシステム「マルチクライアント哲学」は、おそらくこのリストの中で最も主観的な要件です。 それを放棄してZK-SNARKスキームに焦点を当てるという選択肢もあり、それは設計を簡素化するが、その代償として、ETH Workshopにとってより大きな「哲学的ターニングポイント」となり(ETH Workshopの長年のマルチクライアント哲学を事実上放棄しているため)、より大きなリスクをもたらすことになる。 将来、形式検証技術が良くなると、この道を選んだ方が良いのかもしれませんが、今はリスクが大きすぎるようです。もう 1 つのオプションは、構成証明システムの固定セットがプロトコルで認識されているクローズド マルチクライアント システムです。 たとえば、PSE ZK-EVM、Polygon ZK-EVM、Kakarot の 3 つの ZK-EVM を使用することにします。 ブロックが有効であるためには、これら3つのうち2つによって提供される証明が必要です。 これは単一の証明システムよりはましですが、ユーザーは存在する証明システムごとにバリデーターを維持しなければならず、新しい証明システムなどを組み込むための政治的ガバナンスプロセスが必然的に発生するため、システムの適応性が低下します。このことから、私は、証明が「ブロックの外側」に配置され、クライアントによって個別に検証されるオープンなマルチクライアントシステムを好むようになりました。 個々のユーザーは、少なくとも 1 人の証明者がその構成証明システムの証明を作成する限り、ブロックを検証する任意のクライアントを使用できます。 構成証明システムは、プロトコル ガバナンス プロセスを納得させるのではなく、ユーザーに実行を納得させることで影響力を獲得します。 ただし、このアプローチでは、後で説明するように、複雑さのコストが高くなります。### ZK-EVMの実装からどのような重要な特性を得たいのか?基本的な機能の正確性と安全性の保証に加えて、最も重要な属性は速度です。 ZK-EVM機能は非同期で、Nスロットの遅延後に宣言された各回答のみを返すプロトコル内で設計できますが、各ブロックで何が起こっても数秒で証明が生成されることを確実に保証できれば、問題ははるかに簡単になります。今日では、ETHブロックの証明を生成するのに数分から数時間かかりますが、大量並列化を防ぐ理論的な理由はないことがわかっています:ブロックの実行の個々の部分を個別に証明するのに十分なGPUをいつでも組み合わせて、再帰的なSNARKを使用して証明をまとめることができます。 さらに、FPGAとASICによるハードウェアアクセラレーションは、プルーフをさらに最適化するのに役立ちます。 しかし、ここまでたどり着くことは、過小評価してはならない大きなエンジニアリング上の課題です。### ZK-EVM の機能は、プロトコル内でどのようになるでしょうか。EIP-4844 BLOB トランザクションと同様に、ZK-EVM 要求を含む新しいトランザクションの種類が導入されました。実際には、サイドロードを 2 つの別々のサイドロード (1 つは BLOB 用、もう 1 つは配達確認用) に分割し、配達確認の種類ごとに個別のサブネット (および BLOB 用の追加のサブネット) を設定する必要があることに注意してください。コンセンサスレイヤーでは、クライアントがブロック内の各クレームの有効な証拠を見た場合にのみブロックを受け入れる検証ルールを追加しました。 証明はZK-SNARKでなければならず、トランザクション\_and\_witness\_blobsの連結が(Block, Witness)ペアのシリアル化であり、ブロックがWitnessでpre\_state\_rootで実行されることを証明します(i) 有効であり、かつ(ii)正しいpost\_state\_rootを出力します。 おそらく、クライアントは、M-of-Nの複数のタイプの証明を待つことを選択できます。ここで重要なのは、ブロックの実行自体は、ZKEVMClaimTransactionオブジェクト(σpre、σpost、Proof)で提供されるトリプルとともにチェックする必要があるトリプルの1つと考えることができるということです。 その結果、ユーザーの ZK-EVM 実装は実行クライアントを置き換えることができ、実行クライアントは引き続き実行されます(i) 証明者およびブロックビルダー(ii)ローカルで使用するためのデータのインデックス作成と保存を重視するノード。さらに、このアーキテクチャでは実行と検証が分離されるため、ETH エコシステムのさまざまな役割に対して柔軟性と効率性が高まる可能性があります。 たとえば、証明者は実行の詳細を気にせずに証明の生成に集中できますが、実行クライアントは、高速同期や高度なインデックス作成機能など、特定のユーザーのニーズを満たすように最適化できます。### 検証と再構成証明PSE ZK-EVMとPolygon ZK-EVMを使用する2つのETHクライアントがあり、この時点で両方の実装が5秒未満でETHブロックの実行を証明できるところまで進化しており、各証明システムに対して、証明を生成するのに十分な独立したボランティアがハードウェアを実行しているとします。残念ながら、個々のプルーフ・オブ・ザ・ボックス・システムは形式化されていないため、プロトコルでインセンティブを与えることはできませんが、プルーフの実行コストは研究開発に比べて低くなると予想されるため、公共財に資金を提供する機関を通じてプルーファーに簡単に資金を提供することができます。例えば、誰かがZKEvmClaimNetworkTransactionを公開したが、PSE ZK-EVMバージョンの証明しか公開していないとします。 Polygon ZK-EVMのProofノードはこれを見て、Polygon ZK-EVMのProof とともにオブジェクトを計算して再公開します。これにより、ブロックを受け入れる最も早い正直なノードと、同じブロックを受け入れる最新の正直なノードの間の合計最大遅延がδから2δ+Tproveに増加します(ここではTprove<5sを想定)。しかし、良いニュースは、シングルスロットのファイナリティを採用すれば、SSFに内在する複数ラウンドのコンセンサスレイテンシーとともに、この追加の遅延をほぼ確実に「パイプライン化」できることです。 たとえば、この 4 スロットの提案では、「ヘッド投票」ステップはベースブロックの有効性をチェックするだけでよいかもしれませんが、「凍結して確認する」ステップでは証明の存在が必要です。### 拡張機能: "almost-EVMs" のサポートZK-EVM機能の望ましい目標は、「ほぼEVM」、つまり追加機能を備えたEVMをサポートすることです。 これには、新しいプリコンパイル、新しいオペコード、EVMまたは完全に異なるVM(Arbitrum Stylusなど)にできるコントラクト、または同期クロスコミュニケーションを備えた複数の並列EVMが含まれます。いくつかの変更は簡単な方法でサポートできます:ZKEVMClaimTransactionが修正されたEVMルールの完全な記述を渡すことを可能にする言語を定義することができます。 これは、次の状況で使用できます。1.カスタマイズされたガスコストテーブル(ユーザーはガスコストを削減することはできませんが、増やすことはできます)2.特定のオペコードを無効にします3.ブロック番号を設定します(これは、ハードフォークによって異なるルールがあることを意味します)4. フラグを設定して、L2 用には既に標準化されているが L1 用には標準化されていない EVM 変更のフル セット、またはその他の単純な変更を有効にします。たとえば、新しいプリコンパイル済み(またはオペコード)を導入することで、ユーザーがよりオープンな方法で新しい機能を追加できるようにするために、ZKEVMClaimNetworkTransactionのblobセクションにプリコンパイルされた入力/出力レコードを含める方法を追加できます。class PrecompileInputOutputTran(Container):used\_precompile\_addresses:リスト[Address][VersionedHash]入力\_commitments: リスト[Bytes]outputs: リストEVM の実行は次のように変更されます。 inputs という配列は空として初期化されます。 used\_precompile\_addresses のアドレスが呼び出されるたびに、InputsRecord(callee\_address, Gas, input\_calldata) オブジェクトを入力に追加し、呼び出された RETURNDATA を出力に設定します[i]。 最後に、used\_precompile\_addresses が合計で len(outputs) 呼び出されたこと、および inputs\_commitments が、入力の SSZ シリアル化に対する結果の BLOB のコミットメントの結果と一致することを確認します。 inputs\_commitmentsを公開する目的は、外部SNARKが入力と出力の関係を証明できるようにすることです。入力と出力の非対称性 (入力はハッシュに格納され、出力は指定する必要があるバイトに格納される) に注意してください。 これは、入力のみを見てEVMを理解しているクライアントが実行する必要があるためです。 EVMの実行では、すでに入力が生成されているため、生成された入力が宣言された入力と一致するかどうかをチェックするだけでよく、ハッシュチェックのみが必要です。 ただし、出力は完全に提供される必要があるため、データの可用性が使用可能である必要があります。もう1つの便利な機能は、任意の送信者アカウントから「特権トランザクション」を呼び出せるようにすることです。 これらのトランザクションは、他の 2 つのトランザクション間で、またはプリコンパイルの呼び出し中に別の (場合によっては特権のある) トランザクション内で実行できます。 これを使用して、非EVMメカニズムがEVMにコールバックできるようにすることができます。デザインは、新規または変更されたプリコンパイルに加えて、新規または変更されたオペコードをサポートするように変更できます。 プリコンパイルのみでも、デザインは非常に強力です。 例えば：Arbitrum Stylusのような機能は、used\_precompile\_addressesを設定して、ステート内のアカウントオブジェクトに特定のフラグが設定された通常のアカウントアドレスのリストを含めるように設定し、コントラクトがEVMまたはWASM(または他のVM)にコードを書き込むことができる、正しく構築されていることを証明するSNARKを生成することでサポートできます。 特権トランザクションを使用して、WASM アカウントが EVM をコールバックできるようにすることができます。複数のEVMによって実行される入出力レコードと特権トランザクションが正しい方法で一致していることを確認するための外部チェックを追加することで、複数のEVMが同期チャネルを介して相互に通信する並列システムを実証できます。タイプ4のZK-EVMは、Solidityなどの高級言語をSNARK対応のVMに直接変換するものと、EVMコードにコンパイルして規定のZK-EVMで実行するものなど、複数の実装を持つことで機能します。 2番目の(必然的に遅くなる)実装は、失敗証明者がエラーがあると主張するトランザクションを送信し、2つが異なるトランザクションを処理することを提供できる場合にのみ実行できます。純粋な非同期 VM を実装するには、すべての呼び出しに 0 を返し、ブロックの末尾に追加される特権トランザクションに呼び出しをマッピングします。### 拡張機能: 状態証明のサポート上記の設計の課題は、完全にステートレスであるため、データ効率の点で劣ることです。 理想的なデータ圧縮では、ステートフル圧縮により、ステートレス圧縮のみの場合と比較して、ERC20送信のスペース効率が最大3倍向上します。これに加えて、ステートフルなEVMは、witnessデータを提供する必要はありません。 どちらの場合も、原則は同じで、EVMの以前の実行によって入力または生成されたデータが利用可能であることがすでにわかっているのに、データが利用可能であるように要求するのは無駄です。 **ZK-EVM 機能をステートフルにするには、次の 2 つのオプションがあります。σpre が null であるか、データが使用可能なキーと値の事前に宣言されたリスト、または以前に実行された σpost である必要があります。ブロックによって生成されたレシート R の (σpre, σpost, proof) タプルに BLOB コミットメントを追加します。 ブロック、監視、受信、または通常の EIP-4844 BLOB トランザクションを表すコミットメントを含む、ZKEVMClaimTransaction で参照され、実行中にアクセスできる、以前に生成または使用された BLOB コミットメント (一連の命令で参照できる時間制限がある場合があります: "コミット 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 は既に独自のセキュリティを備えた事前確認に裏打ちされたサービスをユーザーに提供しており、レイテンシーは 1 スロットよりもはるかに短くなっています。 このサービスは、引き続きL2の単独の責任となります。* MEV緩和戦略:これには、暗号化されたmempool、レピュテーションベースのシーケンシャル選択などの機能が含まれる場合がありますが、L1は実装に消極的です。* EVM の拡張: Tier 2 プロジェクトは、ユーザーに重要な価値を提供する EVM に大幅な拡張を導入できます。 これには、「ほぼEVM」や、Arbitrum StylusのWASMサポートやSNARKの親しみやすいカイロ言語など、まったく異なるアプローチが含まれます。ユーザーと開発者にとっての利便性: Tier 2 チームは、ユーザーやプロジェクトをエコシステムに引き付け、歓迎されていると感じてもらうために多大な努力を払っています。 この関係はこれからも続くでしょう。
Vitalik: さまざまな「ビルトイン ZK-EVM」バージョン・タイプと設計上の課題について説明します。
文:ヴィタリック・ブテリン
コンピレーション:1912212.eth、Foresight News
オプティミスティック・ロールアップやZKロールアップなど、ETH上のレイヤー2 EVMプロトコルは、EVM検証に依存しています。 ただし、これには巨大なコードベースを信頼する必要があり、そのコードベースにバグがある場合、これらのVMはハッキングされるリスクがあります。 さらに、これは、L1 EVMと完全に同等にしたいZK-EVMでさえ、L1 EVMへの変更を独自のEVMプラクティスに複製するために、何らかの形のガバナンスが必要であることを意味します。
これらのプロジェクトはETH Workshopプロトコルにすでに存在する機能を複製しており、ETHガバナンスはすでにアップグレードとバグの修正を担当しているため、この状況は理想的ではありません。 ZK-EVMは、レイヤー1 ETHワークショップブロックの検証と本質的に同じジョブです!さらに、今後数年間で、ライトクライアントはますます強力になり、まもなくZK-SNARKを使用してレイヤー1 EVMの実行を完全に検証する段階に達すると予想されます。 その時点で、ETHネットワークは内蔵のZK-EVMを効果的に構築します。 そこで疑問が湧いてくるのが、ZK-EVM自体もロールアップに適したものにしてはどうかということです。
本稿では、実装可能な「ビルトインZK-EVM」バージョンをいくつか紹介し、トレードオフと設計上の課題、および特定の方向に進まない理由について説明します。 プロトコル機能を実装する利点は、エコシステムに任せて基盤となるプロトコルをシンプルに保つことの利点と比較検討する必要があります。
内蔵のZK-EVMに求める主な機能は何ですか?
*基本機能:ETHブロックを検証します。 プロトコル関数 (オペコード、プリコンパイル、またはその他のメカニズムのいずれであるかはまだ明確ではありません) は、少なくとも 1 つの事前状態ルート、1 つのブロック、および 1 つの状態後ルートを入力として受け入れ、状態後ルートが実際にブロックの実行結果であることを確認する必要があります。
「オープン」と「クローズド」のマルチクライアントシステム
「マルチクライアント哲学」は、おそらくこのリストの中で最も主観的な要件です。 それを放棄してZK-SNARKスキームに焦点を当てるという選択肢もあり、それは設計を簡素化するが、その代償として、ETH Workshopにとってより大きな「哲学的ターニングポイント」となり(ETH Workshopの長年のマルチクライアント哲学を事実上放棄しているため)、より大きなリスクをもたらすことになる。 将来、形式検証技術が良くなると、この道を選んだ方が良いのかもしれませんが、今はリスクが大きすぎるようです。
もう 1 つのオプションは、構成証明システムの固定セットがプロトコルで認識されているクローズド マルチクライアント システムです。 たとえば、PSE ZK-EVM、Polygon ZK-EVM、Kakarot の 3 つの ZK-EVM を使用することにします。 ブロックが有効であるためには、これら3つのうち2つによって提供される証明が必要です。 これは単一の証明システムよりはましですが、ユーザーは存在する証明システムごとにバリデーターを維持しなければならず、新しい証明システムなどを組み込むための政治的ガバナンスプロセスが必然的に発生するため、システムの適応性が低下します。
このことから、私は、証明が「ブロックの外側」に配置され、クライアントによって個別に検証されるオープンなマルチクライアントシステムを好むようになりました。 個々のユーザーは、少なくとも 1 人の証明者がその構成証明システムの証明を作成する限り、ブロックを検証する任意のクライアントを使用できます。 構成証明システムは、プロトコル ガバナンス プロセスを納得させるのではなく、ユーザーに実行を納得させることで影響力を獲得します。 ただし、このアプローチでは、後で説明するように、複雑さのコストが高くなります。
ZK-EVMの実装からどのような重要な特性を得たいのか?
基本的な機能の正確性と安全性の保証に加えて、最も重要な属性は速度です。 ZK-EVM機能は非同期で、Nスロットの遅延後に宣言された各回答のみを返すプロトコル内で設計できますが、各ブロックで何が起こっても数秒で証明が生成されることを確実に保証できれば、問題ははるかに簡単になります。
今日では、ETHブロックの証明を生成するのに数分から数時間かかりますが、大量並列化を防ぐ理論的な理由はないことがわかっています:ブロックの実行の個々の部分を個別に証明するのに十分なGPUをいつでも組み合わせて、再帰的なSNARKを使用して証明をまとめることができます。 さらに、FPGAとASICによるハードウェアアクセラレーションは、プルーフをさらに最適化するのに役立ちます。 しかし、ここまでたどり着くことは、過小評価してはならない大きなエンジニアリング上の課題です。
ZK-EVM の機能は、プロトコル内でどのようになるでしょうか。
EIP-4844 BLOB トランザクションと同様に、ZK-EVM 要求を含む新しいトランザクションの種類が導入されました。
実際には、サイドロードを 2 つの別々のサイドロード (1 つは BLOB 用、もう 1 つは配達確認用) に分割し、配達確認の種類ごとに個別のサブネット (および BLOB 用の追加のサブネット) を設定する必要があることに注意してください。
コンセンサスレイヤーでは、クライアントがブロック内の各クレームの有効な証拠を見た場合にのみブロックを受け入れる検証ルールを追加しました。 証明はZK-SNARKでなければならず、トランザクション_and_witness_blobsの連結が(Block, Witness)ペアのシリアル化であり、ブロックがWitnessでpre_state_rootで実行されることを証明します
(i) 有効であり、かつ
(ii)正しいpost_state_rootを出力します。 おそらく、クライアントは、M-of-Nの複数のタイプの証明を待つことを選択できます。
ここで重要なのは、ブロックの実行自体は、ZKEVMClaimTransactionオブジェクト(σpre、σpost、Proof)で提供されるトリプルとともにチェックする必要があるトリプルの1つと考えることができるということです。 その結果、ユーザーの ZK-EVM 実装は実行クライアントを置き換えることができ、実行クライアントは引き続き実行されます
(i) 証明者およびブロックビルダー
(ii)ローカルで使用するためのデータのインデックス作成と保存を重視するノード。
さらに、このアーキテクチャでは実行と検証が分離されるため、ETH エコシステムのさまざまな役割に対して柔軟性と効率性が高まる可能性があります。 たとえば、証明者は実行の詳細を気にせずに証明の生成に集中できますが、実行クライアントは、高速同期や高度なインデックス作成機能など、特定のユーザーのニーズを満たすように最適化できます。
検証と再構成証明
PSE ZK-EVMとPolygon ZK-EVMを使用する2つのETHクライアントがあり、この時点で両方の実装が5秒未満でETHブロックの実行を証明できるところまで進化しており、各証明システムに対して、証明を生成するのに十分な独立したボランティアがハードウェアを実行しているとします。
残念ながら、個々のプルーフ・オブ・ザ・ボックス・システムは形式化されていないため、プロトコルでインセンティブを与えることはできませんが、プルーフの実行コストは研究開発に比べて低くなると予想されるため、公共財に資金を提供する機関を通じてプルーファーに簡単に資金を提供することができます。
例えば、誰かがZKEvmClaimNetworkTransactionを公開したが、PSE ZK-EVMバージョンの証明しか公開していないとします。 Polygon ZK-EVMのProofノードはこれを見て、Polygon ZK-EVMのProof とともにオブジェクトを計算して再公開します。
これにより、ブロックを受け入れる最も早い正直なノードと、同じブロックを受け入れる最新の正直なノードの間の合計最大遅延がδから2δ+Tproveに増加します(ここではTprove<5sを想定)。
しかし、良いニュースは、シングルスロットのファイナリティを採用すれば、SSFに内在する複数ラウンドのコンセンサスレイテンシーとともに、この追加の遅延をほぼ確実に「パイプライン化」できることです。 たとえば、この 4 スロットの提案では、「ヘッド投票」ステップはベースブロックの有効性をチェックするだけでよいかもしれませんが、「凍結して確認する」ステップでは証明の存在が必要です。
拡張機能: “almost-EVMs” のサポート
ZK-EVM機能の望ましい目標は、「ほぼEVM」、つまり追加機能を備えたEVMをサポートすることです。 これには、新しいプリコンパイル、新しいオペコード、EVMまたは完全に異なるVM(Arbitrum Stylusなど)にできるコントラクト、または同期クロスコミュニケーションを備えた複数の並列EVMが含まれます。
いくつかの変更は簡単な方法でサポートできます:ZKEVMClaimTransactionが修正されたEVMルールの完全な記述を渡すことを可能にする言語を定義することができます。 これは、次の状況で使用できます。
1.カスタマイズされたガスコストテーブル(ユーザーはガスコストを削減することはできませんが、増やすことはできます) 2.特定のオペコードを無効にします 3.ブロック番号を設定します(これは、ハードフォークによって異なるルールがあることを意味します) 4. フラグを設定して、L2 用には既に標準化されているが L1 用には標準化されていない EVM 変更のフル セット、またはその他の単純な変更を有効にします。
たとえば、新しいプリコンパイル済み(またはオペコード)を導入することで、ユーザーがよりオープンな方法で新しい機能を追加できるようにするために、ZKEVMClaimNetworkTransactionのblobセクションにプリコンパイルされた入力/出力レコードを含める方法を追加できます。
class PrecompileInputOutputTran(Container):used_precompile_addresses:リスト[Address][VersionedHash]入力_commitments: リスト[Bytes]outputs: リスト
EVM の実行は次のように変更されます。 inputs という配列は空として初期化されます。 used_precompile_addresses のアドレスが呼び出されるたびに、InputsRecord(callee_address, Gas, input_calldata) オブジェクトを入力に追加し、呼び出された RETURNDATA を出力に設定します[i]。 最後に、used_precompile_addresses が合計で len(outputs) 呼び出されたこと、および inputs_commitments が、入力の SSZ シリアル化に対する結果の BLOB のコミットメントの結果と一致することを確認します。 inputs_commitmentsを公開する目的は、外部SNARKが入力と出力の関係を証明できるようにすることです。
入力と出力の非対称性 (入力はハッシュに格納され、出力は指定する必要があるバイトに格納される) に注意してください。 これは、入力のみを見てEVMを理解しているクライアントが実行する必要があるためです。 EVMの実行では、すでに入力が生成されているため、生成された入力が宣言された入力と一致するかどうかをチェックするだけでよく、ハッシュチェックのみが必要です。 ただし、出力は完全に提供される必要があるため、データの可用性が使用可能である必要があります。
もう1つの便利な機能は、任意の送信者アカウントから「特権トランザクション」を呼び出せるようにすることです。 これらのトランザクションは、他の 2 つのトランザクション間で、またはプリコンパイルの呼び出し中に別の (場合によっては特権のある) トランザクション内で実行できます。 これを使用して、非EVMメカニズムがEVMにコールバックできるようにすることができます。
デザインは、新規または変更されたプリコンパイルに加えて、新規または変更されたオペコードをサポートするように変更できます。 プリコンパイルのみでも、デザインは非常に強力です。 例えば：
Arbitrum Stylusのような機能は、used_precompile_addressesを設定して、ステート内のアカウントオブジェクトに特定のフラグが設定された通常のアカウントアドレスのリストを含めるように設定し、コントラクトがEVMまたはWASM(または他のVM)にコードを書き込むことができる、正しく構築されていることを証明するSNARKを生成することでサポートできます。 特権トランザクションを使用して、WASM アカウントが EVM をコールバックできるようにすることができます。
複数のEVMによって実行される入出力レコードと特権トランザクションが正しい方法で一致していることを確認するための外部チェックを追加することで、複数のEVMが同期チャネルを介して相互に通信する並列システムを実証できます。
タイプ4のZK-EVMは、Solidityなどの高級言語をSNARK対応のVMに直接変換するものと、EVMコードにコンパイルして規定のZK-EVMで実行するものなど、複数の実装を持つことで機能します。 2番目の(必然的に遅くなる)実装は、失敗証明者がエラーがあると主張するトランザクションを送信し、2つが異なるトランザクションを処理することを提供できる場合にのみ実行できます。
純粋な非同期 VM を実装するには、すべての呼び出しに 0 を返し、ブロックの末尾に追加される特権トランザクションに呼び出しをマッピングします。
拡張機能: 状態証明のサポート
上記の設計の課題は、完全にステートレスであるため、データ効率の点で劣ることです。 理想的なデータ圧縮では、ステートフル圧縮により、ステートレス圧縮のみの場合と比較して、ERC20送信のスペース効率が最大3倍向上します。
これに加えて、ステートフルなEVMは、witnessデータを提供する必要はありません。 どちらの場合も、原則は同じで、EVMの以前の実行によって入力または生成されたデータが利用可能であることがすでにわかっているのに、データが利用可能であるように要求するのは無駄です。 **
ZK-EVM 機能をステートフルにするには、次の 2 つのオプションがあります。
σpre が null であるか、データが使用可能なキーと値の事前に宣言されたリスト、または以前に実行された σpost である必要があります。
ブロックによって生成されたレシート R の (σpre, σpost, proof) タプルに BLOB コミットメントを追加します。 ブロック、監視、受信、または通常の EIP-4844 BLOB トランザクションを表すコミットメントを含む、ZKEVMClaimTransaction で参照され、実行中にアクセスできる、以前に生成または使用された BLOB コミットメント (一連の命令で参照できる時間制限がある場合があります: “コミット 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 プロジェクトは引き続き多くの重要な機能を担当します。