メインコンテンツまでスキップ

「zkML」タグの記事が1件件あります

全てのタグを見る

zkMLと暗号学的証明による検証可能なオンチェーンAI

· 約53分
Dora Noda
Dora Noda
Software Engineer

イントロダクション：ブロックチェーン上で検証可能なAIの必要性​

AIシステムの影響力が増すにつれて、その出力が信頼できるものであることを保証することが重要になります。従来のメソッドは制度的な保証（本質的には 「ただ信頼してください」）に依存しており、暗号学的な保証は提供されません。これは、スマートコントラクトやユーザーが、重いモデルをオンチェーンで再実行することなくAI由来の結果を信頼しなければならないブロックチェーンのような分散型コンテキストでは特に問題となります。ゼロ知識機械学習 (zkML) は、ML計算の 暗号学的な検証 を可能にすることでこの問題に対処します。本質的に、zkMLはプルーバーが 「出力 $Y$ は、入力 $X$ に対してモデル $M$ を実行した結果である」 という簡潔な証明を、$X$ や $M$ の内部詳細を 明かすことなく 生成することを可能にします。これらのゼロ知識証明 (ZKP) は、誰でも（あるいはどのコントラクトでも）効率的に検証でき、AIへの信頼を 「ポリシーから証明へ」 と移行させます。

AIのオンチェーン検証可能性とは、ブロックチェーンが計算自体を実行する代わりに、正しい実行の証明を検証することによって、高度な計算（ニューラルネットワークの推論など）を組み込むことができることを意味します。これには広範な影響があります。スマートコントラクトはAIの予測に基づいて意思決定を行うことができ、分散型自律エージェントはアルゴリズムに従ったことを証明でき、クロスチェーンまたはオフチェーンの計算サービスは検証不可能なオラクルではなく 検証可能な出力 を提供できます。最終的に、zkMLは トラストレスでプライバシーを保護するAI への道を提供します。例えば、AIモデルの決定が正しく、承認されていることを、プライベートデータや独自のモデルの重みを公開することなく証明できます。これは、安全な医療分析からブロックチェーンゲーム、DeFiオラクルまで、幅広いアプリケーションにとって鍵となります。

zkMLの仕組み：ML推論を簡潔な証明に圧縮する​

大まかに言うと、zkMLは暗号学的証明システムとML推論を組み合わせることで、複雑なモデル評価を小さな証明に「圧縮」できるようにします。内部的には、MLモデル（例：ニューラルネットワーク）は、多くの算術演算（行列乗算、活性化関数など）からなるサーキットまたはプログラムとして表現されます。すべての中間値を公開する代わりに、プルーバーはオフチェーンで完全な計算を実行し、その後 ゼロ知識証明プロトコル を使用して、すべてのステップが正しく行われたことを証明します。ベリファイアは、証明といくつかの公開データ（最終出力やモデルの識別子など）のみを与えられ、モデルを再実行することなく、その正当性を 暗号学的に確信 することができます。

これを達成するために、zkMLフレームワークは通常、モデルの計算をZKPに適した形式に変換します：

  • サーキットコンパイル： SNARKベースのアプローチでは、モデルの計算グラフは 算術サーキット または多項式制約の集合にコンパイルされます。ニューラルネットワークの各層（畳み込み、行列乗算、非線形活性化）は、入力に対して出力が正しいことを保証する制約を持つサブサーキットになります。ニューラルネットワークには、多項式に自然に適さない非線形演算（ReLU、Sigmoidなど）が含まれるため、これらを効率的に処理するために ルックアップテーブル のような技術が使用されます。例えば、ReLU（出力 = max(0, 入力)）は、input≥0の場合は出力が入力と等しく、それ以外はゼロであることを検証するカスタム制約またはルックアップによって強制できます。最終結果は、プルーバーが満たさなければならない暗号学的制約の集合であり、これによりモデルが正しく実行されたことが暗黙的に証明されます。
  • 実行トレースと仮想マシン： 別の方法は、zkVM アプローチで行われるように、モデルの推論をプログラムトレースとして扱うことです。例えば、JOLT zkVMはRISC-V命令セットを対象としています。MLモデル（またはそれを計算するコード）をRISC-Vにコンパイルし、各CPU命令が適切に実行されたことを証明できます。JOLTは 「ルックアップ特異点」 技術を導入し、高価な算術制約を、各有効なCPU操作のための高速なテーブルルックアップに置き換えます。すべての操作（加算、乗算、ビット単位演算など）は、事前計算された有効な結果の巨大なテーブルでのルックアップを介してチェックされ、これを効率的に保つために特殊な引数（Lasso/SHOUT）が使用されます。これにより、プルーバーの作業負荷が劇的に削減されます。複雑な64ビット操作でさえ、多くの算術制約の代わりに、証明内で単一のテーブルルックアップになります。
  • 対話型プロトコル (GKRサムチェック)： 3番目のアプローチは、GKR（Goldwasser–Kalai–Rotblum）のような対話型証明を使用して、層状の計算を検証します。ここでは、モデルの計算は層状の算術サーキットとして見なされます（各ニューラルネットワーク層はサーキットグラフの1つの層です）。プルーバーは通常通りモデルを実行しますが、その後、各層の出力がその入力に対して正しいことを証明するために サムチェックプロトコル に参加します。Lagrangeのアプローチ（DeepProve、次に詳述）では、プルーバーとベリファイアは、各層の計算を再実行することなく、その一貫性をチェックする対話型多項式プロトコル（Fiat-Shamirヒューリスティックにより非対話型にされる）を実行します。このサムチェックメソッドは、一枚岩の静的サーキットを生成するのを避け、代わりに最小限の暗号操作（主にハッシュ化または多項式評価）で段階的に 計算の一貫性 を検証します。

どのアプローチであっても、結果は推論全体の正当性を証明する 簡潔な証明（通常は数キロバイトから数十キロバイト）です。この証明は ゼロ知識 であり、秘密の入力（プライベートデータやモデルパラメータ）を隠しておくことができることを意味します。それらは証明に影響を与えますが、ベリファイアには公開されません。意図された公開出力または表明のみが公開されます。これにより、「モデル $M$ を患者データ $X$ に適用すると診断 $Y$ が得られることを、$X$ やモデルの重みを公開せずに証明する」 といったシナリオが可能になります。

