a16z: 段階的に安全で効率的な zkVM を実装する方法 (開発者必読)

著者: a16z crypto

zkVM (ゼロ知識仮想マシン) は、「SNARK を民主化」することを約束し、誰でも (専門的な SNARK の専門知識を持たない人でも)、特定の入力 (または証拠) に基づいて任意のプログラムを正しく実行したことを証明できるようにします。彼らの強みは開発者エクスペリエンスにありますが、現在はセキュリティとパフォーマンスの両方で大きな課題に直面しています。 zkVM のビジョンがその約束を果たすためには、設計者はこれらの課題を克服する必要があります。この記事では、完了までに数年かかる可能性がある zkVM 開発のフェーズについて概説しました。

チャレンジ

セキュリティの面では、zkVM は非常に複雑なソフトウェア プロジェクトであり、依然として脆弱性が多数存在します。パフォーマンスの面では、プログラムが正しく実行されることを証明することは、ネイティブで実行するよりも数十万倍遅くなる可能性があり、現在のところほとんどのアプリケーションを実際の環境に展開することは不可能です。

これらの実際的な課題にもかかわらず、ブロックチェーン業界のほとんどの企業は、zkVM をすぐに導入できるものとして位置づけています。実際、いくつかのプロジェクトでは、オンチェーンアクティビティの証明を生成するためにすでに多大な計算コストを支払っています。しかし、zkVM はまだ不完全であるため、これはシステムが SNARK によって保護されていると見せかけるための高価な方法にすぎません。実際には、システムは許可によって保護されているか、さらに悪いことに、攻撃に対して脆弱です。

安全でパフォーマンスの高い zkVM が実現するまでには、まだ何年もかかります。この投稿では、zkVM の進捗状況を追跡するための一連の具体的かつ段階的な目標を提案します。これらの目標は、誇大宣伝を排除し、コミュニティが実際の進捗状況に集中できるようにします。

セキュリティフェーズ

SNARK ベースの zkVM は通常、次の 2 つの主要コンポーネントで構成されます。

zkVM は基本的に、有効な実行トレースを制約のシステムとしてエンコードします。これは、仮想マシンによるレジスタとメモリの正しい使用を強制するという意味です。次に、SNARK を適用して、これらの制約が満たされていることを証明します。

zkVM のような複雑なシステムにバグがないことを確認する唯一の方法は、形式検証を行うことです。セキュリティ フェーズの詳細は次のとおりです。フェーズ 1 では正しいプロトコルに重点が置かれ、フェーズ 2 と 3 では正しい実装に重点が置かれます。

セキュリティフェーズ1: 正しいプロトコル

再帰の警告: zkVM が再帰を使用する場合、このフェーズが完了したとみなされるには、その再帰に関係するすべての PIOP、コミットメント スキーム、および制約システムを検証する必要があります。

セキュリティフェーズ2: 正しい認証子の実装

形式検証では、zkVM バリデーターの実際の実装 (Rust、Solidity など) がフェーズ 1 で検証されたプロトコルと一致することが証明されます。これを達成することで、実装されたプロトコルが健全なものになることが保証されます (単なる紙上の設計や、Lean などで記述された非効率的な仕様ではありません)。

セキュリティフェーズ2: 正しい認証子の実装

形式検証では、zkVM バリデーターの実際の実装 (Rust、Solidity など) がフェーズ 1 で検証されたプロトコルと一致することが証明されます。これを達成することで、実装されたプロトコルが健全なものになることが保証されます (単なる紙上の設計や、Lean などで記述された非効率的な仕様ではありません)。

フェーズ 2 が検証者の実装のみに焦点を当て (証明者には焦点を当てない) る理由は 2 つあります。まず、検証者を正しく使用すれば、健全性を確保できます (つまり、検証者が誤った記述を実際には真実であると信じることができないようにする必要があります)。第二に、zkVM バリデーターの実装は、証明者の実装よりも桁違いに単純です。

セキュリティフェーズ3: 正しい証明器の実装

zkVM 証明器の実際の実装では、フェーズ 1 と 2 の両方で検証された証明システムの証明が正しく生成されます。つまり、正式に検証されます。これにより完全性が保証されます。つまり、zkVM を使用するシステムは、証明できないステートメントで「行き詰まる」ことはありません。証明者がゼロ知識を達成するつもりであれば、この特性は正式に検証されなければなりません。

