1985年，三位MIT的研究者Shafi Goldwasser、Silvio Micali和Charles Rackoff向STOC会议提交了一篇论文。这篇题为《The Knowledge Complexity of Interactive Proof Systems》的论文提出了一个看似矛盾的问题：一个人能否在不泄露任何信息的情况下，让别人相信他确实知道某个秘密？
这个问题的答案不仅开创了一个全新的密码学领域，更在四十年后成为支撑数千亿美元区块链生态的核心技术。
三个看似不可能同时满足的性质
零知识证明需要同时满足三个性质：完整性（Completeness）——诚实的证明者总能让验证者接受；可靠性（Soundness）——作弊的证明者几乎不可能成功；零知识性（Zero-knowledge）——验证者除了知道"命题为真"之外，学不到任何其他信息。
这三者之间存在深刻的张力。要保证可靠性，验证者似乎必须深入检验证明者的秘密；要保证零知识性，验证者又必须对秘密一无所知。如何在不看的同时确认看见了什么？这个悖论困扰了密码学界多年。
GMR论文的突破性在于引入了交互的概念。证明者不直接展示秘密，而是与验证者进行多轮问答。验证者提出随机挑战，证明者必须正确响应。只要证明者真的知道秘密，就能应对所有挑战；如果证明者在作弊，总有一天会被某个挑战难住。
Schnorr协议：最优雅的零知识证明
1991年，Claus-Peter Schnorr提出了一个简洁的协议，至今仍是理解零知识证明的最佳入门案例。
假设Alice想向Bob证明她知道某个离散对数的值x，满足h = g^x，但不想泄露x本身。协议的流程如下：
- 承诺阶段：Alice选择一个随机数r，计算u = g^r，将u发送给Bob
- 挑战阶段：Bob随机选择一个挑战值c发送给Alice
- 响应阶段：Alice计算z = r + x·c，将z发送给Bob
- 验证阶段：Bob检验g^z 是否等于 u · h^c
这个协议的精妙之处在于：如果Alice真的知道x，她总能正确计算z；如果Alice不知道x，她最多只能猜对一轮挑战，连续猜对的概率随着轮数增加而指数下降。而Bob在验证过程中，除了确认Alice确实知道x之外，对x本身一无所知——因为r是随机的，z也是随机的，不泄露任何关于x的信息。
sequenceDiagram
participant Alice as 证明者
participant Bob as 验证者
Alice->>Alice: 选择随机数r
Alice->>Bob: 发送承诺 u = g^r
Bob->>Bob: 选择随机挑战c
Bob->>Alice: 发送挑战c
Alice->>Alice: 计算响应 z = r + x·c
Alice->>Bob: 发送响应z
Bob->>Bob: 验证 g^z = u·h^c
但Schnorr协议有一个致命缺陷：它需要交互。在互联网时代，让证明者和验证者同时在线进行多轮通信是不现实的。更重要的是，一个证明只能对一个验证者有效——如果Alice想向多个验证者证明，每个验证者都需要独立进行一轮协议。
Fiat-Shamir变换：用哈希替代验证者
1987年，Amos Fiat和Adi Shamir提出了一个天才的想法：用密码学哈希函数替代验证者的角色。
验证者做的事情本质上只有一个：产生随机挑战。既然哈希函数的输出在密码学意义上是"随机"的，为什么不让证明者自己计算挑战呢？具体做法是：证明者将承诺值u代入哈希函数，用哈希输出作为挑战值c。
c = Hash(g, h, u)
这个简单的变换将交互式协议转化为非交互式协议。证明者可以一次性生成整个证明，验证者只需检验哈希值是否正确即可。一个证明可以被任意多个验证者验证，而且可以公开发布。
Fiat-Shamir变换成为现代零知识证明的基石，但也埋下了安全隐患。2022年，Trail of Bits安全团队披露了一系列被命名为Frozen Heart的漏洞，影响了包括SnarkJS、gnark在内的多个主流实现。这些漏洞的共同点是：Fiat-Shamir变换的实现没有将所有公开参数纳入哈希计算。攻击者可以利用这个遗漏，构造出能够通过验证的虚假证明。
从交互式到可验证计算
Fiat-Shamir变换解决了交互问题，但零知识证明真正的大规模应用还要等到2010年代。核心障碍在于：如何证明一般的计算，而不仅仅是证明知道某个离散对数？
答案在于将计算转化为约束系统。任何计算都可以表示为一个算术电路，进而转化为R1CS（Rank-1 Constraint System）——一组形如(a·b = c)的二次约束方程。更进一步，R1CS可以转化为QAP（Quadratic Arithmetic Program）——一种多项式形式，使得验证计算等价于验证多项式在某个点的取值。
这听起来很抽象，但关键洞察是：如果证明者声称多项式p(x)在某个秘密点τ处的取值是v，验证者不需要知道τ，只需要一个对这个多项式的"承诺"。这就是多项式承诺的用武之地。
KZG承诺：用椭圆曲线封装多项式
2010年，Kate、Zaverucha和Goldberg提出了KZG多项式承诺方案，成为现代SNARK系统的核心组件。
假设有一个多项式p(x) = a₀ + a₁x + a₂x² + … + aₙxⁿ。在可信设置阶段，系统生成一组椭圆曲线点：
[g¹, g^(τ²), g^(τ³), …, g^(τⁿ)]
其中τ是一个秘密值，生成后必须销毁——这就是著名的"toxic waste"。证明者可以计算承诺：
C = g^(p(τ)) = g^(a₀ + a₁τ + a₂τ² + …)
由于椭圆曲线的离散对数困难性，知道C无法反推出p(x)的系数。但证明者可以证明p(x)在某个公开点z处的取值确实是v。验证者只需要检验一个配对方程：
e(C - g^v, g) = e(π, g^(τ-z))
其中π是证明者提供的见证。这个验证的计算量与多项式次数无关，始终是常数时间！
KZG承诺的惊人之处在于：无论多项式有多复杂（百万次、千万次），承诺和证明的大小始终是一个椭圆曲线点（约48字节），验证时间始终是两次配对运算。这是零知识证明能够实用的数学基础。
Groth16：最小证明的黄金标准
2016年，Jens Groth发表了论文《On the Size of Pairing-based Non-interactive Arguments》，提出了以他名字命名的Groth16证明系统。这个系统至今仍是证明大小和验证速度的标杆。
Groth16的证明仅包含三个椭圆曲线群元素，总大小约192-288字节（取决于椭圆曲线选择）。验证只需要三次配对运算和若干群运算，耗时约10毫秒。这在区块链场景下极具吸引力——一个证明可以被永久存储在链上，验证成本极低。
但Groth16有一个重大缺陷：每个电路都需要独立的可信设置。如果你想证明"我知道一个满足条件X的秘密"，就需要为X生成一套参数；如果你想证明"我知道一个满足条件Y的秘密"，又需要为Y生成另一套参数。可信设置不仅繁琐，还存在安全风险——如果设置过程的参与者串通保留toxic waste，他们就可以伪造证明。
Zcash在2016年启动时进行了一场著名的可信设置仪式。六位参与者分别在各自的隔离环境中生成参数碎片，仪式完成后销毁所有设备。只要至少一位参与者诚实销毁了自己的碎片，整个系统就是安全的。但这种"信任少数人"的模式，与区块链"无需信任"的哲学存在根本冲突。
PLONK：通用设置的新范式
2019年，PLONK证明系统横空出世，解决了Groth16的最大痛点。PLONK引入了通用和可更新的可信设置——一套参数可以用于证明任意电路，而且任何人都可以添加新的随机性来更新参数，使之前的参与者无法再串通伪造证明。
PLONK还引入了Plonkish算术化方案，允许为特定操作设计自定义门，大幅提升效率。例如，椭圆曲线点乘可以设计专门的门，而不需要拆解成数百个基础门。
PLONK的核心是permutation argument——一种证明多个位置值相等的方法。这通过"grand product check"实现：将所有需要证明相等的位置排列成一个向量，证明这个向量的grand product（所有元素的乘积）等于某个公开值。
PLONK的成功催生了大量衍生系统：Aztec的Barretenberg、zkSync的Boojum、Polygon的Plonky2、Scroll的证明系统等。它们共享Plonkish算术化的核心思想，但在多项式承诺、哈希函数、递归验证等方面各有创新。
STARK：透明与量子抵抗的另一条路
当SNARK阵营在椭圆曲线上精雕细琢时，另一种思路正在悄然崛起。2018年，Eli Ben-Sasson等人提出了STARK（Scalable Transparent ARguments of Knowledge），完全抛弃椭圆曲线和可信设置，改用哈希函数作为唯一密码学假设。
STARK的核心是FRI协议（Fast Reed-Solomon Interactive Oracle Proof of Proximity）。它不依赖椭圆曲线配对，而是通过反复折叠多项式来证明其低次性质。每次折叠都将多项式的次数减半，最终得到一个可以直接验证的低次多项式。
STARK的优势显而易见：
- 透明设置：不需要任何可信设置，不存在toxic waste
- 量子抵抗：哈希函数被认为在量子计算机面前更安全
- 证明生成快：对大规模计算，STARK的证明生成往往比SNARK更快
代价是证明大小。STARK证明的大小是O(log²n)，其中n是电路规模。对于典型的区块链交易，证明大小在45-200KB之间，是Groth16证明的数百倍。这在以太坊上意味着更高的gas成本。
| 特性 | zk-SNARK | zk-STARK |
|---|---|---|
| 证明大小 | ~288字节（常数） | ~100-200KB（对数级） |
| 验证时间 | ~10ms | ~100ms |
| 可信设置 | 需要 | 不需要 |
| 密码学假设 | 椭圆曲线离散对数 + 知识假设 | 抗碰撞哈希函数 |
| 量子抵抗 | 否 | 是 |
| 大规模证明生成 | 较慢 | 较快 |
实际应用中，两种技术正在走向融合。许多系统采用混合方案：用STARK生成大规模计算的证明，再用SNARK将STARK证明压缩成紧凑形式提交到链上。
zkRollup：区块链扩容的核心武器
零知识证明最成功的应用场景是区块链扩容。以太坊每秒只能处理约15笔交易，而Visa每秒处理数万笔。这个性能差距被称为"不可能三角"——去中心化、安全、可扩展三者不可兼得。
zkRollup提供了打破不可能三角的方案。核心思想是：将大量交易在链下执行，生成一个简洁的有效性证明，将证明和压缩后的状态数据提交到链上。链上验证者只需要验证证明，而不需要重新执行每笔交易。
一个zkRollup批次可能包含数千笔交易，但链上只需要存储一个约300字节的SNARK证明和几十KB的状态数据。验证时间约10毫秒，无论批次包含多少交易。理论上，zkRollup可以将以太坊吞吐量提升到每秒数千笔交易。
但zkRollup面临一个工程挑战：如何证明EVM（以太坊虚拟机）的执行？EVM是一个复杂的状态机，包含数百个操作码、几十个预编译合约、复杂的gas计算逻辑。证明EVM执行意味着将整个EVM规范转化为电路。
zkEVM：兼容性与效率的艰难抉择
2022年，Vitalik Buterin提出了zkEVM的分类框架，揭示了兼容性与效率之间的权衡。
Type 1（完全以太坊等价）：不修改任何以太坊规范，直接证明现有以太坊区块。这是最理想的兼容性，但证明一个区块需要数小时。
Type 2（EVM等价）：保持EVM语义不变，但可以修改状态树、区块结构等外围组件。例如，用Poseidon哈希替代Keccak。证明时间大幅缩短，但仍需数十分钟。
Type 3（几乎EVM等价）：移除一些难以证明的预编译合约，对内存和栈处理做小幅修改。Scroll和Polygon的当前版本属于这一类。
Type 4（高级语言等价）：直接从Solidity编译到ZK友好的虚拟机，跳过EVM字节码。zkSync采用这种方案。证明速度最快，但与现有以太坊工具链存在兼容性问题。
这个分类揭示了一个深层洞察：以太坊原本不是为ZK证明设计的。Keccak哈希函数对ZK证明极不友好，需要约200,000个约束才能证明一次哈希计算。而ZK友好的哈希函数如Poseidon只需要几百个约束。
图片来源: vitalik.eth.limo
安全的阴影：Frozen Heart与信任危机
2022年4月，Trail of Bits安全团队披露了一系列影响多个ZKP实现的漏洞，统称为Frozen Heart。这个名字是"Forging Of Zero Knowledge proofs"的首字母缩写。
漏洞根源是Fiat-Shamir变换的不正确实现。在PLONK协议中，挑战值zeta应该通过对所有公开参数（包括电路描述、公开输入、之前的承诺值）进行哈希计算得出。但多个实现忽略了公开输入：
zeta = Hash(transcript) // 正确做法 zeta = Hash(commitments) // 错误做法
这个看似微小的遗漏让攻击者可以构造恶意输入，使验证者接受虚假证明。问题的严重性在于：这是实现层面的漏洞，而非协议本身的缺陷。即使论文描述正确，实现者仍可能犯错。
Frozen Heart漏洞影响了SnarkJS（Iden3）、gnark（ConsenSys）、plonk（Dusk Network）等多个主流库。这些库在漏洞披露后迅速发布修复版本，但有多少使用这些库的应用及时更新，仍是未知数。
更广泛地看，零知识证明系统是密码学中最复杂的工程之一。一个典型的证明系统包含数千行高度优化的代码，涉及椭圆曲线运算、多项式运算、随机数生成等多个安全敏感模块。任何一处的实现错误都可能导致灾难性后果。
性能的边界：证明生成的代价
零知识证明的实用性最终取决于性能。以下是一些来自生产环境的基准数据：
Groth16（使用rapidsnark）：
- 证明生成：约2.3秒（百万约束）
- 证明大小：~288字节
- 验证时间：~10毫秒
PLONK（使用Halo2）：
- 证明生成：约5-10秒（百万约束）
- 证明大小：~1-2KB
- 验证时间：~50毫秒
STARK（使用Winterfell）：
- 证明生成：约1.6秒（百万约束）
- 证明大小：~100KB
- 验证时间：~100毫秒
证明生成是主要瓶颈。对于复杂的zkEVM电路（数千万约束），证明生成可能需要数分钟甚至更长。这意味着用户发起交易后，需要等待较长时间才能看到交易被确认。
硬件加速正在改变这一局面。GPU可以将证明生成速度提升5-10倍，FPGA和ASIC则有更大的潜力。2024年的研究表明，专用硬件可以将证明生成压缩到秒级。
递归证明是另一个重要优化方向。核心思想是：将一个大证明分解为多个小证明，每个小证明由不同的机器并行生成，最后用一个聚合证明将它们合并。这种方法可以将证明生成时间从线性降低到对数级。
市场与生态：从理论到产业
零知识证明已从学术研究演变为一个蓬勃的产业。根据Grand View Research的数据，全球零知识证明市场规模在2024年约为12.8亿美元，预计到2033年将达到75.9亿美元，年复合增长率约22%。
在区块链领域，zkRollup已成为主流扩容方案：
- zkSync Era：每月处理超过1000万笔交易，费用比以太坊主网低10-50倍
- StarkNet：采用STARK技术，TVL（总锁仓价值）超过十亿美元
- Polygon zkEVM：基于PLONK，已部署数百个DeFi应用
- Scroll：Type 2 zkEVM，正在向Type 1演进
在隐私保护领域：
- Zcash：首个大规模应用zk-SNARK的隐私币，已从Sprout升级到Sapling再到Orchard
- Tornado Cash：使用zk-SNARK实现链上隐私交易（虽然其开发者已被美国司法部起诉）
- Aztec Network：隐私Layer2，允许在保持隐私的同时与DeFi交互
在身份验证领域，零知识证明正在革新传统的KYC流程。用户可以证明自己满足某些条件（如年龄超过18岁、在白名单国家）而不暴露具体身份信息。
未竟的征程
四十年过去，零知识证明从理论雏形发展为支撑数千亿美元生态的技术基础。但挑战依然存在：
证明生成速度：对于复杂的智能合约，证明生成仍是分钟级的延迟。用户习惯了秒级响应，证明延迟成为zkRollup广泛采用的障碍。
开发工具成熟度：编写ZK电路仍是一门专业技能。与普通编程相比，ZK开发需要理解约束系统、算术化、多项式承诺等深奥概念。
安全审计难度：ZKP协议的安全审计比传统软件审计困难得多。Frozen Heart漏洞表明，即使是顶级团队也可能犯错。
标准化缺失：目前存在数十种不同的证明系统，互操作性差。一个证明系统生成的证明无法被另一个系统验证。
未来几年，我们可能看到以下趋势：
证明系统的收敛：多种技术路线可能融合，形成少数几个主流方案。例如，用STARK生成证明、用SNARK压缩证明的混合方案。
硬件加速普及：专用芯片可能成为验证节点标配，使证明生成从分钟级压缩到秒级。
开发者工具平民化：更好的编译器和调试器将降低ZK开发的门槛，使其成为普通开发者可以掌握的技能。
应用场景扩展：除区块链外，零知识证明可能在隐私AI、可验证计算、安全多方计算等领域找到新的应用。
零知识证明的故事提醒我们：深刻的技术创新往往需要数十年才能成熟。1985年的GMR论文提出的是一个数学概念，而今天，这个概念正在重塑数字世界的信任基础设施。证明而不揭示——这个悖论式的目标，已经成为可能。
参考资料
- Goldwasser, S., Micali, S., & Rackoff, C. (1985). The knowledge complexity of interactive proof-systems. SIAM Journal on Computing.
- Schnorr, C. P. (1991). Efficient signature generation by smart cards. Journal of Cryptology.
- Kate, A., Zaverucha, G. M., & Goldberg, I. (2010). Constant-size commitments to polynomials and their applications. ASIACRYPT.
- Groth, J. (2016). On the size of pairing-based non-interactive arguments. EUROCRYPT.
- Gabizon, A., Williamson, H., & Ciobotaru, O. (2019). PLONK: Permutations over Lagrange-bases for Oecumenical Noninteractive arguments of Knowledge. IACR Cryptology ePrint Archive.
- Ben-Sasson, E., et al. (2018). Scalable, transparent, and post-quantum secure computational integrity. IACR Cryptology ePrint Archive.
- Trail of Bits. (2022). The Frozen Heart vulnerability in PlonK. Trail of Bits Blog.
- Buterin, V. (2022). The different types of ZK-EVMs. Vitalik’s Blog.
- Dankrad Feist. (2020). KZG polynomial commitments. Dankrad Feist’s Blog.
- LambdaClass. (2024). Our highly subjective view on the history of Zero-Knowledge Proofs. LambdaClass Blog.
- ZKDocs. Schnorr’s identification protocol. ZKDocs.
- ConsenSys. (2021). Zero-Knowledge Proofs: STARKs vs SNARKs. ConsenSys Blog.
- Garima Singh. ZK-SNARKs vs. ZK-STARKs: A Detailed Cryptographic Comparison.
- Grand View Research. (2024). Zero Knowledge Proof Market Size Report.