Vitalik: さまざまなタイプの ZK-EVM の将来
原題：「The different types of ZK-EVMs》
原作者: ヴィタリック
オリジナルコンピレーション：ブロックユニコーン
原題：「
原作者: ヴィタリック
オリジナルコンピレーション：ブロックユニコーン
最近、「ZK-EVM」プロジェクトによる注目度の高い発表が数多く行われています。 Polygon は ZK-EVM プロジェクトをオープンソース化し、ZKSync は ZKSync 2.0 計画をリリースし、比較的新しい Scroll は最近 ZK-EVM をリリースしました。また、プライバシー チームと拡張探索チーム、Nicolas Liochon らのチームによる、EVM から Starkware の zk フレンドリー言語 Cairo のアルファ コンパイラに至るまでの継続的な取り組みもあり、もちろん、私が見逃してしまうプロジェクトもいくつかあります。
これらすべてのプロジェクトの中核となる目標は同じです。ZK-SNARK テクノロジーを使用してイーサリアムのようなトランザクション実行を暗号的に証明し、イーサリアム チェーン自体の検証を容易にするか、イーサリアムが提供するものと同様の (より近い) コンテンツを構築します。スケーラブルな ZK ロールアップ。ただし、これらのプロジェクトには微妙な違いがあり、実用性と速度の間にはトレードオフがあります。この投稿では、EVM 等価性のさまざまな「タイプ」の分類と、それぞれを実装する場合のメリットとコストについて説明します。
概要（図表形式）
タイプ 1 (イーサリアムと完全に同等)
最初のタイプの ZK-EVM は、イーサリアムと完全かつ妥協なく同等であることを目指しています。プルーフの生成を容易にするためにイーサリアム システムの一部を変更することはありません。どんなに周辺的なものであっても、ハッシュ、状態ツリー、トランザクション ツリー、プリコンパイル、またはその他のコンセンサス ロジックを置き換えるものではありません。
利点: 完全な互換性
私たちの目標は、現在行っているように Ethereum ブロック、または少なくとも実行レイヤーを検証できるようにすることです (つまり、ビーコン チェーンのコンセンサス ロジックは含まれていませんが、すべてのトランザクションの実行とスマート コントラクトとアカウントのロジックは含まれています)。
タイプ 1: ZK-EVM は、イーサネット レイヤ 1 自体の拡張性を高めるために最終的に必要なものです。長期的には、タイプ 2 またはタイプ 3 の ZK-EVM でテストされたイーサへの変更がイーサ自体に導入される可能性がありますが、そのような再設計には独自の複雑さが伴います。
タイプ 1: ZK-EVM は、ロールアップで多くのインフラストラクチャを再利用できるため、ロールアップにも最適です。たとえば、Etherum Execution クライアントは、ROLLUP ブロックの生成と処理にそのまま使用できます (または、少なくとも、フェッチが実装されたら再利用でき、その機能は ROLLUP への ETH デポジットをサポートするために再利用できます)。マネージャー、ブロック生成などのツールは非常に簡単に再利用できます。
デメリット: 検証に時間がかかる
イーサリアムはもともと zk との親和性を中心に設計されていないため、イーサリアム プロトコルの多くの部分で zk を検証するために大量の計算が必要になります。タイプ 1 はイーサリアムを正確に複製することを目的としているため、これらの非効率性を軽減する方法はありません。現在、イーサリアムブロックの証明の生成には何時間もかかります。この状況は、ベリファイアを大規模に並列化する賢いエンジニアリングによって、または長期的には ZK-SNARK ASIC によって軽減できます。
建設者は誰ですか?
プライバシーおよびスケーリング探査チーム ZK-EVM は、タイプ 1 ZK-EVM を構築しています。
タイプ 2 (完全に同等の EVM)
2 番目のタイプの ZK - EVM は EVM と完全に同等であることを目指していますが、イーサリアムと完全に同等ではありません。つまり、「内部」からはイーサリアムとまったく同じように見えますが、外部では、特にブロック構造や状態ツリーなどのデータ構造においていくつかの違いがあります。
目標は、既存のアプリケーションと完全な互換性を持たせることですが、開発を容易にし、プルーフをより速く生成できるようにイーサリアムに若干の変更を加えます。
利点: 仮想マシン レベルでの完全なピアツーピア
タイプ 2 ZK-EVM は、エーテルの状態などを保持するデータ構造を変更します。幸いなことに、これらの構造は EVM 自体から直接アクセスできないため、イーサリアム上で動作するアプリケーションは、ほとんどの場合タイプ 2 ZK-EVM ロールアップ上で動作します。 Etherum Execution クライアントをそのまま使用することはできませんが、いくつかの変更を加えることで使用でき、EVM デバッグ ツールやその他のほとんどの開発者インフラストラクチャに引き続きアクセスできます。
ただし、いくつかの例外があります。非互換性は、履歴トランザクション、領収書、または状態に関するクレームを検証するために履歴イーサ ブロックのマークル証明を検証するアプリケーション (たとえば、ブリッジがこれを行う場合があります) で発生します。 Keccak の ZK-EVM を別のハッシュ関数に置き換えると、これらの証明が壊れてしまいます。ただし、将来のイーサの変更 (Verkle Trees など) によって、イーサ自体でもそのようなアプリケーションが壊れる可能性があるため、私は一般的にこの方法でアプリケーションを構築しないことをお勧めします。イーサリアム自体に代わるより良い方法は、将来的に信頼できる履歴アクセスのプリコンパイルを追加することです。
短所: 検証時間は改善されましたが、依然として遅いです。
タイプ 2 ZK-EVM は、主に不必要に複雑で不親切な ZK 暗号化に依存するイーサリアム スタックの部分を削除することにより、タイプ 1 よりも高速な検証時間を実現します。特に、イーサリアムの Keccak および RLP ベースのマークル パトリシア ツリーを変更し、ブロックおよび受信構造を変更する可能性があります。タイプ 2 ZK-EVM は、Poseidon などの異なるハッシュ関数を使用する場合があります。もう 1 つの自然な変更は、コード ハッシュと keccak を保存するように状態ツリーを変更することです。これにより、EXTCODEHASH および EXTCODECOPY オペコードを処理するために検証ハッシュが必要なくなります。
これらの変更により検証時間が大幅に短縮されますが、すべての問題が解決されるわけではありません。 EVM には固有の非効率性と zk 非フレンドリー性があるため、EVM を現状のまま証明するプロセスは依然として時間がかかります。簡単な例はメモリです。MLOAD は、「位置合わせされていない」ブロック (開始と終了が 32 の倍数ではない) を含む任意の 32 バイト ブロックを読み取ることができるため、MLOAD は単純にブロックを読み取るものとして解釈できません。 2 つの連続するブロックを読み取り、ビット演算を実行して結果を結合します。
建設者は誰ですか?
Scroll の ZK-EVM プロジェクトは、Polygon Hermez と同様に、タイプ 2 ZK-EVM に向けて進んでいます。とはいえ、どちらのプロジェクトもまだ完了していません (ZKEVM の作業は完了していません)。特に、より複雑なプリコンパイルの多くはまだ実装されていません。したがって、現時点では両方のプロジェクトでタイプ 3 を検討するのが最適です。
タイプ 2.5 (EVM と同等、ガスコストを除く)
最悪の場合の検証時間を大幅に改善する 1 つの方法は、証明が難しい EVM の特定の操作のオーバーヘッド コストを大幅に増やすことです。これには、プリコンパイル、KECCAK オペコードが含まれる場合がありますが、呼び出し規約や、メモリ、ストレージ、または復元にアクセスする特定のモードも含まれます。
ガスコストを変更すると、開発者ツールの互換性が低下し、一部のアプリケーションが動作しなくなる可能性がありますが、一般に「より深い」EVM 変更よりもリスクが低いと考えられています。開発者は、トランザクションでブロックの容量を超えるガスを要求しないように、またハードコードされたガス料金額で呼び出しを行わないように注意する必要があります (これは、長い間開発者に対する標準的なアドバイスでした)。
タイプ 3 (EVM とほぼ同等)
タイプ 3 ZK-EVM は EVM とほぼ同等ですが、同じことを達成するには、検証時間をさらに短縮し、EVM の開発を容易にするためにいくつかの犠牲を払う必要があります。
長所: 構築が簡単で、検証時間が短縮される
タイプ 3 ZK-EVM では、ZK-EVM 実装で実装するのが特に難しいいくつかの機能が削除される場合があります。ここでは、通常、プリコンパイルがリストの最上位にあります。さらに、タイプ 3 ZK-EVM では、コントラクト コード、メモリ、スタックの処理方法に微妙な違いがある場合があります。
短所: 非互換性が増える
タイプ 3 ZK-EVM は、ほとんどのアプリケーションと互換性があり、残りの部分の書き換えが最小限で済むことを目指しています。ただし、一部のアプリケーションは、タイプ 3 ZK-EVM が削除するプリコンパイルを使用しているため、または EVM によって異なる方法で処理されるエッジ ケースへの微妙な依存関係のために、書き直す必要があります。
建設者は誰ですか?
Scroll と Polygon は両方とも現在の形式ではタイプ 3 ですが、時間の経過とともに互換性が向上することが期待されています。 Polygon は独自の設計を採用しており、ZK を使用して独自の内部言語 zkASM を検証し、zkASM 実装を使用して ZK-EVM コードを解釈します。この実装の詳細にもかかわらず、私はこれを真の Type3ZK-EVM と呼びます。EVM コードを検証することはできますが、そのためにいくつかの異なる内部ロジックが使用されているだけです。
現在、タイプ 3 になることを望んでいる ZK-EVM チームは存在しません。タイプ 3 は、プリコンパイルを追加する複雑な作業が完了し、プロジェクトがタイプ 2.5 に移行できるようになるまでの移行段階にすぎません。ただし、将来的には、開発者に低検証時間と低ガスコスト機能を提供する新しい ZK-SNARK フレンドリーなプリコンパイラを追加することにより、タイプ 1 またはタイプ 2 ZK-EVM が自発的にタイプ 3 ZK-EVM になる可能性があります。
タイプ4（高級言語に相当）
タイプ 4 システムは、高級言語 (SOLIDITY、VYPER、または両方がコンパイルされる中間言語など) で書かれたスマート コントラクト ソース コードを取得し、それを ZK スナーク フレンドリーな言語として明示的に設計されたある種の言語にコンパイルすることによって機能します。
長所: 検証時間が非常に速い
各 EVM 実行ステップのさまざまな部分をすべて証明するために ZK を使用せず、高レベルのコードから直接開始することで、多くのオーバーヘッドを回避できます。
この投稿ではこの利点を一文で説明します (以下の互換性に関連する欠点の大きな箇条書きリストと比較して) が、これを価値判断として解釈すべきではありません。高級言語から直接コンパイルすると、確かにコストが大幅に削減され、証明者になることが容易になるため分散化に役立ちます。
短所: 非互換性が増える
Vyper または Solidity で書かれた「通常の」アプリケーションはコンパイルでき、「正常に動作」しますが、多くのアプリケーションが「正常に動作」しない重要な側面がいくつかあります。
CREATE2 コントラクト アドレスは正確なバイトコードに依存するため、タイプ 4 システム内のコントラクトのアドレスは EVM 内のアドレスと異なる場合があります。これにより、「虚偽の契約」に依存するアプリケーション、ERC-4337 ウォレット、EIP-2470 シングルトン、およびまだデプロイされていないその他の多くのアプリケーションが破壊されます。
手書きの EVM バイトコードは処理が困難です。効率性を高めるために、多くのアプリケーションは一部の部分に手書きの EVM バイトコードを使用します。タイプ 4 システムはこれをサポートしていない可能性がありますが、完全なタイプ 3 ZK-EVM を目指すことなく、これらのユースケースを満たす限定的な EVM バイトコード サポートを実装する方法はあります。
デバッグ インフラストラクチャの多くは EVM バイトコードで実行されるため、続行できません。とはいえ、この欠点は、「従来の」高水準言語または中間言語 (LLVM など) からデバッグ インフラストラクチャにアクセスすることで軽減されます。
開発者はこれらの問題を認識しておく必要があります。
建設者は誰ですか?
ZKSync はタイプ 4 システムですが、時間の経過とともに EVM バイトコードとの互換性が向上する可能性があります。 NetherMind の Warp プロジェクトは、Solidity から Starkware への Cairo コンパイラを構築しており、StarkNet を事実上の Type 4 システムに変えることになります。
数種類の ZK-EVM の将来
これらのタイプは、他のタイプよりも明確に「優れている」または「劣っている」わけではありません。むしろ、これらはトレードオフ領域における相違点です。コーディングがより難しい型は、既存のインフラストラクチャとの互換性が高くなりますが、速度が遅くなります。コーディングがより難しい型は、既存のインフラストラクチャとの互換性が低くなりますが、高速になります。全体として、これらのタイプの人々全員が探索を行っており、これはこの分野にとって健全なことです。
ZK-EVM は、ZK 証明が特に難しいいくつかの機能を含めないことを決定して、タイプ 3 から開始できます。その後、時間の経過とともにこれらの機能を追加し、タイプ 2 に移行できます。
ZK-EVM は、タイプ 2 として開始し、完全なイーサネット互換モードで実行するか、より高速に証明できる変更されたステート ツリーを使用する可能性を提供することで、ハイブリッド タイプ 2/タイプ 1 ZK-EVM になることができます。スロール氏はこの方向への移行を検討している。
タイプ 4 で始まるシステムは、後で EVM コードを処理する機能が追加されるため、時間の経過とともにタイプ 3 になる可能性があります (ただし、開発者は費用と検証時間を削減するために、高級言語から直接コンパイルすることが依然として推奨されています)。
個人的には、ZK-EVM を改善し、イーサリアム自体を ZK-Snark により適したものにすることで、時間が経てばすべてがタイプ 1 になることを願っています。そのような将来では、ZK ロールアップとイーサリアム自体の検証の両方のために、複数の ZK-EVM 実装が存在することになります。理論的には、イーサリアムが L1 で使用される単一の ZK-EVM 実装を標準化する必要はなく、異なるクライアントは異なる証明を使用できるため、コードの冗長性の恩恵を受け続けます。
