ZKVM生存の道：一文で派閥争いを詳解

2023.01.31

共有先

TechFlow厳選深潮セレクト

ZKVM生存の道：一文で派閥争いを詳解

2022年において、ロールアップに関する主な議論の焦点はZkEVMに集中していたように見えるが、ZkVMもまた別のスケーリング手段であることを忘れてはならない。

2023.01.31 - 04:27:24

ZKVMZKEVM

Web3業界の深掘り報道に専念し潮流を洞察

著者：Bryan, IOSG Ventures

Xin Gao、 p0xeidonのBoyuan、 TaikoのDanielおよびSin7Yによる本稿への支援および修正提案に感謝します！

はじめに：

2022年は主にZkEVMに関する議論が中心だったが、ZkVMもまた別のスケーリング手段であることを忘れてはならない。ZkEVMが本稿の主眼ではないものの、ZkVMとZkEVMのいくつかの観点での違いを振り返っておく価値がある。

1. 互換性：どちらもスケーリングを目的とするが、重点は異なる。ZkEVMは既存のEVMとの直接互換性を重視する一方、ZkVMはdappのロジックとパフォーマンスを最適化し、完全なスケーラビリティを実現することを目指す。互換性は最優先事項ではない。基盤が整えば、後からEVM互換性も実現可能である。

2. パフォーマンス：両者には予見可能なパフォーマンスのボトルネックがある。ZkEVMの主な課題は、ZK証明システム内でのカプセル化に不向きなEVMとの互換性維持に伴う余分なコストにある。ZkVMの課題は、命令セット（ISA）の導入により最終的に生成される制約がより複雑になることにある。

3. 開発者体験：Type II ZkEVM（例：Scroll, Taiko）はEVMバイトコードレベルでの互換性を特徴とする。つまり、バイトコードレベル以上のEVMコードすべてに対してZkEVMを通じてゼロ知識証明を生成できる。一方ZkVMには二つの方向性がある。一つは独自DSL（例：Cairo）を開発する方法、もう一つはC++/Rustといった既存の成熟言語との互換を目指すアプローチ（例：Risc0）。今後、ネイティブなSolidityイーサリアム開発者はZkEVMへコストゼロで移行できると考えられるが、より強力で新しいアプリケーションはZkVM上で動作すると予想される。

ZKVM生存之道：一文详解派系之争

多くの人がこの図を覚えているだろう。CairoVMがZkEVM派閥争いから距離を置いている本質的な理由は、設計思想の違いにある。

ZkVMについて議論する前に、まず「ブロックチェーン内でZK証明システムをどう実現するか」を考える必要がある。大別して二つの方法がある — 回路ベースシステム (circuit based) とVMベースシステム (vm-based) である。

まず、回路ベースシステムでは、プログラムを直接制約条件（constraints）に変換し、証明システム（proving system）に入力する。一方VMベースシステムは、命令セット（ISA）によってプログラムを実行し、その過程で実行トレース（execution trace）を生成する。この実行トレースはその後、制約条件にマッピングされ、証明システムに送られる。

回路ベースシステムの場合、各マシンにおけるプログラムの計算がそれぞれ制約される。一方VMベースシステムでは、ISAが回路ジェネレータ（circuit generator）に組み込まれており、プログラムの制約を生成する。このとき回路ジェネレータは命令セット、実行サイクル、メモリなどの制限を持つ。VMは汎用性を提供し、これらの制限内であればどのマシンでもプログラムを実行できるようになる。

VM内でのZKPプログラムの大まかな流れは以下の通りである。

ZKVM生存之道：一文详解派系之争

出典: Bryan, IOSG Ventures

長所と短所：

- 開発者(developer)の視点から、回路ベースシステムでは通常、各制約のコストに対する深い理解が求められる。一方、VMベースのプログラム作成では回路が静的であり、開発者が気にするのは主に命令（instructions）となる。

- 検証者(verifier)の視点から、同じ純粋SNARKバックエンドを使用する前提で、回路ベースシステムとVMベースシステムは回路の汎用性において大きく異なる。回路システムはプログラムごとに異なる回路を生成するのに対し、VMは異なるプログラムに対しても同じ回路を生成する。つまり、Rollup内では回路システムが必要とする検証コントラクト（verifier contract）をL1上に複数デプロイしなければならない。

- アプリケーション(application)の視点から、VMはメモリモデルを設計に組み込むことでアプリケーションのロジックをより複雑にするが、回路システムはプログラムのパフォーマンス向上を目的とする。

- システムの複雑さ(complexity)の視点から、VMはメモリモデル、ホスト(host)とゲスト(guest)間通信など、より多くの複雑さをシステムに取り込む。対して回路システムはより簡潔である。