オンチェーン検証の実現： 証明が生成されると、ブロックチェーンに投稿できます。スマートコントラクトには、プリコンパイルされた暗号プリミティブを使用して、証明をチェックするための検証ロジックを含めることができます。例えば、Ethereumには多くのzk-SNARKベリファイアで使用されるBLS12-381ペアリング操作のためのプリコンパイルがあり、SNARK証明のオンチェーン検証を効率的にします。STARK（ハッシュベースの証明）はサイズが大きくなりますが、慎重な最適化や、場合によってはいくつかの信頼の仮定（例えば、StarkWareのL2は、SNARKよりも高いガス代がかかるものの、オンチェーンのベリファイアコントラクトによってEthereum上でSTARK証明を検証します）によって、オンチェーンで検証することが可能です。重要なのは、チェーンがMLモデルを実行する必要がなく、元の計算よりも はるかに安価な 検証のみを実行する点です。要約すると、zkMLは 高価なAI推論を、ブロックチェーン（または任意のベリファイア）がミリ秒から数秒でチェックできる小さな証明に圧縮します。

Lagrange DeepProve：zkMLのブレークスルーのアーキテクチャとパフォーマンス​

Lagrange Labsによる DeepProve は、速度とスケーラビリティに焦点を当てた最先端のzkML推論フレームワークです。2025年に発表されたDeepProveは、Ezklのような以前のソリューションよりも劇的に高速な新しい証明システムを導入しました。その設計は、サムチェック付きGKR対話型証明プロトコル とニューラルネットワークサーキット向けの特殊な最適化を中心にしています。以下にDeepProveの仕組みとそのパフォーマンス達成方法を説明します：

  • ワンタイム前処理： 開発者は、訓練済みのニューラルネットワーク（現在サポートされているタイプには、多層パーセプトロンや一般的なCNNアーキテクチャが含まれます）から始めます。モデルは標準的なグラフ表現であるONNX形式にエクスポートされます。次に、DeepProveのツールがONNXモデルを解析し、効率的な体演算のために 量子化（重みを固定小数点/整数形式に変換）します。この段階で、暗号プロトコルのための証明鍵と検証鍵も生成します。このセットアップはモデルごとに1回行われ、推論ごとに繰り返す必要はありません。DeepProveは統合の容易さを強調しています：「モデルをONNXにエクスポート → ワンタイムセットアップ → 証明を生成 → どこでも検証」。

  • 証明 (推論 + 証明生成)： セットアップ後、プルーバー（ユーザー、サービス、またはLagrangeの分散型プルーバーネットワークによって実行可能）は新しい入力 $X$ を受け取り、それに対してモデル $M$ を実行して出力 $Y$ を得ます。この実行中、DeepProveは各層の計算の 実行トレース を記録します。SNARKアプローチのようにすべての乗算を事前に静的サーキットに変換するのではなく、DeepProveは 線形時間のGKRプロトコル を使用して各層をその場で検証します。各ネットワーク層について、プルーバーは層の入力と出力にコミットし（例えば、暗号学的ハッシュや多項式コミットメントを介して）、その後、出力が層の関数に従って入力から実際に得られたものであることを証明するためにサムチェック引数に参加します。サムチェックプロトコルは、実際の値を明らかにすることなく、層の計算をエンコードする多項式の評価の合計の正しさをベリファイアに繰り返し納得させます。非線形操作（ReLU、softmaxなど）は、DeepProveでは ルックアップ引数 を通じて効率的に処理されます。活性化関数の出力が計算された場合、DeepProveは各出力がその関数のために事前計算されたテーブルからの有効な入力-出力ペアに対応することを証明できます。層ごとに証明が生成され、その後、モデル全体のフォワードパスをカバーする 1つの簡潔な証明に集約 されます。暗号技術の重い処理は最小限に抑えられます。DeepProveのプルーバーは、巨大な制約システムを解くのではなく、主に通常の数値計算（実際の推論）といくつかの軽い暗号コミットメントを実行します。

  • 検証： ベリファイアは、最終的な簡潔な証明といくつかの公開値（通常はモデルのコミットされた識別子（$M$ の重みへの暗号コミットメント）、入力 $X$（プライベートでない場合）、および主張された出力 $Y$）を使用して正しさをチェックします。DeepProveのシステムでの検証には、サムチェックプロトコルのトランスクリプトと最終的な多項式またはハッシュコミットメントの検証が含まれます。これは古典的なSNARKの検証（数回のペアリングかもしれない）よりも複雑ですが、モデルを再実行するよりもはるかに安価 です。Lagrangeのベンチマークでは、中規模のCNNに対するDeepProve証明の検証には、ソフトウェアで 0.5秒 程度かかります。これは、例えば、数十万のパラメータを持つ畳み込みネットワークが正しく実行されたことを確認するのに約0.5秒かかることを意味し、検証のためにGPUでそのCNNをナイーブに再計算するよりも 500倍以上高速 です。（実際、DeepProveはCNNで最大 521倍、MLPで 671倍 の検証高速化を再実行と比較して測定しました。）証明サイズはオンチェーンで送信するのに十分小さく（数十KB）、検証は必要であればスマートコントラクトで実行できますが、0.5秒の計算には慎重なガス最適化またはレイヤー2での実行が必要になるかもしれません。

アーキテクチャとツール： DeepProveはRustで実装されており、開発者向けにツールキット（zkml ライブラリ）を提供しています。ONNXモデルグラフをネイティブにサポートしているため、PyTorchやTensorFlowからのモデル（エクスポート後）と互換性があります。証明プロセスは現在、数百万パラメータまでのモデルを対象としています（テストには400万パラメータの密結合ネットワークが含まれます）。DeepProveは、多線形多項式コミットメント（層の出力にコミットするため）、計算を検証するためのサムチェックプロトコル、非線形操作のためのルックアップ引数など、暗号コンポーネントの組み合わせを活用しています。特筆すべきは、Lagrangeのオープンソースリポジトリが、以前の研究（ScrollのCenoプロジェクトからのサムチェックとGKRの実装）に基づいていることを認めており、zkMLとゼロ知識ロールアップ研究の交差点を示していることです。

リアルタイムのスケーラビリティを達成するために、LagrangeはDeepProveをその プルーバーネットワーク（特殊なZKプルーバーの分散型ネットワーク）と組み合わせています。重い証明生成はこのネットワークにオフロードできます。アプリケーションが推論の証明を必要とするとき、ジョブをLagrangeのネットワークに送信し、そこで多くのオペレーター（セキュリティのためにEigenLayerにステークされている）が証明を計算して結果を返します。このネットワークは、信頼性の高い証明生成を経済的にインセンティブ付けします（悪意のあるまたは失敗したジョブはオペレーターをスラッシングします）。プルーバー間で作業を分散させることで（そして潜在的にGPUやASICを活用することで）、Lagrangeプルーバーネットワーク はエンドユーザーから複雑さとコストを隠します。その結果、高速でスケーラブル、かつ分散型のzkMLサービスが実現します：「検証可能なAI推論を高速かつ手頃な価格で」。

