当前位置：首页 > news >正文

ICICLE-Snark：目前最快的 Groth16 实现

news 2025/9/28 11:35:19

1. 引言

零知识证明（Zero-Knowledge Proofs）近年来迅速发展，其中 Groth16 已成为最广泛使用的证明系统之一，具有许多非常适合区块链应用的特点：

验证继续3次 pairing 运算，使Groth16成为验证速度非常快的 ZK 证明。
Groth16 生成的证明是固定大小，仅3个群元素，这比其它证明系统在链上存储和交易成本上更节省。
虽然Groth16 证明者（prover）端计算量很大，但通过硬件加速可以显著加快，使 Groth16 在高吞吐量应用中也可行。

Groth16 最大的权衡是每个电路（circuit）都需要可信设置（trusted setup）。尽管这是一个缺点，但Groth16的以上特点，使其成为区块链及其它以外用途的理想选择 —— 单个证明就能证明复杂计算的正确性而不暴露输入，任何人只需3次 pairing 就能验证。

2. Groth16 工作原理

生成一个 Groth16 证明需要在大的素域（prime field）和椭圆曲线群上执行大量算术运算。本文不深入 QAP（Quadratic Arithmetic Programs）和 R1CS（Rank-1 Constraint Systems）。

可以把Groth16证明者阶段分成两步：

计算商多项式（quotient）
和生成证明。

在这些步骤中，会包含：

3 个 IFFT（反快速傅里叶变换），
3 个 FFT（快速傅里叶变换），
以及 5 个 MSM（多标量乘法，多标量乘法是指多个标量与群元素的结合操作）。
除此之外，还有element-wise 按元素乘法和减法等操作。

MSM 和 NTT／FFT 这两大原语掌控了Groth16 证明过程的大部分时间。

MSM（Multi-Scalar Multiplication）与基于快速傅里叶变换的多项式求值（FFT／NTT）是最主要的瓶颈。MSM 大约占证明时间的 ~60%，FFT 大约占 ~30%。

Groth16 证明者需要两个文件：witness 文件与 zkey 文件。

witness 文件包含给定输入根据电路产生的中间值，包括公开与私密输入。对每个输入都是独一无二的。
zkey 文件则包含电路、可信设置、证明与验证密钥等，是在可信设置阶段生成的，对每个电路唯一。

3. 现有 Groth16 实现的状况

目前已有很多 Groth16 的实现，常见的包括：

SnarkJS（https://github.com/iden3/snarkjs（JavaScript）） — 易用、访问性好，也提供了3种zkSNARKs证明系统，以及用于设置与验证的工具。
Rapidsnark（https://github.com/iden3/rapidsnark（C++ 和汇编）） — 用 C++ 和汇编写成，比 SnarkJS 快约 4 到 10 倍。
Arkworks（http://github.com/arkworks-rs/groth16（Rust））
Lambdaworks（https://github.com/lambdaclass/lambdaworks/tree/main/crates/provers/groth16（Rust））
Gnark（https://github.com/Consensys/gnark（Go））

4. 用 ICICLE 突破 Groth16 速度障碍

ICICLE 是一个前沿的密码学库（ICICLE-snark（https://github.com/ingonyama-zk/icicle-snark（C++和Rust））），旨在加速诸如 ZKP（零知识证明）等高级算法与协议，在多种计算后端（包括 GPU、CPU、Metal 等）上运行。它支持 C++、Rust、Go 多种前端，使得在不同开发环境中集成更加容易。只用一个代码库，就能利用三种流行语言和多个硬件平台。

4.1 ICICLE 加速 Groth16

起初Ingonyama团队只计划把 MSM 和 NTT 部分集成进 ICICLE，但由于数据传输与类型转换的问题，性能并没有达到预期。最终的解决方案是从头构建一个 Groth16 的 prover，该 prover 使用 ICICLE 实现。参考代码库是（iden3 团队的）SnarkJS（https://github.com/iden3/snarkjs（JavaScript））。这样可以允许所构造的 prover 使用现有的 zkey 文件。任何人都可以从 SnarkJS 或 Rapidsnark 切换到 ICICLE-snark（https://github.com/ingonyama-zk/icicle-snark（C++和Rust））。

ICICLE 已经对第2节“Groth16 工作原理” 中提到的那些原语（MSM, FFT／NTT 等）做了高度优化。

另一个现有工具的问题在于，它们被设计为命令行工具（CLI）使用。
这意味着如果要多次为同一个电路生成证明，那么其实有许多数据是可以缓存并复用的，如：

