Vitalik：異なるタイプのZK-EVMの未来

原文标题：《ZK-EVMの異なるタイプ》

作者：Vitalik

编译：Block unicorn，Foresight News

最近、多くの「ZK-EVM」プロジェクトが高らかに発表されています。Polygonは彼らのZK-EVMプロジェクトを公開し、ZKSyncは彼らのZKSync 2.0計画を発表し、比較的新しいScrollも最近彼らのZK-EVMを発表しました。また、プライバシーとスケーラビリティを探求するチームや、Nicolas Liochonなどのチームによる継続的な努力があり、EVMからStarkwareのzkフレンドリー言語Cairoのアルファコンパイラまで、もちろんいくつかのプロジェクトは見逃すかもしれません。

これらすべてのプロジェクトの核心的な目標は同じです：ZK-SNARK技術を使用して、Ethereumに類似したトランザクションの実行に対する暗号証明を行い、Ethereumチェーン自体の検証を容易にするか、Ethereumが提供する内容（ほぼ）と同じだが、スケーラビリティが高いzkロールアップを構築することです。しかし、これらのプロジェクト間には微妙な違いがあり、実用性と速度の間のトレードオフがあります。この記事では、EVM等価性の異なる「タイプ」の分類を説明し、各タイプを実現することの利点とコストを試みます。

概説 ( 図表形式 )

タイプ1（Ethereumと完全に等価）

第一のタイプのZK-EVMは、Ethereumと完全かつ妥協のない等価性を追求します。これらは、証明を生成しやすくするためにEthereumシステムのいかなる部分も変更しません。ハッシュ、状態ツリー、トランザクションツリー、プリコンパイル、または他のコンセンサスロジックを置き換えることはありません。

利点：完璧な互換性

私たちの目標は、現在のようにEthereumブロックを検証できること、または少なくとも実行層を検証できることです（したがって、ビーコンサインセンサスロジックは含まれませんが、すべてのトランザクション実行とスマートコントラクトおよびアカウントロジックは含まれます）。

タイプ1：ZK-EVMは、Ethereumの第1層自体をよりスケーラブルにするために必要です。長期的には、タイプ2またはタイプ3のZK-EVMでテストされたEthereumへの変更がEthereum自体に導入される可能性がありますが、そのような再設計には独自の複雑さが伴います。

タイプ1：ZK-EVMは、集約の理想的な選択肢でもあります。なぜなら、集約が大量の基盤インフラを再利用できるからです。たとえば、Etherum Executionクライアントは、ROLLUPブロックを生成および処理するためにそのまま使用できます（または少なくとも、抽出が実装されると再利用でき、その機能はROLLUPに保存されたETHをサポートするために再利用できます）。そのため、ブロックリソースマネージャー、ブロック生成などのツールは非常に簡単に再利用できます。

欠点：検証時間

Ethereumは最初からzkフレンドリーに設計されていなかったため、Ethereumプロトコルの多くの部分はzkを検証するために大量の計算を必要とします。タイプ1の目標はEthereumを完全に複製することなので、これらの非効率性を緩和する方法はありません。現在、Ethereumブロックの証明には数時間かかります。この状況は、巧妙なエンジニアリングによって大規模に並列化された検証者を使用するか、長期的にはZK-SNARK専用の集積回路によって緩和される可能性があります。

ビルダーは誰ですか？

プライバシーとスケーラビリティを探求するチームがタイプ1のZK-EVMを構築しています。

タイプ2（完全に等価なEVM）

第二のタイプのZK-EVMは、EVMと完全に等価であることを目指していますが、Ethereumとは完全には等価ではありません。つまり、内部から見ると完全にEthereumのように見えますが、外部ではブロック構造や状態ツリーなどのデータ構造にいくつかの違いがあります。

その目標は、既存のアプリケーションと完全に互換性があることですが、開発を容易にし、証明をより迅速に生成するためにEthereumにいくつかの小さな変更を加えます。

利点：仮想マシンレベルでの完全な対等性の実現

タイプ2のZK-EVMは、Ethereumの状態を保存するためのデータ構造に変更を加えます。幸いなことに、これらの構造はEVM自体が直接アクセスできないため、Ethereum上で動作するアプリケーションはほぼ常にタイプ2のZK-EVM集約上で動作します。Etherum Executionクライアントをそのまま使用することはできませんが、いくつかの変更を加えることで使用でき、EVMデバッグツールやほとんどの他の開発者インフラを引き続き使用できます。

