Skip to main content
Midnight こども学園

原文準拠 Phase 2：ゼロ知識証明

1.2 ゼロ知識証明の方式

Midnight Academy Phase 2 / Unit 1 / 1.2 の原文準拠版。Bulletproofs・Groth16・Plonk・STARKs を、証明サイズ・証明時間・検証時間・信頼セットアップの4軸で正確に比較し、Midnight が Plonk 系（Halo 2）を選ぶ理由まで。

📘 Academy原文準拠 ｜ Phase 2 · Unit 1 · Lesson 1.2 Zero-Knowledge Proof Systems 内容に忠実な日本語版です。原文（英語）・図・動画は公式 Academy（外部リンク・別タブで開きます）を正本に。

いまのゼロ知識証明（Zero-Knowledge Proof）の方式は、性能の特徴も、必要な信頼の前提も、システムごとに大きくちがいます。カテゴリの境目はあいまいになりがちですが、ほとんどのシステムは次の4つの観点で比べられます。

  • 証明サイズ（Proof size）：証明はバイト数でどれくらい大きいか？
  • 証明時間（Prover time）：証明を作るのにどれくらいかかるか？
  • 検証時間（Verifier time）：証明をどれくらい速く検証できるか？
  • 信頼セットアップ（Trusted setup）：特別なセットアップ儀式（不正されていないと信頼しないといけないもの）が必要か？

代表的なシステムをいくつか比べてみましょう。

STARKs・Bulletproofs・Plonk・Groth16の4方式を、証明サイズ・検証速度・セットアップの要否・耐量子性などの観点で並べたZKPシステム比較表

方式 信頼セットアップ 証明サイズ 検証 ひとことで
Bulletproofs 不要 小さい文には小さいが、文の複雑さで増大（succinct ではない）（〜2〜20 KB+） やや遅い Monero で利用
Groth16（zk-SNARK） 必要・回路ごと とても小さい（〜200 バイト） 速い アプリごとに儀式が要る
Plonk（zk-SNARK） 一度だけ（使い回せる） Groth16 よりやや大きい Groth16 よりやや遅い 共有インフラ向き
STARKs 不要（transparent） 大きい（〜100〜200 KB） わりと速い オフチェーンのバッチ計算向き

Bulletproofs

信頼セットアップが不要で、小さな文（statement）に対してはコンパクトです。ただし、証明サイズは文の複雑さとともに大きくなる（＝ succinct ではない）という弱点があります。検証はやや遅く、証明サイズ（〜2〜20 KB+）は大きなプログラムには実用的でなくなります。Monero で使われています。

Groth16（zk-SNARK）

とても小さな証明（〜200 バイト）と速い検証が特長ですが、回路ごとの信頼セットアップ（circuit-specific trusted setup）が必要です。つまり、新しいアプリケーションごとに、それ専用のセットアップ儀式が要ります。

参考までに、信頼セットアップ儀式（trusted setup ceremony）とは、証明システムを成立させる暗号パラメータを作るために乱数を生成する、一度きりのプロセスのことです。システム全体を動かす「マスターキー」を作るイメージですが、落とし穴があります。その乱数（“toxic waste” と呼ばれる毒物）を知っている者は、偽の証明を作れてしまうのです。

トラステッド・セットアップ・セレモニーのフロー図。参加者1〜3がそれぞれランダムな数値を生成し、すべての乱数を結合して公開パラメータを作成、トキシック・ウェイストを破棄してZKPシステムの準備完了に至る。トキシック・ウェイストが残ると偽の証明を作成できるというリスク注記付き

これを防ぐため、セットアップ儀式には複数の参加者が加わり、それぞれが乱数（ランダムさ）を持ち寄ります。たった1人でも自分の分の toxic waste を正直に破棄すれば、システムは安全に保たれます。