证明密钥（proving key）
基（bases）
和 NTT 域（NTT domain）。

为了利用这种缓存技巧，Ingonyama团将其Groth16 prover 开发成了一个后台工作进程和 Rust 库。

4.2 ICICLE 中的数据转换与数据传输

将代码迁移到 GPU 时，最大的问题之一是数据传输和数据类型转换。要能使用 ICICLE 并利用 CUDA，需要将数据转换为 ICICLE 的类型并移动到device端。通常为 CUDA kernel 准备数据的时间会比 kernel 本身执行时间还要长。

类型转换（conversion）如果用 naïve 的方式（如多次调用 from 函数）会非常慢。在 Rust 中，如果可以保证安全，可以使用 transmute 直接改动已有内存的类型，这样几乎可以完全加速——transmute 调用只花费约 20–30 纳秒，而 naive 转换可能花费约 100 毫秒。
数据传输速度受限于硬件。因此如果可能，应尽量避免将数据在host与device之间频繁移动。这是为什么团队选择从头构造 Groth16 prover 而不是仅替换部分 MSM／NTT 调用。

4.3 ICICLE 中的 MSM 与 NTT 优化

ICICLE 中的 MSM 与 NTT 优化有：

替换5个 MSM 所用的实现为 ICICLE 的 MSM，在规模为 $2^{22}$ 的情况下平均提升约 63倍。
同样替换 3 个 IFFT + 3 个 FFT 为 ICICLE 的 FFT API，在规模为 $2^{22}$ 的情况下平均提升约 320倍。

4.4 ICICLE 中的VecOps（向量运算）优化

ICICLE 中的VecOps（向量运算）优化：

有很多地方需要对长向量做element-wise按元素的乘法与减法。这类操作在 GPU 上高度并行化。
- 使用 ICICLE 的 VecOps API 而不是在 CPU 上处理这些长数组，平均提升约 200倍（在规模 $2^{22}$ 时）。

在这里插入图片描述

4.5 ICICLE 中的缓存机制（Cache）优化

在许多应用场景中（如证明服务或 Layer-2 rollups），可能会对同一个电路和证明密钥（proving key）做多个证明。

ICICLE 利用这一点，把与 zkey 文件相关的计算保留在设备内存中，并缓存这些计算结果。称为 CacheManager。如果某次已经针对某个 zkey 文件算过某些值，下次用到就可以重用，不必重新计算。

在这里插入图片描述

5. 性能基准与实验结果

在以下两种设置上进行了基准测试：

使用 4080 GPU + Intel i9-13900K CPU
使用 4090 GPU + Ryzen 9 9950X CPU

用 MoPro（https://github.com/zkmopro/benchmark-app/tree/main/mopro-core/examples/circom）基准里的电路来对比不同证明系统的性能。测试包括：

“复杂电路”：用于纯粹基准测试，以便对比约束数量多寡与性能差异。
Anon Aadhaar：一个零知识协议，允许 Aadhaar 身份所有者在不暴露其身份信息的情况下证明身份。
Aptos Keyless：Aptos Keyless 让用户无需密钥或助记词，而使用诸如 OIDC 凭证（Google, Apple 等）来创建账户。

如前所述，在生产环境中，一个项目更有可能重复证明相同的电路。
为了利用这一点，ICICLE使用了缓存系统（Cache system）。
然而，由于所对比的其他工具都是命令行工具（CLI），因此在一次证明完成后就会退出。
为了保持公平，同时提供了启用缓存和不启用缓存两种基准测试结果。
在这里插入图片描述

6. 如何集成 ICICLE

可将 ICICLE-snark 集成到自身项目的代码库里。根据使用的语言有两种方式：

在 Rust 项目中使用
在其他编程语言中使用

6.1 在 Rust 项目中使用 ICICLE

如果自身项目代码库是用 Rust 编写的，那么最佳实践是将ICICLE Groth16 prover作为 Rust Crate 使用。
只需要通过执行：

cargo add ICICLE-snark

将其添加到依赖中。

之后，就可以导入证明函数，并创建一个 CacheManager 实例，然后通过提供 witness 文件和 zkey 文件的路径来开始证明。

use icicle_snark::{groth16_prove, CacheManager};fn main() {let mut cache_manager = CacheManager::default();let witness = "witness.wtns";let zkey = "circuit_final.zkey";let proof = "proof.json";let public = "public.json";let device = "CUDA"; // 若需可以替换为 CPU 或 METALgroth16_prove(&witness,&zkey,&proof,&public,device,&mut cache_manager).unwrap();
}