一、引言：当 ZK 从论文走进工程
零知识证明（Zero-Knowledge Proof, ZKP）在区块链领域的讨论热度，从 2021 年 Rollup 叙事兴起至今从未消退。但如果你真正动手写过一条基于 Groth16 的验证合约，或者尝试把一个 ERC-20 转账逻辑塞进 Circom 电路，就会发现理论论文和可生产代码之间隔着一条不小的鸿沟。
这篇文章不打算重复「什么是 ZK-SNARKs」「Plonk 和 Groth16 的区别」这类基础概念，而是聚焦在公链扩容场景下，ZK 技术从论文走向生产环境时遇到的真实瓶颈，以及过去两年社区和团队摸索出的突破路径。我会尽量用工程化的视角来讨论，配合可运行的代码片段和实测数据，希望能给正在调研或落地 ZK 扩容方案的同学一些参考。
二、瓶颈一：证明生成的计算开销
2.1 问题的规模
一个典型的 ZK-Rollup 区块，需要证明数千笔交易的执行正确性。以 zkSync Era 早期数据为例，单个区块的 witness 规模在几十 MB 量级，生成一个 Groth16 证明需要数分钟甚至更久。这个延迟直接决定了 Rollup 的最终确认时间，也影响了用户体验——用户发起一笔提现，可能要等十几分钟才能拿到 L1 的最终确认。
下表对比了不同证明系统在相同计算规模下的实测性能（基于 2024 年底社区公开 benchmark 数据整理）：
| 证明系统 | 电路规模（约束数） | 单证明生成时间 | 验证 Gas 成本 | 内存峰值 |
|---|---|---|---|---|
| Groth16 | 10M | ~180s | ~280k Gas | ~64 GB |
| Plonk（KZG） | 10M | ~240s | ~350k Gas | ~48 GB |
| Halo2 | 10M | ~300s | ~400k Gas | ~32 GB |
| STARK（FRI） | 10M | ~90s | ~1.2M Gas | ~16 GB |
可以看到，STARK 在生成速度上有明显优势，但验证成本高出数倍。Groth16 的验证成本最低，但需要可信设置，且证明生成的内存消耗极高。没有一种方案在所有维度上占优，这也是为什么主流 Rollup 团队往往采用混合策略。
2.2 硬件加速的实践
解决证明生成慢的最直接手段是硬件加速。2023 年以来，多家团队开始使用 GPU 和 FPGA 加速 MSM（多标量乘法）和 NTT（数论变换）这两个最耗时的计算步骤。下面是一个使用gnark
