a16z：zkVMの安全で効率的な実現を段階的に進める方法とは？
TechFlow厳選深潮セレクト
a16z：zkVMの安全で効率的な実現を段階的に進める方法とは？
開発者必見。
Web3業界の深掘り報道に専念し潮流を洞察執筆：a16z crypto
翻訳：Odaily 星球日報 Golem
zkVM（ゼロ知識仮想マシン）は「SNARKの民主化」を約束しており、専門的なSNARK知識を持たない人でも、特定の入力（またはワitness）上で任意のプログラムが正しく実行されたことを証明できるようにすることを目指しています。その最大の利点は開発者体験にありますが、現在は安全性とパフォーマンスの両面で大きな課題に直面しています。zkVMのビジョンが真に実現するためには、設計者はこれらの課題を克服しなければなりません。本稿では、zkVM開発のあり得る段階を提示します。これらを達成するには数年かかるでしょう。
課題
安全性の観点から見ると、zkVMは非常に複雑なソフトウェアプロジェクトであり、依然として多数のバグを内包しています。パフォーマンスの観点では、プログラムの正しさを証明する速度が、ローカル実行に比べて数十万倍遅くなる可能性があり、これにより大多数のアプリケーションは現時点では実用的な展開が困難です。
こうした現実的な課題があるにもかかわらず、ブロックチェーン業界の多くの企業はzkVMを即時展開可能な技術として描いています。実際、一部のプロジェクトは大量の計算コストを支払ってオンチェーン活動の証明を生成しています。しかし、zkVMはまだ不完全であるため、これは単にSNARKによってシステムが保護されているふりをする高価な方法にすぎず、実際には許可制によって守られているか、あるいはそれより悪いことに攻撃に対して脆弱な状態にある可能性があります。
安全かつ高性能なzkVMの実現までには、まだ数年の時間がかかります。本稿では、zkVMの進捗を追跡するための具体的な段階的目標を提示します。これらの目標は過剰な宣伝を取り除き、コミュニティが真の進歩に集中するのを助けます。
セキュリティ段階
SNARKベースのzkVMは通常、以下の2つの主要コンポーネントから構成されます：
-
多項式インタラクティブオラクル証明 (PIOP)：多項式（またはそこから導出される制約）に関する主張を証明するためのインタラクティブな証明フレームワーク。
-
多項式コミットメント方式 (PCS)：証明者が多項式の評価に関して発見されずに嘘をつくことができないようにする仕組み。
zkVMは、有効な実行トレースを制約システムとして符号化し—広い意味では、仮想マシンがレジスタやメモリを正しく使用していることを強制する—その後SNARKを適用して、これらの制約が満たされることを証明します。
zkVMのような複雑なシステムにエラーがないことを保証する唯一の方法は形式的検証です。以下にセキュリティ段階の詳細を示します。第1段階は正しいプロトコルに焦点を当て、第2段階および第3段階は正しい実装に焦点を当てます。
セキュリティ段階 1 ：正しいプロトコル
-
PIOPの健全性についての形式的検証による証明；
-
特定の暗号学的仮定または理想モデルのもとで、PCSが拘束的であることを示す形式的検証による証明；
-
Fiat-Shamirを使用する場合、PIOPとPCSを組み合わせることで得られる簡潔なアргументが、ランダムオラクルモデルにおいて安全であることを示す形式的検証による証明（必要に応じて他の暗号学的仮定を補強）；
-
PIOPが適用される制約システムがVMの意味論と等価であることを示す形式的検証による証明；
-
上記のすべての部分を包括的に「結合」し、VMバイトコードで指定された任意のプログラムを実行するための単一の、形式的に検証された安全なSNARK証明を作成する。プロトコルがゼロ知識を実現する意図である場合、ワitnessに関する機密情報が漏れないことも形式的に検証しなければならない。
再帰に関する注意：zkVMが再帰を使用する場合、この段階を完了するには、再帰内で関与するすべてのPIOP、コミットメント方式、制約システムも検証しなければなりません。
セキュリティ段階 2 ：正しい検証器実装
zkVM検証器の実際の実装（Rust、Solidityなど）が第1段階で検証されたプロトコルと一致することを、形式的検証で証明する。これを実現することで、実装されたプロトコルが妥当であることが保証されます（紙上の設計やLeanなどで書かれた非効率な仕様ではなく）。
第2段階が検証器の実装（証明器ではない）にのみ注目するのは二つの理由からです。第一に、検証器を正しく使用すれば信頼性（つまり、検証器が偽の主張を真であると信じてしまうことの防止）を保証できます。第二に、zkVM検証器の実装は証明器の実装に比べて桁違いに単純だからです。
セキュリティ段階 3 ：正しい証明器実装
zkVM証明器の実際の実装が、第1段階および第2段階で検証された証明システムの証明を正しく生成することを、形式的に検証する。これにより完全性が保証され、つまりzkVMを使用するシステムが証明不可能な文によって「停止」することはありません。証明器がゼロ知識を実現する意図である場合、この性質も形式的に検証しなければなりません。
予想されるタイムライン
第1段階の進捗：来年には段階的な成果（例：ZKLib）が期待できます。しかし、少なくとも2年以内に第1段階の要件を完全に満たすzkVMは存在しません。
第2および第3段階：これらの段階は第1段階の一部と並行して進めることができます。例えば、いくつかのチームはPlonk検証器の実装が論文のプロトコルと一致することをすでに証明しています（ただし、論文のプロトコル自体が完全に検証されているとは限りません）。それでも、どのzkVMも4年以内に第3段階に到達することはないと予想され、おそらくさらに長くなるでしょう。
重要な注意点：Fiat-Shamirの安全性と検証済みバイトコード
主要な複雑さの一つは、Fiat-Shamir変換の安全性に関する未解決の研究問題です。すべての3段階はFiat-Shamirとランダムオラクルをその無欠な安全性の一部として扱いますが、実際にはこの枠組み全体に脆弱性が存在する可能性があります。これは、ランダムオラクルが過度に理想化されており、実際に使用されるハッシュ関数との間に差異があるためです。最悪の場合、Fiat-Shamirの問題により、第2段階に到達したシステムが後になって完全に安全でないことが判明する可能性があります。これは深刻な懸念事項であり、継続的な研究が必要です。このような脆弱性をよりよく防ぐために、変換自体を修正する必要があるかもしれません。
再帰を使用しないシステムは理論的により堅牢です。なぜなら、既知のいくつかの攻撃は再帰的証明で使用される回路と類似した回路を対象としているからです。
もう一点注目に値するのは、バイトコード自体に欠陥がある場合、コンピュータプログラムが正しく実行された（バイトコードで指定された）という証明の価値は限定的だということです。したがって、zkVMの有用性は大きく、形式的に検証されたバイトコードを生成する方法に依存しています。これは巨大な課題であり、本稿の範囲を超えています。
ポスト量子時代の安全性について
少なくとも今後5年間（おそらくそれ以上）、量子コンピュータは重大な脅威とはなりませんが、バグは生存リスクです。したがって、現在の主な重点は、本稿で議論した安全性とパフォーマンスの段階を満たすことです。非量子安全なSNARKを使ってこれらの安全性要件をより早く満たせるのであれば、そうすべきです。ポスト量子SNARKが追いつくか、暗号関連の量子コンピュータが現実的な懸念になるまでは。
zkVMのパフォーマンス現状
現在、zkVM証明器が生み出すオーバーヘッド係数は、ネイティブ実行コストの約100万倍に近づいています。プログラムがXサイクルで実行される場合、その正しさを証明するコストは約X × 100万CPUサイクルになります。これは1年前と同じ状況であり、今日も変わっていません。
一般的な説明は、このオーバーヘッドを受け入れ可能に聞こえるように描写することが多いです。例えば：
-
「すべてのイーサリアムメインネットの証明を年間で生成するコストは100万ドル未満である。」
-
「数十台のGPUからなるクラスタを使って、ほぼリアルタイムでイーサリアムブロックの証明を生成できる。」
-
「最新のzkVMは前世代より1000倍高速になった。」
技術的にはこれらの主張は正確ですが、適切な文脈なしでは誤解を招く可能性があります。例えば：
-
旧zkVMより1000倍速くても、絶対速度は依然として非常に遅い。これはむしろ状況がどれほど悪いのかを示しており、どれほど良いのかを示しているわけではありません。
-
イーサリアムメインネットの処理能力を10倍に増やす提案がすでに出されています。これにより、現在のzkVMのパフォーマンスはさらに遅くなります。
-
「イーサリアムブロックのほぼリアルタイム証明」と言われているものでも、多くのブロックチェーンアプリケーションが求める速度よりはるかに遅い（例：Optimismのブロック時間は2秒で、イーサリアムの12秒よりもはるかに速い）。
-
「数十台のGPUを常にエラーなく稼働させる」ことは、受け入れ可能な活性保証に達していません。
-
年間100万ドル未満でイーサリアムメインネットのすべての活動を証明することは、イーサリアムのフルノードが年間約25ドルの計算コストしかかからないという事実を反映しています。
ブロックチェーン以外のアプリケーションでは、このようなオーバーヘッドは明らかに高すぎます。並列化や工学的手法では、これほどの巨大なオーバーヘッドを相殺できません。我々は、ネイティブ実行と比較して、zkVMの速度低下が10万倍以内であることを基本的なベンチマークとするべきです—たとえそれが最初の一歩にすぎなくても。真の主流採用には、1万倍またはそれ以下のオーバーヘッドが必要になるでしょう。
パフォーマンスの測定方法
SNARKのパフォーマンスには3つの主要な構成要素があります：
-
基盤となる証明システムの内在的効率。
-
アプリケーション固有の最適化（例：プリコンパイル）。
-
工学的およびハードウェアアクセラレーション（例：GPU、FPGA、マルチコアCPU）。
後者の2つは実用的な展開に不可欠ですが、いずれの証明システムにも一般に適用可能であるため、必ずしも基本的なオーバーヘッドを反映しているわけではありません。例えば、zkEVMにGPUアクセラレーションとプリコンパイルを追加すれば、簡単に50倍の加速が可能です。これは純粋なCPUベースでプリコンパイルなしの方法よりもはるかに速く、本質的に効率の低いシステムでも、同程度に手を入れられていないシステムより優れているように見えます。
したがって、以下では専用ハードウェアやプリコンパイルを使わない場合のSNARKのパフォーマンスに焦点を当てます。これは、通常すべての3つの要因を1つの「目玉数字」にまとめてしまう現在のベンチマーク手法とは異なります。それはまるで、ダイヤモンドの価値をその本質的な純度ではなく、研磨にかかる時間で判断するようなものです。私たちの目的は、汎用証明システムの内在的オーバーヘッドを除外し、コミュニティが混在要因を排除して、証明システム設計の真の進歩に集中できるようにすることです。
パフォーマンス段階
以下は、パフォーマンス実現のための5つのマイルストーンです。まず、CPU上の証明器オーバーヘッドを複数桁削減しなければなりません。それから、ハードウェアによるさらなる削減に重点を移すべきです。メモリ使用量も改善されなければなりません。
以下のすべての段階において、開発者はzkVM設定に合わせてカスタムコードを書く必要はありません。開発者体験はzkVMの主要な利点です。DevExを犠牲にしてパフォーマンス基準を満たすことは、zkVM自体の意義を損ないます。
これらの指標は証明器コストに焦点を当てています。しかし、検証器コストに制限がない場合（つまり、証明サイズや検証時間に上限がない場合）、どのような証明器指標も簡単に満たせてしまいます。したがって、各段階に該当するシステムは、証明サイズと検証時間の最大値を明確に指定しなければなりません。
パフォーマンス要件
第1段階の要件：「合理的かつ非自明な検証コスト」：
-
証明サイズ：証明サイズはワitnessサイズより小さくなければならない。
-
検証時間：証明の検証速度は、プログラムのネイティブ実行（つまり、正しさの証明なしで計算を実行する）よりも遅くなってはならない。
これらは最低限の簡潔性の要件です。これらは、証明サイズと検証時間が、ワitnessを検証者に送信して直接チェックさせる方法よりも劣らないことを保証します。
第2段階以降の要件：
-
最大証明サイズ：256 KB。
-
最大検証時間：16ミリ秒。
これらの上限値は、新しい高速証明技術により検証コストが高くなる可能性を考慮して意図的に余裕を持たせています。同時に、あまりにも高価すぎてほとんどプロジェクトがブロックチェーンに取り入れることを望まないような証明は排除しています。
速度段階 1
単一スレッドの証明は、プリコンパイルに依存せず、さまざまなアプリケーション（イーサリアムブロックの証明だけではない）で測定した場合、ネイティブ実行より最大10万倍遅くなければならない。
具体的には、現代のノートパソコンで毎秒約30億サイクルで動作するRISC-Vプロセッサを想像してください。第1段階を達成するとは、同じノートパソコン上で毎秒約3万のRISC-Vサイクル（シングルスレッド）を証明できることを意味します。ただし、検証コストは前述の通り「合理的かつ非自明」でなければなりません。
速度段階 2
単一スレッドの証明は、ネイティブ実行より最大1万倍遅くなければならない。
あるいは、有望なSNARK手法のいくつか（特にバイナリフィールドに基づくもの）は現在のCPUやGPUの制約を受けているため、FPGA（あるいはASIC）を使用して比較してもよい：
-
FPGAがネイティブ速度でシミュレートできるRISC-Vコアの数；
-
RISC-Vの（ほぼ）リアルタイムでのシミュレーションと証明に必要なFPGAの数。
後者が前者より最大1万倍多くてもよい場合、第2段階に合格します。標準CPU上では、証明サイズは最大256KB、検証時間は最大16ミリ秒でなければなりません。
速度段階 3
速度段階2に到達するだけでなく、自動合成および形式検証されたプリコンパイルを使用して、広範なアプリケーションに対して1000倍未満の証明オーバーヘッドを実現できること。本質的には、各プログラムに対して命令セットを動的にカスタマイズして証明を高速化できるが、使いやすく、形式的に検証可能な方法で行われること。
メモリ段階 1
証明器に必要なメモリが2GB未満の状態で、速度段階1を達成すること（ゼロ知識も同時に実現）。
これは多くのモバイルデバイスやブラウザにとって重要であり、無数のクライアント側zkVMユースケースを開きます。クライアント側での証明生成は重要です。なぜなら、私たちのスマートフォンは現実世界との継続的な接点であり、位置情報や認証情報などを追跡しているからです。証明生成に2GB以上のメモリが必要であれば、現在のほとんどのモバイルデバイスにとっては多すぎます。2点を明確にします：
-
2GBの空間制限は、数兆CPUサイクルを必要とする大規模な文に対象を絞ります。小規模な文に対してのみ空間制限を達成する証明システムは、広範な適用性を持ちません。
-
証明器が非常に遅い場合、簡単に2GB以下のメモリに収まります。したがって、メモリ段階1を単純なものにしないために、2GBの空間制限内で速度段階1を満たすことを要求します。
メモリ段階 2
速度段階1が、メモリ使用量が200MB未満の状態で達成されること（メモリ段階1より10倍良好）。
なぜ2GB以下を目指すのか？ ブロックチェーン以外の例を考えます：HTTPSでサイトにアクセスするたびに、認証と暗号化のために証明書をダウンロードします。代わりに、サイトはこれらの証明書を所有していることのzk証明を送信できます。大規模なサイトでは、毎秒数百万のそのような証明を発行する可能性があります。各証明の生成に2GBのメモリが必要なら、合計でPB級のRAMが必要になります。非ブロックチェーン用途への展開には、さらにメモリ使用量を削減することが不可欠です。
プリコンパイル：最後の一マイルか、杖か？
zkVM設計におけるプリコンパイルとは、特定の機能向けに特別に設計された専用SNARK（または制約システム）を指します。例えば、デジタル署名のためのKeccak/SHAハッシュや楕円曲線群演算などです。イーサリアムでは（大部分の重い作業がMerkleハッシュと署名チェックに関係するため）、いくつかの手作りのプリコンパイルで証明器のオーバーヘッドを減らすことができます。しかし、それを杖のように依存しても、SNARKが目指すべき場所に到達できません。理由は以下の通りです：
-
ほとんどのアプリケーション（ブロックチェーン内外問わず）にとって依然として遅い：ハッシュと署名のプリコンパイルを使用しても、現在のzkVMは依然として遅く（ブロックチェーン内でも外でも）、基盤となる証明システムの効率が低いためです。
-
セキュリティ障害：正式検証されていない手書きのプリコンパイルは間違いなくバグだらけであり、壊滅的なセキュリティ障害につながる可能性があります。
-
開発者体験が悪い：現在のほとんどのzkVMでは、新しいプリコンパイルを追加するには各機能ごとに制約システムを手動で書く必要があります—本質的には1960年代スタイルのワークフローに戻ってしまいます。既存のプリコンパイルを使用する場合でも、開発者は各プリコンパイルを呼び出すためにコードを再構築しなければなりません。私たちは安全性と開発者体験を最適化すべきであり、インクリメンタルなパフォーマンスのためにこれらを犠牲にしてはいけません。そうすることは、パフォーマンスが本来あるべきレベルに達していないことを示しているにすぎません。
-
I/OオーバーヘッドとRAMの欠如：プリコンパイルは重い暗号タスクのパフォーマンスを向上させますが、入出力の伝送時に大きなオーバーヘッドが生じ、RAMを使用できないため、より多様なワークロードには有意義な加速を提供できない可能性があります。ブロックチェーン環境内であっても、イーサリアムのようなモノリシックL1を超えて（例：クロスチェーンブリッジのシリーズを構築したい場合）、異なるハッシュ関数や署名スキームに直面します。問題ごとに繰り返しプリコンパイルを行うことは拡張性がなく、巨大なセキュリティリスクを伴います。
これらの理由すべてから、私たちの最優先事項は、基盤となるzkVMの効率を向上させることです。最高のzkVMを生み出す技術は、最高のプリコンパイルも生み出します。長期的にはプリコンパイルが依然として重要になると信じていますが、それは自動合成され、形式的に検証された場合に限ります。これにより、zkVMの開発者体験の利点を維持しつつ、壊滅的なセキュリティリスクを回避できます。この見解は速度段階3に反映されています。
予想されるタイムライン
少数のzkVMが今年後半に速度段階1およびメモリ段階1を達成すると予想しています。また、2年以内に速度段階2を達成できると考えますが、まだいくつか登場していない新アイデアがなければ達成できない可能性もあります。残りの段階（速度段階3およびメモリ段階2）の達成にはさらに数年かかると予想しています。
まとめ
本稿では、zkVMの安全性とパフォーマンスの段階を別々に特定しましたが、これら2つの側面は完全に独立しているわけではありません。zkVMでさらなるバグが発見されるにつれ、一部のバグはパフォーマンスが大幅に低下しない限り修復できない可能性があります。zkVMがセキュリティ段階2に到達するまでは、パフォーマンスの追求は控えるべきです。
zkVMはゼロ知識証明を真に普及させる可能性を秘めていますが、まだ始まったばかりであり、セキュリティの課題と巨大なパフォーマンスオーバーヘッドに満ちています。過剰な宣伝とマーケティングは、真の進捗を評価するのを難しくしています。明確な安全性とパフォーマンスのマイルストーンを提示することで、邪魔なノイズを取り除くロードマップを提供したいと思います。目標は達成できますが、そのためには時間と継続的な努力が必要です。
TechFlow公式コミュニティへようこそ
Telegram購読グループ：https://t.me/TechFlowDaily
Twitter公式アカウント：https://x.com/TechFlowPost
Twitter英語アカウント：https://x.com/BlockFlow_News
a16z
