jakiro
著者：Justin Thaler出典：A16Z翻訳：Shan Oppa、Bitchain Vision
ゼロ知識仮想マシン（ZKVMS）目的は、「おしっこを普及させる」ことで、スナークの専門知識のない人々でさえ、特定の入力（または目撃者）でプログラムを正しく実行することを証明できるようにすることです。その中心的な利点は開発者エクスペリエンスにありますが、現在ZKVMは安全そしてパフォーマンスまだ大きな課題があります。ZKVMSが約束を果たしたい場合、デザイナーはこれらの障害を克服しなければなりません。この記事では、ZKVM開発の可能性のある段階を調べて、プロセス全体が必要になる場合があります年そうしてはじめて、それを行うことができます – これが迅速に達成できると言っている人を信じないでください。
課題
存在する安全一方で、ZKVMは非常に複雑なソフトウェアプロジェクトであり、まだ脆弱性に満ちています。
存在するパフォーマンスに関しては、プログラムがネイティブよりも正しく実行されていることを証明するのが遅い場合があります。数十万回、ほとんどのアプリケーションを現実の世界に展開します今のところ不可能です。
それでも、ブロックチェーン業界の多くの声はまだZKVMを促進していますすぐに展開できます、そして一部のプロジェクトでさえ、鎖でのアクティビティのゼロ知識証明を生成するために、すでに高い計算コストを支払っています。ただし、ZKVMSにはまだ多くの脆弱性があるため、このアプローチは実際には高価な変装、システムをスナークによって保護されているように見せますが、実際には許可制御、またはさらに悪いことに攻撃リスクへの暴露。
現実には、私たちはまだ本当に安全で効率的なZKVMを構築することから何年も離れています。この記事では、一連の提案を提案しています具体的で段階的ZKVMの真の進歩を追跡し、誇大広告を弱め、コミュニティが実際の技術的ブレークスルーに焦点を当てるように導くのに役立つという目標。
安全開発段階
背景
に基づくスナークのzkvms通常、2つのコアコンポーネントが含まれています。
1。多項式インタラクティブオラクルプルーフ（PIOP）：多項式を校正するためのインタラクティブな証明フレームワーク（または多項式から派生した制約）。
2。多項式コミットメントスキーム（PCS）：調査者が検出されずに多項式評価結果を偽造できないことを確認してください。
ZKVMパス有効な実行軌跡を制約システムにエンコードします、仮想マシンを確認してください登録するそしてメモリそして、スナークを使用して、これらの制約の満足度を証明します。
このような複雑なシステムでは、ZKVMが脆弱であることを確認する唯一の方法は正式な検証。以下は、ZKVMセキュリティのさまざまな段階です。第1フェーズは、契約の正しさに焦点を当てています、2番目と3番目の段階は、正確性の達成に焦点を当てています。
セキュリティフェーズ1：適切なプロトコル
-
PIOP信頼性の正式な検証。
-
PCは、特定の暗号化の仮定または理想的なモデルに基づく正式な検証の拘束力のある証明です。
-
Fiat-Shamirが使用されている場合、PIOPとPCを組み合わせることで得られる簡潔な議論は、ランダムオラクルモデルの正式な検証証明です（必要に応じて他の暗号化仮定で強化されました）。
-
PIOPによって適用される制約システムは、VMのセマンティクスの正式な検証証明と同等です。
-
これらのセクションはすべて、VMバイトコードで指定されたプログラムを実行するための単一の正式に実証された安全なスナーク証明に完全に「接着」されています。プロトコルがゼロ知識を実装することを意図している場合、この属性も正式に検証して、証人に関する機密情報が明らかにされていないことを確認する必要があります。
ZKVMが使用されている場合再帰、次にPIOP、コミットメントスキーム、制約システムすべて検証する必要がありますそうでなければ、このサブステージを完全に見なすことはできません。
セキュリティフェーズ2：修正された検証器の実装
この段階にはZKVMが必要です検証剤実際の実装（錆、堅実さなど）が実行されます正式な検証、第1フェーズで検証されたプロトコルに準拠していることを確認してください。このフェーズを完了し、ZKVMを意味します成し遂げるそして理論的デザイン1つだけでなく、一貫しています紙のセキュリティ契約、またはリーンなどの言語で書かれた非効率的な仕様。
なぜ証明ではなく、バリデーターのみに焦点を当てます主に2つの理由があります：最初に、バリデーターが正しいことを確認するには、ZKVMプルーフシステムの完全性を確認できます（つまり、虚偽の証明を受け入れるようにバリーターがスプーフィングされていないことを確認してください）。2番、ZKVMの検証剤実装は、Proverの実装よりも1桁以上単純です、検証剤の正確性は、短期的には保証されやすくなります。
セキュリティフェーズ3：正しいプロバーの実装
この段階にはZKVMが必要です証拠の実際の実装正式な検証、それができることを確認してください適切に生成されました第1段階と2番目の段階で検証された証明システムの証明。この段階の目標は次のとおりです完全、つまり、ZKVMを使用するシステムは、法的声明を証明することができません。立ち往生してください。ZKVMにゼロ知識属性が必要な場合、証拠が証人に関する情報を開示しないことを確認するために、正式な検証を提供する必要があります。
推定された時刻表
フェーズ1の進行：来年の進捗を楽しみにしています（たとえば、zklibそれは努力です）。しかし、少なくとも2年以内にフェーズ1の要件を完全に満たすことができるZKVMはありません。
ステージ2および3：これらのフェーズは、フェーズ1の特定の側面で同時に進めることができます。たとえば、一部のチームは、Plonk Validatorの実装がペーパーのプロトコルと一致することを実証しています（ただし、プロトコル自体は完全に検証されていない場合があります）。それでも、ZKVMが4年以内にフェーズ3に到達するとは思っていません。
キーノート：Fiat-Shamir Security vs. Verified Byteコード
大きな複雑さの問題はそれですフィアット・シャミール変革の安全性に関する未解決の研究の質問がまだあります。3つのセキュリティフェーズはすべて、フィアットシャミールとランダムオラクルを絶対に安全に扱いますが、実際にはパラダイム全体に脆弱性がある可能性があります。これは次のためですランダムオラクルの理想化されたモデルと実際に使用されたハッシュ関数の間には違いがあります。
最悪の場合、到達しました安全フェーズ2システムはそうするかもしれませんフィアット・シャミル関連の問題のために完全に安全でないことがわかりました。これは私たちの高い注目と継続的な研究に値します。必要になるかもしれませんフィアット・シャミル変換自体を変更して、そのような脆弱性をよりよく防御する。
再帰を使用しないシステムは、理論的に安全です、一部の既知の攻撃には、再帰的証明で使用されている攻撃と同様の回路が含まれるためです。しかし、このリスクはまだです未解決の基本的な問題。
注意すべきもう1つの問題は、ZKVMが特定の計算プログラム（bytecodeで指定）があることを証明したとしても、正しく実行します、しかし、場合ByteCode自体には欠陥があります、次に、この証明の価値非常に限られています。したがって、ZKVMの実用性は大部分に依存します正式に検証されたバイトコードを生成する方法、そしてこの挑戦非常に巨大です、そしてこの記事の範囲を超えて。
量子安全性について
量子コンピューターは、少なくとも5年（またはそれ以上）にわたって深刻な脅威をもたらすことはありませんが、ソフトウェアの脆弱性は生死の問題です。したがって、現在の優先事項は、この記事で提案されているセキュリティとパフォーマンスの目標を達成することです。Quantum以外のセーフスナークがこれらの目標をより速く満たすことができる場合は、優先順位を付ける必要があります。量子抵抗性のスナークが追いつくとき、または実際の脅威を持つ量子コンピューターが出現しようとしている兆候があるときに切り替えることを検討してください。
特定のセキュリティレベル
100ビットクラシックセキュリティ貴重な資産を保護するために使用されるスナークです最小標準（しかし、まだいくつかのシステムがありますこの低水準を満たしていません）。それでも、これはまだです受け入れられるべきではありません通常、標準的な暗号化の練習には必要です128ビットセキュリティ以上。Snarkのパフォーマンスが本当に標準に達している場合、パフォーマンスを改善するために安全を減らすべきではありません。
パフォーマンスフェーズ
現在の状況
現在、ZKVM証拠計算オーバーヘッドはほぼですネイティブの処刑100万倍。言い換えれば、プログラムのネイティブ実行に必要な場合X CPUサイクル、それで正しい実行の証明を生成しますほぼ必要ですX×1,000,000 CPUサイクル。この状況はですだからこれは1年前でしたが、それでも今日です（いくつかの誤解がありますが）。
今日の業界でいくつかの一般的な声明は、次のような誤解を招く可能性があります。
1。「イーサリアムメインネット全体の証明を生成するコストは、年間100万ドル未満です。」
2。「イーサリアムブロックのリアルタイムプルーフ生成をほぼ実装し、数十個のGPUしか必要としませんでした。」
3。「当社の最新のZKVMは、以前の世代よりも1000倍高速です。」
ただし、これらの主張は、文脈なしでは誤解を招く可能性があります。
•古いZKVMよりも1000倍高速で、それでも非常に遅い可能性があります、これはもっとわかります過去はどれほど悪いのか、今どれほど良いかではありません。
•Ethereumメインネットワークのコンピューティング量は、将来10回増加する可能性があります、ZKVMの現在のパフォーマンスが需要に追いつく可能性がはるかに低くなります。
•いわゆる「ほぼリアルタイム」の証明生成は、まだ多くのブロックチェーンアプリケーションのニーズの下にあります遅すぎる（例えば楽観主義には2秒のブロック時間があり、イーサリアムの12秒よりもはるかに速い）。
•「GPUの行為は長い間24時間年中無休で実行されます」利用不可十分なアクティビティが保証されています。
• これら証明生成時間は通常、1MBを超えるプルーフサイズ用です、これは多くのアプリケーション向けです大きすぎる。
•「年間100万ドル未満の費用」という理由だけでEthereumフルノードは、年間約25ドルの計算のみを実行します。
ブロックチェーン以外のアプリケーションシナリオの場合、このコンピューティングオーバーヘッドは明らかに高すぎます。並列コンピューティングやエンジニアリングの最適化がいくつあるかに関係なく、このような巨大なコンピューティングオーバーヘッドを補うことはできません。
設定すべき基本的な目標は次のとおりです。パフォーマンスオーバーヘッドは、ネイティブの実行の100,000倍以下です。しかし、それでも、これはまだ最初のステップにすぎません。真に大規模な主流アプリケーションを実装したい場合は、オーバーヘッドをネイティブ実行の10,000倍以下に減らす必要がある場合があります。
パフォーマンス測定
スナークのパフォーマンスには3つの主要なコンポーネントがあります。
1。基礎となる実績のあるシステムの固有の効率。
2。特定のアプリケーションの最適化（例えば、事前にコンパイルされます）。
3。エンジニアリングとハードウェアの加速（例：GPU、FPGA、またはマルチコアCPU）。
（2）および（3）は実際の展開に重要ですが、それらはあらゆる証明システムに適しているため、必ずしも基本的なオーバーヘッドを反映するとは限らない改善。たとえば、ZKEVMにGPU加速度とプリコンパイルを追加すると、CPUだけに依存するよりも速度が50倍速く速度を容易に改善できます。
したがって、この記事は測定に焦点を当てています専用のハードウェアと事前コンパイルのないスナークの基本的なパフォーマンス。これは、現在のベンチマークアプローチとは異なり、通常、3つの要因すべてを「一般的な価値」に組み合わせています。それはようなものです固有の明確さを評価するのではなく、時間を磨くことでダイヤモンドを裁判官。
私たちの目標はですユニバーサルプルーフシステムを分離する固有のオーバーヘッド、まだ研究されていないテクノロジーのエントリへの障壁を下げ、コミュニティが気を散らすのを助け、それによって焦点を当ててシステム設計の真の進歩を証明します。
パフォーマンスフェーズ
これが私が提案した5つのパフォーマンスフェーズのマイルストーンです。まず、オーバーヘッドを減らすためにハードウェアにさらに頼る前に、CPUのプローバーオーバーヘッドを大幅に減らす必要があります。同時に、メモリの使用も改善する必要があります。
すべての段階で、開発者はZKVMのパフォーマンスのためにコードを調整しないでください。開発者エクスペリエンスは、ZKVMの中心的な利点です。パフォーマンスベンチマークを満たすためにDeVexが犠牲にされた場合、ベンチマークの重要性を失うだけでなく、ZKVMの元の意図に違反します。
これらの指標は主に焦点を当てていますコストの証明。ただし、バリデーターが許可されている場合無制限のコストの増加（つまり、無制限のプルーフサイズまたは検証時間）、Proverインジケーターを簡単に満たすことができます。したがって、次の段階の要件を満たす必要があります。最大証明サイズと最大検証時間を同時に定義する必要があります。
フェーズ1の要件：「合理的な非自明の検証コスト」
•証明サイズ：証人のサイズよりも小さくなければなりません。
•検証時間：検証証明の速度は、プログラムのネイティブ実行よりも遅くてはなりません（つまり、計算の直接的な実行よりも遅くなってはなりません）。
これらは最小シンプルな要件、確認する証人のサイズと検証時間は、証人を直接バリデーターに送り、それを直接チェックさせることよりも悪くありません。
ステージ2以上
•最大証明サイズ：256 kb。
•最大検証時間：16ミリ秒。
これらのキャップは、たとえより高い検証コストをもたらす可能性がある場合でも、意図的に新しい高速プルーフテクノロジーに対応するために緩く設定されています。同時に、これらの上限は非常に高価な証拠を除外して、ブロックチェーンで使用する意思のあるプロジェクトはほとんどありません。
速度ステージ1
シングルスレッドの証明は、ネイティブの実行よりも100,000倍遅くなってはなりません（Ethereum Block Proofだけでなく、複数のアプリケーションに適用されます）。
具体的には、最新のラップトップのRISC-Vプロセッサが約で実行されると仮定します。毎秒30億サイクル、その後、ステージ1に到達することは、ノートブックができることを意味します30,000 RISC-Vサイクル/秒速度生成の証明（単一スレッド）。
バリデーターコストは、以前に定義された「合理的でない非自明の検証コスト」標準を満たす必要があります。
速度フェーズ2
シングルスレッドの証明は、ネイティブの実行よりも10,000倍遅くなってはなりません。
または、いくつかの有望なスナーク方法（特にバイナリドメインスナーク）は現在のCPUおよびGPUによって制限されているため、このフェーズはFPGA（またはASIC）を介して満たすことができます。
1. FPGAがネイティブ速度でシミュレートするRISC-Vコアの数を計算します。
2。RISC-Vの実行をシミュレートして証明するために必要なFPGAの数を計算します（リアルタイム近く）。
3。if（2）数量10,000回以下（1）、その後、ステージ2が満たされます。
•証明サイズ：最大256 kb。
•検証時間：標準CPUで最大16ミリ秒。
スピードステージ3
到達中速度フェーズ2に基づいて1000倍以内の証明費用の証明（複数のアプリケーションに適用）使用する必要があります自動合成と正式な検証の事前化。基本的に、各プログラムの命令セットを動的にカスタマイズして、証明生成をスピードアップします、しかし、それは保証する必要があります使いやすさと正式な検証。（についてなぜ両刃の剣が事前に縮まっているのか、そしてなぜ「手書き」の事前コンパイルが持続可能なアプローチではないのか、次のセクションを参照してください。））
メモリステージ1
2 GB未満のメモリの場合成し遂げる速度ステージ1、そして満足しますゼロの知識要件。のためのこの段階モバイルデバイスまたはブラウザそれは非常に重要です多数のクライアントZKVMユースケースドアを開けた。たとえば、スマートフォンが使用されますロケーションプライバシー、アイデンティティ資格情報など。証明生成が1〜2 GB以上のメモリを必要とする場合、ほとんどのモバイルデバイスは機能しません。
2つの重要なメモ：
1.大規模なコンピューティング（ネイティブ実行の数兆サイクルが必要です）の場合でも、プルーフシステムは2 GBのメモリキャップを維持する必要があります。そうしないと、適用性が制限されます。
2。証明が非常に遅い場合、2 GBのメモリキャップを維持するのは簡単です。したがって、メモリステージ1が意味をなすためには、2 GBのメモリ制限内で速度ステージ1に到達する必要があります。
メモリステージ2
200 MB未満のメモリ成し遂げる速度ステージ1（メモリステージ1よりも10倍高速）。
なぜそれを200 MBに減らすのですか？Aを考慮してください非ブロックチェーンシナリオ：HTTPS Webサイトにアクセスすると、認証と暗号化証明書がダウンロードされます。ウェブサイトが代わりにこれらの証明書のZKプルーフを送信する場合、大規模なWebサイトは毎秒生成する必要がある場合があります何百万もの証拠。証明ごとに2 GBのメモリが必要な場合、コンピューティングリソースの要件が満たされますPBレベル、明らかに実行可能ではありません。したがって、メモリの使用量をさらに削減します非ブロックチェーンアプリケーションそれは非常に重要です。
プリコンパイル：ラストマイル、または松葉杖？
事前コンパイルされています指します特定の機能（ハッシュ、楕円曲線シグネチャなど）に特化したスナーク制約システム。イーサリアムでは、事前コンパイルはメルクルのハッシュと署名の検証のオーバーヘッドを減らすことができますが、事前コンパイルへの過度の依存はスナークのコア効率を実際に改善することはできません。
プリコンパイルの問題
1。まだ遅すぎます：ハッシュと署名で事前にコンパイルされていても、ZKVMには、ブロックチェーンの内外でコアプルーフシステムの非効率性の問題があります。
2。セキュリティの脆弱性：手書きの事前コンパイルが正式に検証されていない場合、ほぼ特定の脆弱性があり、壊滅的なセキュリティ障害につながる可能性があります。
3。開発者の体験が悪い：現在、多くのZKVMが開発者を必要としています手書き制約システム、1960年代のプログラミング方法と同様に、開発体験に深刻な影響を与えます。
4。ベンチマーク誤解を招く：ベンチマークが特定の事前拡張の最適化に依存している場合、スナークのデザイン自体を強化するのではなく、手動制約システムの最適化に焦点を当てることを誤解させる可能性があります。
5。I/Oオーバーヘッドとラムフリーアクセスプリコンパイルは、重い暗号タスクのパフォーマンスを向上させることができますが、入力/出力を渡すと大幅なオーバーヘッドが発生し、RAMを使用できないため、より多様なワークロードに意味のある加速を提供しない場合があります。
ブロックチェーン環境でさえ、単一のL1のようなイーサリアムを超えている限り（たとえば、一連のクロスチェーンブリッジを構築する必要があります）、さまざまなハッシュ関数と署名スキームに直面します。この問題を解決するための継続的な事前コンパイルは、スケーラブルではなく、大きなセキュリティリスクをもたらします。
私は、プリコンパイルが長期的にはまだ重要であると信じていますが、それは自動的に合成され、公式に検証された後にのみ起こります。これにより、壊滅的なセキュリティリスクを避けながら、ZKVMの開発者エクスペリエンスの利点を維持できます。このビューはフェーズ3に反映されています。
予想される時刻表
私は今年後半にいくつかのZKVMSが到達することを期待しています速度ステージ1そしてメモリステージ1。今後2年間でこれを達成できると思います。速度フェーズ2、しかし、この目標を新しい研究のアイデアなしに達成できるかどうかは明らかではありません。
私は残りのステージを期待しています（スピードステージ3そしてメモリステージ2）達成するには何年もかかります。
この記事には、ZKVMのセキュリティ段階とパフォーマンス段階がそれぞれリストされていますが、2つは完全に独立していません。ZKVMの脆弱性が発見され続けているため、これらの脆弱性の一部の修正が必然的に大幅なパフォーマンス低下につながると思います。したがって、ZKVMでは達成されます安全フェーズ2以前は、パフォーマンステストの結果は暫定データと見なされるべきでした。
ZKVMは、ゼロ知識が本当に人気があることが証明される可能性が非常に高いですが、それはまだ初期段階にあり、セキュリティの課題と厳しいパフォーマンスのボトルネックに満ちています。市場の誇大広告とマーケティングの宣伝により、測定の真の進歩が困難になります。明確なセキュリティとパフォーマンスのマイルストーンを使用して、霧をきれいにするロードマップを提供したいと考えています。最終的には目標を達成しますが、時間がかかり、研究と工学の継続的な努力がかかります。