予定時刻

フェーズ 1 の進捗: 今後 1 年間で漸進的な成果が期待できます (例: ZKLib)。しかし、少なくとも 2 年間はフェーズ 1 の要件を完全に満たす zkVM は存在しません。

フェーズ 2 および 3: これらのフェーズは、フェーズ 1 のいくつかの側面と並行して進めることができます。たとえば、一部のチームは、Plonk バリデータの実装が論文のプロトコルと一致することを証明しました (論文のプロトコル自体は完全に検証されていない可能性があります)。そうは言っても、zkVM が 4 年以内にステージ 3 に到達するとは予想していません。おそらくそれ以上かかるでしょう。

重要な注意事項: Fiat-Shamir セキュリティと検証済みバイトコード

大きな問題は、フィアット・シャミール変換の安全性に関して未解決の研究課題があることです。 3 つのフェーズすべてにおいて、フィアット・シャミールとランダム オラクルはその絶対的なセキュリティの一部とみなされますが、実際にはパラダイム全体に脆弱性がある可能性があります。これは、理想化されたランダム オラクルと実際に使用されるハッシュ関数との間の不一致が原因です。最悪の場合、ステージ 2 に到達したシステムが、フィアット・シャミール問題により、後になって完全に安全でないことが判明する可能性があります。これにより深刻な懸念が生じ、現在も研究が続けられています。この種の脆弱性に対する保護を強化するには、変換自体を変更する必要があるかもしれません。

再帰のないシステムは、既知の攻撃の一部に再帰証明で使用されるものと同様の回路が含まれるため、理論的にはより堅牢です。

また、バイトコード自体に欠陥がある場合、コンピュータ プログラムが (バイトコードで指定されたとおりに) 正しく実行されたことを証明しても、その価値は限られることにも注意してください。したがって、zkVM の有用性は、形式的に検証されたバイトコードを生成する方法に大きく依存します。これは、この論文の範囲を超える大きな課題です。

ポスト量子時代の安全保障について

量子コンピューターは、少なくとも今後 5 年間 (おそらくそれ以上) は深刻な脅威にはなりませんが、脆弱性は実存的なリスクとなります。したがって、現在、主な焦点は、この記事で説明したセキュリティとパフォーマンスの段階を満たすことに置く必要があります。非量子安全 SNARK を使用してこれらのセキュリティ要件をより迅速に満たすことができる場合は、ポスト量子 SNARK が追いつくまで、または人々が暗号に関連する量子コンピューターについて真剣に懸念するまで、他の選択肢を検討する前にそうするべきです。

zkVMの現在のパフォーマンス

現在、zkVM 証明者によって発生するオーバーヘッド係数は、ネイティブ実行コストの 100 万倍近くになります。プログラムの実行に X サイクルかかる場合、正しい実行を証明するコストは約 X 倍の 100 万 CPU サイクルになります。これは 1 年前もそうでしたし、今日もそうです。

一般的な物語では、この支出は容認できるものであるかのように表現されることが多い。例えば：

これらの主張は技術的には正確ですが、適切な文脈がなければ誤解を招く可能性があります。例えば：

これらの主張は技術的には正確ですが、適切な文脈がなければ誤解を招く可能性があります。例えば：

ブロックチェーン以外のアプリケーションの場合、このようなオーバーヘッドは明らかに高すぎます。 いかなる並列化やエンジニアリングでも、このような膨大なオーバーヘッドを相殺することはできません。これは単なる第一歩ですが、zkVM の基本的なベースラインをネイティブ実行と比較して 100,000 倍以上遅くならないようにすることを目指す必要があります。 真の主流採用には、10,000 倍以下のオーバーヘッドが必要になる可能性があります。

パフォーマンスを測定する方法

SNARK パフォーマンスには、主に 3 つのコンポーネントがあります。

後者の 2 つは実際の展開には重要ですが、一般的にあらゆる証明システムに適用されるため、必ずしも基礎となるオーバーヘッドを反映するものではありません。たとえば、GPU アクセラレーションとプリコンパイルを zkEVM に追加すると、プリコンパイルなしの純粋な CPU ベースのアプローチに比べて 50 倍の高速化を簡単に達成できます。これは、本質的に効率の低いシステムでも、同様に洗練されていないシステムよりも優れているように見えるほどです。

