通过 zkML 和密码学证明实现可验证的链上 AI
引言：区块链上对可验证 AI 的需求
随着 AI 系统的影响力日益增强，确保其输出的可信度变得至关重要。传统方法依赖于机构担保（本质上是_“相信我们就行”），但这并不能提供任何密码学上的保证。在像区块链这样的去中心化环境中，这个问题尤为突出，因为智能合约或用户必须信任一个由 AI 推导出的结果，却无法在链上重新运行一个计算量巨大的模型。零知识机器学习 (zkML) 通过允许对机器学习 (ML) 计算进行_密码学验证_来解决这个问题。本质上，zkML 使证明者能够生成一个简洁的证明，证明“输出 $Y$ 来自于在输入 $X$ 上运行模型 $M$”——并且无需透露 $X$ 或 $M$ 的内部细节。这些零知识证明 (ZKPs) 可以被任何人（或任何合约）高效地验证，从而将 AI 的信任基础从“策略”转变为“证明”_。
AI 的链上可验证性意味着区块链可以通过验证一个正确执行的证明来整合高级计算（如神经网络推理），而无需亲自执行这些计算。这具有广泛的影响：智能合约可以基于 AI 预测做出决策，去中心化自治代理可以证明它们遵循了其算法，跨链或链下计算服务可 以提供可验证的输出，而不是无法验证的预言机。最终，zkML 为实现无需信任且保护隐私的 AI 提供了一条路径——例如，证明一个 AI 模型的决策是正确且经过授权的，_同时_不暴露私有数据或专有模型权重。这对于从安全医疗分析到区块链游戏和 DeFi 预言机等各种应用都至关重要。
zkML 的工作原理：将 ML 推理压缩为简洁证明
从宏观上看，zkML 将密码学证明系统与 ML 推理相结合，使得一个复杂的模型评估可以被“压缩”成一个微小的证明。在内部，ML 模型（例如神经网络）被表示为一个由许多算术运算（矩阵乘法、激活函数等）组成的电路或程序。证明者在链下执行完整的计算，然后使用零知识证明协议来证明每一步都正确完成，而不是揭示所有中间值。验证者仅凭证明和一些公开数据（如最终输出和模型标识符），就能在密码学上确信其正确性，而无需重新执行模型。
为了实现这一点，zkML 框架通常将模型计算转换为一种适合 ZKP 的格式：
- 电路编译： 在基于 SNARK 的方法中，模型的计算图被编译成一个_算术电路_或一组多项式约束。神经网络的每一层（卷积、矩阵乘法、非线性激活）都成为一个子电路，其约束确保了在给定输入的情况下输出是正确的。由于神经网络涉及非线性操作（如 ReLU、Sigmoid 等），这些操作天然不适合多项式，因此采用查找表等技术来高效处理它们。例如，一个 ReLU（输出 = max(0, 输入)）可以通过一个自定义约束或查找来强制执行，该约束或查找验证当输入≥0 时输出等于输入，否则为零。最终结果是一组密码学约束，证明者必须满足这些约束，从而间接证明模型运行正确。
- 执行轨迹与虚拟机： 另一种方法是将模型推理视为一个程序轨迹，正如在 zkVM 方法中所做的那样。例如，JOLT zkVM 针对 RISC-V 指令集；可以将 ML 模型（或计算它的代码）编译成 RISC-V，然后证明每个 CPU 指令都正确执行。JOLT 引入了一种_“查找奇点”_技术，用快速的表查找替代了昂贵的算术约束，以处理每个有效的 CPU 操作。每个操作（加法、乘法、位运算等）都通过在一个巨大的预计算有效结果表中进行查找来检查，并使用专门的论证（Lasso/SHOUT）来保持其高效性。这大大减少了证明者的工作量：即使是复杂的 64 位操作，在证明中也变成了一次表查找，而不是许多算术约束。
- 交互式协议 (GKR Sum-Check)： 第三种方法使用像 GKR (Goldwasser–Kalai–Rotblum) 这样的交互式证明来验证分层计算。在这里，模型的计算被看作一个分层算术电路（每个神经网络层是电路图的一层）。证明者正常运行模型，然后参与一个 sum-check 协议_来证明每一层的输出相对于其输入是正确的。在 Lagrange 的方法（DeepProve，下文详述）中，证明者和验证者执行一个交互式多项式协议（通过 Fiat-Shamir 变为非交互式），该协议检查每一层计算的一致性，而无需重新进行计算。这种 sum-check 方法避免了生成一个庞大的静态电路；相反，它以逐步的方式验证_计算的一致性，且密码学操作最少（主要是哈希或多项式求值）。
无论采用何种方法，最终都会得到一个简洁的证明（通常为几 KB 到几十 KB），证明整个推理过程的正确性。该证明是_零知识的_，意味着任何秘密输入（私有数据或模型参数）都可以保持隐藏——它们影响证明的生成，但不会向验证者透露。只有预期的公共输出或断言才会被揭示。这使得诸如_“证明模型 $M$ 应用于患者数据 $X$ 得到诊断 $Y$，而不泄露 $X$ 或模型的权重”_这样的场景成为可能。
实现链上验证： 一旦生成了证明，就可以将其发布到区块链上。智能合约可以包含验证逻辑来检查该证明，通常使用预编译的密码学原语。例如，以太坊有用于许多 zk-SNARK 验证器中使用的 BLS12-381 配对操作的预编译合约，这使得 SNARK 证明的链上验证非常高效。STARKs（基于哈希的证明）虽然更大，但通过仔细优化或可能带有一些信任假设，仍然可以在链上验证（例如，StarkWare 的 L2 通过一个链上验证器合约在以太坊上验证 STARK 证明，尽管 Gas 成本比 SNARKs 高）。关键在于，区块链不需要执行 ML 模型——它只需运行一个验证过程，这比原始计算要_便宜得多_。总而言之，zkML 将昂贵的 AI 推理压缩成一个微小的证明，区块链（或任何验证者）可以在毫秒到秒级的时间内完成验证。
Lagrange DeepProve：一个 zkML 突破的架构与性能
由 Lagrange Labs 推出的 DeepProve 是一个专注于速度和可扩展性的尖端 zkML 推理框架。DeepProve 于 2025 年发布，引入了一种新的证明系统 ，其速度远超之前的解决方案（如 Ezkl）。其设计核心是_带有 sum-check 的 GKR 交互式证明协议_以及针对神经网络电路的专门优化。以下是 DeepProve 的工作原理及其性能表现：
-
一次性预处理： 开发者从一个训练好的神经网络开始（目前支持的类型包括多层感知器和流行的 CNN 架构）。模型被导出为 ONNX 格式，这是一种标准的图表示。然后，DeepProve 的工具会解析 ONNX 模型并对其进行_量化_（将权重转换为定点/整数形式），以便进行高效的域运算。在此阶段，它还会为密码学协议生成证明和验证密钥。这个设置过程对每个模型只需进行一次，无需在每次推理时重复。DeepProve 强调易于集成：“将你的模型导出到 ONNX → 一次性设置 → 生成证明 → 随处验证”。
-
证明（推理 + 证明生成）： 设置完成后，证明者（可以由用户、服务或 Lagrange 的去中心化证明者网络运行）接收一个新的输入 $X$ 并在其上运行模型 $M$，得到输出 $Y$。在此执行过程中，DeepProve 会记录每一层计算的执行轨迹。与 SNARK 方法预先将每个乘法转换为静态电路不同，DeepProve 使用线性时间的 GKR 协议来动态验证每一层。对于每个网络层，证明者提交该层的输入和输出（例如，通过密码学哈希或多项式承诺），然后参与一个 sum-check 论证，以证明输出确实是根据该层的功能由输入产生的。sum-check 协议通过迭代方式让验证者相信一个编码了该层计算的多项式求值之和的正确性，而无需透露实际值。非线性操作（如 ReLU、softmax）在 DeepProve 中通过_查找论证_得到高效处理——如果一个激活函数的输出被计算出来，DeepProve 可以证明每个输出都对应于该函数预计算表中的一个有效输入-输出对。逐层 生成证明，然后聚合成一个覆盖整个模型前向传播的简洁证明。密码学的繁重工作被最小化——DeepProve 的证明者主要执行正常的数值计算（实际的推理）外加一些轻量级的密码学承诺，而不是解决一个巨大的约束系统。
-
验证： 验证者使用最终的简洁证明以及一些公开值——通常是模型的承诺标识符（对 $M$ 权重的密码学承诺）、输入 $X$（如果不是私密的）和声称的输出 $Y$——来检查正确性。在 DeepProve 的系统中，验证涉及验证 sum-check 协议的记录以及最终的多项式或哈希承诺。这比验证一个经典的 SNARK（可能只需几次配对操作）要复杂，但它比_重新运行模型要便宜得多_。在 Lagrange 的基准测试中，验证一个中等规模 CNN 的 DeepProve 证明在软件中大约需要 0.5 秒。这意味着用约 0.5 秒就能确认一个拥有数十万参数的卷积网络运行正确——比在 GPU 上简单地重新计算该 CNN 进行验证快 500 倍以上。（事实上，DeepProve 测得 CNN 的_验证速度快了 521 倍_，MLP 的_验证速度快了 671 倍_，相较于重新执行。）证明的大小足够小，可以在链上传输（几十 KB），并且验证可以在智能合约中执行，尽管 0.5 秒的计算可能需要仔细的 Gas 优化或在 Layer-2 上执行。
架构与工具： DeepProve 使用 Rust 实现，并为开发者提供了一个工具包（zkml 库）。它原生支持 ONNX 模型图，使其与 PyTorch 或 TensorFlow 导出的模型兼容。目前的证明过程针对参数量高达数百万的模型（测试包括一个 400 万参数的密集网络）。DeepProve 结合了多种密码学组件：一个多线性多项式承诺（用于承诺层输出）、用于验证计算的 sum-check 协议，以及用于非线性操作的查找论证。值得注意的是，Lagrange 的开源仓库承认其工作建立在先前工作（Scroll 的 Ceno 项目中的 sum-check 和 GKR 实现）之上，这表明 zkML 与零知识 rollup 研究存在交集。
为了实现实时可扩展性，Lagrange 将 DeepProve 与其证明者网络 (Prover Network) 相结合——这是一个由专门的 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 在约 0.6 秒内验证了 26.4 万参数 CNN 的证明，而在该测试中，验证 Ezkl 的证明（基于 Halo2）在 CPU 上耗时超过 5 分钟。这些速度提升源于 DeepProve 的近线性复杂度：其证明者的扩展性大致为 O(n)，其中 n 是操作数，而基于电路的 SNARK 证明者通常具有超线性的开销（FFT 和多项式承诺的扩展性）。事实上，DeepProve 的证明者吞吐量可以与普通推理 运行时间在同一数量级内——最新的 GKR 系统对于大型矩阵乘法，其速度可以比原始执行慢不到 10 倍，这在 ZK 领域是一项了不起的成就。这使得_实时或按需证明_变得更加可行，为在交互式应用中实现可验证 AI 铺平了道路。
用例： Lagrange 已经与 Web3 和 AI 项目合作，应用 zkML。用例包括：可验证的 NFT 特征（证明一个由 AI 生成的游戏角色或收藏品的进化是由授权模型计算的）、AI 内容的来源证明（证明一张图片或一段文本是由特定模型生成的，以打击深度伪造）、DeFi 风险模型（证明一个评估金融风险的模型输出，而不泄露专有数据），以及_医疗或金融领域的私密 AI 推理_（医院可以获得带有证明的 AI 预测，确保正确性而不暴露患者数据）。通过使 AI 输出可验证且保护隐私，DeepProve 为去中心化系统中_“你可以信任的 AI”打开了大门——从一个“盲目信任黑盒模型”的时代，迈向一个“客观保证”_的时代。
基于 SNARK 的 zkML：Ezkl 与 Halo2 方法
传统的 zkML 方法使用 zk-SNARKs（简洁非交互式知识论证）来证明神经网络推理。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$ 映射到 $\max(0,x)$，适用于一定范围的 $x$ 值。Halo2 的查找论证允许映射 16 位（或更小）的值块，因此大的域（如所有 32 位值）通常被_“分块”_成几个较小的查找。这种分块增加了约束的数量。
- 大整数运算或除法（如果有的话）同样被分解成小块。最终结果是一大组针对特定模型架构定制的 R1CS/PLONK 约束。
然后，Ezkl 使用 Halo2 生成一个证明，证明在给定秘密输入（模型权重、私有输入）和公共输出的情况下，这些约束成立。工具与集成： SNARK 方法的一个优势是它利用了众所周知的原语。Halo2 已经在以太坊的 rollup 中使用（例如 Zcash、zkEVMs），因此它经过了实战检验，并且有现成的链上验证器。Ezkl 的证明使用 BLS12-381 曲线，以太坊可以通过预编译合约进行验证，这使得在智能合约中验证 Ezkl 证明变得非常直接。该团队还提供了用户友好的 API；例如，数据科学家可以在 Python 中使用他们的模型，并使用 Ezkl 的命令行工具来生成证明，而无需深入了解电路知识。
优势： Ezkl 的方法得益于 SNARKs 的通用性和生态系统。它支持相当复杂的模型，并且已经有了_“实际的集成案例（从 DeFi 风险模型到游戏 AI）”_，证明了 现实世界中的 ML 任务。因为它在模型的计算图层面操作，所以可以应用特定于 ML 的优化：例如，修剪不重要的权重或量化参数以减小电路大小。这也意味着模型机密性是天然的——权重可以被视为私有见证数据，因此验证者只看到_某个_有效的模型产生了该输出，或者最多只是一个对模型的承诺。SNARK 证明的验证速度极快（通常在链上为几毫秒或更短），并且证明大小很小（几 KB），这对于区块链使用非常理想。
劣势： 性能是其阿喀琉斯之踵。基于电路的证明带来了巨大的开销，尤其是随着模型规模的增长。据记载，历史上 SNARK 电路对证明者来说可能比仅仅运行模型本身要多出_一百万倍的工作量_。Halo2 和 Ezkl 对此进行了优化，但像大型矩阵乘法这样的操作仍然会产生_大量_的约束。如果一个模型有数百万个参数，证明者就必须处理相应数百万个约束，并在此过程中执行繁重的 FFT 和多重指数运算。这导致了很长的证明时间（对于非平凡的模型通常需要几分钟或几小时）和高内存使用。例如，用 Ezkl 证明一个相对较小的 CNN（例如几十万个参数）在单台机器上可能需要几十分钟。DeepProve 背后的团队指出，对于某些模型证明，Ezkl 需要数小时，而 DeepProve 可以在几分钟内完成。大型模型甚至可能无法装入内存，或者需要分割成多个证明（然后需要递归聚合）。虽然 Halo2 经过了_“适度优化”，但任何需要“分块”查找或处理宽位操作的需求都会转化为额外的开销。总而言之，可扩展性有限——Ezkl 对于中小型模型效果很好（并且在基准测试中确实_优于一些早期的替代方案，如朴素的基于 Stark 的 VM），但随着模型规模超过某个点，它就会遇到困难。
尽管存在这 些挑战，Ezkl 和类似的基于 SNARK 的 zkML 库是重要的垫脚石。它们证明了_在链上实现可验证的 ML 推理是可能的_，并且已经有了活跃的使用。值得注意的是，像 Modulus Labs 这样的项目展示了使用 SNARKs（经过大量优化）在链上验证一个 1800 万参数的模型。成本虽然不菲，但这显示了发展轨迹。此外，Mina 协议拥有自己的 zkML 工具包，该工具包使用 SNARKs 来允许 Mina 上的智能合约（本身就是基于 Snark 的）验证 ML 模型的执行。这表明基于 SNARK 的 zkML 正在获得越来越多的多平台支持。
基于 STARK 的方法：透明且可编程的 ZK for ML
zk-STARKs（可扩展透明知识论证）为 zkML 提供了另一条途径。STARKs 使用基于哈希的密码学（如用于多项式承诺的 FRI），并避免了任何可信设置。它们通常通过模拟一个 CPU 或 VM 并证明其执行轨迹是正确的来运作。在 ML 的背景下，可以为神经网络构建一个自定义的 STARK，_或者_使用一个通用的 STARK VM 来运行模型代码。
通用 STARK VMs (RISC Zero, Cairo)： 一个直接的方法是编写推理代码并在 STARK VM 中运行它。例如，Risc0 提供了一个 RISC-V 环境，任何代码（例如，用 C++ 或 Rust 实现的神经网络）都可以在其中执行并通过 STARK 进行证明。同样，StarkWare 的 Cairo 语言可以表达任意计算（如 LSTM 或 CNN 推理），然后由 StarkNet STARK 证明者进行证明。其优势在于灵活性——你不需要为每个模型设计自定义电路。然而，早期的基准测试表明，对于 ML 任务，朴素的 STARK VM 比优化的 SNARK 电路要慢。在一次测试中，一个基于 Halo2 的证明 (Ezkl) 比在 Cairo 上的基于 STARK 的方法快约 3 倍，甚至比在 2024 年某个基准测试中的 RISC-V STARK VM 快 66 倍。这种差距是由于在 STARK 中模拟每个低级指令的开销以及 STARK 证明中较大的常数（哈希虽然快，但需要大量使用；STARK 证明的大小也更大等）。然而，STARK VM 正在不断改进，并具有透明设置（无需可信设置）和后量子安全的优点。随着对 STARK 友好的硬件和协议的发展，证明速度将会提高。
DeepProve 的方法 vs STARK： 有趣的是，DeepProve 使用 GKR 和 sum-check 产生的证明在精神上更像一个 STARK——它是一个交互式的、基于哈希的证明，不需要结构化的参考字符串。其权衡是它的证明更大，验证比 SNARK 更重。然而，DeepProve 表明，精心的协议设计（专门针对 ML 的分层结构）可以在证明时间上远超通用的 STARK VM 和 SNARK 电路。我们可以将 DeepProve 视为一个_定制的 STARK 风格_的 zkML 证明者（尽管他们为了简洁性使用了 zkSNARK 这个术语，但它没有传统 SNARK 那样的小常数大小验证，因为 0.5 秒的验证时间比典型的 SNARK 验证要长）。传统的 STARK 证明（如 StarkNet 的）通常需要数万次域运算来验证，而 SNARK 的验证可能只需几十次。因此，一个权衡是显而易见的：SNARKs 产生更小的证明和更快的验证器，而 STARKs（或 GKR）则以证明大小和验证速度为代价，提供了更容易的扩展性和无需可信设置的便利。
新兴的改进： JOLT zkVM（前面在 JOLTx 下讨论过）实际上输出的是 SNARKs（使用 PLONKish 承诺），但它体现了可以应用于 STARK 环境的 思想（Lasso 查找理论上可以与 FRI 承诺一起使用）。StarkWare 和其他公司正在研究加速常见操作证明的方法（例如在 Cairo 中使用自定义门或提示来处理大整数运算等）。还有 Privacy & Scaling Explorations (PSE) 的 Circomlib-ML，它为 CNN 层等提供了 Circom 模板——这是面向 SNARK 的，但概念上类似的模板也可以为 STARK 语言制作。
在实践中，利用 STARKs 的非以太坊生态系统包括 StarkNet（如果有人编写验证器，就可以在链上验证 ML，尽管成本很高）和 Risc0 的 Bonsai 服务（这是一个链下证明服务，它发出 STARK 证明，可以在各种链上进行验证）。截至 2025 年，区块链上的大多数 zkML 演示都倾向于使用 SNARKs（因为验证器效率高），但 STARK 方法因其透明性和在高安全性或抗量子环境中的潜力而仍然具有吸引力。例如，一个去中心化计算网络可能会使用 STARKs 让任何人在没有可信设置的情况下验证工作，这对于长期性很有用。此外，一些专门的 ML 任务可能会利用对 STARK 友好的结构：例如，大量使用 XOR/位运算的计算在 STARKs 中可能比在 SNARK 域运算中更快（因为这些在布尔代数和哈希中成本低廉）。
SNARK vs STARK for ML 总结：
- 性能： SNARKs（如 Halo2）每个门的证明开销巨大，但得益于强大的优化和用于验证的小常数；STARKs（通用型）的常数开销较大，但扩展性更线性，并避免了像配对这样昂贵的密码学操作。DeepProve 表明，定制方法（sum-check）可以产生近线性的证明时间（快），但证明类似于 STARK。JOLT 表明，即使是通用 VM，通过大量使用查找也可以变得更快。根据经验，对于高达数百万次操作的模型：一个优化良好的 SNARK (Ezkl) 可以处理，但可能需要几十分钟，而 DeepProve (GKR) 可以在几秒钟内完成。2024 年的 STARK VM 可能介于两者之间，或者比 SNARKs 差，除非经过专门优化（Risc0 在测试中较慢，Cairo 在没有自定义提示的情况下也较慢）。
- 验证： SNARK 证明验证最快（毫秒级，链上数据最少，约几百字节到几 KB）。STARK 证明更大（几十 KB），并且由于需要多次哈希步骤，验证时间更长（几十毫秒到几秒）。在区块链术语中，一个 SNARK 验证可能花费约 20 万 Gas，而一个 STARK 验证可能花费数百万 Gas——通常对于 L1 来说太高，但在 L2 或使用简洁验证方案时可以接受。
- 设置与安全： 像 Groth16 这样的 SNARKs 每个电路都需要一个可信设置（对于任意模型不友好），但通用 SNARKs（PLONK、Halo2）有一个一次性的设置，可以重用于任何达到特定大小的电路。STARKs 不需要设置，只使用哈希假设（加上经典的多项式复杂性假设），并且是后量子安全的。这使得 STARKs 对于长期性很有吸引力——即使量子计算机出现，证明仍然安全，而当前的 SNARKs（基于 BLS12-381）会被量子攻击破解。
我们将在稍后的比较表中整合这些差异。
FHE for ML (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 (ZKPs)： 当目标是_可验证性和公共可审计性_时是理想选择。如果你想让任何人（或任何合约）确信_“模型 $M$ 在 $X$ 上被正确评估并产生了 $Y$”_，ZKP 就是解决方案。它们还提供隐私作为附加好处（如果需要，你可以通过将 $X$、$Y$ 或 $M$ 作为证明的私有输入来隐藏它们），但它们的主要特点是正确执行的证明。
互补关系： 值得注意的是，ZKP 保护的是_验证者_（他们对秘密一无所知，只知道计算是正确完成的），而 FHE 保护的是_证明者_的数据免受计算方的影响。在某些情况下，这两者可以结合——例如，一个不受信任的节点网络可以使用 FHE 对用户的私有数据进行计算，然后向用户（或区块链）提供 ZK 证明，证明计算是按照协议进行的。这将同时涵盖隐私和正确性，但以今天的算法来看，性能成本是巨大的。在短期内更可行的是混合方案，如_可信执行环境 (TEE) + ZKP_ 或_函数加密 + ZKP_——这些超出了我们的范围，但它们旨在提供类似的功能（TEE 在计算期间保持数据/模型秘密，然后 ZKP 可以证明 TEE 做了正确的事情）。
总而言之，FHE-of-ML 优先考虑输入/输出的机密性，而 zkML 优先考虑可验证的正确性（可能带有隐私）。下表 1 对比了关键属性：
| 方法 | 证明者性能 (推理与证明) | 证明大小与验证 | 隐私特性 | 是否需要可信设置？ | 是否后量子安全？ |
|---|---|---|---|---|---|
| zk-SNARK (Halo2, Groth16, PLONK 等) | 证明者开销巨大（未经优化时可达正常运行时间的 10^6 倍；实践中为 10^3–10^5 倍）。针对特定模型/电路进行优化；中等模型证明时间为分钟级，大型模型为小时级。最近的 zkML SNARKs（如 DeepProve with GKR）极大地改善了这一点（近线性开销，例如百万参数模型从分钟级缩短到秒级）。 | 证明非常小（通常 < 100 KB，有时约几 KB）。验证速度快：几次配对或多项式求值（链上通常 < 50 毫秒）。DeepProve 基于 GKR 的证明更大（几十到几百 KB），验证时间约 0.5 秒（仍远快于重新运行模型）。 | 数据机密性： 是——输入可以在证明中保持私密（不被泄露）。模型隐私： 是——证明者可以承诺模型权重而不泄露它们。输出隐藏： 可选——证明可以是一个关于某个陈述的证明，而不泄露输出（例如，“输出具有属性 P”）。然而，如果输出本身需要在链上使用，它通常会变为公开的。总的来说，SNARKs 提供了完全的_零知识_灵活性（可以隐藏任何你想要的部分）。 | 取决于方案。Groth16/EZKL 每个电路都需要一个可信设置；PLONK/Halo2 使用一个通用的设置（一次性）。DeepProve 的 sum-check GKR 是透明的（无需设置）——这是该设计的一个优点。 | 经典的 SNARKs（BLS12-381 曲线）不是后量子安全的（易受针对椭圆曲线离散对数问题的量子攻击）。一些较新的 SNARKs 使用后量子安全的承诺，但 Ezkl 中使用的 Halo2/PLONK 不是 后量子安全的。GKR (DeepProve) 使用哈希承诺（例如 Poseidon/Merkle），这些承诺被推测是后量子安全的（依赖于哈希原像抗性）。 |
| zk-STARK (FRI, 基于哈希的证明) | 证明者开销高，但扩展性更_线性_。对于大型任务，通常比原生执行慢 10^2–10^4 倍，且有并行化空间。2024 年，通用 STARK VM（Risc0, Cairo）在 ML 上的性能比 SNARK 慢（例如，在某些情况下比 Halo2 慢 3-66 倍）。专门的 STARKs（或 GKR）可以接近线性开销，并在大型电路上胜过 SNARKs。 | 证明更大：通常为几十 KB（随电路大小/log(n) 增长）。验证者必须进行多次哈希和 FFT 检查——验证时间约为 O(n^ε)，其中 ε 很小（例如，约 50 毫秒到 500 毫秒，取决于证明大小）。在链上，这成本更高（StarkWare 的 L1 验证器每个证明可能消耗数百万 Gas）。一些 STARKs 支持递归证明以压缩大小，但会增加证明者的时间成本。 | 数据与模型隐私： STARK 可以通过随机化轨迹数据（在多项式求值中添加盲化因子）来实现零知识，因此它可以像 SNARK 一样隐藏私有输入。许多 STARK 实现侧重于完整性，但 zk-STARK 变体确实允许隐私。所以是的，它们可以像 SNARKs 一样隐藏输入/模型。输出隐藏： 理论上同样可行（证明者不将输出声明为公开），但很少使用，因为通常我们想要揭示/验证的是输出。 | 无需可信设置。 透明性是 STARKs 的一个标志——只需要一个公共随机字符串（Fiat-Shamir 可以推导出来）。这使得它们对于开放式使用很有吸引力（任何模型，任何时间，无需为每个模型举行仪式）。 | 是的，STARKs 依赖于哈希和信息论安全假设（如随机预言机和 FRI 中某些码字解码的难度）。这些被认为是能抵抗量子对手的。因此，STARK 证明 是抗后量子攻击的，这对于未来可验证 AI 的发展是一个优势。 |
| FHE for ML (全同态加密应用于推理) | 证明者 = 在加密数据上进行计算的一方。 计算时间极高：比明文推理慢 10^3–10^5 倍是常见的。高端硬件（多核服务器、FPGA 等）可以缓解这一点。一些优化（低精度推理、分级 FHE 参数）可以减少开销，但存在根本的性能损失。FHE 目前对于小型模型或简单线性模型是可行的；深度网络在超出玩具规模后仍然具有挑战性。 | 不生成证明。结果是一个加密的输出。验证（检查正确性）并非由 FHE 单独提供——人们信任计算方不会作弊。（如果与安全硬件结合，可能会得到一个证明；否则，恶意服务器可能返回一个不正确的加密结果，客户端解密后得到错误输出而不知情）。 | 数据机密性： 是——输入是加密的，所以计算方对其一无所知。模型隐私： 如果模型所有者在加密输入上进行计算，模型在他们那边是明文的（不受保护）。如果角色互换（客户端持有加密的模型，服务器进行计算），模型可以保持加密，但这种情况不太常见。有一些技术，如安全两方 ML，结合 FHE/MPC 来保护两者，但这超出了普通 FHE 的范畴。输出隐藏： 默认情况下，计算的输出是加密的（只有持有私钥的一方，通常是输入所有者，才能解密）。所以输出对计算服务器是隐藏的。如果我们希望输出公开，客户端可以解密并揭示它。 | 无需设置。每个用户生成自己的密钥对进行加密。信任依赖于密钥保持秘密。 | FHE 方案（例如 BFV, CKKS, TFHE）的安全性基于格问题（带误差学习），这些问题被认为是能抵抗量子攻击的（至少目前没有已知的有效量子算法） 。所以 FHE 通常被认为是后量子安全的。 |
表 1：zk-SNARK、zk-STARK 和 FHE 方法在机器学习推理中的比较（性能与隐私权衡）。
Web3 应用的用例与影响
通过 zkML 实现 AI 与区块链的融合，为 Web3 开启了强大的新应用模式：
-
去中心化自治代理与链上决策： 智能合约或 DAO 可以整合由 AI 驱动的决策，并保证其正确性。例如，想象一个 DAO 使用神经网络分析市场状况后执行交易。有了 zkML，DAO 的智能合约可以要求一个 zkSNARK 证明，证明_授权的 ML 模型_（具有已知的哈希承诺）在最新数据上运行并产生了推荐的操作，然后该操作才会被接受。这可以防止恶意行为者注入虚假的预测——区块链_验证了 AI 的计算_。随着时间的推移，甚至可能出现完全在链上的自治代理（查询链下 AI 或包含简化模型的合约），在 DeFi 或游戏中做出决策，其所有行动都通过 zk 证明被证明是正确且符合策略的。这提高了对自治代理的信任，因为它们的“思考”过程是透明且可验证的，而不是一个黑箱。
-
可验证计算市场： 像 Lagrange 这样的项目实际上正在创建可验证的计算市场——开发者可以将繁重的 ML 推理外包给一个证明者网络，并获得带有结果的证明。这类似于去中心化的云计算，但内置了信任：你不需要信任服务器，只需要信任证明。这是对预言机和链下计算的范式转变。像以太坊即将推出的 DSC（去中心化排序层）或预言机网络可以利用这一点来提供具有密码学保证的数据或分析源。例如，一个预言机可以提供“模型 X 在输入 Y 上的结果”，任何人都可以验证附加在链上的证明，而不是相信预言机的一面之词。这可以实现区块链上的_可验证 AI 即服务_：任何合约都可以请求一个计算（比如“用我的私有模型为这些信用风险打分”），并且只有在有有效证明的情况下才接受答案。像 Gensyn 这样的项目正在探索使用这些验证技术的去中心化训练和推理市场。
-
NFT 与游戏——来源与进化： 在区块链游戏或 NFT 收藏品中，zkML 可以证明特征或游戏动作是由合法的 AI 模型生成的。例如，一个游戏可能允许 AI 进化一个 NFT 宠物的属性。没有 ZK，聪明的用户可能会修改 AI 或结果以获得一个更优越的宠物。有了 zkML，游戏可以要求一个证明，证明_“宠物的新属性是由官方进化模型在宠物的旧属性上计算得出的”_，从而防止作弊。生成艺术 NFT 也是如此：艺术家可以发布一个生成模型作为承诺；之后，在铸造 NFT 时，证明每个图像都是由该模型在给定某个种子的情況下产生的，从而保证其真实性（甚至可以在不向公众透露确切模型的情况下做到这一点，保护艺术家的知识产权）。这种_来源验证_以一种类似于可验证随机性的方式确保了真实性——只不过在这里是可验证的创造力。
-
敏感领域的隐私保护 AI： zkML 允许在不暴露输入的情况下确认结果。在医疗保健领域，患者的数据可以由云提供商通过 AI 诊断模型运行；医院收到诊断结果和一个证明，证明_该模型（可能由一家制药公司私有持有）在患者数据上正确运行_。患者数据保持私密（在证明中只使用了加密或承诺的形式），模型权重保持专有——但结果是可信的 。监管机构或保险公司也可以验证是否只使用了经批准的模型。在金融领域，一家公司可以向审计师或监管机构证明，其风险模型已应用于其内部数据并产生了某些指标，而无需透露底层的敏感财务数据。这使得合规和监督能够通过密码学保证而不是手动信任来实现。
-
跨链与链下互操作性： 由于零知识证明本质上是可移植的，zkML 可以促进_跨链 AI_ 结果。一条链上可能有一个 AI 密集型应用在链下运行；它可以将结果的证明发布到另一条区块链上，后者将无需信任地接受它。例如，考虑一个多链 DAO 使用 AI 来聚合社交媒体上的情绪（链下数据）。AI 分析（对大量数据的复杂 NLP）在链下由一个服务完成，该服务然后向一个小区块链（或多个链）发布一个证明，证明_“分析已正确完成，输出的情绪评分为 0.85”_。所有链都可以验证并在其治理逻辑中使用该结果，而无需各自重新运行分析。这种可互操作的可验证计算正是 Lagrange 网络旨在支持的，通过同时服务于多个 rollup 或 L1。它消除了在链间移动结果时对可信桥梁或预言机假设的需求。
-
AI 对齐与治理： 从一个更具前瞻性的角度来看，zkML 被强调为_AI 治理与安全_的工具。例如，Lagrange 的愿景声明认为，随着 AI 系统变得越来越强大（甚至达到超级智能），密码学验证对于确保它们遵守既定规则至关重要。通过要求 AI 模型为其推理或约束生成证明，人类保留了一定程度的控制——“你无法信任你无法验证的东西”。虽然这还处于推测阶段，并且涉及社会和技术两方面，但该技术可以强制一个自主运行的 AI 代理仍然证明它正在使用一个经批准的模型并且没有被篡改。去中心化 AI 网络可能会使用链上证明来验证贡献（例如，一个协作训练模型的节点网络可以证明每个更新都是忠实计算的）。因此，zkML 可能在_确保 AI 系统即使在去中心化或不受控制的环境中也能对人类定义的协议负责_方面发挥作用。
总之，zkML 和可验证的链上 AI 代表了先进密码学和机器学习的融合，有望增强 AI 应用中的信任、透明度和隐私。通过比较主要方法——zk-SNARKs、zk-STARKs 和 FHE——我们看到了性能与隐私之间的一系列权衡，每种方法都适用于不同的场景。像 Ezkl 这样的基于 SNARK 的框架和像 Lagrange 的 DeepProve 这样的创新，使得用实际的努力证明重要的神经网络推理成为可能，为可验证 AI 的实际部署打开了大门。基于 STARK 和 VM 的方法承诺了更大的灵活性和后量子安全性，随着该领域的成熟，这将变得越来越重要。FHE 虽然不是可验证性的解决方案，但它解决了机密 ML 计算的互补需求，并且在与 ZKP 结合或在特定的私密环境中，它可以让用户在不牺牲数据隐私的情况下利用 AI。
对 Web3 的影响是显著的：我们可以预见智能合约对 AI 预测做出反应，并知道它们是正确的；计算市场中结果可以无需信任地出售；数字身份（如 Worldcoin 通过虹膜 AI 实现的个人身份证明）受到 zkML 的保护，以确认某人是人类而不泄露其生物特征图像；以及通常会出现一类新的_“可证明的智能”，丰富区块链应用。许多挑战依然存在——超大型模型的性能、开发者的人体工程学以及对专门硬件的需求——但发展轨迹是明确的。正如一份报告所指出的，“今天的 ZKP 可以支持小型模型，但中到大型模型打破了这一范式”_；然而，快速的进步（DeepProve 相较于先前技术实现了 50-150 倍的速度提升）正在将这一界限向外推进。随着正在进行的研究（例如，关于硬件加速和分布式证明），我们可以期待越来越大、越来越复杂的 AI 模型变得可证明。zkML 可能很快就会从利基演示演变为可信 AI 基础设施的重要组成部分，确保随着 AI 的普及，它能以一种可审计、去中心化且符合用户隐私和安全的方式实现。
