🤖

数式なしで理解するzkVM入門：RISC Zero zkVM

2025/04/22に公開

想定読者: Circom / zk‑SNARK を触ったことがあるが、まだ zkVM を動かしたことがない人

ゴール: zkVMの概要を理解する

 zkVMとは？zkSNARKは証明サイズの小ささと検証の効率性で広く採用されてきましたが、開発難易度の高さとTrusted setupの必要性が実用化の障壁となっていました。zkVMはこれらの課題を解決し、普通のプログラミング言語（主にRust）でゼロ知識証明が作れる革新的なアプローチです。

 0. 雑におさらい ― zk‑SNARK は何が嬉しかった？以前の記事 ZK-SNARKs実践入門 - Circomとsnarkjsによるゼロ知識証明の実装 では、次のようなフローを学びました：
Circom で回路を組む
Powers‑of‑Tau → Groth16 の trusted setup
snarkjs で prover / verifier を実行
ZK-SNARKsの基本概念や実装方法に興味がある方は、ぜひ以下の記事もご覧ください。

https://zenn.dev/naizo01/articles/eb541a2e1409ea
表1: zk-SNARKの長所と課題


✨メリット
🌪️課題


証明は「数百 byte」級で超コンパクト

Trusted setup が必須 – 破棄し忘れるとセキュリティ崩壊

検証がガス激安

回路 DSL を覚え、コンストレイント数を手動管理

—

量子計算への耐性がない（ペアリング暗号は Shor アルゴリズムで解ける）


 1. zkVM とは？zkVM (Zero‑Knowledge Virtual Machine) は以下を実現するシステムです：
Rust プログラムをそのまま走らせ、その"実行が正しかった"という STARK 証明を自動生成する
このセクションで学ぶこと:
zkVMの基本的な特徴と利点
RISC Zero zkVMの主な特性
表2: RISC Zero zkVMの特徴


特徴
メモ


STARK ベース
透明（trusted setup 不要）、既知の攻撃に対し量子耐性が期待できる

Rust ネイティブ

cargo new 感覚で始められる（公式サポートは Rust のみ）

証明サイズ

Hello World レベルの最小プログラムでも約32Kサイクルとなり、証明サイズは約200KB、数十万サイクルでは約270KB前後

圧縮 (Bonsai)
STARK証明をGroth16でラップすることで約0.5KB（512バイト）程度まで圧縮可能


 2. zk‑SNARK vs zkVM の比較このセクションの要点:
開発体験、証明サイズ、セキュリティモデルの違いを理解する
どのような場合にzkVMが適しているかの判断基準を得る
表3: 技術比較


観点
zk‑SNARK (Groth16)
zkVM (STARK)


Trusted setup
必要
不要

証明サイズ
使用する楕円曲線に依存：BN254で約128バイト、BLS12-381で約192バイト（一定）
200KB〜数MB（実行ステップ数に応じて増加）

検証ガス
約23万gas
未圧縮STARKは数百万gas（SNARKの10〜15倍）→ Groth16ラップで約28万gas

開発体験
回路DSL（CircomやZoKrates等）
Rust（公式サポート）

ループ / 再帰
事前展開が必要
動的に書ける

量子耐性
なし（楕円曲線ペアリングは量子計算で破られる可能性）
SHA-256やPoseidonハッシュを使用し、既知の攻撃に対し高い耐性あり


 「何倍？」をざっくり数字で見る — 証明サイズ編表4: 証明サイズの実際の比較


ケース
zk‑SNARK (Groth16)
zkVM (RISC Zero /STARK)
ざっくり倍率


最小プログラム (32K cycle)
≈ 192 B (BLS12-381)
≈ 201 KB
≈ 1,070 倍

256 K cycles
192 B
249.6 KB
≈ 1,330 倍

1M cycles
192 B
≈ 270 KB
≈ 1,430 倍

重要ポイント

