ヴィタリック：ZK-EVMがイーサL1にカプセル化されるとどうなるのか？

原文：https://notes.ethereum.org/@vbuterin/enshrined_zk_evm
翻訳者：Dengchain Community^[1)翻訳チーム

Etherの上に構築されたOptimistic RollupsやZK RollupsなどのLayer2 EVMプロトコルは、EVM検証に依存しています。しかし、これには大規模なコードベースを信頼する必要があり、コードベースに脆弱性がある場合、これらのVMはハッキングされる危険性があります。さらに、L1 EVMと完全に同等であることを意図しているZK-EVMでさえ、L1 EVMから独自のEVM実装への変更を複製するために、何らかの形のガバナンス機構を必要とします。

これらのプロジェクトはイーサネット・プロトコルにすでに存在する機能を複製しており、イーサネットのガバナンスはすでにアップグレードとバグ修正を担当しているため、この状況は理想的ではありません！さらに、今後数年間で、ライトクライアント ^[2] はますます強力になり、やがて ZK-SNARKs を使用して L1 EVM の実行を完全に検証するようになると予想しています。その時点で、EtherNet ネットワークは事実上 ZK-EVM を内蔵することになります。したがって、なぜ ZK-EVM をネイティブでロールアップできるようにしないのかという疑問が生じます。

この記事では、実装可能なカプセル化 ZK-EVM のいくつかのバリエーションについて説明し、トレードオフと設計上の課題、および特定の方向を取らない理由について詳しく説明します。プロトコル機能を実装する利点は、エコシステムから離れ、基礎となるプロトコルをシンプルに保つ利点と天秤にかけるべきです。

ZK-EVMのパッケージ化で得たい主な機能は何ですか?

基本機能: イーサネット ブロックの検証。プロトコル機能 (それがオペコードであるか、プリコンパイルであるか、または他のメカニズムであるかは未定) は、入力として (少なくとも) プリステート ルート、ブロック、およびポストステート ルートを受け入れ、ポストステート ルートが実際にプリステート ルート上でブロックを実行した結果であることを検証しなければなりません。

イーサネットのマルチクライアント哲学^[3]との互換性は、単一の証明システムの使用を避け、その代わりにクライアントごとに異なる証明システムを許容することを意味します。

• データ可用性の要件: カプセル化されたZK-EVMを介して実行されるEVMの実行について、以下のことを意味します。EVMの実行では、基礎となるデータの可用性を保証したい^[4]ので、別の証明システムを使用する証明者は実行を再証明でき、その証明システムに依存するクライアントは新しく生成された証明を検証できる。

• 証明はEVMとブロックデータ構造の外部に格納される：ZK-EVM機能はSNARKをEVMへの直接入力として受け取りません。その理由は、クライアントによって期待するSNARKの種類が異なるからです。その代わりに、ブロブ検証に似ているかもしれません。トランザクションは、プルーフを必要とするステートメント(プレステート、ブロックボディ、ポストステート)を含むことができ、オペコードまたはプリコンパイルはこれらのステートメントのコンテンツにアクセスすることができ、クライアントのコンセンサスルールは、これらのステートメントのそれぞれについて、データの可用性とブロック内のプルーフの存在をチェックします。

監査可能性：いずれかの実行が証明された場合、ユーザーや開発者がそれをチェックできるように、基礎となるデータが利用可能であることを望みます。事実上、これはデータの可用性要件が重要であるもう1つの理由を追加します。

スケーラビリティ: 特定のZK-EVMシナリオで脆弱性が発見された場合、私たちはそれを素早く、ハードフォークを必要とせずに修正できるようにしたいと考えています。そのため、EVMとブロックデータ構造の外部にプルーフを格納することの重要性が高まります。

ALMOST-EVMのサポート: L2の魅力の1つは、実行レベルでイノベーションを起こし、EVMをスケールアップできることです。ある L2 の VM が EVM とわずかに異なるだけである場合、L2 の EVM と同じ部分はネイティブのプロトコル内 ZK-EVM を使用し、EVM と異なる部分については独自のコードに依存するだけでよいと思います。これは、ZK-EVMの機能を設計することで、呼び出し元がビットフィールド、オペコード、アドレスリストを指定し、EVM自体ではなく、外部から供給されるテーブルで処理できるようにすることで実現できます。また、限られた範囲でガスコストをカスタマイズ可能にすることもできます。

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

マルチクライアントのアイデアは、おそらく上記のリストの中で最も主張の強い要件です。>.これを放棄して ZK-SNARK スキームに集中するという選択肢もあります。これは設計を単純化しますが、Ether にとってより大きな アイデアの転換 (Ether の長年にわたるマルチクライアント哲学を事実上放棄することになるため) となり、より大きなリスクをもたらすという代償を伴います。長期的な将来、たとえばフォーマルな検証技術がより洗練されたときなどには、このルートに進むほうがよいかもしれませんが、現時点ではリスクが大きすぎるように思われます。

もう1つの選択肢は、クローズド・マルチクライアント・システムで、そこではプロトコルで証明システムの固定セットが知られています。例えば、PSE ZK-EVM^[5] 、Polygon ZK-EVM^[6]  and  Kakarot^[7] の3つのZK-EVMを使用することにするかもしれない。ブロックが有効とみなされるには、これら3つのうち2つの証明が必要である。これは単一の証明システムよりは良いが、システムの適応性が低くなる。ユーザーは各証明システムのバリデータを維持しなければならず、例えば新しい証明システムを組み込んだ政治的ガバナンスプロセスに影響を与えることは避けられないからだ。