パフォーマンスのマイルストーン： DeepProveの主張は、以前の最先端技術であるEzklに対するベンチマークによって裏付けられています。約26.4万パラメータを持つCNN（CIFAR-10スケールのモデル）に対して、DeepProveの証明時間は約1.24秒であったのに対し、Ezklでは 約196秒 であり、約 158倍高速 でした。400万パラメータを持つより大きな密結合ネットワークでは、DeepProveは約2.3秒で推論を証明したのに対し、Ezklでは約126.8秒（約54倍高速）でした。検証時間も短縮されました。DeepProveは26.4万CNNの証明を約0.6秒で検証しましたが、Ezklの証明（Halo2ベース）をCPUで検証するにはそのテストで5分以上かかりました。この高速化は、DeepProveのほぼ線形な複雑さから来ています。そのプルーバーは操作の数に対してほぼ O(n) でスケールしますが、サーキットベースのSNARKプルーバーはしばしば超線形なオーバーヘッド（FFTと多項式コミットメントのスケーリング）を持ちます。実際、DeepProveの プルーバーのスループット は、プレーンな推論ランタイムの1桁以内に収まることがあります。最近のGKRシステムは、大規模な行列乗算において生の実行よりも10倍未満の遅さであり、これはZKにおける印象的な成果です。これにより、リアルタイムまたはオンデマンドの証明 がより実現可能になり、対話型アプリケーションにおける検証可能なAIへの道が開かれます。

ユースケース： LagrangeはすでにWeb3およびAIプロジェクトと協力してzkMLを適用しています。ユースケースの例としては、検証可能なNFTの特性（ゲームキャラクターやコレクティブルのAI生成による進化が、承認されたモデルによって計算されたことを証明する）、AIコンテンツの来歴（ディープフェイクと戦うために、画像やテキストが特定のモデルによって生成されたことを証明する）、DeFiリスクモデル（独自のデータを明らかにすることなく、金融リスクを評価するモデルの出力を証明する）、および医療や金融における プライベートAI推論（病院が患者データを公開することなく、正しさを保証する証明付きでAI予測を得ることができる）などがあります。AIの出力を 検証可能かつプライバシー保護 にすることで、DeepProveは分散システムにおける 「信頼できるAI」 への扉を開きます。これは 「ブラックボックスモデルへの盲目的な信頼」 の時代から 「客観的な保証」 の時代への移行を意味します。

SNARKベースのzkML：EzklとHalo2アプローチ​

zkMLへの従来のアプローチは、zk-SNARK (Succinct Non-interactive Arguments of Knowledge) を使用してニューラルネットワークの推論を証明します。Ezkl (ZKonduit/Modulus Labsによる) は、このアプローチの代表的な例です。これはHalo2証明システム（BLS12-381上の多項式コミットメントを持つPLONKスタイルのSNARK）を基盤としています。Ezklは、開発者がPyTorchやTensorFlowモデルを取得し、ONNXにエクスポートし、Ezklがそれを自動的にカスタム算術サーキットにコンパイルするツールチェーンを提供します。

仕組み： ニューラルネットワークの各層は制約に変換されます：

  • 線形層（密結合または畳み込み）は、入力、重み、出力間のドット積を強制する乗算-加算制約の集合になります。
  • 非線形層（ReLU、sigmoidなど）は、そのような関数が多項式ではないため、ルックアップまたは区分的制約 を介して処理されます。例えば、ReLUは、ブールセレクタ $b$ と、$y = x \cdot b$、$0 \le b \le 1$、そして $x>0$ の場合に $b=1$ を保証する制約によって実装できます（これは一つの方法です）。あるいは、より効率的には、$x$ の値の範囲に対して $x \mapsto \max(0,x)$ をマッピングするルックアップテーブルを使用します。Halo2のルックアップ引数は16ビット（またはそれ以下）の値のチャンクをマッピングできるため、大きなドメイン（すべての32ビット値など）は通常、いくつかの小さなルックアップに 「チャンク化」 されます。このチャンク化は制約の数を増やします。
  • 大きな整数の演算や除算（もしあれば）も同様に小さな部分に分割されます。結果として、特定のモデルアーキテクチャに合わせた大規模な R1CS/PLONK制約 の集合ができあがります。

Ezklはその後、Halo2を使用して、秘密の入力（モデルの重み、プライベートな入力）と公開の出力が与えられた場合にこれらの制約が成り立つという証明を生成します。ツールと統合： SNARKアプローチの利点の一つは、よく知られたプリミティブを活用することです。Halo2はすでにEthereumのロールアップ（例：Zcash、zkEVM）で使用されているため、実戦でテストされており、オンチェーンベリファイアがすぐに利用できます。Ezklの証明はBLS12-381曲線を使用しており、これはEthereumがプリコンパイルを介して検証できるため、スマートコントラクトでEzklの証明を検証するのは簡単です。チームはまた、ユーザーフレンドリーなAPIも提供しています。例えば、データサイエンティストはPythonでモデルを扱い、EzklのCLIを使用して、サーキットに関する深い知識がなくても証明を生成できます。

長所： Ezklのアプローチは、SNARKの一般性とエコシステムから恩恵を受けます。それは合理的に複雑なモデルをサポートし、すでに 「実用的な統合（DeFiリスクモデルからゲーミングAIまで）」 を実現し、現実世界のMLタスクを証明しています。モデルの計算グラフのレベルで動作するため、ML固有の最適化を適用できます。例えば、重要でない重みを枝刈りしたり、パラメータを量子化してサーキットサイズを削減したりします。これはまた、モデルの機密性 が自然に保たれることを意味します。重みはプライベートなウィットネスデータとして扱うことができるため、ベリファイアは 何らかの 有効なモデルが出力を生成したこと、あるいはせいぜいモデルへのコミットメントしか見ることができません。SNARK証明の検証は非常に高速 であり（通常、オンチェーンで数ミリ秒以下）、証明サイズも小さい（数キロバイト）ため、ブロックチェーンでの使用に理想的です。