以下は現在のL1/L2における回路ベースおよびVMベースプロジェクトの一覧である。

ZKVM生存之道：一文详解派系之争

出典: Bryan, IOSG Ventures

仮想機械の設計原則

VMには二つの重要な設計原則がある。

第一に、プログラムが正しく実行されることを保証する。つまり、出力（＝制約）と入力（＝プログラム）が正しく一致していること。これは通常ISA命令セットによって達成される。
第二に、コンパイラが高級言語から適切な制約形式に変換する際に正しく動作することを保証する。

1. ISA命令セット

回路ジェネレータの動作方法を規定するもの。主な責任は、命令（instructions）を正しく制約条件（constraint）にマッピングし、証明システムに送ることにある。ZKシステムではRISC（精簡命令セット）が使用される。ISAには二つの選択肢がある。

一つは独自のカスタムISA（custom ISA）を構築する方法で、Cairoの設計に見られる。一般的に、以下の四種類の制約ロジックがある。
カスタムISAの基本設計思想は、制約条件を最小限に抑え、プログラムの実行・検証を高速化することにある。
もう一つは既存のISA（existing ISA）を利用する方法で、Risc0の設計で採用されている。単に実行時間を簡潔に抑えるだけでなく、Risc-Vのような既存ISAはフロントエンド言語およびバックエンドハードウェアとの親和性という追加メリットを持つ。ただし（解決すべき可能性のある）問題として、検証時間の面で劣る可能性がある（検証時間はRisc-Vの主要設計目標ではないため）。

2. コンパイラ(Compiler)

大まかに言えば、コンパイラはプログラミング言語を段階的にマシンコードに翻訳する。ZK環境下では、C、C++、Rustなどの高級言語を制約システム（R1CS、QAP、AIRなど）向けの低レベルコード表現に変換することを指す。二つのアプローチがある。

既存のZK回路表現（existing circuit representations）に基づいたコンパイラを設計する方法 — Bellmanのように直接呼び出し可能なライブラリや、Circomのような低レベル言語から始まる。異なる表現を集約するために、Zokratesのようなコンパイラ（それ自体がDSLでもある）は、任意の低レベル表現にコンパイル可能な抽象層を提供しようとする。
（既存の）コンパイラ基盤（compiler infrastructure）を活用して構築する方法。基本的な考え方は、複数のフロントエンドおよびバックエンドに対応する中間表現（intermediate representation）を利用することにある。

Risc0のコンパイラはmulti-level intermediate representation（MLIR）に基づいており、LLVMのように複数の中間表現（IR）を生成できる。異なるIRはそれぞれ設計上の重点が異なり、一部はハードウェア最適化に特化しているため、開発者はニーズに応じて選択できる柔軟性を提供する。GCCのvnTinyRAMやTinyRAMでも同様の考え方が見られる。zkSyncもまたコンパイラ基盤を活用する一例である。

その他にも、CirCのようにZK向けに設計されたコンパイラ基盤があり、LLVMの設計思想を一部借用している。

これら二つの最も重要な設計ステップ以外にも、以下の考慮事項がある。

1. セキュリティ(security)と検証コスト(verifier cost)のトレードオフ

システムが使用するビット数が高いほど（＝セキュリティが高いほど）、検証コストも高くなる。セキュリティは鍵生成器（例えばSNARKにおける楕円曲線）に反映される。

2. フロントエンドおよびバックエンドとの互換性(compatibility)

互換性は回路の中間表現（intermediate representation）の有効性に依存する。IRは正しさ（プログラム出力が入力と一致し、かつ証明システムに適合しているか）と柔軟性（複数のフロントエンド・バックエンドをサポート）のバランスを取る必要がある。もしIRが当初R1CSのような低次数制約システム向けに設計されていた場合、AIRのような高次数制約システムとの互換性は難しくなる。

3. 効率向上のための手作り回路(hand-crafted circuits)

汎用モデルの欠点は、複雑な命令を必要としないシンプルな操作において効率が低いことである。

これまでの理論的背景を簡単に述べておく。

Pinocchioプロトコル以前: 検証可能な計算を実現したが、検証時間が非常に遅かった。
Pinocchioプロトコル: 検証可能性と検証成功率において理論的な実現可能性を提示（検証時間がプログラム実行時間より短い）。回路ベースシステムである。
TinyRAMプロトコル: Pinocchioに比べ、TinyRAMはむしろVMに近く、ISAを導入することでメモリアクセス（RAM）、制御フロー（control flow）などの制限を回避した。
vnTinyRAMプロトコル: 鍵生成（key generation）が個々のプログラムに依存しなくなったことで、追加の汎用性を提供。回路ジェネレータを拡張し、より大きなプログラムを処理可能にした。

