Vitalik：異なるタイプのZK-EVMの将来
TechFlow厳選深潮セレクト
Vitalik：異なるタイプのZK-EVMの将来
ZK-EVMの改善およびイーサリアム自体の改良を通じて、それをZK-SNARKにより適した形にすることがより望ましい。イーサリアムがL1で使用する個別のZK-EVM実装について標準化する必要はない。
Web3業界の深掘り報道に専念し潮流を洞察著者：Vitalik
翻訳：Block unicorn，Foresight News
最近、多くの「ZK-EVM」プロジェクトが注目を集めた発表を行っている。Polygonは自らのZK-EVMプロジェクトを公開し、ZKSyncはZKSync 2.0計画を発表した。比較的新しいScrollも最近ZK-EVMをリリースしている。他にもプライバシーとスケーラビリティ探索チームやNicolas Liochonらによるチームが、EVMからStarkwareのzkフレンドリー言語Cairoへのalphaコンパイラーを開発しており、もちろん見過ごしているプロジェクトもあるだろう。
こうしたすべてのプロジェクトの中心的な目的は同じである。ZK-SNARK技術を用いて、イーサリアムに類似したトランザクション実行を暗号的に証明することで、イーサリアムチェーン自体の検証を容易にするか、あるいはイーサリアムとほぼ同等だがスケーラビリティに優れたzk rollupを構築することだ。しかし、これらのプロジェクトには微妙な差異があり、実用性と速度との間でトレードオフが存在する。この記事では、EVM等価性の異なる「タイプ」の分類と、それぞれの実現に伴う利点とコストについて説明しよう。
概要（図表形式）
タイプ1（完全にイーサリアムと等価）
タイプ1のZK-EVMは、完全かつ妥協なしにイーサリアムと等価になることを目指す。イーサリアムシステムのいかなる部分も、証明生成を容易にするために変更しない。ハッシュ、ステートツリー、トランザクションツリー、プリコンパイル、あるいは周辺的なものであっても、いかなるコンセンサスロジックも置き換えない。
利点：完璧な互換性
目標は現在と同様にイーサリアムブロックを検証できるようにすること、あるいは少なくとも実行層（ビーコンチェーンのコンセンサスロジックは対象外だが、すべてのトランザクション実行およびスマートコントラクト・アカウントロジックは含む）を検証できることである。
タイプ1のZK-EVMは、イーサリアムL1自体のスケーラビリティ向上に最終的に必要となる。長期的には、タイプ2またはタイプ3のZK-EVMでテストされたイーサリアムの変更がイーサリアム本体に導入される可能性があるが、そのような再設計には独自の複雑さが伴う。
タイプ1のZK-EVMは、ロールアップにとっても理想的である。なぜなら、大量のインフラストラクチャを再利用できるためだ。たとえば、イーサリアム実行クライアントをそのまま使用してロールアップブロックの生成・処理が可能になる（あるいは、引き出し機能が実装されれば再利用可能になり、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ロールアップでも動作する。イーサリアム実行クライアントをそのまま使用することはできないが、多少の修正を加えれば使用可能であり、EVMデバッグツールや他の大部分の開発者インフラストラクチャも使い続けることができる。
ただし、少数の例外がある。過去のイーサブロックのMerkle証明を検証することで、過去のトランザクション、レシート、または状態に関する主張を検証するアプリケーション（例えば、ブリッジが時折行う）では不互換性が生じる。Keccakを別のハッシュ関数で置き換えるZK-EVMは、こうした証明を無効にする。しかし、私は通常、このような方法でアプリケーションを構築することは推奨しない。将来的なイーサリアムの変更（例：Verkle Tree）ですら、イーサリアム本体上でもそのようなアプリケーションを壊してしまうからである。より良い代替案は、歴史的アクセスを保証するプリコンパイルをイーサリアム本体に追加することである。
欠点：証明時間の改善、しかし依然遅い
タイプ2のZK-EVMは、不要なほど複雑でzk非フレンドリーなイーサリアムスタックの一部を削除することで、タイプ1よりも速い証明時間を提供する。特に、イーサリアムのKeccakおよびRLPベースのMerkle Patricia Treeを変更し、ブロックやレシート構造も変更する可能性がある。タイプ2のZK-EVMは、Poseidonなど別のハッシュ関数を使用するかもしれない。もう一つの自然な変更は、コードハッシュとkeccakをステートツリーに格納することで、EXTCODEHASHおよびEXTCODECOPYオペコード処理時にハッシュ検証を不要にすることである。
こうした変更により証明時間は大幅に短縮されるが、すべての問題を解決できるわけではない。EVM固有の非効率性とzk非フレンドリー性のため、EVMをそのまま証明するプロセスは依然として遅い。単純な例としてメモリがある。MLOADは任意の32バイトを読み取ることができ、「未整列」のブロック（開始と終了が32の倍数でない）も含まれるため、MLOADは単一のブロック読み取りとして解釈できない。代わりに、連続する2つのブロックを読み取り、結果を結合するためにビット操作を行う必要がある。
誰が開発しているのか？
ScrollのZK-EVMプロジェクトはタイプ2のZK-EVMを目指しており、Polygon Hermezも同様である。ただし、どちらのプロジェクトもまだ完了していない（ZKEVM作業が完了していない）。特に、多くの複雑なプリコンパイルがまだ実装されていない。従って、現時点ではどちらのプロジェクトもタイプ3と考えるのが適切である。
タイプ2.5（EVM相当、ガス料金を除く）
最悪の場合の証明時間を大幅に改善する方法の一つは、ZK-EVMで証明が特に困難な特定の操作のガスコストを大幅に増加させることである。これにはプリコンパイル、KECCAKオペコード、さらには呼び出し規約やメモリ、ストレージ、リバートへのアクセスパターンなどが含まれる。
ガスコストの変化は開発者ツールの互換性を低下させる可能性があり、一部のアプリケーションを破壊するが、通常は「より深い」EVM変更よりもリスクが小さいと見なされている。開発者は、トランザクションに必要なガス量がブロック容量を超えないよう注意し、ハードコードされたガス量で呼び出さないよう注意すべきである（これは長年にわたる開発者向けの標準的な助言である）。
タイプ3（ほぼEVMと等価）
タイプ3のZK-EVMはほぼEVMと等価であるが、完全に一致させるために若干の妥協を行い、さらに証明時間を短縮し、EVMの開発を容易にする。
利点：構築が容易で、証明時間がより高速
タイプ3のZK-EVMは、実装が特に難しい機能を削除する可能性がある。ここでは、プリコンパイルがリストの最上位に来る。また、コントラクトコード、メモリ、スタックの扱いにわずかな違いがある場合もある。
欠点：より多くの非互換性
タイプ3のZK-EVMの目標は、ほとんどのアプリケーションと互換性を持ち、残りは最小限の書き換えで済むようにすることである。つまり、タイプ3のZK-EVMが削除したプリコンパイルを使用しているか、EVMが異なる方法で処理するエッジケースに微妙に依存しているため、一部のアプリケーションは再記述が必要になる。
誰が開発しているのか？
ScrollおよびPolygonの現時点での形態はタイプ3であるが、時間の経過とともに互換性が向上すると期待されている。Polygonは独自の設計を持ち、自社の内部言語zkASMをZKで検証し、zkASMを使ってZK-EVMコードを解釈実行する。こうした実装の詳細があるものの、私はこれを真のタイプ3 ZK-EVMと呼んでいる。それでもEVMコードを検証できるが、異なる内部ロジックを使用しているだけである。
今日、ZK-EVMチームはタイプ3になることを望んでいない。タイプ3は、プリコンパイルの複雑な作業が完了し、プロジェクトがタイプ2.5に移行するまでの過渡期に過ぎない。しかし将来、タイプ1またはタイプ2のZK-EVMが、低証明時間と低ガスコストを提供する新しいZK-SNARKフレンドリーなプリコンパイルを追加することで、意図的にタイプ3のZK-EVMになる可能性がある。
タイプ4（高級言語と同等）
タイプ4のシステムは、SOLIDITY、VYPER、あるいは両者がコンパイルする中間言語など、高級言語で書かれたスマートコントラクトのソースコードを取得し、それを明示的にZK-snarkフレンドリーに設計された言語にコンパイルする方式で動作する。
利点：証明時間が非常に高速
各EVM実行ステップのすべての部分をzkで証明するのではなく、より高次のコードから直接始めるため、多くのオーバーヘッドを回避できる。
この利点については、この記事ではたった一文でしか述べていない（以下にある互換性に関する欠点の長い箇条書きと比べて）が、これは価値判断として解釈すべきではない！高次言語からの直接コンパイルは確かにコストを大きく削減し、証明者になることを容易にすることで分散化にも貢献する。
欠点：より多くの非互換性
VyperやSolidityで書かれた「普通の」アプリケーションはコンパイルされ、「普通に動く」が、重要な側面において多くのアプリケーションは「普通に動かない」：
- タイプ4システムにおけるコントラクトのアドレスは、EVM内でのアドレスと異なる可能性がある。CREATE2によるアドレス決定は正確なバイトコードに依存するため。これは、まだ展開されていない「反事実的コントラクト」、ERC-4337ウォレット、EIP-2470シングルトン、および多くの他のアプリケーションに依存するアプリケーションを破壊する。
- 手書きのEVMバイトコードの使用が難しくなる。効率を高めるため、多くのアプリケーションは特定の部分で手書きのEVMバイトコードを使用している。タイプ4システムはこれをサポートしない可能性があるが、これらのユースケースを満たすために限定的なEVMバイトコードサポートを実装する方法もあり、完全なType3 ZK-EVMになる努力は不要である。
- EVMバイトコード上で動作する多くのデバッグインフラストラクチャは継続使用できない。ただし、より「伝統的な」高級言語または中間言語（例：LLVM）からデバッグインフラストラクチャにアクセスすることで、この欠点は緩和される。
開発者はこれらの問題に注意すべきである。
誰が開発しているのか？
ZKSyncはタイプ4のシステムであり、時間の経過とともにEVMバイトコードとの互換性を高めていく可能性がある。NetherMindのWarpプロジェクトはSolidityからStarkwareのCairoへのコンパイラーを構築しており、これによりStarkNetが事実上のタイプ4システムになる。
各タイプのZK-EVMの将来
これらのタイプは、他のタイプに対して明確に「より良い」または「より悪い」というわけではない。むしろ、トレードオフの空間における異なるポイントである。コーディング難度が低いタイプは既存インフラと互換性が高いが速度が遅く、コーディング難度が高いタイプは互換性が劣るが速度が速い。全体として、すべてのタイプが探求されていることは、この分野にとって健全なことである。
- ZK-EVMはタイプ3から始め、特にZK証明が難しい機能を含めないことでスタートする。その後、時間の経過とともにそれらの機能を追加し、タイプ2へ移行する可能性がある。
- ZK-EVMはタイプ2から始め、全イーサ互換モードで動作するか、証明がより高速な変更済みステートツリーを使用する可能性を提供することで、ハイブリッド型2/タイプ1 ZK-EVMになる可能性がある。Scrollはこの方向を検討している。
- タイプ4から始まるシステムは、後にEVMコード処理能力を追加することでタイプ3になる可能性がある（ただし、開発者には依然として高級言語からの直接コンパイルを推奨し、費用と証明時間の削減を促す）。
- イーサリアム本体がZKフレンドリー化のために変更を採用すれば、タイプ2またはタイプ3のZK-EVMはタイプ1のZK-EVMになれる。
- タイプ1またはタイプ2のZK-EVMは、ZK-SNARKフレンドリーな言語で書かれたコードを検証するプリコンパイルを追加することで、タイプ3のZK-EVMになることができる。これにより、開発者はイーサ互換性と速度の間で選択できるようになる。これは完全なEVM同等性を損なうためタイプ3となるが、実用上はタイプ1およびタイプ2の多くの利点を持つ。主な欠点は、一部の開発者ツールがZK-EVMのカスタムプリコンパイルを理解しないことだが、これは修正可能である。開発者ツールは、プリコンパイルを含むEVMコードの等価実装をサポートする設定フォーマットを追加することで、汎用プリコンパイルサポートを実装できる。
個人的には、時間の経過とともにすべてがタイプ1になることを願っている。ZK-EVMの改善と、イーサリアム自体のZK-Snarkへの適合性向上を通じて。そのような未来では、zkロールアップにも、イーサリアム本体の検証にも使える複数のZK-EVM実装が存在するだろう。理論的には、イーサリアムL1で使用される単一のZK-EVM実装を標準化する必要はない。異なるクライアントが異なる証明を使用でき、コード冗長性の恩恵を続けられるからである。
しかし、そのような未来に到達するにはかなりの時間がかかるだろう。その間、イーサリアムの拡張およびイーサリアムベースのZKロールアップのさまざまな道筋で多くの革新が見られるだろう。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
@VitalikButerin
