「暗号学の主流」とされるゼロ知識証明（ZKP）を批判する
TechFlow厳選深潮セレクト
「暗号学の主流」とされるゼロ知識証明（ZKP）を批判する
ZKシステムは、形式検証などのセキュリティツールやEcneなどの他のセキュリティ関連ツールと併用する必要がある場合があります。
Web3業界の深掘り報道に専念し潮流を洞察*注：これは1時間で書かれた草稿です。主に情報を素早くまとめるためのものであり、非常に多くの潜在的な誤りや不完全な情報が含まれている可能性があります。
ZKに対する主な批判は以下の2つです：
-
一つは証明生成に時間がかかる点（そのため、さまざまなベンチマークや新しいZKプロトコル、ハードウェア最適化が存在する）；
-
もう一つは、システムおよびアプリケーションのセキュリティがまだ十分に検証されていない点です。
証明生成性能
ゼロ知識証明（ZK）はブロックチェーン分野で非常に人気のある技術です。オンチェーンの計算リソースは希少かつ高価であるため、ZKはこれらの計算をオフチェーンで実行することを可能にします。オフチェーンでの証明生成には非常に長い時間がかかりますが、最終的な証明と関連する検証計算が圧縮されるため、計算が「オンチェーンで行われた」と見なすことができます。
ZKの証明生成時間が長くなる問題は、研究者や開発者によってしばしば軽視されます。なぜなら、これはZKが本質的に避けられないトレードオフだからです。
彼らはこの欠点を直接批判するわけではありませんが、その対策としてさまざまな解決策や議論を多数提案しています。
つまり、さまざまなソリューションを提示し、大量のベンチマークを行うことで、ZKの極めて長い証明時間について暗黙のうちに言及しているのです。
a) ベンチマーク
ZKアプリケーションのパフォーマンスを測定する前に、まずZKプロトコルの基盤となるコミットメント方式の性能をテストする必要があります。
例えば、FRIはSTARKを生み出し、KZGは通常のSNARKを、IPAはBulletproofを生み出します。基盤となるコミットメント方式の性能テストは、ZKアプリケーションのパフォーマンスには直感的ではありませんが、ZKの証明時間が長い理由を理解する上で非常に役立ちます。
上記のリンクからわかるように、これらの基盤プロトコルは計算が複雑であるだけでなく（証明時間を長くする原因となる）、メモリ消費量も非常に大きいという問題があります。
もちろん、メモリ消費はハードウェア構成要件との関係が深く、今日のテーマとは異なります。
具体的なSNARKのパフォーマンステストに関して、a16z cryptoはこれをフロントエンドとバックエンドに分けました：
-
フロントエンドは、Cairo言語やzkVMなどの高級言語で、ZKアプリケーション開発者が直接扱う部分；
-
バックエンドは、SNARK証明生成時間に近い、コミットメントなどの低レベルな暗号操作です。
著者は、SNARKの証明生成には約100倍の計算オーバーヘッドがあると述べており、各ZKプロトコルにはさらに追加のオーバーヘッドがあります。例えば：
「Groth16では、Pはペアリングフレンドリーな群上で動作しなければならないが、その演算は通常ペアリング非対応の群よりも少なくとも2倍遅い。これにより、前述の100-|C|推定値に対してさらに最低6倍の遅延が生じる。」
全体として、zk-SNARKの追加的なパフォーマンスオーバーヘッドは200〜1000倍の範囲にあると言えます。
また、この記事ではzk-SNARKの他の制限事項、例えば信頼できるセットアップやメモリ使用量についても言及しています。
Modulus Labsの記事では、いくつかのZKプロトコルの実際のパフォーマンスを測定しています。一部のベンチマークはパラメータ数に基づいており、直感的ではありません。しかし、アプリケーションにおいて、Worldcoinのユースケースでは、「最速」とされるPlonky2を使用しても、証明生成に数分かかり、数十GBのメモリを消費するため、個人用PCでは実行できないと述べています。
b) 再帰とバッチ処理
証明生成時間を短縮するために、複数の証明を並列に生成できます。
一般的に、これを行う方法は2つあります：1つはバッチ処理、もう1つは再帰です。
簡単に言えば、バッチ処理は複数の証明を同時に生成し、最後にそれらを集約する方法であり、再帰は1つの証明内で他の証明を検証する方法です。一般に、再帰的手法はさらに小さな証明サイズという利点を持ちます。
より一般的な集約手法にはHalo2、Plonky2などがあります。これらはそれぞれ異なる方法でバッチ処理と再帰を実装しており、証明時間を短縮しています。
ZKのプロトコル層だけでなく、アプリケーション層でも特定の最適化が可能です。例えば、複数のZKプロトコル（STARK + SNARK）を同時に使用したり、マクロレベルで再帰戦略を採用してアプリケーション固有のチューニングを行うことができます。
一般に、これはプロトコルと証明の分配に関する観点からの証明生成時間を実際に短縮しています。新しいZKプロトコルを探求する際、証明時間の短縮は最も重要な考慮事項です。
c) ハードウェアアクセラレーション
さらに、ハードウェアの観点からも、ZKアプリケーションの物理的・ノードレベルでの証明時間を短縮するための多くの取り組みが行われています。
まず、前述の新しいプロトコルと同様に、HyperPlonkのように、可能な限りハードウェアに優しい設計を目指したZKプロトコルが開発されています。
Paradigmによると、ZKの証明生成が遅い主な原因は、大量のMSM（Multi-Scalar Multiplication）とFFT（高速フーリエ変換）が関与しており、これらはハードウェアに不向きで、ランダムなメモリアクセスなどが原因で最終的な証明生成速度が低下すると指摘しています。このような低レベルの暗号計算では、ZKプロトコルが構成や規模において何らかのトレードオフを行い、ハードウェアに優しくすることが必要です。
いくつかのZKハードウェアアクセラレーション企業は、GPUが現在最も経済的で柔軟なハードウェア選択肢だと述べており、将来的にはFPGAからASIC段階へ移行していくと考えられています。ZKハードウェア企業によれば、初版のASICでZK証明生成時間を少なくとも30％削減できるとされています。
さらに、異なるサーバー構成により、クラウドサーバーをノードとして運用する場合、ハードウェア固有の最適化が必要になることもあります。
セキュリティ
ZKに対するもう一つの批判は、回路コード自体が正しくなければならない（バグがないこと）という点です。
ZKプロトコルが健全性、完全性、ゼロ知識性のいずれかの観点から攻撃された場合、有効なZKシステムではなくなります。このリンクでは、さまざまな攻撃の例を見ることができます。
ZKアプリケーションはtrustlessと呼ばれるかもしれませんが、プロジェクトのZKプロトコルやアプリケーションのコード・アーキテクチャが正しいことを依然として保証する必要があります。ブロックチェーン分野では、複数のZK関連のエラーが存在します。例えば、zkEVMのZK回路コードベースが非常に巨大である問題に対し、VitalikはZKアプリケーションにおけるマルチプルプルーバーの必要性について言及しています。
したがって、ZKシステムは形式的検証などのセキュリティツールやEcneなどの他のセキュリティ関連ツールと併用する必要があるかもしれません。アプリケーションレベルでは、特にzkEVMのような大規模プロジェクトに対して、さらなる監査が必要です。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
msfew / Suning Yao