したがって、以下では、特殊なハードウェアや事前コンパイルなしでの SNARK のパフォーマンスに焦点を当てます。これは、通常 3 つの要素すべてを 1 つの「見出しの数字」にまとめる現在のベンチマーク方法とは異なります。これは、ダイヤモンドの価値を、その本来の透明度ではなく、研磨にかかった時間に基づいて判断するのと同じです。 私たちの目標は、汎用証明システムに固有のオーバーヘッドを取り除き、コミュニティが混乱を解消し、証明システム設計の真の進歩に集中できるように支援することです。

パフォーマンスフェーズ

達成された 5 つのパフォーマンス マイルストーンを以下に示します。まず、CPU 上の証明者のオーバーヘッドを大幅に削減する必要があります。そうして初めて、ハードウェアによるさらなる削減に焦点が移るはずです。メモリ使用量も改善する必要があります。

次のすべての段階で、開発者は必要なパフォーマンスを実現するために zkVM に基づくカスタム コードをセットアップする必要はありません。開発者エクスペリエンスは zkVM の主な利点です。パフォーマンス ベンチマークを満たすために DevEx を犠牲にすると、zkVM 自体の目的が達成されなくなります。

これらのメトリックは証明者のコストに焦点を当てています。ただし、無制限の検証コストが許可されている場合（つまり、証明サイズまたは検証時間に上限がない場合）、どの証明者メトリックも簡単に満たすことができます。したがって、システムが説明したフェーズに準拠するには、証明サイズと検証時間の最大値を指定する必要があります。

パフォーマンス要件

フェーズ 1 の要件:「合理的かつ重大な検証コスト」:

これらは最小限の要件です。これによって、証明のサイズと検証時間が、証人を検証者に送信し、検証者がその正確性を直接確認する場合よりも悪くならないことが保証されます。

フェーズ 2 以降の要件:

これらのカットオフは、より高い検証コストが発生する可能性がある新しい高速証明手法に対応するために意図的に大きくなっています。同時に、非常に高価な証明を除外するため、ブロックチェーンに組み込むことを望むプロジェクトはほとんどありません。

スピードステージ1

シングルスレッドの証明は、プリコンパイルに依存せずに、さまざまなアプリケーション（Ethereum ブロックの証明だけでなく）で測定すると、ネイティブ実行よりも最大 10 万倍遅くなります。

これを具体的に理解するために、現代のラップトップで RISC-V プロセスが毎秒約 30 億サイクルで実行されていると想像してください。ステージ 1 を達成すると、同じラップトップで 1 秒あたり約 30,000 RISC-V サイクル (シングル スレッド) を実証できるようになります。しかし、検証コストは、前述のように「合理的かつ些細なものではない」ものでなければなりません。

これを具体的に理解するために、現代のラップトップで RISC-V プロセスが毎秒約 30 億サイクルで実行されていると想像してください。ステージ 1 を達成すると、同じラップトップで 1 秒あたり約 30,000 RISC-V サイクル (シングル スレッド) を実証できるようになります。しかし、検証コストは、前述のように「合理的かつ些細なものではない」ものでなければなりません。

スピードステージ2

シングルスレッドの証明は、ネイティブ実行よりも最大 1 万倍遅くなります。

あるいは、有望な SNARK アプローチ (特にバイナリ フィールドに基づくもの) の一部は現在の CPU と GPU によって妨げられるため、比較すると FPGA (または ASIC) を使用してこの段階に到達できます。

後者が前者の 10,000 倍以下であれば、フェーズ 2 に進む資格があります。標準 CPU では、証明サイズは最大 256 KB、検証時間は最大 16 ミリ秒である必要があります。

スピードステージ3

スピードステージ 2 に到達することに加えて、自動合成と形式検証の事前コンパイルを使用することで、証明オーバーヘッドを 1000 倍未満に抑えることが可能です (幅広いアプリケーションで)。基本的に、命令セットは各プログラムごとに動的にカスタマイズして証明を高速化できますが、使いやすく、形式的に検証しやすい方法で行われます。

記憶ステージ1