短所： パフォーマンスがアキレス腱です。サーキットベースの証明は、特にモデルが大きくなるにつれて、大きなオーバーヘッドを伴います。歴史的に、SNARKサーキットは、プルーバーにとってモデルを単に実行するよりも 百万倍もの作業 になる可能性があると指摘されています。Halo2とEzklはこれを最適化していますが、それでも、大規模な行列乗算のような操作は 大量の 制約を生成します。モデルに数百万のパラメータがある場合、プルーバーはそれに対応する数百万の制約を処理し、その過程で重いFFTや多重指数演算を実行する必要があります。これにより、証明時間が長くなり（重要でないモデルでもしばしば数分から数時間）、メモリ使用量も多くなります。例えば、比較的小さなCNN（例：数十万パラメータ）でさえ、Ezklを単一のマシンで実行すると証明に数十分かかることがあります。DeepProveのチームは、DeepProveが数分でできる特定のモデルの証明にEzklが数時間かかったと述べています。大規模なモデルはメモリに収まらないか、複数の証明に分割する必要があるかもしれません（その場合、再帰的な集約が必要になります）。Halo2は 「適度に最適化」 されていますが、ルックアップを「チャンク化」したり、広範なビット操作を処理したりする必要がある場合は、追加のオーバーヘッドが発生します。要約すると、スケーラビリティは限定的 です。Ezklは小から中規模のモデルにはうまく機能しますが（そして実際、ベンチマークではいくつかの初期の代替案、例えばナイーブなStarkベースのVMを 上回りました）、モデルサイズがある点を超えると苦戦します。

これらの課題にもかかわらず、Ezklや同様のSNARKベースのzkMLライブラリは重要な足がかりです。それらは、検証済みML推論がオンチェーンで可能である ことを証明し、活発に利用されています。特筆すべきは、Modulus Labs のようなプロジェクトが、SNARKを使用して（重い最適化を伴い）1800万パラメータのモデルをオンチェーンで検証したことを実証したことです。コストは些細なものではありませんでしたが、それはその軌道を示しています。さらに、Mina Protocol は独自のzkMLツールキットを持っており、SNARKを使用してMina上のスマートコントラクト（Snarkベース）がMLモデルの実行を検証できるようにしています。これは、SNARKベースのzkMLに対するマルチプラットフォームサポートの拡大を示しています。

STARKベースのアプローチ：MLのための透明でプログラム可能なZK​

zk-STARK (Scalable Transparent ARguments of Knowledge) は、zkMLへのもう一つのルートを提供します。STARKはハッシュベースの暗号技術（多項式コミットメントのためのFRIなど）を使用し、信頼できるセットアップを回避します。これらはしばしばCPUやVMをシミュレートし、実行トレースが正しいことを証明することによって動作します。MLの文脈では、ニューラルネットワーク用のカスタムSTARKを構築するか、汎用STARK VMを使用してモデルコードを実行するかのいずれかが可能です。

汎用STARK VM (RISC Zero, Cairo)： 簡単なアプローチは、推論コードを書いてSTARK VMで実行することです。例えば、Risc0 はRISC-V環境を提供し、そこでは任意のコード（例：ニューラルネットワークのC++またはRust実装）を実行し、STARKを介して証明できます。同様に、StarkWareの Cairo 言語は任意の計算（LSTMやCNNの推論など）を表現でき、それらはStarkNetのSTARKプルーバーによって証明されます。利点は柔軟性です。各モデルに対してカスタムサーキットを設計する必要がありません。しかし、初期のベンチマークでは、ナイーブなSTARK VMはML用の最適化されたSNARKサーキットと比較して遅いことが示されました。あるテストでは、Halo2ベースの証明（Ezkl）はCairo上のSTARKベースのアプローチよりも約 3倍速く、2024年のあるベンチマークではRISC-V STARK VMよりも 66倍速い ことさえありました。この差は、STARKですべての低レベル命令をシミュレートするオーバーヘッドと、STARK証明の定数が大きいこと（ハッシュは速いが大量に必要、STARKの証明サイズは大きいなど）によるものです。しかし、STARK VMは改善されており、透明なセットアップ（信頼できるセットアップ不要）と ポスト量子セキュリティ という利点があります。STARKフレンドリーなハードウェアとプロトコルが進歩するにつれて、証明速度は向上するでしょう。

DeepProveのアプローチ vs STARK： 興味深いことに、DeepProveがGKRとサムチェックを使用することで得られる証明は、精神的にはSTARKに似ています。それは対話的でハッシュベースの証明であり、構造化された参照文字列を必要としません。トレードオフは、その証明がSNARKよりも大きく、検証が重いことです。しかし、DeepProveは、慎重なプロトコル設計（MLの層状構造に特化）が、証明時間において汎用STARK VMとSNARKサーキットの両方を大幅に上回ることができることを示しています。DeepProveは 特注のSTARKスタイル のzkMLプルーバーと考えることができます（彼らは簡潔さのためにzkSNARKという用語を使用していますが、0.5秒の検証は典型的なSNARK検証よりも大きいため、従来のSNARKの小さな定数サイズの検証はありません）。従来のSTARK証明（StarkNetのものなど）は、検証に数万の体演算を伴うことが多いのに対し、SNARKは数十回程度で検証します。したがって、一つの トレードオフ が明らかです：SNARKはより小さな証明とより速いベリファイアをもたらし、STARK（またはGKR）は証明サイズと検証速度を犠牲にして、より簡単なスケーリングと信頼できるセットアップ不要を提供します。

新たな改善： JOLT zkVM（前述のJOLTxで議論）は実際にはSNARK（PLONK風のコミットメントを使用）を出力していますが、STARKの文脈にも適用できるアイデアを具現化しています（Lassoルックアップは理論的にはFRIコミットメントと共に使用できます）。StarkWareなどは、一般的な操作の証明を高速化する方法を研究しています（例えば、Cairoで大きな整数演算のためにカスタムゲートやヒントを使用するなど）。また、Privacy & Scaling Explorations (PSE) による Circomlib-ML もあり、これはCNN層などのためのCircomテンプレートを提供します。これはSNARK指向ですが、概念的に類似したテンプレートをSTARK言語用に作成することもできます。

