3.3 SNARK 家族与选型：四张面孔对账

3.3 SNARK 家族与选型：四张面孔对账

本节摘要：SNARK（简洁非交互式知识论证）把证明压到几百字节、验证压到毫秒级，代价体系因方案而异。本节走完 Groth16、Plonk、Halo2、Bulletproofs 四个代表方案的技术分野，给出一张多维对比矩阵与一段选型对账演算，并回答"可信设置焦虑"到底该多焦虑。承接 3.2 的非交互化，通往 3.4 的 STARK。

同一家族的四种性格

所有 SNARK 共享一条流水线：把计算编译成算术电路（4.4 节），把电路正确性翻译成多项式关系（4.3 节），再对多项式做承诺与抽查。分野发生在最后一步——用哪种承诺工具、要哪种信任、付出哪种成本。四个代表方案恰好构成四种工程性格。

Groth16：极简主义者。2016 年提出，至今保持证明体积的最小纪录——两百字节上下，验证只需三三次配对运算，上链成本是全家最低。它对" circuit 专属设置"的依赖也最彻底：每份电路都要办一场专属仪式，业务逻辑改一行，仪式推倒重来。适合电路长期稳定、上链验证成本敏感的场景（典型如老牌隐私资产项目），不适合迭代快的业务。

Plonk：通用设置派。2019 年前后与 Sonic、Marlin 一道引入"通用且可升级的设置"：办一次仪式，所有电路共用，后续升级还能在旧仪式参数上叠加。多项式承诺用 KZG 方案，配合自定义门与查找表，对复杂业务逻辑的表达力明显增强。证明比 Groth16 大几倍，验证成本略高，换来的是工程迭代自由——今天多数新项目的默认起点。

Halo2：免设置与递归派。用内积论证（或其变体）彻底取消仪式，且原生支持递归——证明里可以塞进另一份证明的验证，层层套娃把海量工作压成一份证明。代价是证明器更重、实现门槛更高。零现金的 orchard、若干 ZK 虚拟机方案都基于它，"证明链"类应用几乎绕不开。

Bulletproofs：细分场景专家。不依赖仪式，用 Pedersen 承诺加内积论证，证明尺寸对数级。它的软肋在验证：成本与电路规模线性挂钩，大电路直接出局；但在范围证明（证明金额落在合法区间而不披露金额）这个细分里，尺寸、验证、实现难度三者平衡极好，曾长期是隐私支付链的主力。

图：四个方案的多维对比矩阵

选型对账：把感觉换成算术

选型争论常有，但多数争论可以先用一段算术收窄。证明大小决定存储与传输成本，验证开销决定上链 gas，仪式成本决定合规审查难度——三项都可控、可算。跑一个对账脚本，把四个方案的量级差异变成具体数字：

# 选型对账演算：同一业务（10 万门电路）在四个方案下的成本量级
# 量级系数为教学用示意值，工程决策请以所用实现的实测基准替换
circuit_gates = 100_000
plans = {
    #            证明字节  验证耗时量级(ms)  需要仪式  仪式是否通用
    "Groth16":    (200,     1.0,              True,     False),
    "Plonk":      (900,     2.0,              True,     True),
    "Halo2":      (3_000,   3.0,              False,    None),
    "Bulletproofs": (700,   circuit_gates / 1000 * 1.5,  False, None),  # 验证线性于电路
}
print(f"{'方案':<14}{'证明KB':>8}{'验证ms':>10}{'仪式负担':>12}")
for name, (size, vms, setup, universal) in plans.items():
    burden = "无" if not setup else ("通用一次" if universal else "每电路一场")
    print(f"{name:<14}{size/1024:>8.2f}{vms:>10.1f}{burden:>12}")
# 典型输出形态：
# Groth16        0.20      1.0     每电路一场
# Plonk          0.88      2.0       通用一次
# Halo2          2.93      3.0          无
# Bulletproofs   0.68    150.0          无
# 结论方向：上链验证敏感选 Groth16；业务常变选 Plonk；
# 要递归或回避仪式选 Halo2；只有范围证明类小电路才轮到 Bulletproofs
​

数字一出来，很多争论会自动熄火：Bulletproofs 在十万门电路上验证要一百多毫秒，拿去做高频链上验证等于自残；Groth16 的仪式在电路稳定的项目里是一次性成本，焦虑价值有限。仪式焦虑的正确消化方式不是一味回避，而是看三件事：仪式参与方是否足够多且相互独立（破坏至少一方才能作恶）、参数生成是否有公开的可验证过程、电路变更频率是否高到需要通用仪式。

过渡：另一条路不办仪式

把 Bulletproofs 与 Halo2 的"免仪式"推到极致，就是 STARK：不仅不办仪式，连椭圆曲线都不要，全靠哈希函数撑起安全。它的证明更大，但换来的东西在特定场景无可替代——下一节进它的发动机舱看看。

选型访谈：把五个问题问到底

把选型会议里最常见的含糊其辞，换成五个必须答死的问题。一问电路变更频率：季度级变更，仪式成本重于一切，Plonk 系与免仪式方案优先；年度级变更，Groth16 的一次性仪式完全可接受。二问验证发生在哪：只在链上，配对方案的验证成本优势是决定性的；大量验证发生在链下（客户端、服务端），Halo2 与 FRI 路线的免仪式优势开始主导。三问证明生成在谁的机器上：用户端设备（手机、浏览器）生成，证明器体积与内存是硬约束，方案候选立刻收窄；自有集群生成，则吞吐与运维成本说了算。四问合规怎么写：监管或客户合同若要求"无可信第三方参与生成参数"，配对仪式路线直接出局，别等到法务环节才发现。五问团队语言栈：电路 DSL 与团队主语言差距越小，长期维护成本越低——这问题不体面，但真实。

五问答完，候选通常只剩一项或两项。把答案连同 3.3 的对账表一起写进架构决策记录，未来争论时有一份可回溯的依据。

追问两则

**问：方案之间可以混用吗？**可以且常见：业务主电路用一套后端，聚合层用另一套擅长递归的后端，链上验证用最省的配对方案收尾——第 6 章现场里"证明链"就是混用哲学的产物。代价是适配层与多次审计，混用层数要克制。

**问：新方案发布该等多久再用？**看三件事：安全证明是否完整公开、参考实现是否经过第三方审计、是否有真实业务跑过半年以上。三件事没齐之前，把新方案放在灰度或非关键路径上，是行业用血换来的默认姿势。

数一数：体积账的量级感

用具体数字建立量级感：Groth16 的证明约三四个群元素，按主流曲线压缩后两百字节上下——一张短消息的体积，链上存储费可以忽略不计；Plonk 系证明随公共输入与门配置浮动，通常数百字节到一千出头；Halo2 类按配置可到数 KB；Bulletproofs 在范围证明场景几十字节到几百字节、在大电路上迅速膨胀到几十 KB 且验证时间线性失控。把体积换算成上链费与下载时延，再叠上验证时间与仪式负担，四个方案的"综合账单"才会从表格里的定性色块变成可感的差异——数字与第 3 站对账演算互相印证着读。

本节要点回顾

• 流水线共同，分野在承诺：配对承诺（Groth16/Plonk 系）与内积/多项式承诺（Halo2/Bulletproofs）对应不同信任结构；
• Groth16 极小极快但仪式专属，电路稳定且验证成本敏感时它仍是最优解；
• 通用仪式（Plonk）与免仪式（Halo2/Bulletproofs）是迭代自由的两种买法，分别用验证开销与证明器复杂度支付；
• 选型先对账：证明字节、验证毫秒、仪式负担三列填完，结论多半自己浮现。