生の STARK レシート は 約200 KB〜数 MB になる一方、Groth16 は 使用する曲線により128〜192バイト程度と非常に小さい。
プログラムサイズと証明サイズの関係はサブリニアで、実行サイクルが8倍になっても証明サイズは約1.25倍程度。
オンチェーン検証では圧縮が必須（BonsaiサービスによるGroth16ラップなど）。

 3. zkVMで「隠せるもの」セキュリティモデルを理解する:

zkVMでは何が秘匿され、何が公開されるのかを正確に把握することが重要です。
表5: 情報の秘匿性比較


区分
zk‑SNARK (回路型)
zkVM (RISC Zero 例)
解説


入力（witness）
✅ 秘匿
✅ 秘匿

env::read() で渡したデータはreceiptには含まれません。

中間状態（メモリ・レジスタ・スタックなど）
✅ 秘匿
✅ 秘匿
実行トレースはSTARK証明にコミットされるだけで現物は公開されません。

プログラム本体
❌ 公開（回路はVerifying Keyに焼き付き）
✅ 秘匿可
ゲストELFはハッシュ化されImageIDだけが公開。コードを配布しなければロジック自体を秘匿したまま証明できます。

任意出力
回路が決め打ち
選択可

env::commit()した値だけがjournalに公開される。何を公開するかは開発者が制御。


 4. zkVM だからこそできることこのセクションのポイント:

zkVMの導入により、これまでのzk技術では難しかった新しいユースケースが可能になります。
動的制御フロー – 入力長に応じてループ回す等が自然に書ける

例: データ量に応じて処理を変えるオンチェーン認証
既存ライブラリ再利用 – sha2, ed25519-dalek, poseidon-rs など no_std クレートをそのままリンク

例: 既存の暗号ライブラリを使った複雑な証明
大規模ロジック – AI 推論やコンパイラ自己ホストなど数万行でも一括証明

例: プライバシー保護したAIモデル実行の証明
快適デバッグ – 普通の Rust テスト → Guest 化 …と段階移行

例: 通常のRustテストで動作確認後、そのままzkVM化
マルチステップ・プロトコル – env::read() / commit() を複数回呼び、対話を 1 receipt に凝縮

例: 複数のユーザー入力を受け付けるインタラクティブな証明
量子耐性＆透明性 – Trusted setup 不要で将来も安心

例: 長期的なセキュリティが必要なアプリケーション

 5. Host / Guest / Verifier モデルを理解する図1: zkVMの基本アーキテクチャ

 5.1 役割まとめ

役割
説明


Guest
「証明したい処理」そのもの。Rust → RISC‑V ELF → zkVM 内で実行

Host (Prover)
Guest を走らせて receipt を生成

Verifier
Receipt だけで真偽判定する第三者（スマコン、別サーバー等）


 5.2 関係図ここでのポイント:
Guestは「証明したい計算」そのもの
Hostはその計算を実行し証明を生成
Verifierは証明だけを検証
Bonsaiサービスを利用する場合、証明生成用のホストコードは不要（Bonsai側がゲスト実行と証明生成を代行）

 6. Hands‑on ① ― テンプレートをそのまま走らせてみるこのハンズオンで達成すること:
RISC Zero zkVMの開発環境をセットアップする
最小限のプロジェクトを実行して動作確認する

 6.1 ツールインストール# risczero CLI
cargo install --locked cargo-risczero

# zkVM ランタイム (rzup)
curl -L https://risczero.com/install | bash

# ローカルにプロバーを入れる
rzup install

# PATH反映
exec $SHELL -l

 6.2 プロジェクト作成（テンプレート）cargo risczero new demo-zkvm
cd demo-zkvm
ファイル構成の解説:

テンプレートには Guest / Host / build.rs / lib.rs が最小構成で用意されています。

 6.3 まずは"初期コード"を実行# ① Guest の ELF を生成
cargo risczero build --package guest

# ② Host が実行して証明→検証
cargo run -p host

 実行ログ例以下のような表示が確認できれば、成功です。
demo-zkvm % cargo run -p host

   Compiling methods v0.1.0 (/Users/demo-zkvm/methods)