実際には、STARKを活用する 非Ethereumエコシステム には、StarkNet（誰かがベリファイアを書けばMLのオンチェーン検証が可能になるかもしれないが、コストは高い）や Risc0のBonsai サービス（様々なチェーンで検証可能なSTARK証明を発行するオフチェーン証明サービス）があります。2025年現在、ブロックチェーン上のほとんどのzkMLデモは（ベリファイアの効率性から）SNARKを好んでいますが、STARKアプローチは、その透明性と高セキュリティまたは耐量子設定での可能性から、依然として魅力的です。例えば、分散型計算ネットワークは、信頼できるセットアップなしで誰でも作業を検証できるようにSTARKを使用するかもしれません。これは長寿のために有用です。また、一部の特殊なMLタスクは、STARKフレンドリーな構造を活用するかもしれません。例えば、XOR/ビット操作を多用する計算は、SNARKの体演算よりもSTARK（ブール代数とハッシュでは安価なため）の方が速い可能性があります。

MLにおけるSNARK vs STARKの概要：

  • パフォーマンス： SNARK（Halo2など）はゲートあたりの証明オーバーヘッドが大きいですが、強力な最適化と検証のための小さな定数の恩恵を受けます。STARK（汎用）は定数オーバーヘッドが大きいですが、より線形にスケールし、ペアリングのような高価な暗号を回避します。DeepProveは、アプローチをカスタマイズする（サムチェック）ことで、ほぼ線形の証明時間（高速）をSTARKのような証明で実現することを示しています。JOLTは、汎用VMでさえルックアップを多用することで高速化できることを示しています。経験的に、数百万の操作までのモデルでは、十分に最適化されたSNARK（Ezkl）は処理できますが、数十分かかる可能性があり、一方DeepProve（GKR）は数秒でできます。2024年のSTARK VMは、特化されていない限り、SNARKの中間かそれ以下でした（テストではRisc0は遅く、Cairoはカスタムヒントなしでは遅かった）。
  • 検証： SNARK証明は最も速く検証されます（ミリ秒単位、オンチェーンでのデータは最小限で約数百バイトから数KB）。STARK証明はより大きく（数十KB）、多くのハッシュステップのため検証に時間がかかります（数十ミリ秒から数秒）。ブロックチェーンの観点から言えば、SNARKの検証は例えば約20万ガスかかるかもしれませんが、STARKの検証は数百万ガスかかる可能性があり、L1には高すぎることが多く、L2や簡潔な検証スキームでは許容範囲です。
  • セットアップとセキュリティ： Groth16のようなSNARKはサーキットごとに信頼できるセットアップを必要としますが（任意のモデルには不親切）、ユニバーサルSNARK（PLONK、Halo2）は、特定のサイズまでの任意のサーキットに再利用できる一度きりのセットアップを持ちます。STARKはセットアップを必要とせず、ハッシュの仮定（および古典的な多項式複雑性の仮定）のみを使用し、ポスト量子セキュア です。これにより、STARKは長寿のために魅力的です。量子コンピュータが出現しても証明は安全なままですが、現在のSNARK（BLS12-381ベース）は量子攻撃によって破られます。

これらの違いを、まもなく比較表にまとめます。

MLのためのFHE (FHE-o-ML)：プライベート計算 vs. 検証可能計算​

完全準同型暗号 (FHE) は、暗号化されたデータ上で直接計算を実行できる暗号技術です。MLの文脈では、FHEは一種の プライバシー保護推論 を可能にします。例えば、クライアントは暗号化された入力をモデルホストに送信し、ホストはそれを復号せずに暗号文上でニューラルネットワークを実行し、クライアントが復号できる暗号化された結果を返します。これにより データ機密性 が保証されます。モデルの所有者は入力について何も知ることができず（そして、クライアントは出力のみを知り、モデルの内部については知らない可能性があります）。しかし、FHE自体は、ZKPのように 正当性の証明を生成しません。クライアントは、モデルの所有者が実際に正直に計算を実行したと信頼しなければなりません（暗号文が操作された可能性があります）。通常、クライアントがモデルを持っているか、特定の出力分布を期待している場合、露骨な不正は検出できますが、微妙なエラーや間違ったモデルバージョンの使用は、暗号化された出力だけからは明らかになりません。

パフォーマンスのトレードオフ： FHEは計算が非常に重いことで知られています。FHE下でディープラーニング推論を実行すると、桁違いの速度低下が発生します。初期の実験（例：2016年のCryptoNets）では、暗号化されたデータ上で小さなCNNを評価するのに数十秒かかりました。2024年までに、CKKS（近似算術用） やより良いライブラリ（Microsoft SEAL、ZamaのConcrete）などの改善により、このオーバーヘッドは減少しましたが、依然として大きいです。例えば、あるユーザーは、ZamaのConcrete-MLを使用してCIFAR-10分類器を実行するのに、自分のハードウェアで推論ごとに 25〜30分 かかったと報告しています。最適化後、Zamaのチームは192コアサーバーでその推論を約40秒で達成しました。40秒でさえ、平文の推論（0.01秒かもしれない）と比較して非常に遅く、約 $10^3$–$10^4\times$ のオーバーヘッドを示しています。より大きなモデルやより高い精度は、コストをさらに増加させます。さらに、FHE操作は多くのメモリを消費し、時折 ブートストラップ（ノイズ削減ステップ）を必要とし、これは計算コストが高いです。要約すると、スケーラビリティは大きな問題 です。最先端のFHEは小さなCNNや単純なロジスティック回帰を処理できるかもしれませんが、大規模なCNNやTransformerへのスケーリングは現在の実用的な限界を超えています。

プライバシーの利点： FHEの大きな魅力は データプライバシー です。入力はプロセス全体を通じて完全に暗号化されたままでいられます。これは、信頼できないサーバーがクライアントのプライベートデータについて何も知ることなく計算できることを意味します。逆に、モデルが機密（独自）である場合、モデルパラメータを暗号化し、クライアント側でFHE推論を実行することも考えられますが、クライアントが重いFHE計算を行わなければならない場合、強力なサーバーにオフロードするという考えが無意味になるため、これはあまり一般的ではありません。通常、モデルは公開されているか、サーバーが平文で保持しており、データはクライアントの鍵で暗号化されます。そのシナリオでのモデルのプライバシーは、デフォルトでは 提供されません（サーバーはモデルを知っており、クライアントは出力を知りますが重みは知りません）。モデルとデータの両方を互いに秘密に保つことができる、よりエキゾチックな設定（安全な二者間計算やマルチキーFHEなど）もありますが、それらはさらに複雑さを増します。対照的に、ZKPを介したzkMLは、モデルのプライバシー と データのプライバシー を同時に保証できます。プルーバーはモデルとデータの両方を秘密のウィットネスとして持ち、ベリファイアに必要なものだけを明らかにします。

