5.2 性能三本账：证明时间、验证时间与证明体积

5.2 性能三本账：证明时间、验证时间与证明体积

本节摘要：零知识证明的性能由三本账共同决定：证明生成时间（证明者烧算力）、验证时间（验证者花时间或上链费）、证明体积（占带宽与存储）。三本账量纲互不可换、瓶颈各不相同，优化前先分清自己在哪本账上亏钱。本节给出 scaling 规律、链上成本构成，并用聚合摊销演算演示"逐笔不可行、批量救得活"。承接 5.1，通往 5.3 的隐私取舍。

账房先生的三本账

先立账目框架。第一本：证明生成账。这是三本中最贵的一本，成本与电路规模近似线性或准线性（不同方案异），瓶颈部件清晰：SNARK 系耗在 FFT 与多标量乘（MSM）两大件上，STARK 系耗在海量哈希上。GPU 能买到数倍到数十倍加速，分布式证明器能再加一轮。第二本：验证账。简洁证明的招牌在这一本：Groth16 验证只需几次配对，毫秒级；STARK 验证是对数次哈希，稍慢但也不随电路规模线性涨。上链场景里这本账换算成 gas，是商业模型里最敏感的一行。第三本：体积账。证明要被存储、传输、上链，两百字节与两百 KB 在链上存储成本面前是两个世界。

三本账的陷阱在于此消彼长且量纲不同：用递归把第一本摊薄，第三本可能变重；选小证明方案，第一本可能翻倍。账房的第一课就是拒绝"哪个最快"这种问法，改问"哪个业务约束最硬"。

图：三本账的支付方与瓶颈部件

链上成本：把时间账翻译成钱

验证账在上链场景会换算成 gas。构成分三块：证明数据的存储费（calldata 按字节计价，Groth16 两百字节上下是它最大的成本优势；STARK 几十 KB 直接让链上原生验证不现实，需配对数层或专用验证合约）；验证计算费（配对操作单价高但次数固定，哈希验证次数随安全参数涨）；公共输入处理费（承诺树根、空值器等公开值越多，账单越长）。工程上还常有一项隐性成本：升级与维护——电路变更需要重新部署验证合约，这笔"会计科目"在预算里经常被漏掉。

单笔验证不划算的业务，行业给出的答案是聚合摊销：把 N 份证明叠进一份聚合证明（递归验证链），链上只验一次，成本被 N 笔业务分摊。第 6 章的 rollup 就是这套结构的产品化。摊销账怎么算，跑一段演算：

# 聚合摊销演算：逐笔验证 vs 聚合后批量验证
# 成本单位用示意值（毫秒或 gas 均可代入），关键是量级关系
per_proof_verify = 250_000        # 单份证明的链上验证成本（示意：约一次 Plonk 验证）
agg_overhead     = 400_000        # 一份聚合证明的链上验证成本（更大，但只付一次）
prover_ms_per_proof = 700         # 单份证明生成耗时
aggregator_ms_overhead = 5_000    # 聚合器的额外证明耗时

print(f"{'批量规模':>8}{'逐笔成本':>14}{'聚合成本':>12}{'省下比例':>10}")
for n in [10, 100, 1000, 10000]:
    naive = n * per_proof_verify
    aggregated = agg_overhead
    saving = 1 - aggregated / naive
    print(f"{n:>10}{naive:>15,}{aggregated:>13,}{saving:>9.1%}")
# 典型输出：
#       批量规模          逐笔成本      聚合成本    省下比例
#           10      2,500,000      400,000     84.0%
#          100     25,000,000      400,000     98.4%
#         1000    250,000,000      400,000     99.8%
#        10000  2,500,000,000      400,000    100.0%

# 但第一本账在反向提醒：证明生成耗时随批量线性涨
for n in [100, 1000, 10000]:
    total_ms = n * prover_ms_per_proof + aggregator_ms_overhead
    print(f"批量 {n:>5} 的证明器总耗时约 {total_ms/1000:>8.1f} 秒")
# 优化后的商业问题变成：允许的确认延迟内，最多能塞多少笔进一个批次
​

两张表合读，rollup 的经济学骨架就出来了：验证账靠聚合摊到近乎免费，生成账成为新的瓶颈与成本中心——这正是行业把创新火力转向"证明加速"与"证明市场"的原因。第 6 章进现场时，你会看到每个 rollup 团队的方案差异，本质上都是对这两张表的不同答案。

硬件与工程的加速清单

落到工程，加速选项按收益排序。结构级：聚合与递归（摊销第一本）、批处理共享公共计算（一次 FFT 服务多份证明）、电路精简（4.4 节三板斧直接降第一本）。硬件级：GPU 做 MSM 与哈希、FPGA 做稳定流水线、专用加速卡做配对——收益两倍到数十倍不等，代价是运维复杂度。参数级：安全等级从 100 位提到 128 位的成本差异、域大小的选择、抽查次数的取值，都是" lastIndex 一个百分比换一片预算"的微调项。顺序别排反了：先结构、再硬件、最后参数，反着来是常见的预算黑洞。

过渡：三本账之外的第四本

性能之外还有一本隐藏账：隐私的代价。隐藏金额、隐藏身份都要往电路里塞逻辑，第一本账随之膨胀——隐私与扩展的张力到底怎么解？下一节摊开谈。

一笔真实的预算演算

把三本账落成预算科目。设想一个日均处理十万笔证明的服务：第一本账，单份证明生成若为零点几秒的 GPU 时间，按云上单价折算，年度生成成本轻松进入六位数预算区间——这就是为什么现场团队拼命压电路、上聚合；第二本账，若验证发生在链上且每日上链一次聚合证明，验证成本被摊到几乎可以忽略（5.2 正文的摊销表），但若逐笔上链验证，同样的业务量在验证科目上直接不可行——先定验证拓扑，再谈单价；第三本账，几十 KB 的证明若存对象存储几乎免费，若上链则是天文数字——存储位置的选择比压缩算法更影响账单。三笔账算完你会发现，性能优化的顺序其实是商业决策的顺序：先定"验证在哪、数据存哪"，再回来压"生成多快"。

追问三则

**问：证明生成能无脑堆机器吗？**部分能。生成任务的并行度受电路结构限制——批次内独立实例可以多机分跑，但单份大电路的 FFT 阶段并行度有限。堆机器前先看任务画像：独立小证明多的业务堆机器有效，单体大电路的业务先做电路切分与折叠（7.1）。

**问：验证端还有优化空间吗？**有，且常被忽略。批量验证（多个证明共享部分配对计算）、延迟验证（链下积累、定期上链）、验证缓存（同一证明被多方验证时只算一次）三个手段叠加，验证科目还能再降一个台阶。

**问：怎么向管理层汇报三本账？**换成业务语言：生成账是"每单处理成本"、验证账是"结算手续费"、体积账是"存储与带宽费"。三本账各配一条月度趋势线与预算阈值，性能回归一旦越线自动告警——把性能管理做成财务管理的口径，比技术指标更容易获得持续投入。

本节要点回顾

• 三本账量纲互不可换：生成烧算力、验证烧时间或 gas、体积占带宽，优化先认准亏钱的那本；
• 瓶颈部件明确：FFT 与 MSM 主宰 SNARK 证明器，哈希主宰 STARK 证明器，验证端则与电路规模解耦；
• 聚合摊销是结构级解法：验证成本被批量摊薄几个数量级，代价是证明器耗时线性增长；
• 加速顺序：结构、硬件、参数，先数量级后百分比。