Groth16 和 PLONK 有何区别？证明系统的初始化方式对比

一句话理解

Groth16 和 PLONK 是零知识证明里两个常被提起的名字。它们同属基于配对的证明体系，都能把一段计算压缩成很短的证明，但一个关键选择完全不同：Groth16 要为每个电路单独做一次可信初始化，电路一改就得重来；PLONK 用一份与电路无关的通用初始化字符串，换来了电路改动的灵活性。

初始化负担从哪里来

配对型 SNARK 需要一个“结构化参考字符串”：一组由秘密随机值生成的椭圆曲线点，证明者和验证者都用它工作。如果任何参与者完整知道那个秘密随机值，他就能凭空伪造通过验证的证明。常见的缓解方式是接力仪式：许多人依次向字符串加入自己的随机数再公布结果，只要其中任何一人诚实地毁掉了自己的秘密，整体就仍然安全。这个前提本身就是一种信任，也是“可信初始化”这个词的含义。真正的差异从这里展开：这份字符串是按电路生成的，还是一次生成、所有电路共用。

Groth16：为电路定制的紧凑证明

Groth 在 2016 年的论文提出的构造，把一次计算需要满足的关系硬编码进电路，初始化随之与该电路绑定。换来的是极简的证明：证明由常数个群元素组成，验证只需少数几次配对运算。因为证明短、上链验证便宜，它长期被 zk Rollup 和隐私项目选用。代价同样明确：电路规模决定仪式规模，逻辑改动就要重新做一遍；早期一些项目的仪式组织不够透明，也让它背着“信任假设”的名声。

PLONK：把仪式和电路解耦

PLONK 在 2019 年的论文里用拉格朗日基上的置换论证来编码计算关系，把电路细节从初始化里剥离出来：同一份通用字符串可以被任意多个电路复用，还能通过后续参与者只更新一部分的方式“可更新”。对需要频繁迭代电路或支持用户自定义程序的团队，这省掉了反复举办公开仪式的负担。天下没有白得的午餐，通用性换来的是证明者端更高的常数开销和更长的证明，一些追求极致证明体积的场景仍会回头选 Groth16 一类每电路方案。把两条路线放回同一条时间线更直观：2016 年的 Groth16 回答了“证明能不能短到极致”，答案是三个群元素；2019 年的 PLONK 回答了“电路能不能像改代码一样迭代”，代价是证明变长、证明者更重。两者都不是终点——之后出现的STARK一类方案干脆完全免掉了初始化字符串，但验证开销与 Groth 系路线继续各自演化，现实里很多 Rollup 的证明层是混合架构，外层与内层用不同的构造，比较时不能只认一个名字。

两种路线怎么影响你

作为用户，你几乎不会直接接触证明系统，但选择判断素材时可以问三个问题：项目用的是哪类构造，官方文档通常写得出来；初始化字符串怎么产生的，有没有公开仪式、可更新机制或完全不依赖信任的设置；电路改过之后，旧字符串与审计是否还覆盖新电路。“通用初始化”不等于零信任，它只是将信任从每电路仪式转移为“字符串本身诚实生成、且你使用的版本正确”这一条，仍值得核对审计与版本出处。

一个思想实验

想象两个团队都要证明“我知道某个哈希的原像”。A 团队选 Groth16：写死电路、办一次仪式、生成参数、上线；三个月后想把哈希函数换一种，电路重画，仪式重办，整套流程再来一遍。B 团队选通用初始化的路线：字符串早已就绪，改电路只是编译器新一次输出，证明者重新生成密钥参数即可开工。两种节奏的差别不在数学难度，而在工程节拍。读项目资料时，看它的仪式记录、参数版本与电路改动能不能对上号，比看宣传页里的名词更能说明问题。

风险边界

证明系统的安全性只覆盖“计算被正确执行”这一段，代码漏洞、预言机数据、密钥管理和合约升级权限都不在证明保护范围内。两条路线各有取舍，不存在谁绝对领先。本文只作机制说明，不构成投资建议。