オンチェーン検証は不要 (そして不可能)： FHEでは、結果はクライアントに暗号化されて返されます。クライアントはそれを復号して実際の予測を取得します。その結果をオンチェーンで使用したい場合、クライアント（または復号鍵を持つ者）は平文の結果を公開し、それが正しいことを他の人に納得させる必要があります。しかし、その時点で、信頼は再びループに戻ります。ZKPと組み合わせない限り。原則として、FHEとZKPを組み合わせることは可能です。例えば、計算中にデータをプライベートに保つためにFHEを使用し、その後、平文の結果が正しい計算に対応するというZK証明を生成します。しかし、それらを組み合わせることは、FHE と ZKPのパフォーマンスペナルティを支払うことを意味し、今日の技術では非常に非現実的です。したがって、実際にはFHE-of-MLとzkMLは異なるユースケースに対応します：

  • FHE-of-ML： 二者間（クライアントとサーバー）の機密性 が目標である場合に理想的です。例えば、クラウドサービスがMLモデルをホストし、ユーザーはクラウドにデータを明らかにすることなく機密データでクエリできます（そしてモデルが機密である場合、FHEフレンドリーなエンコーディングを介してデプロイするかもしれません）。これはプライバシー保護MLサービス（医療予測など）に最適です。ユーザーは依然としてサービスが忠実にモデルを実行することを信頼する必要がありますが（証明がないため）、少なくとも データ漏洩 は防がれます。Zamaのような一部のプロジェクトは、スマートコントラクトが暗号化された入力で動作できる 「FHE対応EVM (fhEVM)」 を探求していますが、それらの計算をオンチェーンで検証するには、コントラクトが何らかの方法で正しい計算を強制する必要があり、これはZK証明や特殊なセキュアハードウェアを必要とする可能性が高い未解決の課題です。
  • zkML (ZKP)： 検証可能性と公開監査可能性 が目標である場合に理想的です。誰でも（またはどのコントラクトでも）「モデル $M$ が $X$ で正しく評価され、$Y$ を生成した」 ことを確認したい場合、ZKPが解決策です。それらはボーナスとしてプライバシーも提供しますが（必要に応じて $X$、$Y$、または $M$ を証明のプライベートな入力として扱うことで隠すことができます）、その主な特徴は正しい実行の証明です。

補完的な関係： ZKPは ベリファイア を保護し（彼らは秘密について何も知らず、計算が正しく行われたことだけを知ります）、一方FHEは計算を行う当事者から プルーバー のデータを保護することに注意する価値があります。一部のシナリオでは、これらを組み合わせることができます。例えば、信頼できないノードのネットワークがFHEを使用してユーザーのプライベートデータで計算し、その後、計算がプロトコルに従って行われたことをユーザー（またはブロックチェーン）にZK証明で提供することができます。これにより、プライバシーと正当性の両方がカバーされますが、今日のアルゴリズムではパフォーマンスコストが莫大です。近い将来、より実現可能なのは、Trusted Execution Environments (TEE) + ZKP や Functional Encryption + ZKP のようなハイブリッドです。これらは私たちの範囲を超えていますが、同様のものを提供することを目指しています（TEEは計算中にデータ/モデルを秘密に保ち、その後ZKPがTEEが正しいことを行ったことを証明できます）。

要約すると、FHE-of-MLは入力/出力の機密性を優先 し、zkMLは検証可能な正当性（プライバシーの可能性あり）を優先 します。以下の表1は、主要な特性を対比しています：