method: Starting build for riscv32im-risc0-zkvm-elfethods(build)                                
method:    Compiling method v0.1.0 (/Users/demo-zkvm/methods/guest)
method:     Finished `release` profile [optimized] target(s) in 0.56s
   Compiling host v0.1.0 (/Users/demo-zkvm/host)
    Finished `dev` profile [optimized + debuginfo] target(s) in 2.37s
     Running `target/debug/host`
表6: 主要コマンドの解説


コマンド
ざっくり意味


cargo risczero build --package guest

Guest 専用バイナリ (RISC‑V ELF) を作る。Docker 上で no_std ビルドし、METHOD_ELF & METHOD_ID を生成するスクリプトも走る。

cargo run -p host

Host クレートをビルド & 実行。先ほど生成した ELF を読み込み、zkVM を回して receipt を生成し、その場で verify() する。

ポイント: ゲスト側を触らなければ ① は不要。ホストだけ書き換えた場合は cargo run -p host だけで OK。

 6.4 テンプレート内ファイルの役割

ファイル
役割 (一言)


methods/guest/src/main.rs

証明したいロジック本体。

host/src/main.rs

Prover & Verifier。テンプレでは入力なしで Guest を実行し receipt を即検証して表示。

methods/build.rs

ビルドスクリプト。embed_methods! が Guest をコンパイルして METHOD_ELF / METHOD_ID を auto‑gen。編集する機会は稀。

ここまででわかること
コマンド2つを覚えればひとまず動く
触るファイルは基本的に Guest / Host の2つだけ
基本的なワークフローはシンプル

 まとめzkVMは従来のzk-SNARKと比較して次のような点で優れています：

開発体験の向上 - 特殊なDSLではなく標準的なRustで開発可能

Trusted Setupが不要 - より透明性の高いセキュリティモデル

柔軟なプログラミングモデル - 動的なループや条件分岐が自然に書ける

量子耐性 - 将来的な量子コンピュータへの耐性が期待できる
一方で、いくつかの重要な課題も存在します：

証明サイズの増大 - 生のSTARK証明はzk-SNARKと比較して実際には1,000倍以上大きく（約200バイト対200KB以上）、オンチェーン利用には圧縮が必須

証明生成の計算コスト - ローカルでの大規模な証明生成は高負荷で、zkSNARKに比べて処理時間が長い

検証コスト - 未圧縮のSTARK検証はオンチェーンでは現実的でなく（数百万gas）、Groth16ラップで約28万gas程度まで削減できる
現状では、ローカルでの大規模な証明生成は計算負荷が高いですが、BonsaiやSteelなどのサービスを利用した本番環境での導入例（Automataなど）も登場しています。ただし、本番環境のプロダクトに利用するには、まだ用途がかなり限定される印象です。 技術の進化とハードウェアの向上に伴い、今後さらに普及が進むことが期待されます。

 おわりに最後までお読みいただきありがとうございます。

改めまして、naizoと申します。普段はブロックチェーン周りの開発をしています。
細々とブロックチェーン関連の記事を書いていますので、

よろしければぜひフォローしていただけると嬉しいです！
この記事が皆さんにとって、zkVMの開発に挑戦するきっかけになれば幸いです。

質問やフィードバックなどありましたら、コメントやSNSなどでお気軽にご連絡ください。
https://x.com/naizo_eth
https://zenn.dev/naizo01

特徴	メモ
STARK ベース	透明（trusted setup 不要）、既知の攻撃に対し量子耐性が期待できる
Rust ネイティブ	`cargo new` 感覚で始められる（公式サポートは Rust のみ）
証明サイズ	Hello World レベルの最小プログラムでも約32Kサイクルとなり、証明サイズは約200KB、数十万サイクルでは約270KB前後
圧縮 (Bonsai)	STARK証明をGroth16でラップすることで約0.5KB（512バイト）程度まで圧縮可能

