著者：Justin Thaler 出典：a16z 翻訳：シャノーバ、ゴールドファイナンス**ゼロ知識仮想マシン（zkVMs）**は、「SNARKsを一般化する」という目標を持ち、SNARKの専門知識がなくても、特定の入力（または証明）で特定のプログラムが正しく実行されていることを証明できるようにします。その主要な利点は開発者の体験にありますが、現在、zkVMsは**セキュリティ**と**パフォーマンス**の両面で依然として非常に大きな課題に直面しています。zkVMsが約束を果たしたい場合、設計者はこれらの障壁を乗り越えなければなりません。この記事では、zkVMの発展における可能性の段階を探り、このプロセス全体には**数年**かかるかもしれないことに注意してください-誰かがすぐに実現できると言うのを信じないでください。## **チャレンジ**セキュリティ**セキュリティ**に関して、zkVMsは高度に複雑なソフトウェアプロジェクトであり、依然として脆弱性に満ちています。**性能**に関して、プログラムの正しい実行を証明することは、ネイティブで実行するよりも**数十万倍**遅くなる可能性があり、多くのアプリケーションが現実世界での展開に**暫定的に適さない**という状況をもたらしています。それでも、多くの声がzkVMs **をすぐに展開できる**と宣伝していますが、一部のプロジェクトは既に高い計算コストを支払って、オンチェーンアクティビティのゼロ知識証明を生成しています。しかし、zkVMsにはまだ多くの脆弱性が存在しているため、このやり方は実際には**高価な仮面**に過ぎず、システムをSNARKで保護されているように見せかけており、実際には**権限制御**に依存しているか、さらに悪い場合は**攻撃リスクにさらされています**。**実際の状況は、安全で効率的な zkVM を構築するには、まだ数年かかるということです。** この文書では、zkVM の実際の進捗状況を追跡し、煽りを弱め、コミュニティが本当の技術革新に焦点を当てるのをサポートするために、**具体的で段階的な**目標を提案しています。## **セキュリティの発展段階**### **バックグラウンド****SNARK**を基盤とする**zkVMs**は通常、2つの主要なコンポーネントを含みます：1. **多項式インタラクティブオラクルプルーフ（PIOP）**：多項式（または多項式から派生した制約）のインタラクティブプルーフフレームワークを証明するためのもの。 2. 多項式コミットメントスキーム(PCS):証明者が検出されずに多項式評価結果を改ざんできないようにします。zkVMは、実行トレースを制約システムにエンコードすることによって、仮想マシンのレジスタとメモリの正しい使用を確認し、これらの制約の満たされていることをSNARKで証明します。**このように複雑なシステムでは、zkVM に欠陥がないことを保証する唯一の方法は** **形式検証**です。以下は、zkVM のセキュリティに関する異なる段階であり、**第一段階はプロトコルの正確性に焦点を当てています**、**第二段階と第三段階は実装の正確性に焦点を当てています**。### **セキュリティ段階1：正しいプロトコル**1. PIOPの信頼性の正式な検証。2. PCSは、一部の暗号仮定や理想的なモデルの下で制約付き形式の検証を提供します。3. Fiat-Shamirを使用する場合、PIOPとPCSを組み合わせた簡潔な証明によって、必要に応じて他の暗号仮定を使用して、ランダム予言モデルで安全な正式検証が得られます。4. PIOPの制約システムは、VMの意味形式の検証証明に等しいです；5. すべてのこれらの部分を完全に「接着」して、形式的に検証された安全なSNARK証明として1つの単一のプログラムを実行するためのVMバイトコードを指定します。プロトコルがゼロ知識を実現する場合、この特性も形式的に検証する必要があり、証人の機密情報が漏洩しないようにします。zkVMが**再帰**を使用している場合、再帰プロセス中に関与する**PIOP、コミットメントスキーム、制約システム**はすべて検証する必要があります。それ以外の場合、このサブフェーズは完了とは見なされません。### **セキュリティ段階2：正しいバリデータの実装**この段階では、zkVM **バリデータ**の実装（Rust、Solidityなど）を**形式的に検証**して、第一段階で検証されたプロトコルに準拠していることを確認する必要があります。この段階を完了することは、zkVMの**実装**が**理論設計**と一致しており、**紙面上の安全なプロトコル**やLeanなどの言語で書かれた非効率な仕様ではないことを意味します。なぜ**バリデータに焦点を当てているのか、プルーフリーダーに焦点を当てていないのか**には2つの主要な理由があります。まず、**バリデータが正しいことを確認することで、zkVMプルーフシステムの完全性が確保されます**（すなわち、バリデータが誤ったプルーフを受け入れることがないようにする）。次に、**zkVMの検証者の実装はプルーフリーダーの実装よりも1桁以上単純**であり、検証者の正確性を短期間で確保しやすいです。### **セキュリティ段階 3：正しいプルーファーの達成**この段階では、zkVM **プルーバー**の実装に対する**形式的検証**が要求されており、すでに検証された証明システムの証明を**正しく生成**できることを確認します。この段階の目標は**完全性**であり、zkVMを使用するすべてのシステムが合法的なステートメントを証明できないことで**スタックしない**ことを保証します。zkVMがゼロ知識特性を持つ必要がある場合、形式的検証を提供して、証明が証人に関する情報を漏洩しないようにします。### 預定スケジュール### **第1段階の進捗**：明年にはいくつかの進展が期待できます（例：ZKLibはそのような取り組みです）。ただし、少なくとも2年間は、第1段階の要件を完全に満たす zkVM はありません。**第2段と第3段階**：これらの段階は第1段階のいくつかの側面と同時に進行することができます。 たとえば、一部のチームはすでにPlonk検証器の実装が論文のプロトコルに一致することを証明しています（論文のプロトコル自体が完全に検証されていないかもしれません）。 それでも、私はどんなzkVMも3年未満で第3段階に到達することはないと予想しています-それどころか、もっと長いかもしれません。## **重要事項：Fiat-Shamir のセキュリティと検証済みのバイトコード**主要な複雑性の問題の1つは、**Fiat-Shamir 変換の安全性には未解決の研究問題が引き続き存在する**ということです。すべての3つのセキュリティ段階では、Fiat-Shamir およびランダムオラクルを絶対安全と見なしていますが、実際にはパラダイム全体に欠陥がある可能性があります。これは、**ランダムオラクルの理想化モデルと実際に使用されるハッシュ関数との間に差異がある**ためです。最悪の場合、すでに**セキュリティ段階2**に達しているシステムが、**Fiat-Shamir関連の問題により完全に安全でないことが判明する可能性**があります。これには非常に注意を払い、継続的に研究を行う必要があります。**この種の脆弱性をよりよく防御するためには、Fiat-Shamir変換自体を変更する必要があるかもしれません。****再帰を使用しないシステムは理論上より安全**ですが、既知のいくつかの攻撃は再帰証明で使用される回路に類似しています。ただし、このリスクはまだ**未解決の基本的な問題**です。別の注意すべき問題は、zkVM が特定の計算プログラム（バイトコードによって指定される）が**正しく実行**されたことを証明しても、**バイトコード自体に欠陥がある**場合、その証明の価値は**非常に限定される**ということです。したがって、zkVM の実用性は、**形式的に検証されたバイトコードを生成する方法**に大きく依存しており、この課題は**非常に大きく**、また**本文の議論範囲を超えて**います。### **量子耐性に関する****将来の少なくとも5年間（おそらくそれ以上）にわたり、量子コンピュータは深刻な脅威にはならず、ソフトウェアの脆弱性が生死を左右する問題である。**そのため、現在の最優先課題は、この文書で提唱されているセキュリティとパフォーマンスの目標を達成することです。もし非量子耐性のSNARKsがこれらの目標をより速く達成できる場合は、それらを優先的に使用すべきです。抗量子SNARKsが発展に追いつくか、または実際の脅威を示す量子コンピュータが登場する兆候が現れた時に、切り替えを検討しても遅くありません。### **具体のセキュリティレベル****100-bitクラシックセキュリティ**は、貴重な資産を保護するための**最低基準**として、すべてのSNARKに適用されますが（ただし、まだ一部のシステムが**この基準を満たしていない**）、それでもこれは**受け入れてはならない**ものです。一般的な暗号実践では通常、**128ビットのセキュリティ以上**が求められます。**SNARKが本当に基準を満たしているなら、性能向上のためにセキュリティを犠牲にすべきではありません**。## **パフォーマンス段階**### **現状**現在、zkVMの**プルーフ**の計算コストはおよそ**ネイティブ実行の 100 万倍**です。つまり、プログラムのネイティブ実行に**X 個のCPUサイクル**が必要な場合、**正しい実行のプルーフ**を生成するにはおよそ**X × 1,000,000 個のCPUサイクル**が必要です。この状況は**1年前と同じですが、今日も変わりません**（いくつかの誤解が存在するにもかかわらず）。**現在の業界では、いくつかの一般的な用語が誤解を招く可能性があります。例えば：**1. **イーサリアムメインネット全体を証明するコストは、年間 100 万ドル未満です。**2. **「私たちは実質的にイーサリアムブロックのリアルタイムな証明生成を達成しており、数十のGPUが必要です。」**3. **"私たちの最新の zkVM は前世代よりも1000倍速いです。"**しかし、これらの主張は文脈がないと誤解を招く可能性があります：• **zkVMの以前のバージョンよりも1000倍高速ですが、それでも非常に遅い可能性があります**。これは**過去がどれだけひどかったかを示すものであり、現在がどれだけ良いかを示すものではありません**。• **イーサリアムメインネットの計算量は将来的に10倍に増加する可能性があります**、これにより現在のzkVMのパフォーマンスは需要に遅れる可能性があります。多くのブロックチェーンアプリケーションでは、いわゆる「ほぼリアルタイム」のプルーフ生成は依然として遅すぎます（たとえば、Optimismのブロックタイムは2秒で、イーサリアムの12秒よりもはるかに速いです）。• **「数十枚のGPUが長時間24/7稼働している」** ということは**十分な活性保証を提供することはできません**。 • これらの**証明生成時間は通常1MBを超える証明のサイズに対して**であり、これは多くのアプリケーションにとって**大きすぎる**です。• **「1 年間のコストが 100 万ドルに達しない」**というのは、**イーサリアムのフルノードが 1 年間に約 25 ドルの計算しか実行しない**ためです。ブロックチェーン以外のアプリケーションシナリオでは、この種の計算費用は明らかに過大です。どれだけ並列計算やエンジニアリング最適化を行っても、このような巨大な計算費用を補うことはできません。###我々が設定すべき基本目標は、性能のコストがネイティブ実行を100,000倍超えないことです。しかし、それでもこれは最初のステップに過ぎません。真の大規模な主流アプリケーションを実現するには、コストをネイティブ実行の10,000倍以下にまで引き下げる必要があるかもしれません。## **パフォーマンス測定**SNARKの性能は主に3つの要素から構成されています：1. **基本証明システムの確実な効率**。2. **特定アプリケーション向けの最適化**（例：プリコンパイル）。3. **エンジニアリングおよびハードウェアアクセラレーション**（例：GPU、FPGA、またはマルチコアCPU）。（2）と（3）の実際の展開は非常に重要ですが、どちらも任意の証明システムに適用できるため、**基本的な費用の改善を反映するとは限らない**。たとえば、zkEVMにGPUアクセラレーションとプリコンパイルを追加すると、CPUだけに依存するよりも簡単に50倍の速度向上が実現できます-これにより、効率が低い固定システムが同じ最適化を受けていない別のシステムよりも優れて見える可能性があります。したがって、この文書では、**専用ハードウェアや事前コンパイルなしでのSNARKの基本的なパフォーマンス**を評価しています。これは通常のベンチマークテスト方法とは異なり、通常、これらのすべての要素を1つの「総合値」としてまとめます。これは、**ダイヤモンドを磨く時間で評価するのではなく、その固有の透明度を評価する**のと同じです。私たちの目標は**一般的な証明システムの固有の費用を分離し**、未だに深く研究されていない技術のハードルを下げ、コミュニティが干渉要因を取り除いて**証明システムの設計の真の進展に焦点を当てる**ことを支援することです。### **パフォーマンス段階**以下は私が提案した5つのパフォーマンス段階のマイルストーンです。まず第一に、CPU上のプルーフオブステークの費用を大幅に削減する必要があります。その後、ハードウェアによる費用削減にさらに依存することができます。同時に、メモリの使用も改善される必要があります。すべての段階で、**開発者は zkVM のパフォーマンスのためにコードを調整すべきではありません**。 開発者エクスペリエンスは zkVM の主要な利点です。 パフォーマンス基準を満たすために DevEx を犠牲にすることは、基準テストの意味を失うだけでなく、zkVM の目的にも反することになります。これらの指標は主に**証明者のコスト**に焦点を当てています。ただし、検証者の**コストが無制限に増加**することを許可すると（つまり、証明のサイズや検証時間に上限がない場合）、任意の証明者の指標を簡単に満たすことができます。したがって、次の段階の要件を満たすには、**最大証明サイズと最大検証時間の両方を制限する必要があります**。### **ステージ1の要件：「合理的な非凡な検証コスト」**• **サイズの証明**：証拠のサイズ未満である必要があります。• **検証時間**：検証の証明の速度は、プログラムのネイティブな実行よりも遅くしてはならない（つまり、計算の直接実行よりも遅くしてはならない）。これらは**最低限度の簡潔性要件**であり、**証明のサイズと検証時間が、証明を検証者に直接送信し、直接検査させるよりも悪化しない**ことを確認します。### **フェーズ2以上** •最大校正サイズ:256 KB。 • 最大検証時間:16ミリ秒。これらの上限は、新しい高速プルーフ技術に適応するために意図的に緩められており、それがより高い検証コストをもたらす可能性がある場合でも、これを排除しています。同時に、これらの上限は、ブロックチェーンでの使用にほとんどのプロジェクトが意欲を示さない高額な証明を除外しています。### **スピード段階1****シングルスレッドの証明速度はネイティブ実行よりも100,000倍以上遅くなってはならない**（イーサリアムブロック認証に限らず、さまざまなアプリケーションに適用可能）、かつプリコンパイルに依存してはなりません。**具体には**、現代のノートパソコンに搭載された RISC-V プロセッサが約**30億サイクル/秒**で動作していると仮定すると、ステージ1に到達するということは、そのノートパソコンが**30,000 RISC-V サイクル/秒**の速度でプルーフ（シングルスレッド）を生成できることを意味します。バリデーターのコストは、以前に定義された「合理的で非トリビアルな検証コスト」基準を満たさなければなりません。### **スピード段階 2****単一スレッドの証明速度は、ネイティブ実行よりも10,000倍以上遅くなってはならない**。**または**、将来有望な SNARK メソッド（特にバイナリ領域 SNARK）が現在の CPU および GPU 制限に達するため、この段階で FPGA（または ASIC）を使用できます。1. FPGAでネイティブスピードでシミュレートされたRISC-Vコアの数を計算します。2. RISC-Vの実行（ほぼリアルタイム）に必要なFPGAの数を計算し、シミュレーションして証明します。3. もし（2）の数量が（1）の 10,000 倍を超えない場合、段階 2 が満たされます。 • **サイズの証明**: 最大256 KB。 • 検証時間:標準CPUで最大16ms。### **スピード段階 3****速度段階2**に到達した基盤の上で、**1000×以内の証明コスト**（さまざまなアプリケーションに適用）を実現し、**自動合成と形式的検証のためのプリコンパイル**を使用する必要があります。基本的には、**各プログラムの命令セットを動的にカスタマイズして、証明生成を高速化する必要があります**が、**使いやすさと形式的検証を確保する必要があります**（**プリコンパイルがなぜ両刃の剣であるか**、および「手書き」プリコンパイルが持続可能な方法でない理由については、次のセクションを参照してください）。### **メモリ段階 1****2 GB未満のメモリ**で**段階1の速度**を達成し、**ゼロ知識の要件**を満たす。この段階は**モバイルデバイスやブラウザ**にとって重要であり、**多くのクライアントzkVMユースケース**が開かれます。例えば、**位置プライバシーや身元証明**にスマートフォンを使用する場合、証明生成に1-2 GBを超えるメモリが必要な場合、ほとんどのモバイルデバイスは実行できません。**2つの重要なポイント：**1. たとえ大規模な計算（数兆サイクルのCPU実行が必要なものであっても）、証明システムは2 GBのメモリ制限を維持する必要があります。それ以外の場合、適用範囲が制限されます。2. もし速度が非常に遅いことが証明されれば、2 GB のメモリ上限を維持することは非常に簡単です。そのため、メモリ段階1を意味のあるものにするためには、2 GBのメモリ制限内で段階1の速度を達成する必要があります。### **メモリ段階 2****200 MB未満のメモリー**で**スピード段階1**（メモリー段階1より10倍速い）に到達します。なぜ 200 MB に低下させる必要があるのですか？**ブロックチェーン以外のシナリオ**を考えてみましょう：HTTPS ウェブサイトにアクセスすると、認証および暗号化証明書がダウンロードされます。ウェブサイトがこれらの証明書を zk 証明で送信するように変更した場合、大規模なウェブサイトは**数百万の証明**を毎秒生成する必要があります。各証明に 2 GB のメモリが必要ならば、計算リソースの要件は**PB レベル**に達するでしょう。明らかに実現不可能です。したがって、**ブロックチェーン以外のアプリケーション**においてメモリ使用量をさらに削減することが非常に重要です。 **プリコンパイル：最後の一マイル、または杖？****プリコンパイル**とは、**特定の関数（ハッシュ、楕円曲線署名など）を最適化した SNARK 制約システム**を指します。イーサリアムでは、プリコンパイルは Merkle ハッシュと署名検証のコストを削減できますが、プリコンパイルに過度に依存すると、SNARK のコア効率を真に向上させることはできません。**コンパイルされた問題****1. 依然遅い**：ハッシュおよび署名のプリコンパイルを使用しても、zkVM はブロックチェーン内外で依然としてコアプルーフシステムの効率の問題があります。**2.セキュリティホール**：手書きのプリコンパイルが形式的な検証を経ていない場合、ほぼ必ずホールが存在し、致命的なセキュリティの失敗を引き起こす可能性があります。**3.開発者体験が悪い**：現在、多くの zkVM は開発者に**手書きの制約システム**を要求し、1960年代のプログラミング方法と類似しており、開発体験に深刻な影響を与えています。**4.ベンチマークの誤解**：ベンチマークが特定の事前コンパイル最適化に依存している場合、人々は最適化された手動制約システムに焦点を当てることがあり、SNARKデザインの向上ではなく。**5. I/OコストとRAMなしのアクセス**事前にコンパイルすると、重い暗号化タスクのパフォーマンスが向上する可能性がありますが、より多様なワークロードに意味のあるアクセラレーションを提供できない場合があります。これは、入出力を処理する際に多くのコストが発生し、RAMを使用できないためです。ブロックチェーン環境でも、イーサリアムなどの単一のL1を超えると、異なるハッシュ関数や署名方式に直面することになります（たとえば、クロスチェーンブリッジを構築したい場合）。この問題を解決するために、継続的なプリコンパイルが行われており、これは拡張不可能であり、巨大なセキュリティリスクをもたらします。私は確かに、長期的にはプリコンパイルが依然として重要であると信じていますが、それらが自動的に合成され、正式に検証された場合にのみそうなります。これにより、zkVM 開発者のエクスペリエンスを維持しつつ、災害的なセキュリティリスクを回避できます。この見解はステージ3に反映されています。## **予想されるタイムライン**私は、zkVMのマイルストーンとして今年後半に**Speed Phase 1**と**Memory Phase 1**が達成されることを期待しています。次の2年間で**Speed Phase 2**も実現できると考えていますが、新しい研究方針なしにこの目標を達成できるかどうかは現時点では不明です。私は、残りの段階（**スピードステージ3**および**メモリステージ2**）が達成されるには数年かかると予想しています。zkVMのセキュリティとパフォーマンスの段階がそれぞれリストされていますが、これらは完全に独立しているわけではありません。zkVM内の脆弱性が次々と発見される中、いくつかの脆弱性の修正は性能の大幅な低下をもたらすことが避けられないと予想しています。したがって、zkVMが**セキュリティ段階2**に達する前に、そのパフォーマンステスト結果は一時的なデータと見なす必要があります。zkVMはゼロ知識証明の普及において大きな潜在能力を持っていますが、現在はまだ初期段階にあり、セキュリティの課題に満ちており、重大なパフォーマンスのボトルネックが存在しています。市場の煽りとマーケティングの宣伝が、実際の進展を測ることを困難にしています。明確なセキュリティとパフォーマンスのマイルストーンを通じて、私は霧を晴らすための道筋を提供したいと考えています。私たちは最終的に目標に到達するでしょうが、それには時間と研究・エンジニアリングへの継続的な努力が必要です。
a16z: 効率的で安全な zkVM への道筋を探る
著者：Justin Thaler 出典：a16z 翻訳：シャノーバ、ゴールドファイナンス
ゼロ知識仮想マシン（zkVMs）は、「SNARKsを一般化する」という目標を持ち、SNARKの専門知識がなくても、特定の入力（または証明）で特定のプログラムが正しく実行されていることを証明できるようにします。その主要な利点は開発者の体験にありますが、現在、zkVMsはセキュリティとパフォーマンスの両面で依然として非常に大きな課題に直面しています。zkVMsが約束を果たしたい場合、設計者はこれらの障壁を乗り越えなければなりません。この記事では、zkVMの発展における可能性の段階を探り、このプロセス全体には数年かかるかもしれないことに注意してください-誰かがすぐに実現できると言うのを信じないでください。
チャレンジ
セキュリティセキュリティに関して、zkVMsは高度に複雑なソフトウェアプロジェクトであり、依然として脆弱性に満ちています。
性能に関して、プログラムの正しい実行を証明することは、ネイティブで実行するよりも数十万倍遅くなる可能性があり、多くのアプリケーションが現実世界での展開に暫定的に適さないという状況をもたらしています。
それでも、多くの声がzkVMs をすぐに展開できると宣伝していますが、一部のプロジェクトは既に高い計算コストを支払って、オンチェーンアクティビティのゼロ知識証明を生成しています。しかし、zkVMsにはまだ多くの脆弱性が存在しているため、このやり方は実際には高価な仮面に過ぎず、システムをSNARKで保護されているように見せかけており、実際には権限制御に依存しているか、さらに悪い場合は攻撃リスクにさらされています。
実際の状況は、安全で効率的な zkVM を構築するには、まだ数年かかるということです。 この文書では、zkVM の実際の進捗状況を追跡し、煽りを弱め、コミュニティが本当の技術革新に焦点を当てるのをサポートするために、具体的で段階的な目標を提案しています。
セキュリティの発展段階
バックグラウンド
SNARKを基盤とするzkVMsは通常、2つの主要なコンポーネントを含みます：
多項式インタラクティブオラクルプルーフ（PIOP）：多項式（または多項式から派生した制約）のインタラクティブプルーフフレームワークを証明するためのもの。
多項式コミットメントスキーム(PCS):証明者が検出されずに多項式評価結果を改ざんできないようにします。
zkVMは、実行トレースを制約システムにエンコードすることによって、仮想マシンのレジスタとメモリの正しい使用を確認し、これらの制約の満たされていることをSNARKで証明します。
このように複雑なシステムでは、zkVM に欠陥がないことを保証する唯一の方法は 形式検証です。以下は、zkVM のセキュリティに関する異なる段階であり、第一段階はプロトコルの正確性に焦点を当てています、第二段階と第三段階は実装の正確性に焦点を当てています。
セキュリティ段階1：正しいプロトコル
zkVMが再帰を使用している場合、再帰プロセス中に関与するPIOP、コミットメントスキーム、制約システムはすべて検証する必要があります。それ以外の場合、このサブフェーズは完了とは見なされません。
セキュリティ段階2：正しいバリデータの実装
この段階では、zkVM バリデータの実装（Rust、Solidityなど）を形式的に検証して、第一段階で検証されたプロトコルに準拠していることを確認する必要があります。この段階を完了することは、zkVMの実装が理論設計と一致しており、紙面上の安全なプロトコルやLeanなどの言語で書かれた非効率な仕様ではないことを意味します。
なぜバリデータに焦点を当てているのか、プルーフリーダーに焦点を当てていないのかには2つの主要な理由があります。まず、バリデータが正しいことを確認することで、zkVMプルーフシステムの完全性が確保されます（すなわち、バリデータが誤ったプルーフを受け入れることがないようにする）。次に、zkVMの検証者の実装はプルーフリーダーの実装よりも1桁以上単純であり、検証者の正確性を短期間で確保しやすいです。
セキュリティ段階 3：正しいプルーファーの達成
この段階では、zkVM プルーバーの実装に対する形式的検証が要求されており、すでに検証された証明システムの証明を正しく生成できることを確認します。この段階の目標は完全性であり、zkVMを使用するすべてのシステムが合法的なステートメントを証明できないことでスタックしないことを保証します。zkVMがゼロ知識特性を持つ必要がある場合、形式的検証を提供して、証明が証人に関する情報を漏洩しないようにします。
預定スケジュール
第1段階の進捗：明年にはいくつかの進展が期待できます（例：ZKLibはそのような取り組みです）。ただし、少なくとも2年間は、第1段階の要件を完全に満たす zkVM はありません。
第2段と第3段階：これらの段階は第1段階のいくつかの側面と同時に進行することができます。 たとえば、一部のチームはすでにPlonk検証器の実装が論文のプロトコルに一致することを証明しています（論文のプロトコル自体が完全に検証されていないかもしれません）。 それでも、私はどんなzkVMも3年未満で第3段階に到達することはないと予想しています-それどころか、もっと長いかもしれません。
重要事項：Fiat-Shamir のセキュリティと検証済みのバイトコード
主要な複雑性の問題の1つは、Fiat-Shamir 変換の安全性には未解決の研究問題が引き続き存在するということです。すべての3つのセキュリティ段階では、Fiat-Shamir およびランダムオラクルを絶対安全と見なしていますが、実際にはパラダイム全体に欠陥がある可能性があります。これは、ランダムオラクルの理想化モデルと実際に使用されるハッシュ関数との間に差異があるためです。
最悪の場合、すでにセキュリティ段階2に達しているシステムが、Fiat-Shamir関連の問題により完全に安全でないことが判明する可能性があります。これには非常に注意を払い、継続的に研究を行う必要があります。この種の脆弱性をよりよく防御するためには、Fiat-Shamir変換自体を変更する必要があるかもしれません。
再帰を使用しないシステムは理論上より安全ですが、既知のいくつかの攻撃は再帰証明で使用される回路に類似しています。ただし、このリスクはまだ未解決の基本的な問題です。
別の注意すべき問題は、zkVM が特定の計算プログラム（バイトコードによって指定される）が正しく実行されたことを証明しても、バイトコード自体に欠陥がある場合、その証明の価値は非常に限定されるということです。したがって、zkVM の実用性は、形式的に検証されたバイトコードを生成する方法に大きく依存しており、この課題は非常に大きく、また本文の議論範囲を超えています。
量子耐性に関する
**将来の少なくとも5年間（おそらくそれ以上）にわたり、量子コンピュータは深刻な脅威にはならず、ソフトウェアの脆弱性が生死を左右する問題である。**そのため、現在の最優先課題は、この文書で提唱されているセキュリティとパフォーマンスの目標を達成することです。もし非量子耐性のSNARKsがこれらの目標をより速く達成できる場合は、それらを優先的に使用すべきです。抗量子SNARKsが発展に追いつくか、または実際の脅威を示す量子コンピュータが登場する兆候が現れた時に、切り替えを検討しても遅くありません。
具体のセキュリティレベル
100-bitクラシックセキュリティは、貴重な資産を保護するための最低基準として、すべてのSNARKに適用されますが（ただし、まだ一部のシステムがこの基準を満たしていない）、それでもこれは受け入れてはならないものです。一般的な暗号実践では通常、128ビットのセキュリティ以上が求められます。SNARKが本当に基準を満たしているなら、性能向上のためにセキュリティを犠牲にすべきではありません。
パフォーマンス段階
現状
現在、zkVMのプルーフの計算コストはおよそネイティブ実行の 100 万倍です。つまり、プログラムのネイティブ実行にX 個のCPUサイクルが必要な場合、正しい実行のプルーフを生成するにはおよそX × 1,000,000 個のCPUサイクルが必要です。この状況は1年前と同じですが、今日も変わりません（いくつかの誤解が存在するにもかかわらず）。
現在の業界では、いくつかの一般的な用語が誤解を招く可能性があります。例えば：
イーサリアムメインネット全体を証明するコストは、年間 100 万ドル未満です。
「私たちは実質的にイーサリアムブロックのリアルタイムな証明生成を達成しており、数十のGPUが必要です。」
"私たちの最新の zkVM は前世代よりも1000倍速いです。"
しかし、これらの主張は文脈がないと誤解を招く可能性があります：
• zkVMの以前のバージョンよりも1000倍高速ですが、それでも非常に遅い可能性があります。これは過去がどれだけひどかったかを示すものであり、現在がどれだけ良いかを示すものではありません。
• イーサリアムメインネットの計算量は将来的に10倍に増加する可能性があります、これにより現在のzkVMのパフォーマンスは需要に遅れる可能性があります。
多くのブロックチェーンアプリケーションでは、いわゆる「ほぼリアルタイム」のプルーフ生成は依然として遅すぎます（たとえば、Optimismのブロックタイムは2秒で、イーサリアムの12秒よりもはるかに速いです）。
• 「数十枚のGPUが長時間24/7稼働している」 ということは十分な活性保証を提供することはできません。
• これらの証明生成時間は通常1MBを超える証明のサイズに対してであり、これは多くのアプリケーションにとって大きすぎるです。
• **「1 年間のコストが 100 万ドルに達しない」**というのは、イーサリアムのフルノードが 1 年間に約 25 ドルの計算しか実行しないためです。
ブロックチェーン以外のアプリケーションシナリオでは、この種の計算費用は明らかに過大です。どれだけ並列計算やエンジニアリング最適化を行っても、このような巨大な計算費用を補うことはできません。###
我々が設定すべき基本目標は、性能のコストがネイティブ実行を100,000倍超えないことです。しかし、それでもこれは最初のステップに過ぎません。真の大規模な主流アプリケーションを実現するには、コストをネイティブ実行の10,000倍以下にまで引き下げる必要があるかもしれません。
パフォーマンス測定
SNARKの性能は主に3つの要素から構成されています：
基本証明システムの確実な効率。
特定アプリケーション向けの最適化（例：プリコンパイル）。
エンジニアリングおよびハードウェアアクセラレーション（例：GPU、FPGA、またはマルチコアCPU）。
（2）と（3）の実際の展開は非常に重要ですが、どちらも任意の証明システムに適用できるため、基本的な費用の改善を反映するとは限らない。たとえば、zkEVMにGPUアクセラレーションとプリコンパイルを追加すると、CPUだけに依存するよりも簡単に50倍の速度向上が実現できます-これにより、効率が低い固定システムが同じ最適化を受けていない別のシステムよりも優れて見える可能性があります。
したがって、この文書では、専用ハードウェアや事前コンパイルなしでのSNARKの基本的なパフォーマンスを評価しています。これは通常のベンチマークテスト方法とは異なり、通常、これらのすべての要素を1つの「総合値」としてまとめます。これは、ダイヤモンドを磨く時間で評価するのではなく、その固有の透明度を評価するのと同じです。
私たちの目標は一般的な証明システムの固有の費用を分離し、未だに深く研究されていない技術のハードルを下げ、コミュニティが干渉要因を取り除いて証明システムの設計の真の進展に焦点を当てることを支援することです。
パフォーマンス段階
以下は私が提案した5つのパフォーマンス段階のマイルストーンです。まず第一に、CPU上のプルーフオブステークの費用を大幅に削減する必要があります。その後、ハードウェアによる費用削減にさらに依存することができます。同時に、メモリの使用も改善される必要があります。
すべての段階で、開発者は zkVM のパフォーマンスのためにコードを調整すべきではありません。 開発者エクスペリエンスは zkVM の主要な利点です。 パフォーマンス基準を満たすために DevEx を犠牲にすることは、基準テストの意味を失うだけでなく、zkVM の目的にも反することになります。
これらの指標は主に証明者のコストに焦点を当てています。ただし、検証者のコストが無制限に増加することを許可すると（つまり、証明のサイズや検証時間に上限がない場合）、任意の証明者の指標を簡単に満たすことができます。したがって、次の段階の要件を満たすには、最大証明サイズと最大検証時間の両方を制限する必要があります。
ステージ1の要件：「合理的な非凡な検証コスト」
• サイズの証明：証拠のサイズ未満である必要があります。
• 検証時間：検証の証明の速度は、プログラムのネイティブな実行よりも遅くしてはならない（つまり、計算の直接実行よりも遅くしてはならない）。
これらは最低限度の簡潔性要件であり、証明のサイズと検証時間が、証明を検証者に直接送信し、直接検査させるよりも悪化しないことを確認します。
フェーズ2以上
•最大校正サイズ:256 KB。
• 最大検証時間:16ミリ秒。
これらの上限は、新しい高速プルーフ技術に適応するために意図的に緩められており、それがより高い検証コストをもたらす可能性がある場合でも、これを排除しています。同時に、これらの上限は、ブロックチェーンでの使用にほとんどのプロジェクトが意欲を示さない高額な証明を除外しています。
スピード段階1
シングルスレッドの証明速度はネイティブ実行よりも100,000倍以上遅くなってはならない（イーサリアムブロック認証に限らず、さまざまなアプリケーションに適用可能）、かつプリコンパイルに依存してはなりません。
具体には、現代のノートパソコンに搭載された RISC-V プロセッサが約30億サイクル/秒で動作していると仮定すると、ステージ1に到達するということは、そのノートパソコンが30,000 RISC-V サイクル/秒の速度でプルーフ（シングルスレッド）を生成できることを意味します。
バリデーターのコストは、以前に定義された「合理的で非トリビアルな検証コスト」基準を満たさなければなりません。
スピード段階 2
単一スレッドの証明速度は、ネイティブ実行よりも10,000倍以上遅くなってはならない。
または、将来有望な SNARK メソッド（特にバイナリ領域 SNARK）が現在の CPU および GPU 制限に達するため、この段階で FPGA（または ASIC）を使用できます。
FPGAでネイティブスピードでシミュレートされたRISC-Vコアの数を計算します。
RISC-Vの実行（ほぼリアルタイム）に必要なFPGAの数を計算し、シミュレーションして証明します。
もし（2）の数量が（1）の 10,000 倍を超えない場合、段階 2 が満たされます。
• サイズの証明: 最大256 KB。
• 検証時間:標準CPUで最大16ms。
スピード段階 3
速度段階2に到達した基盤の上で、1000×以内の証明コスト（さまざまなアプリケーションに適用）を実現し、自動合成と形式的検証のためのプリコンパイルを使用する必要があります。基本的には、各プログラムの命令セットを動的にカスタマイズして、証明生成を高速化する必要がありますが、使いやすさと形式的検証を確保する必要があります（プリコンパイルがなぜ両刃の剣であるか、および「手書き」プリコンパイルが持続可能な方法でない理由については、次のセクションを参照してください）。
メモリ段階 1
2 GB未満のメモリで段階1の速度を達成し、ゼロ知識の要件を満たす。この段階はモバイルデバイスやブラウザにとって重要であり、多くのクライアントzkVMユースケースが開かれます。例えば、位置プライバシーや身元証明にスマートフォンを使用する場合、証明生成に1-2 GBを超えるメモリが必要な場合、ほとんどのモバイルデバイスは実行できません。
2つの重要なポイント：
たとえ大規模な計算（数兆サイクルのCPU実行が必要なものであっても）、証明システムは2 GBのメモリ制限を維持する必要があります。それ以外の場合、適用範囲が制限されます。
もし速度が非常に遅いことが証明されれば、2 GB のメモリ上限を維持することは非常に簡単です。そのため、メモリ段階1を意味のあるものにするためには、2 GBのメモリ制限内で段階1の速度を達成する必要があります。
メモリ段階 2
200 MB未満のメモリーでスピード段階1（メモリー段階1より10倍速い）に到達します。
なぜ 200 MB に低下させる必要があるのですか？ブロックチェーン以外のシナリオを考えてみましょう：HTTPS ウェブサイトにアクセスすると、認証および暗号化証明書がダウンロードされます。ウェブサイトがこれらの証明書を zk 証明で送信するように変更した場合、大規模なウェブサイトは数百万の証明を毎秒生成する必要があります。各証明に 2 GB のメモリが必要ならば、計算リソースの要件はPB レベルに達するでしょう。明らかに実現不可能です。したがって、ブロックチェーン以外のアプリケーションにおいてメモリ使用量をさらに削減することが非常に重要です。
プリコンパイル：最後の一マイル、または杖？
プリコンパイルとは、特定の関数（ハッシュ、楕円曲線署名など）を最適化した SNARK 制約システムを指します。イーサリアムでは、プリコンパイルは Merkle ハッシュと署名検証のコストを削減できますが、プリコンパイルに過度に依存すると、SNARK のコア効率を真に向上させることはできません。
コンパイルされた問題
1. 依然遅い：ハッシュおよび署名のプリコンパイルを使用しても、zkVM はブロックチェーン内外で依然としてコアプルーフシステムの効率の問題があります。
2.セキュリティホール：手書きのプリコンパイルが形式的な検証を経ていない場合、ほぼ必ずホールが存在し、致命的なセキュリティの失敗を引き起こす可能性があります。
3.開発者体験が悪い：現在、多くの zkVM は開発者に手書きの制約システムを要求し、1960年代のプログラミング方法と類似しており、開発体験に深刻な影響を与えています。
4.ベンチマークの誤解：ベンチマークが特定の事前コンパイル最適化に依存している場合、人々は最適化された手動制約システムに焦点を当てることがあり、SNARKデザインの向上ではなく。
5. I/OコストとRAMなしのアクセス事前にコンパイルすると、重い暗号化タスクのパフォーマンスが向上する可能性がありますが、より多様なワークロードに意味のあるアクセラレーションを提供できない場合があります。これは、入出力を処理する際に多くのコストが発生し、RAMを使用できないためです。
ブロックチェーン環境でも、イーサリアムなどの単一のL1を超えると、異なるハッシュ関数や署名方式に直面することになります（たとえば、クロスチェーンブリッジを構築したい場合）。この問題を解決するために、継続的なプリコンパイルが行われており、これは拡張不可能であり、巨大なセキュリティリスクをもたらします。
私は確かに、長期的にはプリコンパイルが依然として重要であると信じていますが、それらが自動的に合成され、正式に検証された場合にのみそうなります。これにより、zkVM 開発者のエクスペリエンスを維持しつつ、災害的なセキュリティリスクを回避できます。この見解はステージ3に反映されています。
予想されるタイムライン
私は、zkVMのマイルストーンとして今年後半にSpeed Phase 1とMemory Phase 1が達成されることを期待しています。次の2年間でSpeed Phase 2も実現できると考えていますが、新しい研究方針なしにこの目標を達成できるかどうかは現時点では不明です。
私は、残りの段階（スピードステージ3およびメモリステージ2）が達成されるには数年かかると予想しています。
zkVMのセキュリティとパフォーマンスの段階がそれぞれリストされていますが、これらは完全に独立しているわけではありません。zkVM内の脆弱性が次々と発見される中、いくつかの脆弱性の修正は性能の大幅な低下をもたらすことが避けられないと予想しています。したがって、zkVMがセキュリティ段階2に達する前に、そのパフォーマンステスト結果は一時的なデータと見なす必要があります。
zkVMはゼロ知識証明の普及において大きな潜在能力を持っていますが、現在はまだ初期段階にあり、セキュリティの課題に満ちており、重大なパフォーマンスのボトルネックが存在しています。市場の煽りとマーケティングの宣伝が、実際の進展を測ることを困難にしています。明確なセキュリティとパフォーマンスのマイルストーンを通じて、私は霧を晴らすための道筋を提供したいと考えています。私たちは最終的に目標に到達するでしょうが、それには時間と研究・エンジニアリングへの継続的な努力が必要です。