アプローチプルーバーのパフォーマンス (推論と証明)証明サイズと検証プライバシー機能信頼できるセットアップ？ポスト量子？
zk-SNARK (Halo2, Groth16, PLONKなど)重いプルーバーオーバーヘッド（最適化なしで通常のランタイムの最大10^6倍、実際には10^3–10^5倍）。特定のモデル/サーキットに最適化。中規模モデルで数分、大規模モデルで数時間の証明時間。最近のzkML SNARK（GKR付きDeepProve）はこれを大幅に改善（ほぼ線形のオーバーヘッド、例：数百万パラメータモデルで数分の代わりに数秒）。非常に小さな証明（多くは100KB未満、時には数KB程度）。検証は高速：数回のペアリングまたは多項式評価（通常、オンチェーンで50ms未満）。DeepProveのGKRベースの証明はより大きく（数十〜数百KB）、約0.5秒で検証（モデルの再実行よりはるかに高速）。データ機密性： はい – 入力は証明内でプライベートにでき、公開されません。モデルプライバシー： はい – プルーバーはモデルの重みにコミットし、それらを公開しません。出力の隠蔽： オプション – 証明は出力を明らかにせずにステートメントについてのものであることができます（例：「出力はプロパティPを持つ」）。しかし、出力自体がオンチェーンで必要な場合、通常は公開されます。全体として、SNARKは完全な ゼロ知識 の柔軟性を提供します（隠したい部分を隠せます）。スキームによる。Groth16/EZKLはサーキットごとに信頼できるセットアップが必要。PLONK/Halo2はユニバーサルセットアップ（一度きり）を使用。DeepProveのサムチェックGKRは透明（セットアップ不要）– その設計のボーナス。古典的なSNARK（BLS12-381曲線）は PQセキュアではない（楕円曲線離散対数問題に対する量子攻撃に脆弱）。一部の新しいSNARKはPQセキュアなコミットメントを使用しますが、Ezklで使用されるHalo2/PLONKはPQセキュアではありません。GKR（DeepProve）はハッシュコミットメント（例：Poseidon/Merkle）を使用し、これらはPQセキュアであると推測されています（ハッシュの原像困難性に依存）。
zk-STARK (FRI, ハッシュベースの証明)プルーバーのオーバーヘッドは高いが、より 線形 なスケーリング。通常、大規模タスクではネイティブより10^2–10^4倍遅く、並列化の余地あり。汎用STARK VM（Risc0, Cairo）は2024年にMLでSNARKと比較して遅いパフォーマンスを示した（例：一部のケースでHalo2より3倍–66倍遅い）。特殊なSTARK（またはGKR）は線形オーバーヘッドに近づき、大規模サーキットでSNARKを上回ることができます。証明はより大きい：しばしば数十KB（サーキットサイズ/log(n)と共に増加）。ベリファイアは複数のハッシュとFFTチェックを行う必要があり、検証時間は小さなεに対して約O(n^ε)（例：証明サイズに応じて約50msから500ms）。オンチェーンでは、これはより高価です（StarkWareのL1ベリファイアは証明ごとに数百万ガスかかることがあります）。一部のSTARKは、プルーバー時間を犠牲にしてサイズを圧縮するために再帰的証明をサポートします。データとモデルのプライバシー： STARKはトレースデータをランダム化する（多項式評価にブラインディングを追加する）ことでゼロ知識にすることができ、SNARKと同様にプライベートな入力を隠すことができます。多くのSTARK実装は完全性に焦点を当てていますが、zk-STARKの変種はプライバシーを可能にします。したがって、はい、SNARKのように入力/モデルを隠すことができます。出力の隠蔽： 理論的には同様に可能ですが（プルーバーが出力を公開として宣言しない）、通常は出力が公開/検証したいものであるため、めったに使用されません。信頼できるセットアップは不要。 透明性はSTARKの特徴です – 共通のランダム文字列のみを必要とします（Fiat-Shamirが導出可能）。これにより、オープンエンドな使用（任意のモデル、いつでも、モデルごとのセレモニーなし）に魅力的です。はい、STARKはハッシュと情報理論的なセキュリティの仮定（ランダムオラクルやFRIにおける特定のコードワード復号の困難性など）に依存しています。これらは量子攻撃者に対して安全であると考えられています。したがって、STARK証明はPQ耐性があり、検証可能なAIを将来にわたって保証する上で利点があります。
MLのためのFHE (推論に適用される完全準同型暗号)プルーバー = 暗号化データ上で計算を行う当事者。 計算時間は非常に高い：平文推論より10^3–10^5倍遅いのが一般的。ハイエンドハードウェア（多コアサーバー、FPGAなど）でこれを緩和できます。一部の最適化（低精度推論、レベル化FHEパラメータ）はオーバーヘッドを削減できますが、基本的なパフォーマンスヒットがあります。FHEは現在、小さなモデルや単純な線形モデルには実用的ですが、ディープネットワークはトイサイズを超えると依然として困難です。証明は生成されません。結果は暗号化された出力です。正当性をチェックするという意味での 検証 はFHE単独では提供されません – 計算を行う当事者が不正をしないと信頼します。（セキュアハードウェアと組み合わせれば、アテステーションが得られるかもしれませんが、そうでなければ、悪意のあるサーバーは不正な暗号化結果を返し、クライアントは違いを知らずに間違った出力に復号する可能性があります）。データ機密性： はい – 入力は暗号化されているため、計算を行う当事者はそれについて何も知りません。モデルプライバシー： モデルの所有者が暗号化された入力で計算を行っている場合、モデルは彼らの側で平文です（保護されていません）。役割が逆の場合（クライアントがモデルを暗号化して保持し、サーバーが計算する）、モデルは暗号化されたままにできますが、このシナリオはあまり一般的ではありません。FHE/MPCを組み合わせて両方を保護する安全な二者間MLのような技術もありますが、これらはプレーンなFHEを超えています。出力の隠蔽： デフォルトでは、計算の出力は暗号化されています（秘密鍵を持つ当事者、通常は入力の所有者のみが復号可能）。したがって、出力は計算サーバーから隠されています。出力を公開したい場合、クライアントは復号して公開できます。セットアップは不要。各ユーザーは暗号化のために独自の鍵ペアを生成します。信頼は鍵が秘密に保たれることに依存します。FHEスキーム（例：BFV, CKKS, TFHE）のセキュリティは、格子問題（Learning With Errors）に基づいており、これらは量子攻撃に耐性があると考えられています（少なくとも効率的な量子アルゴリズムは知られていません）。したがって、FHEは一般的に ポスト量子セキュア と考えられています。

表1：機械学習推論のためのzk-SNARK、zk-STARK、およびFHEアプローチの比較（パフォーマンスとプライバシーのトレードオフ）。

Web3アプリケーションへのユースケースと影響​

