> オリジナルタイトル: The path to secure and efficient zkVMs: How to track progress> 原著者: a16z crypto>オリジナルコンピレーション:Golem、OdailyzkVM（ゼロ・ナレッジ・バーチャル・マシン）は、「SNARKを一般化する」と約束し、誰でも（SNARKの専門知識を持っていない人でも）特定の入力（または証拠）上で任意のプログラムを正しく実行したことを証明できるようにします。彼らの主な利点は開発者のエクスペリエンスにありますが、現在、セキュリティとパフォーマンスの両面で大きな課題に直面しています。 zkVMのビジョンを実現するためには、設計者はこれらの課題を乗り越える必要があります。この記事では、zkVMの開発の可能な段階を示し、これらの段階を完了するには数年かかるでしょう。# チャレンジセキュリティの面では、zkVM は非常に複雑なソフトウェアプロジェクトであり、依然として脆弱性に満ちています。パフォーマンスの面では、プログラムの正しい実行を証明する速度は、ローカルでの実行よりも数十万倍遅くなる可能性があり、これによりほとんどのアプリケーションは現実世界で展開することができません。これらの現実の課題が存在するにもかかわらず、ブロックチェーン業界の多くの企業は、zkVMを即座に展開できるものとして描写しています。実際、いくつかのプロジェクトは、証明を生成するために多額の計算コストを支払っています。ただし、zkVMはまだ完全ではないため、これは単にSNARKによる保護を受けているかのように見せかける高価な方法であり、実際には許可によって保護されているか、さらに悪い場合には攻撃を受けやすいということです。安全で高性能なzkVMを実現するまで、数年の時間がかかります。この記事では、zkVMの進捗状況を追跡するための段階的な具体的な目標が提案されており、これらの目標により、煽動が排除され、コミュニティが真の進歩に集中できるようになります。# セキュリティ段階SNARKに基づくzkVMは通常、2つの主要なコンポーネントを含みます：・**多項式インタラクティブOracle証明(PIOP)：**多項式（またはその制約から導かれたもの）に関する述説を証明するためのインタラクティブ証明フレームワーク。· **多項式コミットメントスキーム (PCS)：** 証明者が多項式評価について偽りをつけることが発見されないように保証します。zkVMの本質は、実行を効果的に追跡し、それを制約システムにエンコードすることです。すなわち、仮想マシンがレジスタとメモリを正しく使用するように強制し、その後SNARKを適用してこれらの制約が満たされていることを証明します。zkVMなどの複雑なシステムにエラーがないことを確認する唯一の方法は、形式的な検証です。以下はセキュリティ段階の細分化です。段階1では正しいプロトコルに焦点を当て、段階2と段階3では正しい実装に焦点を当てています。## セキュリティ段階1：正しいプロトコル1. PIOPの信頼性の正式な検証。2、一部の暗号仮定または理想モデルにおいて制約力を持つ形式での検証証明；3、Fiat-Shamir を使用する場合、PIOP と PCS を組み合わせた簡潔な証明によって、ランダムオラクルモデルで安全な正式検証が提供されます（必要に応じて他の暗号仮定を使用して強化する）。PIOPの制約システムは、VMの意味形式検証証明に等しいです。5、すべてのこれらの部分を統合して、形式的に検証された安全な SNARK 証明として1つの統一されたものにします。これにより、VM バイトコードで指定されたプログラムを実行できます。プロトコルがゼロ知識を実現しようとする場合、この特性も形式的に検証する必要があり、証人に関する機密情報が漏洩しないようにします。**再帰警告：** zkVM が再帰を使用する場合、この段階を完了と見なすために、再帰に関与するすべての PIOP、プロミスプラン、および拘束システムを検証する必要があります。## セキュリティ段階2：正しい検証器の実装zkVM検証器の実装（Rust、Solidityなどを使用）が第1段階の検証プロトコルと一致していることを形式的に検証すること。これにより、実装されたプロトコルが合理的であることが保証されます（単なる紙上の設計やLeanなどで書かれた効率の悪い仕様ではなく）。第2段階では、検証器の実装に焦点を当てる理由は2つあります。まず、検証器を正しく使用するだけで信頼性が確保されるため（つまり、検証器が虚偽の声明を信じることができないことが実際に真実であることを確認するため）。 また、zkVMの検証器の実装はproverの実装よりも1桁単位で簡単です。## セキュリティステップ3：正しいプルーフリーダーの実装zkVMプルーバーの実装は、ステージ1およびステージ2の検証プルーフシステムの証明を正しく生成し、公式検証を取得します。これにより、完全性が確保され、「カードが挟まる」ステートメントがzkVMを使用するシステムによって行われないことが保証されます。プルーバーがゼロ知識を実装する場合、このプロパティを正式に検証する必要があります。## 推定タイムライン**· 第1段階の進展:**来年、ZKLibなどの成果を期待できます。しかし、少なくとも2年間は、zkVMが第1段階の要件を完全に満たすことはできません。**· 第2および第3段階：**これらの段階は第1段階の一部と同時に進行することができます。たとえば、いくつかのチームは、Plonk検証器の実装が論文のプロトコルに一致することを証明しています（論文のプロトコル自体が完全に検証されていないかもしれません）。**それでも、私はzkVMが4年未満で第3段階に到達することはないと予想しています。そして、おそらくそれ以上の時間がかかるでしょう。**## キーポイント：Fiat-Shamir のセキュリティと検証済みのバイトコード主要な複雑な要因の1つは、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の速度が100,000倍以下に低下することを基準とすべきです-たとえこれが最初のステップであるに過ぎないにしても。本当の主流の採用には、10,000倍以下の費用が必要かもしれません。## パフォーマンスの評価方法SNARKのパフォーマンスには3つの主要な構成要素があります：· ベースプルーフシステムの内在効率。アプリケーション固有の最適化（例：プリコンパイルなど）。・エンジニアリングおよびハードウェアアクセラレーション（例：GPU、FPGA、またはマルチコアCPU）。後の2つは実際の展開に非常に重要ですが、通常はどのプルーフシステムにも適用されるため、基本的なコストを反映するとは限りません。たとえば、zkEVMにGPUアクセラレーションとプリコンパイルを追加すると、CPUベースでプリコンパイルを行わない方法よりも50倍高速化できます。これにより、本質的に効率の低いシステムが同じように磨かれていないシステムよりも優れて見えるだけで十分です。**したがって、専用ハードウェアや事前コンパイルのない状況で、SNARK のパフォーマンスを重点的に紹介します。**これは通常のベンチマークテスト手法とは異なり、後者は通常、これらすべての要素を「ヘッドライン数字」としてまとめます。これは、ダイヤモンドの固有の透明度ではなく、研磨時間に基づいてダイヤモンドの価値を判断することに相当します。私たちの目標は、一般的な証明システムの固有の費用を排除することです-コミュニティが混乱要因を排除し、証明システム設計の真の進歩に焦点を当てるのを支援することです。# パフォーマンス段階以下は、5つのパフォーマンス達成のマイルストーンです。まず、CPU上のプルーバーのコストを数桁削減する必要があります。そのようにしなければ、ハードウェアをさらに削減する方向に重点を置くべきです。メモリ使用率も向上させる必要があります。すべての段階で、開発者はzkVMに特定のコードをカスタマイズする必要はありません。 開発者のエクスペリエンスはzkVMの主要な利点です。 パフォーマンス基準を満たすためにDevExを犠牲にすることは、zkVMの本質に反するものです。これらの指標は、プルーファーのコストに重点を置いています。ただし、無制限の検証者コスト（つまり、プルーフのサイズや検証時間に上限がない）を許可すると、任意のプルーファーの指標を簡単に満たすことができます。したがって、システムが所定の段階を満たすためには、プルーフのサイズと検証時間に最大値を指定する必要があります。###パフォーマンス要件**段階 1 要件：「合理であり、かつ非凡な検証コスト」：**・サイズ証明：サイズ証明はウィットネスサイズよりも小さくする必要があります。· 検証時間：検証証明の速度は、ローカルプログラムの実行速度よりも遅くなってはなりません（すなわち、計算を実行する際に正確性証明がない場合）。これらは最低限度の簡潔な要件です。これにより、証明のサイズと検証時間が、証人に証拠を送信し、証人が直接正確性を確認する方法よりも悪化しないことが保証されます。ステージ2以降の要件:· 校正の最大サイズ: 256 KB。· 最大検証時間:16ミリ秒これらの閾値は意図的に拡大されており、新しい高速プルーフ技術による高い検証コストに対応するためです。同時に、非常に高価なプルーフが除外されており、ほとんどのプロジェクトがそれらをブロックチェーンに含めることを望んでいません。## 速度フェーズ 1シングルスレッドプルーフは、ローカル実行よりも最大10万倍遅くする必要があります。 一連のアプリケーションで測定する（イーサリアムブロックに限定されない）プリコンパイルに依存しません。具体的に言えば、現代のノートパソコンで約30億回のサイクルで動作するRISC-Vプロセスを想像してみてください。段階1を達成すると、同じノートパソコンで約30,000個のRISC-Vサイクル（シングルスレッド）を1秒間に証明できるようになります。ただし、検証コストは「合理的でなければならない」という前述の条件を満たさなければなりません。## 速度フェーズ 2シングルスレッドプルーフは、ローカル実行よりも最大で10,000倍遅くなければなりません。または、将来性のあるいくつかの SNARK メソッド（特にバイナリフィールドに基づくメソッド）が現在の CPU および GPU によって妨げられているため、この段階に到達するためには、FPGA（場合によっては ASIC）を使用することを検討することができます。FPGAはローカルスピードでシミュレートできるRISC-Vコアの数を持つことができます；RISC-Vの（ほぼ）リアルタイム実行に必要なFPGAの数量をシミュレーションおよび証明します。後者が前者より最大で10,000倍多い場合、第2段階に進む資格があります。標準CPUでは、証明サイズは最大256 KB、検証時間は最大16ミリ秒でなければなりません。## 速度フェーズ 3**段階2に到達するだけでなく、自動合成と形式検証を使用して、1000倍未満の証明コストで（一般的なアプリケーションに適用可能な）事前コンパイルされた実装を行うことができます。**基本的に、証明を加速するためにそれぞれのプログラムに動的にカスタマイズされた命令セットを提供することができますが、使いやすさと形式検証を考慮する必要があります。## メモリ段階 1第1段階の速度は、プルーフソンのメモリが2GB未満であることを実現しています（同時にゼロ知識も実現しています）。多くのモバイルデバイスやブラウザにとって、これは非常に重要です。そのため、多くのクライアント zkVM ユースケースが開始されています。クライアント証明は非常に重要です。なぜなら、私たちの携帯電話は私たちが現実世界と持続的に接触する手段だからです：位置、証明などを追跡します。証明を生成するのに1-2 GB以上のメモリが必要な場合、現代のほとんどのモバイルデバイスにとっては多すぎます。2つの点を明確にする必要があります：・2 GBのスペース制限は大規模なステートメントに適用されます（数兆のCPUサイクルが必要なステートメントをローカルで実行するため）。 小規模なステートメントに対してのみスペース制限を実現する証明システムは一般的に適用範囲が不足しています。· 証明器が非常に遅い場合、証明器のメモリを 2 GB 以下に保つことが非常に簡単になります。そのため、メモリ段階 1 を簡単にしないために、2 GB の空間制限内で速度段階 1 を満たすことを要求します。## メモリ段階 2段階1の速度は、メモリ使用量が200MB未満で実現されました（メモリ段階1よりも10倍良い）。2 GB 以下に押さえる理由は何ですか？非ブロックチェーンの例を考えてみましょう：ウェブサイトにHTTPSでアクセスするたびに、証明書をダウンロードして身元確認と暗号化を行います。逆に、ウェブサイトはこれらの証明書を持つ zk 証明を送信できます。大規模なウェブサイトは、1秒あたり数百万のこのような証明を送信する可能性があります。各証明が生成に2 GBのメモリを必要とする場合、合計でPB単位のRAMが必要になります。メモリ使用量をさらに削減することは、非ブロックチェーン展開にとって非常に重要です。## コンパイル済み：最後の1マイルは杖ですか？zkVMデザインでは、プリコンパイルは特定の機能に合わせてカスタマイズされた専用のSNARK（または制約システム）を指します。たとえば、デジタル署名に使用されるKeccak/SHAハッシュや楕円曲線群演算などです。イーサリアムでは（ほとんどの重い作業はMerkleハッシュと署名検証に関連しています）、手動で作成されたいくつかのプリコンパイルは検証者の負担を減らすことができます。しかし、それらを杖として依存するだけでは、SNARKが必要とする目標を達成することはできません。その理由は次のとおりです：**· 大部分のアプリケーション（内部および外部のブロックチェーン）にとっては、まだ速すぎます：**ハッシュと署名の事前コンパイルを使用しても、現在の zkVM は依然として遅すぎます（ブロックチェーン環境内外を問わず）、なぜならコアの証明システムが効率的でないからです。**· セキュリティ障害：**正式に検証されていない手書きのプリコンパイルは、ほぼ間違いだらけであり、壊滅的なセキュリティ障害を引き起こす可能性があります。**· 開発者のエクスペリエンスが悪い：** 現在のほとんどの zkVMs では、新しいプリコンパイルを追加するということは、各機能に手動で制約システムを書く必要があることを意味します。実質的には、1960年代の作業フローに戻ってしまいます。既存のプリコンパイルを使用していても、開発者はそれぞれのプリコンパイルを呼び出すためにコードを再構築する必要があります。パフォーマンスの増分を追求するために、セキュリティと開発者のエクスペリエンスを犠牲にするのではなく、セキュリティと開発者のエクスペリエンスを最適化すべきです。このようなアプローチは、パフォーマンスが適切なレベルに達していないことを示すだけであり、証明することはできません。**· I/OコストがかかりRAMなし：**事前にコンパイルすると、重い暗号化タスクのパフォーマンスが向上する可能性がありますが、より多様なワークロードに意味のある加速を提供できない可能性があります。なぜなら、入出力の伝達時に多くのコストがかかり、RAMを使用できないためです。ブロックチェーン環境でも、例えばイーサリアムのような単一のL1（例：クロスチェーンブリッジのシリーズを構築したい場合など）を超えている限り、異なるハッシュ関数や署名方式に直面することになります。同じ問題に何度も事前にコンパイルを行うことは、拡張性がなく、大きなセキュリティリスクをもたらす可能性があります。これらすべての理由から、私たちの最優先課題は、zkVMの効率を向上させることです。最高のzkVMテクノロジーを生み出すことは、最高のプリコンパイルを生み出すことにもつながります。私は、プリコンパイルが長期的には引き続き非常に重要であると確信していますが、それらが自動的に合成され、公式に検証されることが前提です。これにより、zkVMの開発者エクスペリエンスを維持すると同時に、災害的なセキュリティリスクを回避することができます。この視点は、段階3のスピードに反映されています。## 推定タイムライン私は、zkVMの一部が今年の後半に段階1の速度と段階1のメモリを実現すると予想しています。将来2年間で段階2の速度も実現すると考えていますが、まだ確定していません。新しいアイデアが出てこなければ、この目標を達成できるかどうかはわかりません。残りの段階（速度段階3とメモリ段階2）を実現するには数年かかると予想しています。# まとめこの記事では、zkVMのセキュリティとパフォーマンスの段階をそれぞれ確認しましたが、zkVMのこれらの側面は完全に独立していません。zkVMでより多くの脆弱性が発見されるにつれ、一部の脆弱性はパフォーマンスが大幅に低下する場合にのみ修正できると予想されます。zkVMがセキュリティ段階2に達するまで、パフォーマンスは一時停止すべきです。zkVMはゼロ知識証明の普及を実現する可能性がありますが、まだ初期段階にあり、セキュリティの課題や大きなパフォーマンスのコストがあります。煽りやマーケティング活動により、実際の進捗を評価することが困難になっています。明確なセキュリティとパフォーマンスのマイルストーンを明らかにすることで、邪魔を排除するロードマップを提供できることを願っています。目標は達成されますが、それには時間と継続的な努力が必要です。原文リンク**：**
a16z: 安全で効率的な zkVM を段階的に実装する方法 (開発者向け必見)
zkVM（ゼロ・ナレッジ・バーチャル・マシン）は、「SNARKを一般化する」と約束し、誰でも（SNARKの専門知識を持っていない人でも）特定の入力（または証拠）上で任意のプログラムを正しく実行したことを証明できるようにします。彼らの主な利点は開発者のエクスペリエンスにありますが、現在、セキュリティとパフォーマンスの両面で大きな課題に直面しています。 zkVMのビジョンを実現するためには、設計者はこれらの課題を乗り越える必要があります。この記事では、zkVMの開発の可能な段階を示し、これらの段階を完了するには数年かかるでしょう。
チャレンジ
セキュリティの面では、zkVM は非常に複雑なソフトウェアプロジェクトであり、依然として脆弱性に満ちています。パフォーマンスの面では、プログラムの正しい実行を証明する速度は、ローカルでの実行よりも数十万倍遅くなる可能性があり、これによりほとんどのアプリケーションは現実世界で展開することができません。
これらの現実の課題が存在するにもかかわらず、ブロックチェーン業界の多くの企業は、zkVMを即座に展開できるものとして描写しています。実際、いくつかのプロジェクトは、証明を生成するために多額の計算コストを支払っています。ただし、zkVMはまだ完全ではないため、これは単にSNARKによる保護を受けているかのように見せかける高価な方法であり、実際には許可によって保護されているか、さらに悪い場合には攻撃を受けやすいということです。
安全で高性能なzkVMを実現するまで、数年の時間がかかります。この記事では、zkVMの進捗状況を追跡するための段階的な具体的な目標が提案されており、これらの目標により、煽動が排除され、コミュニティが真の進歩に集中できるようになります。
セキュリティ段階
SNARKに基づくzkVMは通常、2つの主要なコンポーネントを含みます：
・**多項式インタラクティブOracle証明(PIOP)：**多項式（またはその制約から導かれたもの）に関する述説を証明するためのインタラクティブ証明フレームワーク。
· 多項式コミットメントスキーム (PCS)： 証明者が多項式評価について偽りをつけることが発見されないように保証します。
zkVMの本質は、実行を効果的に追跡し、それを制約システムにエンコードすることです。すなわち、仮想マシンがレジスタとメモリを正しく使用するように強制し、その後SNARKを適用してこれらの制約が満たされていることを証明します。
zkVMなどの複雑なシステムにエラーがないことを確認する唯一の方法は、形式的な検証です。以下はセキュリティ段階の細分化です。段階1では正しいプロトコルに焦点を当て、段階2と段階3では正しい実装に焦点を当てています。
セキュリティ段階1：正しいプロトコル
2、一部の暗号仮定または理想モデルにおいて制約力を持つ形式での検証証明；
3、Fiat-Shamir を使用する場合、PIOP と PCS を組み合わせた簡潔な証明によって、ランダムオラクルモデルで安全な正式検証が提供されます（必要に応じて他の暗号仮定を使用して強化する）。
PIOPの制約システムは、VMの意味形式検証証明に等しいです。
5、すべてのこれらの部分を統合して、形式的に検証された安全な SNARK 証明として1つの統一されたものにします。これにより、VM バイトコードで指定されたプログラムを実行できます。プロトコルがゼロ知識を実現しようとする場合、この特性も形式的に検証する必要があり、証人に関する機密情報が漏洩しないようにします。
再帰警告： zkVM が再帰を使用する場合、この段階を完了と見なすために、再帰に関与するすべての PIOP、プロミスプラン、および拘束システムを検証する必要があります。
セキュリティ段階2：正しい検証器の実装
zkVM検証器の実装（Rust、Solidityなどを使用）が第1段階の検証プロトコルと一致していることを形式的に検証すること。これにより、実装されたプロトコルが合理的であることが保証されます（単なる紙上の設計やLeanなどで書かれた効率の悪い仕様ではなく）。
第2段階では、検証器の実装に焦点を当てる理由は2つあります。まず、検証器を正しく使用するだけで信頼性が確保されるため（つまり、検証器が虚偽の声明を信じることができないことが実際に真実であることを確認するため）。 また、zkVMの検証器の実装はproverの実装よりも1桁単位で簡単です。
セキュリティステップ3：正しいプルーフリーダーの実装
zkVMプルーバーの実装は、ステージ1およびステージ2の検証プルーフシステムの証明を正しく生成し、公式検証を取得します。これにより、完全性が確保され、「カードが挟まる」ステートメントがzkVMを使用するシステムによって行われないことが保証されます。プルーバーがゼロ知識を実装する場合、このプロパティを正式に検証する必要があります。
推定タイムライン
**· 第1段階の進展:**来年、ZKLibなどの成果を期待できます。しかし、少なくとも2年間は、zkVMが第1段階の要件を完全に満たすことはできません。
**· 第2および第3段階：**これらの段階は第1段階の一部と同時に進行することができます。たとえば、いくつかのチームは、Plonk検証器の実装が論文のプロトコルに一致することを証明しています（論文のプロトコル自体が完全に検証されていないかもしれません）。それでも、私はzkVMが4年未満で第3段階に到達することはないと予想しています。そして、おそらくそれ以上の時間がかかるでしょう。
キーポイント：Fiat-Shamir のセキュリティと検証済みのバイトコード
主要な複雑な要因の1つは、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の速度が100,000倍以下に低下することを基準とすべきです-たとえこれが最初のステップであるに過ぎないにしても。本当の主流の採用には、10,000倍以下の費用が必要かもしれません。
パフォーマンスの評価方法
SNARKのパフォーマンスには3つの主要な構成要素があります：
· ベースプルーフシステムの内在効率。
アプリケーション固有の最適化（例：プリコンパイルなど）。
・エンジニアリングおよびハードウェアアクセラレーション（例：GPU、FPGA、またはマルチコアCPU）。
後の2つは実際の展開に非常に重要ですが、通常はどのプルーフシステムにも適用されるため、基本的なコストを反映するとは限りません。たとえば、zkEVMにGPUアクセラレーションとプリコンパイルを追加すると、CPUベースでプリコンパイルを行わない方法よりも50倍高速化できます。これにより、本質的に効率の低いシステムが同じように磨かれていないシステムよりも優れて見えるだけで十分です。
**したがって、専用ハードウェアや事前コンパイルのない状況で、SNARK のパフォーマンスを重点的に紹介します。**これは通常のベンチマークテスト手法とは異なり、後者は通常、これらすべての要素を「ヘッドライン数字」としてまとめます。これは、ダイヤモンドの固有の透明度ではなく、研磨時間に基づいてダイヤモンドの価値を判断することに相当します。私たちの目標は、一般的な証明システムの固有の費用を排除することです-コミュニティが混乱要因を排除し、証明システム設計の真の進歩に焦点を当てるのを支援することです。
パフォーマンス段階
以下は、5つのパフォーマンス達成のマイルストーンです。まず、CPU上のプルーバーのコストを数桁削減する必要があります。そのようにしなければ、ハードウェアをさらに削減する方向に重点を置くべきです。メモリ使用率も向上させる必要があります。
すべての段階で、開発者はzkVMに特定のコードをカスタマイズする必要はありません。 開発者のエクスペリエンスはzkVMの主要な利点です。 パフォーマンス基準を満たすためにDevExを犠牲にすることは、zkVMの本質に反するものです。
これらの指標は、プルーファーのコストに重点を置いています。ただし、無制限の検証者コスト（つまり、プルーフのサイズや検証時間に上限がない）を許可すると、任意のプルーファーの指標を簡単に満たすことができます。したがって、システムが所定の段階を満たすためには、プルーフのサイズと検証時間に最大値を指定する必要があります。
###パフォーマンス要件
段階 1 要件：「合理であり、かつ非凡な検証コスト」：
・サイズ証明：サイズ証明はウィットネスサイズよりも小さくする必要があります。
· 検証時間：検証証明の速度は、ローカルプログラムの実行速度よりも遅くなってはなりません（すなわち、計算を実行する際に正確性証明がない場合）。
これらは最低限度の簡潔な要件です。これにより、証明のサイズと検証時間が、証人に証拠を送信し、証人が直接正確性を確認する方法よりも悪化しないことが保証されます。
ステージ2以降の要件:
· 校正の最大サイズ: 256 KB。
· 最大検証時間:16ミリ秒
これらの閾値は意図的に拡大されており、新しい高速プルーフ技術による高い検証コストに対応するためです。同時に、非常に高価なプルーフが除外されており、ほとんどのプロジェクトがそれらをブロックチェーンに含めることを望んでいません。
速度フェーズ 1
シングルスレッドプルーフは、ローカル実行よりも最大10万倍遅くする必要があります。 一連のアプリケーションで測定する（イーサリアムブロックに限定されない）プリコンパイルに依存しません。
具体的に言えば、現代のノートパソコンで約30億回のサイクルで動作するRISC-Vプロセスを想像してみてください。段階1を達成すると、同じノートパソコンで約30,000個のRISC-Vサイクル（シングルスレッド）を1秒間に証明できるようになります。ただし、検証コストは「合理的でなければならない」という前述の条件を満たさなければなりません。
速度フェーズ 2
シングルスレッドプルーフは、ローカル実行よりも最大で10,000倍遅くなければなりません。
または、将来性のあるいくつかの SNARK メソッド（特にバイナリフィールドに基づくメソッド）が現在の CPU および GPU によって妨げられているため、この段階に到達するためには、FPGA（場合によっては ASIC）を使用することを検討することができます。
FPGAはローカルスピードでシミュレートできるRISC-Vコアの数を持つことができます；
RISC-Vの（ほぼ）リアルタイム実行に必要なFPGAの数量をシミュレーションおよび証明します。
後者が前者より最大で10,000倍多い場合、第2段階に進む資格があります。標準CPUでは、証明サイズは最大256 KB、検証時間は最大16ミリ秒でなければなりません。
速度フェーズ 3
**段階2に到達するだけでなく、自動合成と形式検証を使用して、1000倍未満の証明コストで（一般的なアプリケーションに適用可能な）事前コンパイルされた実装を行うことができます。**基本的に、証明を加速するためにそれぞれのプログラムに動的にカスタマイズされた命令セットを提供することができますが、使いやすさと形式検証を考慮する必要があります。
メモリ段階 1
第1段階の速度は、プルーフソンのメモリが2GB未満であることを実現しています（同時にゼロ知識も実現しています）。
多くのモバイルデバイスやブラウザにとって、これは非常に重要です。そのため、多くのクライアント zkVM ユースケースが開始されています。クライアント証明は非常に重要です。なぜなら、私たちの携帯電話は私たちが現実世界と持続的に接触する手段だからです：位置、証明などを追跡します。証明を生成するのに1-2 GB以上のメモリが必要な場合、現代のほとんどのモバイルデバイスにとっては多すぎます。2つの点を明確にする必要があります：
・2 GBのスペース制限は大規模なステートメントに適用されます（数兆のCPUサイクルが必要なステートメントをローカルで実行するため）。 小規模なステートメントに対してのみスペース制限を実現する証明システムは一般的に適用範囲が不足しています。
· 証明器が非常に遅い場合、証明器のメモリを 2 GB 以下に保つことが非常に簡単になります。そのため、メモリ段階 1 を簡単にしないために、2 GB の空間制限内で速度段階 1 を満たすことを要求します。
メモリ段階 2
段階1の速度は、メモリ使用量が200MB未満で実現されました（メモリ段階1よりも10倍良い）。
2 GB 以下に押さえる理由は何ですか？非ブロックチェーンの例を考えてみましょう：ウェブサイトにHTTPSでアクセスするたびに、証明書をダウンロードして身元確認と暗号化を行います。逆に、ウェブサイトはこれらの証明書を持つ zk 証明を送信できます。大規模なウェブサイトは、1秒あたり数百万のこのような証明を送信する可能性があります。各証明が生成に2 GBのメモリを必要とする場合、合計でPB単位のRAMが必要になります。メモリ使用量をさらに削減することは、非ブロックチェーン展開にとって非常に重要です。
コンパイル済み：最後の1マイルは杖ですか？
zkVMデザインでは、プリコンパイルは特定の機能に合わせてカスタマイズされた専用のSNARK（または制約システム）を指します。たとえば、デジタル署名に使用されるKeccak/SHAハッシュや楕円曲線群演算などです。イーサリアムでは（ほとんどの重い作業はMerkleハッシュと署名検証に関連しています）、手動で作成されたいくつかのプリコンパイルは検証者の負担を減らすことができます。しかし、それらを杖として依存するだけでは、SNARKが必要とする目標を達成することはできません。その理由は次のとおりです：
**· 大部分のアプリケーション（内部および外部のブロックチェーン）にとっては、まだ速すぎます：**ハッシュと署名の事前コンパイルを使用しても、現在の zkVM は依然として遅すぎます（ブロックチェーン環境内外を問わず）、なぜならコアの証明システムが効率的でないからです。
**· セキュリティ障害：**正式に検証されていない手書きのプリコンパイルは、ほぼ間違いだらけであり、壊滅的なセキュリティ障害を引き起こす可能性があります。
· 開発者のエクスペリエンスが悪い： 現在のほとんどの zkVMs では、新しいプリコンパイルを追加するということは、各機能に手動で制約システムを書く必要があることを意味します。実質的には、1960年代の作業フローに戻ってしまいます。既存のプリコンパイルを使用していても、開発者はそれぞれのプリコンパイルを呼び出すためにコードを再構築する必要があります。パフォーマンスの増分を追求するために、セキュリティと開発者のエクスペリエンスを犠牲にするのではなく、セキュリティと開発者のエクスペリエンスを最適化すべきです。このようなアプローチは、パフォーマンスが適切なレベルに達していないことを示すだけであり、証明することはできません。
**· I/OコストがかかりRAMなし：**事前にコンパイルすると、重い暗号化タスクのパフォーマンスが向上する可能性がありますが、より多様なワークロードに意味のある加速を提供できない可能性があります。なぜなら、入出力の伝達時に多くのコストがかかり、RAMを使用できないためです。ブロックチェーン環境でも、例えばイーサリアムのような単一のL1（例：クロスチェーンブリッジのシリーズを構築したい場合など）を超えている限り、異なるハッシュ関数や署名方式に直面することになります。同じ問題に何度も事前にコンパイルを行うことは、拡張性がなく、大きなセキュリティリスクをもたらす可能性があります。
これらすべての理由から、私たちの最優先課題は、zkVMの効率を向上させることです。最高のzkVMテクノロジーを生み出すことは、最高のプリコンパイルを生み出すことにもつながります。私は、プリコンパイルが長期的には引き続き非常に重要であると確信していますが、それらが自動的に合成され、公式に検証されることが前提です。これにより、zkVMの開発者エクスペリエンスを維持すると同時に、災害的なセキュリティリスクを回避することができます。この視点は、段階3のスピードに反映されています。
推定タイムライン
私は、zkVMの一部が今年の後半に段階1の速度と段階1のメモリを実現すると予想しています。将来2年間で段階2の速度も実現すると考えていますが、まだ確定していません。新しいアイデアが出てこなければ、この目標を達成できるかどうかはわかりません。残りの段階（速度段階3とメモリ段階2）を実現するには数年かかると予想しています。
まとめ
この記事では、zkVMのセキュリティとパフォーマンスの段階をそれぞれ確認しましたが、zkVMのこれらの側面は完全に独立していません。zkVMでより多くの脆弱性が発見されるにつれ、一部の脆弱性はパフォーマンスが大幅に低下する場合にのみ修正できると予想されます。zkVMがセキュリティ段階2に達するまで、パフォーマンスは一時停止すべきです。
zkVMはゼロ知識証明の普及を実現する可能性がありますが、まだ初期段階にあり、セキュリティの課題や大きなパフォーマンスのコストがあります。煽りやマーケティング活動により、実際の進捗を評価することが困難になっています。明確なセキュリティとパフォーマンスのマイルストーンを明らかにすることで、邪魔を排除するロードマップを提供できることを願っています。目標は達成されますが、それには時間と継続的な努力が必要です。
原文リンク
：