16 四个旋钮

◻ 本章先赊三条

第一条。这些方案不是「一代比一代强」，而是在同一组约束下的不同取值点。2016 年的 Groth16 至今仍在生产环境里，因为它在「证明大小」这一格上没被超过。 第二条。「STARK 和 SNARK 谁更好」这个问题本身是坏的——STARK 是 SNARK 的一种，这个对立完全来自命名事故。 第三条。这些方案可以叠在一起用，而且工业界几乎都这么干。第 17 章讲叠的办法。

四个旋钮

先把旋钮说清楚，因为它们不是独立的——拧一个必然动另一个。

旋钮	它决定什么	被谁拉扯
1. 证明大小	要传多少字节、上链要付多少存储费	抽查次数（第 11 章）、承诺方案（第 13 章）
2. 验证成本	验一次要多少毫秒、上链要多少 gas	同上。它和证明大小几乎总是同向
3. 要不要仪式	信任模型、以及改电路的运营成本	承诺方案：KZG 要，哈希不要（第 15 章）
4. 假设的干净程度	它建立在几条「目前没人能破」上，以及量子计算机来了会怎样	椭圆曲线 → 会被 Shor 算法打破；只用哈希 → 目前认为安全
（5. 证明者成本）	时间和内存。第 14 章那一整章	几乎所有选择都会影响它

那张表

下面的数字是量级，不同实现和参数会有出入；引用的是各方案公开文献里的典型值。

方案	证明大小	验证	仪式	靠什么	抗量子
Groth16 2016	128 字节	3 次配对，几毫秒	每个电路一场	配对 + 电路专用参数	否
PlonK 2019	约 500 字节	常数次配对	通用一场，可更新	配对（KZG）	否
Halo2 / IPA 2019–	几 KB	对数级，但常数大	不要	离散对数	否
Bulletproofs 2017	1 – 2 KB	随电路线性增长	不要	离散对数	否
STARK 2018	45 – 200 KB	polylog，几十万次哈希	不要	只有哈希	是
折叠 / Nova 2021–	看最终包一层用什么	看最终那层	看方案	离散对数	否

盯着这张表看一分钟，能看出三条规律：

证明大小和「假设干净程度」是反着的。最短的（128 字节）假设最多（配对 + 电路专用仪式），最干净的（只用哈希）最长（45 KB 起）。你付出的信任，买回来的是字节数。
Bulletproofs 那一行是个陷阱。它的证明只有 1–2 KB，看起来很美——但验证成本随电路线性增长。这意味着它在链上验一个大电路，可能比链下重算还贵。只看「证明大小」这一列选型，会栽在这里。
2016 年的方案至今没被淘汰。这在软件行业里很少见，原因是那 128 字节触到了一个下界——它就是三个椭圆曲线上的点，再短就装不下了。

✎ 术语正名

SNARK = Succinct Non-interactive ARgument of Knowledge。STARK = Scalable Transparent ARgument of Knowledge。

注意第一个字母变了：STARK 的 S 是「可扩展」（证明者成本近线性、验证成本 polylog），T 是「透明」（不需要仪式）。按定义，STARK 就是一种 SNARK——它简洁、非交互、是知识论证。

那为什么到处都在说「SNARK vs STARK」？因为社区约定俗成地用「SNARK」特指基于配对的那一族（Groth16、PlonK）。这是一次命名事故，而它制造了一个不存在的对立。

更准确的分法是按承诺方案：用 KZG（配对）的，用 IPA（离散对数）的，用 Merkle + FRI（哈希）的。这三条路的区别，就是上面那张表的全部内容。把「什么什么 ARK」这些名字忘掉，记住这三条路。

怎么选

实际决策通常由几个非常具体的问题决定，而不是由「哪个更先进」：

问题	如果是	指向
证明要上链吗？链上存储贵吗？	是，而且很贵	Groth16 / PlonK（几百字节）
电路会经常改吗？	会	避开 Groth16（每次都要重办仪式）
能接受「相信有人删了」吗？	不能	STARK / Halo2
被证的计算有多大？	非常大（几亿步）	STARK（证明者成本近线性，最能扛）
这份证明要保存二十年吗？	是	STARK（其他的都会被量子计算机打破）
又要小又要透明？	是	叠起来用：STARK 证一切，再用一层 SNARK 把它压到几百字节（第 17 章）

最后那一行是今天的主流做法。因为这些方案不是互斥的选项，是可以串联的零件。

◆ 一个真实的约束长什么样

以太坊 2026 年为 L1-zkEVM 定的硬性指标，是这张表最好的注脚——它把四个旋钮全部写成了验收条件：

延迟      99% 的主网区块，证明生成 ≤ 10 秒
证明大小  ≤ 300 KB
安全性    ≥ 128 比特（且要用统一的工具核算）
硬件      本地证明设备 ≤ 10 万美元，功耗 ≤ 10 kW

注意「证明大小 ≤ 300 KB」和「安全性 ≥ 128 比特」这两条是同一笔账的两栏：证明大小 ≈ 抽查次数 × 每次的路径长度，而抽查次数 ≈ 安全比特 ÷ log₂(blowup)。第 11 章那个 blowup 旋钮，最后就落在这张验收表上。

还有一条更值得注意：「功耗 ≤ 10 kW」。密码学的性能指标里出现电费，说明这门技术已经从论文阶段走到了机房阶段。

⌨ 自己跑一遍

把「证明大小 ↔ 安全比特 ↔ blowup」这三者的关系写成一个小算式，你就能自己给上面那张验收表算账：

import math