Zcash の儀式は有名で、参加者を複数の大陸にまたがって配置し、放射性崩壊（radioactive decay）や溶岩ランプ（lava lamps）まで使って乱数を生成し、使ったコンピューターを物理的に破壊しました。

問題は、少なくとも1人が正直だったと信頼するしかない点です。もし全員が共謀した（あるいは全員が侵害された）場合は、偽の証明が可能になってしまいます。だからこそ、この要件をそもそも持たない “transparent” なシステム（STARKs など）が魅力的に映るのです。証明サイズが大きくなるなど、別のトレードオフはあったとしても。

Plonk（zk-SNARK）

ユニバーサルな SNARK です。証明は Groth16 よりやや大きく、検証もやや遅いですが、必要な信頼セットアップは一度だけ（複数のアプリで使い回せる）です。そのため、複数のアプリケーションが同じインフラを共有する Midnight のようなエコシステムには、より実用的です。

Halo 2 は Plonk の実装の1つで、特定の多項式コミットメント方式（polynomial commitment scheme）を採用しており、再帰的な証明（recursive proofs）をサポートし、特定のバックエンドと組み合わせると信頼セットアップを回避できます。

STARKs

transparent（信頼セットアップ不要）で、ポスト量子安全（post-quantum secure）、そして prover にとってスケーラブルです。ただし、ZK の性質は明示的に追加する必要があり、証明は大きく（〜100〜200 KB）なります。検証はわりと速く、オフチェーンでの計算のバッチ処理（例：StarkNet）に向いていますが、証明サイズとプライバシー保証が決定的に重要な Midnight のようなユースケースには、あまり理想的ではありません。

まとめ：実システムはアイデアを混ぜている

ひとことで言うと、zk-SNARK と zk-STARK はよく対比されますが、現実のシステムはアイデアを混ぜ合わせています。

  • Bulletproofs は、スケーラビリティと透明性という点で STARKs に似ていますが、succinct ではありません。
  • Plonk は SNARK 系に属しますが、汎用アプリケーション向けにより良いトレードオフを提供します。

Midnight のようなプライバシー重視のチェーンにとっては、再帰能力（recursive capability）があり、回路ごとのセットアップが不要な SNARK システムが理想的です。だからこそ、Plonk 由来のシステム（例：Halo 2）が選ばれています。

たとえ：配送方法を選ぶように

ZKP システムを選ぶのは、配送方法を選ぶのに似ています。

方式 たとえ
Bulletproofs 普通の郵便。特別な準備は要らないが、荷物のサイズは中身とともに大きくなる
Groth16 プレミアムの速達。荷物は小さく配達も速いが、ルートごとにセットアップが高くつく
Plonk 標準的な宅配便。荷物はやや大きいが、すべてを1つの配送ネットワークでまかなえる
STARKs 貨物輸送。巨大な荷を安全に扱えるが、コンテナは常に大きい

開発者として押さえる点

  • 方式を比べる軸は4つ：証明サイズ / 証明時間 / 検証時間 / 信頼セットアップ。境目はあいまいで、実システムはアイデアを混ぜる
  • Groth16 は証明〜200 バイトと最小だが回路ごとの信頼セットアップが要る。Plonk は一度だけ・使い回せるセットアップで、汎用アプリ向けのトレードオフが良い
  • 信頼セットアップの肝は toxic waste。1人でも正直に破棄すれば安全だが、全員共謀・侵害なら偽証明が可能。これを避けるのが STARKs の transparent という性質
  • STARKs は transparent・ポスト量子安全だが証明が大きい（〜100〜200 KB）。プライバシーと証明サイズが効く Midnight には不向き
  • Midnight の選択は Plonk 由来の Halo 2：再帰的証明に対応し、回路ごとセットアップ不要。複数アプリが同じインフラを共有する設計に合う

やさしい版・公式へ

つぎに読むページ

➡️ 原文準拠コースの入口へ戻る。このコースについて（次のレッスンは順次追加します）