zkMLを介したAIとブロックチェーンの融合は、Web3における強力な新しいアプリケーションパターンを解き放ちます：

  • 分散型自律エージェントとオンチェーンでの意思決定： スマートコントラクトやDAOは、正当性の保証付きでAI駆動の意思決定を組み込むことができます。例えば、取引を実行する前に市場状況を分析するためにニューラルネットワークを使用するDAOを想像してみてください。zkMLを使用すると、DAOのスマートコントラクトは、アクションが受け入れられる前に、承認されたMLモデル（既知のハッシュコミットメントを持つ）が最新のデータで実行され、推奨されたアクションを生成したというzkSNARK証明を要求できます。これにより、悪意のあるアクターが偽の予測を注入するのを防ぎます – チェーンが AIの計算を検証します。時間が経てば、DeFiやゲームで意思決定を行う完全にオンチェーンの自律エージェント（オフチェーンAIをクエリするか、簡略化されたモデルを含むコントラクト）を持つことさえ可能になり、そのすべての動きはzk証明を介して正しく、ポリシーに準拠していることが証明されます。これにより、自律エージェントの「思考」がブラックボックスではなく、透明で検証可能になるため、信頼性が向上します。

  • 検証可能な計算市場： Lagrangeのようなプロジェクトは、効果的に 検証可能な計算マーケットプレイス を作成しています – 開発者は重いML推論をプルーバーのネットワークにアウトソースし、結果と共に証明を受け取ることができます。これは分散型クラウドコンピューティングに似ていますが、信頼が組み込まれています。サーバーを信頼する必要はなく、証明だけを信頼すればよいのです。これはオラクルやオフチェーン計算にとってパラダイムシフトです。Ethereumの今後のDSC（分散型シーケンシングレイヤー）やオラクルネットワークのようなプロトコルは、これを使用して暗号学的な保証付きのデータフィードや分析フィードを提供できます。例えば、オラクルは「入力Yに対するモデルXの結果」を提供し、誰もがオラクルの言葉を信頼するのではなく、添付された証明をオンチェーンで検証できます。これにより、ブロックチェーン上で サービスとしての検証可能なAI が可能になります。どのコントラクトも計算（「私のプライベートモデルでこれらの信用リスクをスコアリングして」など）を要求し、有効な証明がある場合にのみ回答を受け入れることができます。Gensyn のようなプロジェクトは、これらの検証技術を使用して分散型のトレーニングおよび推論マーケットプレイスを探求しています。

  • NFTとゲーミング – 来歴と進化： ブロックチェーンゲームやNFTコレクティブルでは、zkMLは特性やゲームの動きが正当なAIモデルによって生成されたことを証明できます。例えば、ゲームがAIにNFTペットの属性を進化させることを許可するかもしれません。ZKがなければ、賢いユーザーはAIや結果を改変して優れたペットを手に入れるかもしれません。zkMLを使用すると、ゲームは 「ペットの新しいステータスは、ペットの古いステータスに対して公式の進化モデルによって計算された」 という証明を要求でき、不正を防ぎます。ジェネレーティブアートNFTについても同様です。アーティストはジェネレーティブモデルをコミットメントとしてリリースできます。後でNFTをミントするときに、各画像が特定のシードを与えられてそのモデルによって生成されたことを証明し、真正性を保証します（そして、アーティストのIPを保護するために、正確なモデルを公開することなくそれを行うことさえできます）。この 来歴検証 は、検証可能なランダム性に似た方法で真正性を保証します – ここでは検証可能な創造性です。

  • 機密領域におけるプライバシー保護AI： zkMLは 入力を公開することなく結果の確認 を可能にします。医療では、患者のデータがクラウドプロバイダーによってAI診断モデルに通されるかもしれません。病院は診断と、そのモデル（製薬会社が非公開で保有している可能性がある）が患者データで正しく実行された という証明を受け取ります。患者データはプライベートなままであり（証明では暗号化またはコミットされた形式のみが使用された）、モデルの重みは独自のままです – それでも結果は信頼されます。規制当局や保険会社も、承認されたモデルのみが使用されたことを検証できます。金融では、企業は監査人や規制当局に対して、そのリスクモデルが内部データに適用され、特定のメトリクスを生成した ことを、基礎となる機密性の高い財務データを明らかにすることなく証明できます。これにより、手動の信頼ではなく、暗号学的な保証によるコンプライアンスと監督が可能になります。

  • クロスチェーンおよびオフチェーンの相互運用性： ゼロ知識証明は基本的にポータブルであるため、zkMLは クロスチェーンAI の結果を促進できます。あるチェーンがオフチェーンで実行されるAI集約的なアプリケーションを持っているかもしれません。その結果の証明を別のブロックチェーンに投稿でき、そのブロックチェーンはそれをトラストレスに受け入れます。例えば、ソーシャルメディア全体のセンチメントを集約するためにAIを使用するマルチチェーンDAOを考えてみましょう（オフチェーンデータ）。AI分析（大規模データに対する複雑なNLP）はオフチェーンのサービスによって行われ、その後、「分析は正しく行われ、出力センチメントスコア = 0.85」 という証明を小さなブロックチェーン（または複数のチェーン）に投稿します。すべてのチェーンは、それぞれが分析を再実行する必要なく、その結果を検証し、ガバナンスロジックで使用できます。この種の 相互運用可能な検証可能計算 は、Lagrangeのネットワークが複数のロールアップやL1に同時にサービスを提供することでサポートしようとしているものです。これにより、チェーン間で結果を移動する際に、信頼できるブリッジやオラクルの仮定が不要になります。

  • AIアライメントとガバナンス： より未来志向の観点から、zkMLは AIガバナンスと安全性 のためのツールとして注目されています。例えば、Lagrangeのビジョンステートメントでは、AIシステムがより強力になるにつれて（超知能でさえ）、合意されたルールに従うことを保証するために暗号学的検証が不可欠になると主張しています。AIモデルにその推論や制約の証明を生成させることを要求することで、人間はある程度の制御を維持します – 「検証できないものは信頼できない」。これは推測的であり、技術的な側面だけでなく社会的な側面も関わりますが、この技術は、自律的に実行されているAIエージェントが、承認されたモデルを使用しており、改ざんされていないことを証明することを強制できます。分散型AIネットワークは、貢献を検証するためにオンチェーン証明を使用するかもしれません（例：モデルを共同でトレーニングするノードのネットワークは、各更新が忠実に計算されたことを証明できます）。したがって、zkMLは、分散型または制御されていない環境であっても、AIシステムが人間定義のプロトコルに対して説明責任を負い続けることを保証する 上で役割を果たす可能性があります。

結論として、zkMLと検証可能なオンチェーンAI は、AIアプリケーションにおける信頼、透明性、プライバシーを向上させる可能性のある、高度な暗号技術と機械学習の融合を表しています。主要なアプローチ – zk-SNARK、zk-STARK、FHE – を比較することで、パフォーマンスとプライバシーの間のトレードオフのスペクトルが見え、それぞれが異なるシナリオに適しています。EzklのようなSNARKベースのフレームワークやLagrangeのDeepProveのような革新により、実質的なニューラルネットワーク推論を現実的な労力で証明することが可能になり、検証可能なAIの現実世界での展開への扉が開かれました。STARKベースおよびVMベースのアプローチは、より大きな柔軟性とポスト量子セキュリティを約束しており、これは分野が成熟するにつれて重要になるでしょう。FHEは、検証可能性の解決策ではありませんが、機密性の高いML計算という補完的なニーズに対応し、ZKPとの組み合わせや特定のプライベートな文脈では、ユーザーがデータプライバシーを犠牲にすることなくAIを活用できるようにします。

Web3への影響 は重要です。AIの予測に反応するスマートコントラクト（それが正しいと知っている）、結果がトラストレスに販売される計算市場、zkMLによって保護された デジタルアイデンティティ（Worldcoinの虹彩AIによる人格証明のように、生体認証画像を漏らすことなく人間であることを確認する）、そして一般的にブロックチェーンアプリケーションを豊かにする新しいクラスの 「証明可能なインテリジェンス」 が予見できます。非常に大規模なモデルのパフォーマンス、開発者のエルゴノミクス、特殊なハードウェアの必要性など、多くの課題が残っていますが、その軌道は明確です。あるレポートが指摘したように、「今日のZKPは小さなモデルをサポートできるが、中規模から大規模なモデルはそのパラダイムを壊す」。しかし、急速な進歩（DeepProveによる従来技術に対する50倍–150倍の高速化）がその境界を押し広げています。継続的な研究（ハードウェアアクセラレーションや分散証明など）により、ますます大きく複雑なAIモデルが証明可能になることが期待できます。zkMLは、ニッチなデモから、信頼できるAIインフラストラクチャの不可欠なコンポーネント へとすぐに進化するかもしれません。これにより、AIがユビキタスになるにつれて、それが 監査可能で、分散化され、ユーザーのプライバシーとセキュリティに沿った 方法で行われることが保証されます。