このことが、私が好むオープンなマルチクライアントシステムの原動力となり、そこでは証明は「ブロックの外」に置かれ、クライアントによって個別に検証されます。個々のユーザーは、その証明システムのために証明を作成する証明者がいる限り、好きなだけ多くのクライアントを使用してブロックを検証することができます。証明システムは、プロトコルのガバナンス・プロセスを説得するのではなく、ユーザーを説得して実行させることで影響力を得る。しかし、このアプローチには、後述するように、はるかに高い複雑性コストがかかります。

私たちがZK-EVM実装に求める主な機能は何でしょうか？

正しい機能とセキュリティの基本的な保証の他に、最も重要な機能は速度です。N スロット後にのみ各ステートメントの答えを返す非同期プロトコル内 ZK-EVM 関数を設計することは可能ですが、各ブロッククロックで何が起こっても独立であるように、証明が数秒で生成できることを確実に保証できれば、問題ははるかに簡単になります。

イーサリアムのブロックの証明を生成するには、今日では何分も何時間もかかりますが、大規模な並列化を妨げる理論的な理由はありません。再帰的 SNARK を使用して証明をマージすることができます。さらに、FPGAやASICによるハードウェアアクセラレーションは、証明を最適化するのに役立ちます。しかしながら、これを達成することは、過小評価されるべきではない重要な工学的課題です。

プロトコル内のZK-EVM機能は、具体的にどのようなものですか？

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

ZK-EVM 宣言を含む新しいトランザクションタイプを紹介します。align: left;">EIP-4844と同様に、メモリプールで伝播されるオブジェクトは、トランザクションの変更バージョンになります。

後者は前者に変換できますが、逆はできません。また、（EIP-4844^[9]で導入された）ブロック側のカーオブジェクトを拡張し、ブロック内で行われた宣言の証明リストを含むようにしました。

実際には、おそらく次のように分割したいことに注意してください。サイドカーを2つに分け、1つはブロブ用、もう1つは証明用とし、証明の種類ごとに別のサブネット(ブロブ用には別のサブネット)を用意することになるでしょう。

コンセンサスレイヤーでは、検証ルールを追加します：ブロックは、クライアントがブロック内の各ステートメントに対して有効な証明を見た場合のみ、受け入れることができます。その証明は、transaction_and_witness_blobの連結が(Block, Witness)ペアの直列化であること、およびpre_state_rootでのWitness(i)の使用が有効であることを証明するZK-SNARKでなければなりません。の使用が有効であり、(ii) 正しいpost_state_rootが出力されることです。潜在的に、クライアントはM-of-Nの複数のタイプの証明を待つことを選択することができます。

ここで言及すべき哲学的なポイントの1つは、ブロックの実行自体は、単に と同じタイプの証明が必要であるとみなすことができるということです。(σpre,σpost,Proof)トリプルの1つで、ZKEVMClaimTransactionオブジェクトで提供されるトリプルと一緒にチェックする必要があります。このように、ユーザーのZK-EVM実装は、実行クライアントを置き換えることができます。実行クライアントは、(i)証明者とブロックビルダー、および(ii)インデックスをローカルで使用し、データを保存することを気にするノードによって使用されます。

検証と再証明

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

残念ながら、個々の証明システムは含まれていないため、プロトコルでインセンティブを受けることはありません。しかし、研究開発に比べれば、証明者を運営するコストは低く、したがって、公共財の資金調達に使われているのと同じ汎用機関を通じて、単純に証明者に資金を提供することができます。証明者に資金を提供することができます。

誰かがZKEvmClaimNetworkTransactionを公開し、PSE ZK-EVMの証明バージョンだけを公開したとします。多角形ZK-EVMの証明ノードはこれを見て、証明を計算し、多角形ZK-EVMの証明を再公開します。

これにより、ブロックを受け入れる最も早い正直なノードと、最も遅い正直なノードとの間の最大遅延の合計が増加します。δから2δ+Tprove（ここではTprove <5sと仮定する）に増加します。

しかし、良いニュースは、シングルスロット最終決定性を使用する場合、SSFに固有のコンセンサスレイテンシの複数のラウンドと一緒に、この追加のレイテンシをほぼ確実に「パイプライン化」できるということです。たとえば、この4スロットの提案[10]では、「ヘッダー投票」ステップは基礎となるブロックの妥当性をチェックするだけでよいかもしれませんが、「凍結と確認」ステップは証明の存在を必要とします。

拡張: ほぼEVMのサポート

ZK-EVM機能の望ましい目標の1つは、ほぼEVMをサポートすることです。EVM です。

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

ガス料金テーブルをカスタマイズする（ユーザーはガス料金を減らすことはできませんが、増やすことはできます）

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

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

L1ではなくL2専用のEVM変更セット全体をアクティブにするフラグを設定する、または他の単純な変更

新しいプリコンパイラ(またはオペコード)を導入することで、ユーザーがよりオープンに新機能を導入できるようにするために、ZKEVMClaimNetworkTransactionのblobの一部として含まれるプリコンパイルされた入出力スクリプトを