ただし、いくつかの例外もあります。歴史的なEthereumブロックのMerkle証明を検証するために、歴史的なトランザクション、レシート、または状態に関する声明を検証するアプリケーションには互換性の問題が発生します（たとえば、ブリッジは時々これを行います）。Keccakの代わりに異なるハッシュ関数を使用するZK-EVMは、これらの証明を破壊します。しかし、私は通常、このようにアプリケーションを構築しないことをお勧めします。なぜなら、将来のEthereumの変更（たとえば、Verkle Trees）は、Ethereum自体でもそのようなアプリケーションを破壊する可能性があるからです。Ethereum自体にとって、より良い代替案は、将来の信頼できる歴史アクセスのプリコンパイルを追加することです。

欠点：検証時間の改善も依然として遅い

タイプ2のZK-EVMは、タイプ1よりも速い検証時間を提供しますが、主に不必要な複雑さと不親切なZK暗号に依存するEthereumスタックの部分を削除することによってです。特に、EthereumのKeccakやRLPベースのMerkle Patriciaツリーを変更する可能性があり、ブロックや受信構造も変更する可能性があります。タイプ2のZK-EVMは、Poseidonのような異なるハッシュ関数を使用する可能性があります。もう一つの自然な変更は、状態ツリーを変更してコードハッシュとkeccakを保存することで、EXTCODEHASHやEXTCODECOPYオペコードを処理するためにハッシュを検証する必要がなくなります。

これらの変更は検証時間を大幅に改善しますが、すべての問題を解決するわけではありません。EVMの固有の非効率性とzkに対する不親切性のため、EVMをそのまま証明するプロセスは依然として遅いです。簡単な例はメモリです：MLOADは任意の32バイトを読み取ることができ、「アラインされていない」ブロック（開始と終了が32の倍数でない）を含むため、MLOADは単にブロックを読み取ることとして解釈できません。代わりに、2つの連続したブロックを読み取り、結果を結合するためにビット操作を実行する必要があるかもしれません。

ビルダーは誰ですか？

ScrollのZK-EVMプロジェクトは、Polygon Hermezと同様に、タイプ2のZK-EVMの方向に進んでいます。つまり、これらの2つのプロジェクトはまだ完成していません（ZKEVMの作業は完了していません）。特に、より複雑なプリコンパイルの多くはまだ実装されていません。したがって、現在のところ、両方のプロジェクトはタイプ3を考慮するのが最善です。

タイプ2.5（EVMと同等、ガスコストを含まない）

最悪のケースの検証時間を大幅に改善する方法の一つは、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コードを解釈します。このような実装の詳細があっても、私はそれを真のタイプ3のZK-EVMと呼び続けます。なぜなら、それは依然としてEVMコードを検証できるからです。ただし、いくつかの異なる内部ロジックを使用してそれを実現しています。

今日、ZK-EVMチームはタイプ3になりたいとは思っていません。タイプ3は、プリコンパイルの複雑な作業が完了するまでの過渡的な段階に過ぎません。プロジェクトはタイプ2.5に移行できます。しかし、将来的には、タイプ1またはタイプ2のZK-EVMが自発的にタイプ3のZK-EVMになる可能性があります。方法は、新しいZK-SNARKフレンドリーなプリコンパイラを追加し、開発者に低い検証時間とガスコストの機能を提供することです。

タイプ4（高級言語に相当）

タイプ4システムの動作方法は、高級言語で書かれたスマートコントラクトのソースコード（たとえば、SOLIDITY、VYPER、またはその両方をコンパイルする中間言語）を採用し、それをZK-snarkフレンドリーな言語に明示的に設計された何かにコンパイルすることです。

利点：検証時間が非常に速い

各EVM実行ステップのすべての異なる部分を証明するためにZKを使用せず、より高いレベルのコードから直接始めることで、多くのオーバーヘッドを回避できます。

私はこの記事でこの利点を一文で説明しました（下の互換性に関連する欠点の大きな箇条書きリストと比較して）、しかしこれは価値判断として解釈されるべきではありません！高級言語から直接コンパイルすることで、コストを大幅に削減でき、証明者になることが容易になるため、分散化を助けることができます。

欠点：より多くの非互換性

