Author: Justin Thaler Source: a16z Translated by Good Oba, Golden Finance
Zero Knowledge Virtual Machines (zkVMs)は、「SNARKを大衆に提供する」ことを目的としている。「SNARKの専門知識を持たない人でも、特定の入力（または証人）に対して正しくプログラムを実行したことを証明できるようにする。その中核となる強みは開発者の体験ですが、現在のところ zkVM は、セキュリティとパフォーマンスにおいてまだ大きな課題に直面しています。zkVM がその約束を果たすには、設計者はこれらの障害を克服しなければなりません。この記事では、何年もかかるかもしれないプロセスである zkVM 開発の可能な段階を探ります。
課題
セキュリティ 面では、zkVM は非常に複雑なソフトウェア プロジェクトであり、まだ脆弱性に満ちています。脆弱性に満ちています。
パフォーマンスの面では、プログラムの正しい実行は、ネイティブで実行するよりも何十万倍も遅くなる可能性があることが判明しており、ほとんどのアプリケーションの実世界への展開を今のところ実現不可能にしています。>.
にもかかわらず、ブロックチェーン業界の多くの声は、zkVMはすでに即座にデプロイする準備ができているという事実を宣伝し続けており、一部のプロジェクトでさえ、オンチェーン活動のゼロ知識証明を生成するために、すでに高い計算コストを支払っています。しかし、zkVM にはまだ多くの脆弱性が存在するため、このアプローチは、実際には特権制御に依存しているか、より悪いことにSNARKにさらされているにもかかわらず、システムが SNARK によって保護されているように見せかけるための高価な偽装にすぎません。攻撃リスクにさらされるのです。
真にセキュアで効率的なzkVMを構築するには、まだ何年もかかるというのが現実です。このペーパーでは、zkVM の本当の進歩を追跡し、誇大広告を弱め、真のブレークスルーにコミュニティの注意を向けるのに役立つ、一連の具体的かつ段階的な目標を提案します。
Security development stages
Background
SNARK に基づく zkVM は通常、2 つのコアコンポーネントを含んでいます:
1.Polynomial Interactive Oracle Proof, PIOP）：多項式（または多項式から派生した制約）を証明するための対話型証明フレームワーク。
2. 多項式コミットメントスキーム(Polynomial Commitment Scheme: PCS): 検出されることなく、証明者が多項式の評価を改竄できないことを保証する。
zkVMは、VMのレジスタとメモリの正しい使用を、有効な実行軌跡を制約のシステムとして符号化し、次に、これらの制約の満足度を証明するためにSNARKを使用することによって保証します。SNARKを使用して、これらの制約の満足度を証明します。
このような複雑なシステムにおいて、zkVM が脆弱でないことを保証する唯一の方法は形式的な検証です。ここでは、フェーズ 1 はプロトコルの正しさに焦点を当て、フェーズ 2 と 3 は実装の正しさに焦点を当てます。
セキュリティ ステージ 1: 正しいプロトコル
。PIOP の信頼性の正式な検証証明
PCSが特定の暗号学的仮定または理想モデルのもとで拘束力を持つことの正式な検証証明
フィアット・シャミールを使用する場合、PCSの信頼性を証明する必要があります。
PIOPとPCSを組み合わせて得られる簡潔な議論は、確率的述語モデル（必要に応じて他の暗号的仮定で補強される）において安全である形式的検証証明である。
VMバイトコードで指定された任意のプログラムを実行するために、これらのすべての部分を単一の、正式に検証された、安全なSNARK証明に包括的に「接着」します。プロトコルがゼロ知識であることを意図している場合、この属性も、証人に関する機密情報が開示されないことを保証するために、正式に検証されなければなりません。
zkVMが再帰を使用する場合、再帰中に関与するPIOP、コミットメントスキーム、および制約システムは検証されなければなりません。strong>でなければ、サブフェーズが完了したとは見なされません。
Security Phase 2: 正しいバリデータの実装
このフェーズでは、zkVM バリデータ (たとえば、Rust、Solid) の実際の実装を検証する必要があります。実装 (例: Rust、Solidity など) が formal validation を実行し、最初のフェーズですでに検証されたプロトコルに準拠していることを確認します。このフェーズの完了は、zkVMの実装が理論的設計と一致していることを意味し、単なる紙の上のセキュリティプロトコルや、Leanのような言語で書かれた非効率な仕様ではありません。
検証者だけに焦点を当て、証明者には焦点を当てないことが重要である主な理由は2つあります：第1に、検証者が正しいことを保証することは、zkVM証明システムの完全性を保証します（すなわち、検証者がだまされて間違った証明を受け入れることができないことを保証します）。偽の証明を受け入れるように)。第二に、zkVM の検証者の実装は、証明者の実装よりも一桁以上単純であり、検証者の正しさが短期的に保証される可能性が高くなります。
Security Phase 3: Correct Prover Implementations
このフェーズでは、zkVM の実際の prover 実装が formally implemented であることを要求します。フェーズ 1 と 2 で検証された証明システムの証明を 正しく生成できることを保証するために、実装は 正式に検証される。このフェーズの目標は、完全性、すなわち、zkVMを使用するシステムが、合法的なステートメントを証明できないために立ち往生しないことです。zkVMがゼロ知識特性を持つことが要求される場合、証明が証人の情報を明らかにしないことを保証するために、形式的な検証が提供されなければなりません。
予想されるタイムライン
フェーズ1の進捗: 来年中に何らかの進展が期待できます (たとえば、ZKLib はそのような取り組みの 1 つです)。しかし、少なくとも 2 年間は、どの zkVM もフェーズ 1 の要件を完全に満たすことはできないでしょう。
Phase 2 とPhase 3 ：これらのフェーズは、フェーズ 1 のいくつかの側面と並行して進めることができます。たとえば、Plonk検証器の実装が論文のプロトコルと一致することを示したチームもあります（論文のプロトコル自体は完全には検証されていないかもしれませんが）。とはいえ、どのzkVMも4年以内に第3フェーズに到達するとは思っていません。
主な注意点: Fiat-Shamir セキュリティ vs. 検証済みバイトコード
VM の主な複雑さの問題の 1 つは、まだ未解決の研究課題があることです。Fiat-Shamir変換のセキュリティに関する未解決の研究課題があります。すべての3つのセキュリティフェーズは、Fiat-Shamirと確率的述語を絶対的に安全なものとして扱いますが、実際にはパラダイム全体が脆弱である可能性があります。これは、ランダム予測マシンの理想化されたモデルと、実際に使用されるハッシュ関数の間の不一致によるものです。
最悪のシナリオでは、セキュリティステージ2に達したシステムが、フィアット・シャミール（Fiat-Shamir）関連の問題により、完全に安全でないことが判明するかもしれません。これは大いに注目され、継続的な研究に値します。そのような脆弱性をよりよく防御するために、Fiat-Shamir変換自体を修正する必要があるかもしれません。
再帰を使用しないシステムは理論的にはより安全です。しかし、このリスクは依然として未解決の基本的な問題です。
注意すべきもう1つの問題は、zkVMが（バイトコードで指定された）ある計算手順が正しく実行されたことを証明したとしても、バイトコード自体に欠陥がある場合、証明の価値は極めて限定的であるということです。strong>は極めて限定的である。したがって、zkVMの有用性は、正式に検証されたバイトコードを生成する方法に大きく依存しており、この課題は非常に大きく、この論文の範囲を超えています。
反量子セキュリティ
量子コンピュータは、少なくとも今後5年間（あるいはそれ以上）は深刻な脅威にはならないでしょう。ソフトウェアの脆弱性は死活問題です。したがって、今優先されるべきは、この論文で提示されたセキュリティとパフォーマンスの目標を達成することです。量子安全でないSNARKがこれらの目標をより早く達成できるのであれば、その使用を優先すべきです。量子に強いSNARKの開発が追いつくまで、あるいは現実的な脅威を持つ量子コンピュータが登場する兆しが見えるまで待ち、それから切り替えを検討する。
特定のセキュリティレベル
100ビットの古典的セキュリティは、どのSNARKも貴重な資産を守るために使用するセキュリティレベルです。しかし、この低い基準を満たさないシステムもまだあります。それでも、これは許容されるべきではなく、標準的な暗号化手法では通常128 ビット以上のセキュリティが要求されます。SNARKのパフォーマンスが本当に十分であるならば、パフォーマンスを上げるためにセキュリティを下げる必要はないはずです。
パフォーマンス段階
現在の状況
現在、zkVM プローバの計算オーバーヘッドは、ネイティブ実行の約100万倍です。言い換えれば、プログラムのネイティブ実行が X CPU サイクルかかるとすると、正しい実行の証明を生成するには X × 1,000,000 CPU サイクルほどかかります。これは1年前もそうでしたし、今日も（多少の誤解はあるにせよ）そうです。
業界で現在話題になっていることの中には、
1. 「イーサネット全体のプルーフ生成のコスト」
「イーサネット全体のプルーフ生成のコスト」
1.EtherNetメインネット全体のプルーフ生成コストは年間100万ドル未満です。"
2.「わずか数十個のGPUで、イーサリアムブロックの証明をほぼリアルタイムで生成できるようにした」
3."私たちの最新のzkVMは、以前のものより1000倍高速です。"
しかし、これらの記述は文脈なしでは誤解を招く可能性があります:
- 古いzkVMより1000倍高速です。
- 古い zkVM より 1000 倍高速で、まだ非常に遅いこともあります。
- メイン Ether ネットワーク上のコンピュート量は、将来 10 倍になる可能性があります。
- いわゆる「ほぼリアルタイム」のプルーフ生成は、多くのブロックチェーン・アプリケーションのニーズにはまだ遅すぎる（例えば、Optimismのブロックタイムは低すぎる）。Optimismのブロックタイム2秒は、Etherの12秒よりもはるかに速い）。
- 24時間365日稼働している何十ものGPUは、十分な活動保証を提供していません。です。
- これらの証明生成時間は、通常1MBを超える証明サイズに対するものであり、多くのアプリケーションにとっては大きすぎます。
- 「年間コスト100万ドル未満」というのは、単に1つのイーサ・ノードが1年に約25ドルの計算しか実行しないからです。
ブロックチェーン以外のアプリケーションシナリオでは、この計算オーバーヘッドは明らかに高すぎます。並列コンピューティングやエンジニアリングの最適化をいくら行っても、このような膨大な計算オーバーヘッドを補うことはできません。
基本的な目標は、ネイティブ実行の10万倍を超えないパフォーマンスオーバーヘッドを持つことです。しかし、それでもこれは最初のステップに過ぎません。真に大規模なメインストリームでの採用のためには、オーバーヘッドをネイティブ実行の1万倍以下にする必要があるかもしれません。
パフォーマンス測定
SNARKのパフォーマンスには3つの主要コンポーネントがあります。
1. 基礎となる証明システムの固有の効率。
2. 特定のアプリケーションのための最適化 (プリコンパイルなど)。
3. エンジニアリングおよびハードウェア アクセラレーション (例: GPU、FPGA、またはマルチコア CPU)。
(2) と (3) は実際の展開には不可欠ですが、どのような証明システムにも適用できるため、必ずしも根本的なオーバーヘッドの改善を反映するわけではありません。たとえば、zkEVM に GPU アクセラレーションとプリコンパイルを追加すると、CPU だけに頼るよりも簡単に 50 倍速くなります。
したがって、この記事では、専用ハードウェアとプリコンパイルなしで SNARK の基本性能を測定することに焦点を当てます。これは、現在のベンチマーク手法とは対照的であり、一般的に 3 つの要素すべてを 1 つの「総合値」にまとめます。これは、ダイヤモンドの本来の透明度を評価するのではなく、研磨にかかる時間で判断するようなものです。
私たちの目標は、汎用プルーフシステム特有のオーバーヘッドを分離し、まだ深く研究されていない技術への参入障壁を下げ、コミュニティがプルーフシステム設計における真の進歩に集中できるよう、雑念を取り除く手助けをすることです。.
性能段階
私が提案する5つの性能段階のマイルストーンは以下の通りです。まず、CPU上のプロヴァーのオーバーヘッドを大幅に削減する必要があり、その後、オーバーヘッドを削減するためにハードウェアにさらに頼ることができます。同時に、メモリ使用量も改善しなければならない。
すべての段階において、開発者は zkVM パフォーマンスのためにコードを微調整する必要はありません。開発者のエクスペリエンスは、zkVM の核となる強みです。パフォーマンス ベンチマークを満たすために DevEx を犠牲にすることは、ベンチマークの目的を打ち消すだけでなく、そもそも zkVM の目的も打ち消します。
これらのメトリクスは、証明者コストに焦点を当てています。しかし、もし証明者のコストが無制限に成長することが許されるなら（すなわち、証明サイズや証明時間に上限がない）、どのような証明者メトリックも簡単に満たすことができます。したがって、以下の段階を満たすためには、最大証明サイズと最大検証時間の両方を制限しなければならない。
第1段階の要件：「妥当な非自明な検証コスト」
。- 証明サイズ: 証人サイズより小さくなければならない。
- 検証時間: 証明の検証は、プログラムのネイティブ実行よりも遅くてはならない（すなわち、計算の直接実行よりも遅くてはならない）。
これらは最小限の単純さの要件であり、証明のサイズと検証時間が、証明をバリデータに直接送って直接チェックさせるよりも悪くならないことを保証します。
Stage 2以上
- 最大証明サイズ: 256 KB。
- 最大証明時間: 16ミリ秒。
これらの上限は、検証コストが高くなる可能性があるにもかかわらず、新しい高速証明技術に対応するために意図的に緩くなっています。同時に、これらの上限は、ブロックチェーン上で使用したいと思うプロジェクトがほとんどないほどコストのかかる証明を除外しています。
Speed Stage 1
Single-threaded proofs must not be more than 100,000 times slower than native execution((イーサリアムのブロック証明だけでなく、複数のアプリケーションに対して)、プリコンパイルに頼ってはいけません。
具体的には、約30億サイクル/秒で動作するRISC-Vプロセッサを搭載した最新のラップトップを想定すると、ステージ1に到達することは、ラップトップが30,000 RISC-Vサイクル/秒で動作できるようになることを意味します。30,000RISC-Vサイクル/秒。
ベリファイアのコストは、以前に定義した「妥当な非自明な検証コスト」の基準を満たさなければなりません。
速度段階2
シングルスレッド証明は、ネイティブ実行の10,000倍より遅くてはなりません。
あるいは、いくつかの有望なSNARK手法（特にバイナリドメインSNARK）は現在のCPUやGPUの制約によって制限されているため、この段階はFPGA（あるいはASIC）でも満たすことができます:
1. FPGA がネイティブ速度でエミュレートする RISC-V コアの数を計算します。
2. RISC-V 実行 (ほぼリアルタイム) をシミュレートおよび証明するために必要な FPGA の数を計算します。
3. (2)の数が(1)の10,000倍を超えない場合、ステージ2を満たします。
- サイズを証明する。
- 検証時間: 標準CPUで最大16ミリ秒。
Speed Stage 3
Speed Stage 2を達成し、1000 × 以下の証明オーバーヘッドを達成。× x 以下の証明オーバヘッド (広範なアプリケーションに対して) を達成し、自動合成と正式に検証されたプリコンパイルを使用しなければなりません。基本的には、証明生成を高速化するために各プログラムの命令セットを動的にカスタマイズするが、使いやすさと形式的検証は保証されなければならない。(プリコンパイルが諸刃の剣である理由、および「手書き」プリコンパイルが持続可能なアプローチでない理由については、次のセクションを参照してください)。
Memory Stage 1
RAM 2 GB 未満で Speed Stage 1 に到達。、ゼロ知識要件も満たしています。このステージは、モバイル デバイスまたはブラウザにとって重要であり、多数のクライアントサイド zkVM ユースケースへの扉を開きます。たとえば、スマートフォンは ロケーション プライバシー、ID クレデンシャルなどのために使用されます。証明生成に1～2 GB以上のメモリが必要な場合、ほとんどのモバイルデバイスは実行されません。
2つの重要な注意事項：
1.大規模な計算（ネイティブ実行に数兆CPUサイクルを必要とする）であっても、証明システムは2GBのメモリ制限を維持しなければなりません。さもなければ適用が制限される。
2.証明が極端に遅い場合、2GBのメモリ上限を維持するのは簡単です。200MB未満のRAMからSpeed Stage 1 (Memory Stage 1の10倍向上)へ。
なぜ200MBまで下げるのか非ブロックチェーンのシナリオを考えてみましょう: HTTPSサイトにアクセスすると、認証と暗号化の証明書がダウンロードされます。HTTPS サイトにアクセスすると、認証と暗号化の証明書がダウンロードされます。代わりにサイトがこれらの証明書の zk 証明書を送信する場合、大規模なサイトでは毎秒数百万の証明書を生成する必要があるかもしれません。各証明が2 GBのメモリを必要とする場合、計算リソース要件はPBレベルとなり、これは明らかに実現不可能です。したがって、非ブロックチェーンアプリケーションにとって、メモリ使用量をさらに削減することは非常に重要です。
プリコンパイル：最後の1マイル、それとも松葉杖？
プリコンパイルは、特定の関数（ハッシュ、楕円曲線署名など）専用に最適化されたSNARK制約システムを指します。イーサネットでは、プリコンパイルは Merkle ハッシュと署名検証のオーバーヘッドを削減しますが、プリコンパイルへの過度の依存は SNARK のコア効率を実際には改善しません。
プリコンパイルの問題点
1.まだ遅すぎる: ハッシュと署名のプリコンパイルを行っても、zkVMはブロックチェーン内外の概念実証システムのコアの低さに苦しんでいます。：ハッシュと署名の事前コンパイルでさえ、zkVMは依然としてブロックチェーンの内側と外側の両方で、コアの証明システムの非効率性に悩まされています。
2.セキュリティの脆弱性: 正式に検証されていない手書きの事前コンパイルは、ほぼ必然的に脆弱であり、壊滅的なセキュリティの失敗につながる可能性があります。
3.開発者エクスペリエンスの低下: 現在、多くの zkVM は、1960 年代にプログラミングが行われていた方法と同様に、開発者に 手書き制約 を要求します。
4.ベンチマークは誤解を招く: ベンチマークが特定のプリコンパイルの最適化に依存している場合、SNARK 設計自体を改善するのではなく、手書き制約システムの最適化に焦点を当てることは誤解を招く可能性があります。
5.I/OオーバーヘッドとRAMアクセスなしプリコンパイルは、重い暗号化タスクのパフォーマンスを向上させることができますが、入出力の受け渡しに多くのオーバーヘッドが発生するため、より多様なワークロードでは意味のある高速化を提供できない可能性があります。
ブロックチェーン環境であっても、イーサのような単一のL1を超えると（たとえば、一連のクロスチェーンブリッジを構築したい場合）、すぐに異なるハッシュ関数や署名スキームに直面することになります。この問題を解決するために常にプリコンパイルすることは、スケーラブルではありませんし、大きなセキュリティリスクをもたらします。
私は、プリコンパイルは長期的にはまだ重要だと考えていますが、それは自動的に合成され、正式に検証された後だけです。こうすることで、zkVMの開発者エクスペリエンスの利点を維持しつつ、致命的なセキュリティリスクを回避することができます。この見解は、ステージ3に反映されています。
Anticipated timeline
Speed Stage 1 および Speed Stage 2 に到達する一握りの zkVM を今年後半に期待しています。strong>そしてメモリー・ステージ1も今年の後半には達成できると思います。また、スピードステージ2も今後2年以内に達成できると思いますが、新しい研究アイデアがなければそこに到達できるかどうかはわかりません。
残りのステージ（スピードステージ3とメモリーステージ2）に到達するには数年かかると予想しています。
この記事では、zkVM のセキュリティとパフォーマンスの段階を別々にリストしていますが、これらは完全に独立しているわけではありません。zkVMの脆弱性が発見され続けるにつれて、これらの脆弱性のいくつかを修正することは、必然的に大幅なパフォーマンス低下につながると予想しています。したがって、パフォーマンス テスト結果は、zkVM がセキュリティ ステージ 2 に達するまでは暫定的なものと考えるべきです。
zkVMは、ゼロ知識証明を真にユビキタスなものにする大きな可能性を秘めていますが、セキュリティ上の課題や深刻なパフォーマンスのボトルネックに悩まされるなど、まだ初期段階にあります。市場の誇大宣伝やマーケティング上の誇大広告が、真の進歩を測ることを困難にしている。明確なセキュリティとパフォーマンスのマイルストーンによって、霧を晴らすロードマップを提供したい。私たちはいずれそこに到達するでしょうが、それには時間と研究とエンジニアリングにおける継続的な努力が必要です。
Alex
Brian
Kikyo
Hui Xin