一、引言：当 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 成本内存峰值Groth1610M~180s~280k Gas~64 GBPlonk（KZG）10M~240s~350k Gas~48 GBHalo210M~300s~400k Gas~32 GBSTARK（FRI）10M~90s~1.2M Gas~16 GB可以看到，STARK 在生成速度上有明显优势，但验证成本高出数倍。Groth16 的验证成本最低，但需要可信设置，且证明生成的内存消耗极高。没有一种方案在所有维度上占优，这也是为什么主流 Rollup 团队往往采用混合策略。2.2 硬件加速的实践解决证明生成慢的最直接手段是硬件加速。2023 年以来，多家团队开始使用 GPU 和 FPGA 加速 MSM（多标量乘法）和 NTT（数论变换）这两个最耗时的计算步骤。下面是一个使用gnark