VyperまたはSolidityで書かれた「通常の」アプリケーションはコンパイルされ、「通常通りに動作」しますが、いくつかの重要な側面があり、多くのアプリケーションは「通常通りに動作」しません：

• タイプ4システム内の契約のアドレスは、EVM内のアドレスとは異なる可能性があります。なぜなら、CREATE2の協定アドレスは正確なバイトコードに依存するからです。これにより、まだデプロイされていない「反事実契約」、ERC-4337ウォレット、EIP-2470シングルトン、および多くの他のアプリケーションに依存するアプリケーションが破壊されます。
• 手書きのEVMバイトコードは使用が難しくなります。効率を向上させるために、多くのアプリケーションは特定の部分で手書きのEVMバイトコードを使用します。タイプ4システムはこれをサポートしない可能性がありますが、これらのユースケースを満たすために限られたEVMバイトコードサポートを実現する方法はいくつかあります。完全なタイプ3のZK-EVMになる努力をする必要はありません。
• 多くのデバッグインフラは続行できません。なぜなら、これらのインフラはEVMバイトコードで動作するからです。つまり、より多くの「従来の」高級または中間言語からデバッグインフラにアクセスすることで、この欠点は軽減されます（たとえば、LLVM）。

開発者はこれらの問題に注意する必要があります。

ビルダーは誰ですか？

ZKSyncはタイプ4のシステムですが、時間が経つにつれてEVMバイトコードの互換性を高める可能性があります。NetherMindのWarpプロジェクトは、SolidityからStarkwareのCairoへのコンパイラを構築しており、これによりStarkNetは事実上のタイプ4システムになります。

ZK-EVMの未来のいくつかのタイプ

これらのタイプは、他のタイプよりも「優れている」または「劣っている」というわけではありません。むしろ、これらはトレードオフの空間における異なる点です：コーディングの難易度が低いタイプは既存のインフラとより互換性がありますが、速度は遅くなります。コーディングの難易度が高いタイプは既存のインフラとあまり互換性がありませんが、速度は速くなります。全体として、これらのすべてのタイプの人々は探求しており、これはこの分野にとって健康的です。

• ZK-EVMはタイプ3から始まり、特に難しいZK証明の機能を含めないことを決定できます。その後、時間の経過とともにこれらの機能を追加し、タイプ2に移行することができます。
• ZK-EVMはタイプ2から始まり、全Ethereum互換モードで動作するか、より迅速に証明できるように変更された状態ツリーを使用する可能性があります。Scrollはこの方向に進むことを検討しています。
• タイプ4から始まるシステムは、時間の経過とともにタイプ3に移行する可能性があります。なぜなら、後でEVMコードを処理する能力が追加されるからです（ただし、開発者にはコストと検証時間を削減するために高級言語から直接コンパイルすることが奨励され続けます）。
• Ethereum自体がその変更を採用してZKに対してよりフレンドリーになる努力をすれば、タイプ2またはタイプ3のZK-EVMはタイプ1のZK-EVMになる可能性があります。
• タイプ1またはタイプ2のZK-EVMは、プリコンパイラを追加することでZK-SNARKフレンドリーな言語内のコードを検証し、タイプ3のZK-EVMになることができます。これにより、開発者はEthereumの互換性と速度の間で選択を行うことができ、タイプ3になります。なぜなら、完璧なEVMの同等性を破るからですが、実際の目的と目的の観点からは、タイプ1とタイプ2の多くの利点を持つことになります。主な欠点は、一部の開発者ツールがZK-EVMのカスタムプリコンパイルを理解しないことかもしれませんが、これは修正可能です：開発者ツールは、プリコンパイルを含むEVMコードの等価実装をサポートする構成フォーマットを通じて一般的なプリコンパイルサポートを追加できます。

私個人としては、時間の経過とともにすべてがタイプ1に変わることを望んでいます。ZK-EVMの改善とEthereum自体の改善により、ZK-Snarkにより適したものになることを願っています。そのような未来では、複数のZK-EVM実装が存在し、ZKロールアップにもEthereum自体の検証にも使用されるでしょう。理論的には、EthereumはL1で使用される単一のZK-EVM実装を標準化する必要はありません。異なるクライアントは異なる証明を使用できるため、コードの冗長性から引き続き利益を得ることができます。

しかし、そのような未来に到達するにはかなりの時間がかかります。その間、私たちはEthereumの拡張とEthereumベースのZKロールアップのさまざまなアプローチで多くの革新を目にするでしょう。