コマンド	ざっくり意味
`cargo risczero build --package guest`	Guest 専用バイナリ (RISC‑V ELF) を作る。Docker 上で no_std ビルドし、`METHOD_ELF` & `METHOD_ID` を生成するスクリプトも走る。
`cargo run -p host`	Host クレートをビルド & 実行。先ほど生成した ELF を読み込み、zkVM を回して receipt を生成し、その場で `verify()` する。

ファイル	役割 (一言)
`methods/guest/src/main.rs`	証明したいロジック本体。
`host/src/main.rs`	Prover & Verifier。テンプレでは入力なしで Guest を実行し receipt を即検証して表示。
`methods/build.rs`	ビルドスクリプト。`embed_methods!` が Guest をコンパイルして `METHOD_ELF` / `METHOD_ID` を auto‑gen。編集する機会は稀。

✨メリット	🌪️課題
証明は「数百 byte」級で超コンパクト	Trusted setup が必須 – 破棄し忘れるとセキュリティ崩壊
検証がガス激安	回路 DSL を覚え、コンストレイント数を手動管理
—	量子計算への耐性がない（ペアリング暗号は Shor アルゴリズムで解ける）

観点	zk‑SNARK (Groth16)	zkVM (STARK)
Trusted setup	必要	不要
証明サイズ	使用する楕円曲線に依存：BN254で約128バイト、BLS12-381で約192バイト（一定）	200KB〜数MB（実行ステップ数に応じて増加）
検証ガス	約23万gas	未圧縮STARKは数百万gas（SNARKの10〜15倍）→ Groth16ラップで約28万gas
開発体験	回路DSL（CircomやZoKrates等）	Rust（公式サポート）
ループ / 再帰	事前展開が必要	動的に書ける
量子耐性	なし（楕円曲線ペアリングは量子計算で破られる可能性）	SHA-256やPoseidonハッシュを使用し、既知の攻撃に対し高い耐性あり

ケース	zk‑SNARK (Groth16)	zkVM (RISC Zero /STARK)	ざっくり倍率
最小プログラム (32K cycle)	≈ 192 B (BLS12-381)	≈ 201 KB	≈ 1,070 倍
256 K cycles	192 B	249.6 KB	≈ 1,330 倍
1M cycles	192 B	≈ 270 KB	≈ 1,430 倍

区分	zk‑SNARK (回路型)	zkVM (RISC Zero 例)	解説
入力（witness）	✅ 秘匿	✅ 秘匿	`env::read()` で渡したデータはreceiptには含まれません。
中間状態（メモリ・レジスタ・スタックなど）	✅ 秘匿	✅ 秘匿	実行トレースはSTARK証明にコミットされるだけで現物は公開されません。
プログラム本体	❌ 公開（回路はVerifying Keyに焼き付き）	✅ 秘匿可	ゲストELFはハッシュ化されImageIDだけが公開。コードを配布しなければロジック自体を秘匿したまま証明できます。
任意出力	回路が決め打ち	選択可	`env::commit()`した値だけがjournalに公開される。何を公開するかは開発者が制御。

役割	説明
Guest	「証明したい処理」そのもの。Rust → RISC‑V ELF → zkVM 内で実行
Host (Prover)	Guest を走らせて receipt を生成
Verifier	Receipt だけで真偽判定する第三者（スマコン、別サーバー等）

zkVMとは？

0. 雑におさらい ― zk‑SNARK は何が嬉しかった？

1. zkVM とは？

2. zk‑SNARK vs zkVM の比較

「何倍？」をざっくり数字で見る — 証明サイズ編

3. zkVMで「隠せるもの」

4. zkVM だからこそできること

5. Host / Guest / Verifier モデルを理解する

5.1 役割まとめ

5.2 関係図

6. Hands‑on ① ― テンプレートをそのまま走らせてみる

6.1 ツールインストール

6.2 プロジェクト作成（テンプレート）

6.3 まずは"初期コード"を実行

実行ログ例

6.4 テンプレート内ファイルの役割

まとめ

おわりに

Discussion