フェーズ 1 の速度は、証明者に 2 GB 未満のメモリを必要とすることなく達成されました (ゼロ知識も達成しました)。

これは多くのモバイル デバイスやブラウザーにとって重要であり、無数のクライアント側 zkVM の使用例が生まれます。クライアント認証が重要なのは、携帯電話が現実世界と常につながっており、位置情報や資格情報などを追跡しているためです。証明の生成に 1 ～ 2 GB を超えるメモリが必要な場合、今日のほとんどのモバイル デバイスでは対応しきれません。次の 2 つの点を明確にする必要があります。

記憶ステージ2

フェーズ 1 の速度は、200 MB 未満のメモリ使用量で達成されました (メモリではフェーズ 1 の 10 倍優れています)。

なぜ 2 GB 未満に押し下げるのですか?ブロックチェーン以外の例を考えてみましょう。HTTPS 経由で Web サイトにアクセスするたびに、認証と暗号化のための証明書をダウンロードします。代わりに、Web サイトはこれらの証明書を所有していることを証明する zk 証明を送信できます。大規模な Web サイトでは、1 秒あたり数百万のこのような証明が発行される可能性があります。各証明の生成に 2 GB のメモリが必要な場合は、合計 PB の RAM が必要になります。非ブロックチェーンの展開では、メモリ使用量をさらに削減することが重要です。

事前コンパイル: 最後の 1 マイルか、それとも松葉杖か?

zkVM 設計では、プリコンパイルは、Keccak/SHA ハッシュやデジタル署名の楕円曲線グループ演算など、特定の機能に合わせて調整された特殊な SNARK (または制約システム) を指します。 Ethereum (ほとんどの作業に Merkle ハッシュと署名チェックが含まれる) では、手作業でプリコンパイルを数回実行することで、証明者のオーバーヘッドを削減できます。しかし、それらを頼りにするだけでは、SNARK を必要な場所に到達させることはできません。理由は次のとおりです。

zkVM 設計では、プリコンパイルは、Keccak/SHA ハッシュやデジタル署名の楕円曲線グループ演算など、特定の機能に合わせて調整された特殊な SNARK (または制約システム) を指します。 Ethereum (ほとんどの重労働が Merkle ハッシュと署名チェックを伴う) では、手作業による事前コンパイルをいくつか行うことで証明者のオーバーヘッドを削減できます。しかし、それらを頼りにするだけでは、SNARK を必要な場所に到達させることはできません。理由は次のとおりです。

これらすべての理由から、私たちの最優先事項は、基盤となる zkVM の効率を向上させることです。最高の zkVM を生成する技術は、最高のプリコンパイラも生成します。プリコンパイルは長期的には不可欠なものであり続けると私は信じていますが、それは自動的に合成され、正式に検証される場合に限られます。このようにして、壊滅的なセキュリティ リスクを回避しながら、zkVM の開発者エクスペリエンスの利点が維持されます。この見解はスピードステージ3に反映されています。

予定時刻

今年後半には、いくつかの zkVM がスピード ステージ 1 とメモリ ステージ 1 に到達すると予想しています。今後 2 年以内にスピード フェーズ 2 に到達すると思いますが、まだ登場していない新しいアイデアがなければ、そこに到達できるかどうかはわかりません。残りのフェーズ（スピードフェーズ3とメモリフェーズ2）の達​​成には数年かかると予想しています。

要約する

この投稿では zkVM のセキュリティとパフォーマンスの段階を個別に説明していますが、zkVM のこれらの側面は完全に独立しているわけではありません。 zkVM でさらに多くの脆弱性が発見されるにつれて、いくつかの脆弱性は大幅なパフォーマンスの低下を伴ってのみ修正されると予想されます。 zkVM が安全ステージ 2 に達するまでパフォーマンスを一時停止する必要があります。

zkVM はゼロ知識証明を真に普及させる可能性を秘めていますが、まだ初期段階にあり、セキュリティ上の課題と大幅なパフォーマンスのオーバーヘッドを伴います。誇大宣伝やマーケティング宣伝により、実際の進捗状況を評価することが困難になります。安全性とパフォーマンスのマイルストーンを明確にすることで、気を散らすものを排除するためのロードマップを提供したいと考えています。我々はそこに到達できるでしょうが、それには時間と継続的な努力が必要です。