上記のモデルはすべてSNARKをバックエンド証明システムとしているが、特にVMを扱う際には、STARKやPlonkの方がより適したバックエンドとされる。これは、その制約システムがCPUのようなロジックを実装するのに適しているためである。

次に、本文ではSTARKベースの三つのVM— Risc0, MidenVM, CairoVMについて紹介する。要するに、すべてSTARKを証明システムとしているが、それぞれ異なる点がある。

Risc0はRisc-Vを活用し、命令セットの簡潔性を実現。R0はMLIR上でコンパイルされ、これはLLVM-IRの変種で、Rust、C++など複数の既存汎用プログラミング言語をサポートする。Risc-Vにはハードウェアとの親和性といった追加メリットもある。
Midenはイーサリアム仮想マシン（EVM）との互換性を目指しており、本質的にはEVMのロールアップである。Midenは現在独自のプログラミング言語を持っているが、将来的にはMoveのサポートも目指している。
Cairo VMはStarkwareが開発。これら三システムで使われるSTARK証明システムは、現Starkware社長であるEli Ben-Sassonによって発明された。

さらに詳しく違いを見てみよう。

ZKVM生存之道：一文详解派系之争

*上の表の読み方：いくつかの注釈...

●Word size（ワードサイズ） - これらのVMが基盤とする制約システムはAIRであり、CPUアーキテクチャに類似しているため、CPUのワードサイズ（32/64ビット）を選択するのが適切である。

●Memory access（メモリアクセス） - Risc0がレジスタを使用するのは、Risc-V命令セットがレジスタベースだからである。Midenはデータ保存に主にスタックを使用する。これはAIRの機能がスタックに類似しているため。CairoVMは汎用レジスタを使用しない。Cairoモデルではメインメモリへのアクセスコストが低いためである。

●Program feed（プログラム実行） - 異なる手法には利点と欠点がある。たとえば、mast root方式は命令処理時にデコードが必要なため、多数のステップを含むプログラムでは証明者コストが高くなる。Bootloading方式は、プライバシーを維持しつつ、証明者コストと検証者コストのバランスを取ろうとする。

●Non-determinism（非決定性） - 非決定性はNP完全問題の重要な属性である。これを利用することで過去の実行を迅速に検証できる。反面、より多くの制約を生じるため、検証面での妥協が必要になる。

●Acceleration on complex operations（複雑演算の高速化） - CPU上で実行が遅い計算がある。例えばXORやANDなどのビット演算、ECDSAのようなハッシュ処理、範囲チェック（range-check）など。これらはブロックチェーン／暗号技術ではネイティブだが、CPUではそうではない（ビット演算を除く）。DSLでこれらを直接実装すると、証明サイクルが尽きやすくなる。

●Permutation/multiset （順列／多重集合） - 多くのZKVMで広く使用され、二つの目的がある。1. 完全な実行トレースの保存を減らして検証者コストを下げる。2. 検証者が完全な実行トレースを知っていることを証明する。

最後に、筆者はRisc0の現状とそれがなぜ興奮を呼ぶのかについて述べたい。

R0の現状：

a. 自社開発の「Zirgen」コンパイラ基盤が開発中。これを他の既存ZK専用コンパイラと性能比較するのは興味深いだろう。

b. field extensionなど、いくつかの興味深い革新。より堅牢なセキュリティパラメータおよび大きな整数での演算を可能にする。

c. ZKハードウェアとZKソフトウェア企業統合における課題を経験し、Risc0はハードウェア抽象層を採用してハードウェア開発を容易にしている。

d. まだ開発中（work-in-progress）！

- 手作り回路（hand-crafted circuits）のサポート、複数のハッシュアルゴリズムのサポート。現在、専用SHA256回路は実装済みだが、すべてのニーズを満たすわけではない。どの回路を最適化するかはRisc0が提供するユースケースに依存すると筆者は考える。SHA256は良い出発点である。一方、ZKVMの位置づけは柔軟性を提供する。たとえば、Keccakを使う気がなければ無視すればよい（笑）。

- 再帰（recursion）：非常に大きなテーマであり、本レポートでは深入りしない。Risc0がより複雑なユースケース／プログラムをサポートするにつれ、再帰の必要性は高まる。再帰をさらに支援するため、現在GPUアクセラレーションのハードウェア側ソリューションを研究中である。

- 非決定性（non-determinism）の処理：これはZKVMが必然的に扱わなければならない属性であり、従来のVMにはない問題である。非決定性はVMの実行を高速化する助けとなる。MLIRは従来のVM問題に比較的強く、Risc0が非決定性をZKVMシステム設計にどう組み込むかは注目に値する。