def stark_size(n, blowup, security_bits, hash_bytes=32):
    """粗略估算：抽查次数 × 每条 Merkle 路径的长度"""
    queries = math.ceil(security_bits / math.log2(blowup))
    depth   = math.ceil(math.log2(n * blowup))
    return queries, depth, queries * depth * hash_bytes

for blowup in (2, 4, 8, 16, 64):
    q, d, size = stark_size(n=2**20, blowup=blowup, security_bits=128)
    print('blowup %2d → 抽 %3d 次，树高 %2d，约 %6.1f KB，证明者成本 ×%d'
          % (blowup, q, d, size / 1024, blowup))

blowup  2 → 抽 128 次，树高 21，约   84.0 KB，证明者成本 ×2
blowup  4 → 抽  64 次，树高 22，约   44.0 KB，证明者成本 ×4
blowup  8 → 抽  43 次，树高 23，约   30.9 KB，证明者成本 ×8
blowup 16 → 抽  32 次，树高 24，约   24.0 KB，证明者成本 ×16
blowup 64 → 抽  22 次，树高 26，约   17.9 KB，证明者成本 ×64

把 blowup 从 2 调到 64，证明从 84 KB 缩到 18 KB，代价是证明者贵 32 倍。这就是第 1 号和第 5 号旋钮在互相拉扯的实际形状——而工业界普遍选 8 或 16，因为再往右走，证明者那一头的电费涨得比省下的带宽更值钱。

（真实系统还要加上多条多项式、FRI 各层的开销，所以实际证明比这个估算大几倍。但这个算式的形状是对的，你可以拿它去检查任何一份 STARK 参数表是否自洽。）

python3 -c " import math for b in (2,4,8,16,64): q=math.ceil(128/math.log2(b)); d=math.ceil(math.log2(2**20*b)) print(b, q, d, '%.1f KB'%(q*d*32/1024))"

在线跑：python.org/shell。各方案的准确参数看它们各自的论文或规范，注意一定要看它声称的是多少比特安全——同一个方案在 80 比特和 128 比特下的证明大小差一半。

▸ 在现实里

Zcash 用过 Groth16，后来往 Halo2 迁移。迁移的核心动机就是那一行：摆脱「每次升级都要重办仪式」。技术选型被运营成本推着走，这在这个领域是常态。
以太坊的 blob（EIP-4844）用 KZG。因为它要的正是「承诺极短、验证极快」，而它接受了那场 14 万人的仪式。同一条链上，不同组件用不同的方案。
StarkNet 从一开始就用 STARK。理由是不办仪式、抗量子、以及证明者成本在超大计算上更扛得住。代价就是那张表里的 45–200 KB。
「先进」在这个领域是个很弱的词。2016 年的 Groth16 今天仍是「证明最小」的记录保持者；2010 年的 KZG 是以太坊 blob 的基础；1960 年的里德–所罗门码是每一个 STARK 的引擎。这一行里，新东西通常不是取代旧东西，而是在四维空间里占了另一个点。

✗ 这个直觉是错的

「STARK 比 SNARK 新，而且不用可信设置、还抗量子，那显然应该用 STARK。」

三个问题。第一，STARK 就是一种 SNARK，这个对立是命名事故（见上面的术语正名）。第二，「不用仪式」不等于「假设更少」：STARK 的可靠性依赖「那个哈希函数确实像随机预言机」，这是第 8 章那个被理论界证明不严谨的模型。第三，代价是证明大了几百倍——在以太坊主网上，多传 45 KB 是一笔真金白银的费用。

更值得警惕的是「抗量子」这一格。它确实是 STARK 的真实优势，但要问清楚：你这份证明需要在二十年后仍然可信吗？大多数 rollup 的证明验完就没用了——它只在被验证的那一刻起作用，链上状态一旦确认，证明的历史价值为零。对这类场景，「抗量子」是一个买了用不上的属性。而对「二十年后还要能证明这份文件当年存在」这种场景，它就是必需品。

判据是：把四个旋钮各自写一句「如果这一格很差会怎样」，然后看哪一句对你的系统是致命的。剩下三格再差都可以忍。这本书里所有的技术选型，都可以用这一句话来做。

✓ 结账

第一条「不是一代比一代强」——付清了：2016 年的 Groth16 至今保持着 128 字节的纪录，因为那是三个群元素的物理下界。 第二条「STARK 是 SNARK 的一种」——付清了：S 从 Succinct 换成了 Scalable，T 是 Transparent。真正的分类应该按承诺方案：KZG / IPA / 哈希三条路。 第三条「可以叠起来用」——记了一半：那张决策表最后一行给出了做法（STARK 证一切，SNARK 包一层）。怎么叠，下一章。

这一章的一句话

这些方案不是先进程度的排序，而是「证明大小、验证成本、要不要仪式、假设干净程度」这四维空间里的不同取值点；选型的正确问法不是「哪个更好」，而是「哪一格出问题会要我的命」。

下一章讲那个「叠起来」的动作，而它有一个几乎像文字游戏的名字：证明「我验过一个证明」。一旦验证足够便宜，验证这件事本身就成了一段很短的计算——短到值得再为它生成一份证明。这个自指的动作打开了三扇门：把一整条区块链的历史压成一个几十 KB 的文件、把一个巨大的计算切成几千块并行地证、以及把一份 45 KB 的 STARK 压成 128 字节。

而它的可行性，取决于第 10 章那张成本表上的一个数字：把 SHA-256 写进电路要 33512 条约束，换成为算术而生的哈希只要 182 条。差 184 倍。下一章我会把那 33512 条亲手数出来——顺便验证一下我数的那台电路，算出的哈希值和 node:crypto 逐位相同。