17. 系统对比、参数、选型与安全审计清单
资料快照：2026-07-29。性能数字会过时，分层方法与安全问题更持久。
1. 先写 proof stack，再谈名字
推荐用七元组描述系统：
\[\boxed{ (\mathcal A,\mathcal I,\mathcal P,\mathbb F, \mathcal H,\mathcal T,\mathcal R) }\]其中：
- $\mathcal A$：arithmetization，AIR / PLONKish / R1CS / CCS；
- $\mathcal I$：polynomial IOP，quotient / permutation / lookup / sumcheck；
- $\mathcal P$：PCS/IOPP，KZG / IPA / FRI / WHIR / BaseFold；
- $\mathbb F$：base/extension field 或 curve cycle；
- $\mathcal H$：Merkle/transcript/circuit hash；
- $\mathcal T$：setup 与 Fiat–Shamir 模型；
- $\mathcal R$：recursion/aggregation/wrapper。
“用了 PLONK”只给出 $\mathcal A,\mathcal I$ 的一部分；“用了 STARK”通常暗示 AIR+hash proximity，但仍没有说明 field、FRI 变体、ZK 与 recursion。
2. 核心路线横向表
| 路线 | 常见算术化 | commitment / low degree | setup | proof 尺寸直觉 | verifier 直觉 | PQ 路线 |
|---|---|---|---|---|---|---|
| KZG-PLONK | 单变量 PLONKish | KZG | universal/updatable SRS | 很小，常数个群元素/标量 | pairing + MSM | 否 |
| IPA-PLONKish | PLONKish | IPA | 无 structured toxic waste | 对数级 opening | curve MSM | 否 |
| 经典 STARK | AIR | Merkle + FRI/DEEP | transparent | 较大，查询 paths 主导 | hash + field | 可合理实现 |
| Circle STARK | flat AIR / AIR | Merkle + Circle FRI | transparent | 与具体参数相关，仍为 hash proof | hash + M31/扩域 | 可合理实现 |
| HyperPlonk | multilinear PLONK | multilinear PCS + sumcheck | 取决于 PCS | 后端相关 | sumcheck + PCS | 后端相关 |
| WHIR/BaseFold | multilinear/Σ-IOP | hash/code PCS | transparent | 通常大于 KZG、可小于传统 hash 方案 | 快速 hash/field verifier | 可合理实现 |
| Binius | binary PLONKish | binary tower multilinear PCS | transparent 路线 | 参数相关 | binary/extension field | 可合理实现 |
| Nova/HyperNova | R1CS/CCS | folding + vector/ML PCS | 后端相关 | accumulator 与 compressed proof 要分开 | decider/compression 相关 | 后端相关 |
“可合理实现为 PQ”不是无条件证明。必须同时覆盖 hash 实例、Fiat–Shamir 的 QROM compiler、knowledge soundness、recursion/wrapper 与部署参数。
3. 选型决策树
flowchart TB
S["首要目标是什么？"] --> Q{"必须避免量子脆弱的群假设？"}
Q -->|"是"| H["hash/code-based 路线"]
Q -->|"否"| V{"链上极短 proof / pairing 预编译优先？"}
V -->|"是"| K["KZG-PLONK 或短 SNARK wrapper"]
V -->|"否"| I["IPA-PLONKish / folding"]
H --> B{"主要计算形状？"}
B -->|"长执行轨迹 / zkVM"| A["AIR + FRI / Circle FRI"]
B -->|"sumcheck / multilinear"| W["WHIR / BaseFold / Binius"]
A --> Z{"必须隐藏 witness？"}
W --> Z
Z -->|"是"| ZK["核对实际 ZK encoding 与模拟证明"]
Z -->|"否，只做 validity"| VAL["可用非 ZK argument"]
I --> R{"长期增量计算？"}
R -->|"是"| N["Nova / HyperNova / ProtoStar / Halo accumulation"]
R -->|"否"| P["普通 PLONKish proof"]
这是第一轮筛选，不替代 benchmark。
4. 按计算形状选择算术化
4.1 AIR
适合：
- CPU/VM 每一步重复相同 transition；
- 大量相邻行约束；
- 多 components/tables；
- small-field SIMD/GPU prover。
代价：
- 不规则 control flow 要 selectors/padding；
- RAM 语义需 permutation/lookup；
- trace length 常被最长路径和 2-power padding 放大。
4.2 PLONKish
适合：
- gadget/component library；
- 自定义门与 rotations；
- 电路结构静态，重复证明许多 witnesses；
- lookup tables 与 copy constraints 丰富。
代价：
- floor planning/layout 会影响 rows/columns；
- high-degree gate 增加 quotient；
- equality-enabled columns 和 lookup arguments 增加 proof openings。
4.3 Multilinear / sumcheck
适合：
- 原始数据天然是 $2^\ell$ evaluations；
- 大量 inner product、matrix、table selection；
- 希望避免 FFT；
- folding/IVC 与 giant structured lookup。
代价：
- sumcheck rounds 和 evaluation claims 较多；
- memory layout/claim reduction 复杂；
- PCS 对最终性能影响极大。
4.4 CCS / folding-friendly relation
适合长期 IVC 与异构 step circuits。若只做一次性 proof，额外 accumulator/compression 复杂度可能没有收益。
5. 按 verifier 环境选择 PCS
5.1 EVM / pairing 预编译
KZG/短 pairing SNARK 往往具有 proof bytes 与 gas 优势。可让内层使用 STARK/FRI，最终递归到一个 pairing wrapper。
需要接受：
- powers-of-tau 或其他 setup；
- 非 PQ final proof；
- wrapper circuit/bridge 成为新的 trusted computing base。
5.2 浏览器、移动端、本地 verifier
hash + small-field verification 可能比 pairing library 更易部署，但 proof 下载量会更大。IPA 避免 pairing，却仍有 curve MSM。
必须实际测：
- WASM SIMD；
- memory peak；
- proof parse/hash 时间；
- 网络传输；
- 是否有 native/JS big-int fallback。
5.3 递归 circuit 内
选择“原生友好”的 primitives：
- inner curve base field = outer scalar field；
- inner field = outer circuit field；
- algebraic hash degree/trace rows 低；
- verifier query pattern 易固定；
- proof parser 可电路化且无可变长歧义。
原生 verifier 快不代表递归 verifier 快。
6. Setup 不是二元选项
| 类型 | 示例 | 需要信任什么 |
|---|---|---|
| circuit-specific trusted | 某些早期 pairing SNARK | 每个 circuit ceremony |
| universal/updatable structured | KZG-PLONK | 至少一次诚实 contribution、最大 degree |
| 无 structured toxic waste | IPA | generator independence / DLOG |
| transparent | FRI/WHIR + Merkle | hash、公开 randomness、ROM/QROM |
还要问：
- 参数由谁生成、如何验证 contribution？
- verification key 是否正确绑定 circuit？
- setup 上限是否覆盖 future circuit 与 blinding degree？
- transparent 参数中的 field/domain/hash 是否固定且版本化？
“无需 trusted setup”不等于“无需任何公共参数或安全假设”。
7. Soundness budget 必须逐项相加
先把实现正确性写成 theorem 的前提：
\[\mathcal A_{\mathrm{impl}} := \mathsf{ProtocolConformance} \land \mathsf{ParserSoundness} \land \mathsf{CircuitVerify}\equiv\mathsf{NativeVerify} \land \mathsf{StatementBinding}.\]在 $\mathcal A_{\mathrm{impl}}$ 以及各密码学假设成立的条件下，一个实际 cryptographic soundness 上界形如
\[\Pr[ \mathsf{AcceptFalse} \mid \mathcal A_{\mathrm{impl}} ] \le \epsilon_{\mathrm{arith}} +\epsilon_{\mathrm{batch}} +\epsilon_{\mathrm{PCS/IOPP}} +\epsilon_{\mathrm{FS}} +\epsilon_{\mathrm{hash}} +\epsilon_{\mathrm{rec}}.\]右侧只放入 security theorem 或 reduction 真正量化的坏事件。实现 bug 不是默认可相加的概率项：一个漏约束、错误 transcript 顺序或 statement substitution 可能确定性地破坏接受关系，使错误接受概率达到 1，而不是“损失若干 bits”。
7.1 Algebraic identity error
若错误 polynomial degree 至多 $d$，随机点域为 $\mathbb K$：
\[\epsilon_{\mathrm{arith}}\le\frac d{|\mathbb K|}.\]多个 constraints 随机组合的 error 还与组合 polynomial 关于挑战的 degree 有关。
7.2 Batching error
$m$ 个 claims 用
\[\sum_{i=0}^{m-1}v^iP_i\]合并，错误抵消概率通常含
\[\frac{m-1}{|\mathbb K|}.\]若多次 batching 复用同一个 challenge，不能默认错误独立。
7.3 FRI / proximity error
受：
- code rate / blowup；
- folding factor；
- query count；
- domain/extension field；
- DEEP/OODS；
- unique-decoding、Johnson bound 或 conjectured list-decoding 模式；
- grinding；
- 多表 correlated agreement；
共同影响。必须调用具体变体 theorem/参数工具，不能只用 $(1-\delta)^q$ 直觉。
7.4 PCS error
- KZG/IPA 是计算假设下的 binding/knowledge error；
- Merkle 是 collision/second-preimage 与 oracle binding；
- degree binding、batch opening 和 subgroup validation 是独立接口。
7.5 Recursion error
深度 $L$ 的 proof chain 不能无说明地继续沿用单步 $\lambda$ bits。要按所用 theorem 处理 union bound、accumulation soundness、Fiat–Shamir nesting 与 final decider。
7.6 实现正确性不是 $\epsilon_{\mathrm{impl}}$
代码审计、differential tests、formal verification 与 reproducible test vectors 是建立 $\mathcal A_{\mathrm{impl}}$ 的证据，不是自动生成某个 $\epsilon_{\mathrm{impl}}$ 的方法。若发现
\[\mathsf{CircuitVerify}(\pi,x) \ne \mathsf{NativeVerify}(\pi,x)\]或 parser/transcript/statement binding 偏离 specification，应判定抽象 soundness theorem 的适用前提失败，并单独修复与重新审计。只有在明确给出随机硬件故障、抽样测试漏检等额外概率模型时，才可以报告相应 operational risk；它不能与协议的 cryptographic soundness bits 混成一个无条件总和。
8. Small-field 参数的正确问法
若 base field 只有约 31 bits，不表示系统只有 31-bit soundness。现代 STARK 可：
- 在 degree/trace 上用 base field；
- 在 random challenges 上用高次 extension；
- 重复 proximity queries；
- 使用 cryptographic hash；
- 加 proof-of-work/grinding。
反过来，使用四次扩域也不自动等于 124-bit soundness，因为：
\[\epsilon_{\mathrm{total}} \ne \frac1{|\mathbb F|^4}\]这一项还要和 code proximity、hash、batching 等相加。
参数说明至少列：
| 项 | 应报告 |
|---|---|
| base field | modulus / characteristic |
| challenge field | extension degree、不可约 polynomial |
| trace/quotient degree | 最大值 |
| LDE | blowup、rate、domains |
| proximity | protocol、folding factor、queries |
| hash | function、digest、leaf encoding |
| FS | transcript spec、grinding bits |
| security mode | proven / conjectured |
9. Zero-knowledge 的逐层清单
9.1 Witness columns
- 是否加 $Z_HR$ masking 或 ZK encoding？
- 盲化随机数维数是否覆盖所有 opened linear functionals？
- padding/blinding rows 是否真正随机？
9.2 Auxiliary arguments
- permutation accumulator 是否盲化？
- sorted lookup columns 是否盲化？
- multiplicities 是否泄露 query histogram？
- quotient/linearization evaluations 是否可联立消掉 masks？
9.3 Transcript 与 metadata
即使 algebraic proof ZK，也可能泄露：
- circuit shape；
- trace length；
- instruction count；
- branch-dependent table sizes；
- proof timing/memory/network size；
- repeated witness 的 deterministic commitments。
ZK 定义应说明哪些 leakage 是 public statement 的一部分。
9.4 Recursion
- inner public states 是否应隐藏？
- accumulator 是否 rerandomize？
- final compression 是否 ZK？
- 多次 session 是否 linkable？
10. Post-quantum 声称的逐层清单
要声称“整个系统 PQ”，至少检查：
- PCS 不依赖 DLOG/pairing；
- Merkle/transcript hash 选定足够的量子安全参数；
- Fiat–Shamir compiler 有适用的 QROM 分析；
- knowledge soundness/extractor 在目标量子模型中成立；
- recursion/wrapper 没重新引入椭圆曲线；
- signatures、ceremony attestations、proof distribution channel 也有迁移方案。
“STARK 通常 hash-based”只能作为路线直觉，不能替代上述证明。
11. Benchmark 必须标准化
11.1 至少报告这些量
- 关系规模：cycles、rows、constraints、lookups；
- field/curve/hash；
- security bits 与 proven/conjectured mode；
- hardware、threads、SIMD/GPU、memory；
- warm/cold cache；
- prover time、peak RSS/VRAM；
- proof bytes；
- native verifier time；
- recursive verifier rows/time；
- setup/preprocessing 是否计入；
- batch size 与 amortized cost。
11.2 prover 时间分解
建议报告
\[T_{\mathrm{prove}} =T_{\mathrm{witness}} +T_{\mathrm{FFT}} +T_{\mathrm{MSM}} +T_{\mathrm{hash}} +T_{\mathrm{constraint}} +T_{\mathrm{opening}} +T_{\mathrm{IO}}.\]只给总时间无法判断系统在另一硬件上的表现。
11.3 不要比较不同 statement
“每秒 cycles”可能隐藏：
- 某 VM 一条 cycle 做的工作更多；
- 某系统预编译/lookup table 不同；
- public/private memory model 不同；
- proof 没启用 ZK；
- security level 不同；
- 只 benchmark 核心 permutation 而非完整 program。
12. 2026 年项目/论文定位快照
| 名称 | 更准确的定位 | 本资料快照提醒 |
|---|---|---|
| 原始 PLONK | 单变量 permutation PIOP + 常见 KZG compiler | 基础协议，不等于所有 PLONKish |
| Halo 2 | PLONKish columns/rotations/lookups + IPA 路线 | 以其 Book/具体 crate spec 为准 |
| Kimchi | 多列 custom-gate PLONKish + bulletproof-style PCS | Pickles recursion 是另一层 |
| Plonky2 | PLONK/FRI 技术组合的 recursive SNARK 实现 | 官方仓库已标注弃用 |
| QED Plonky2.5 | 在 Plonky2 circuit 中验证旧版 Plonky3 proof 的第三方 prototype | 不是官方协议版本，也不是当前 proof adapter |
| Plonky3 | 模块化 polynomial-IOP toolkit | 不是单一固定 proof protocol |
| Plonky3-recursion | 把固定 Uni/Batch-STARK verifier 编译为 multi-chip circuit | 独立项目；当前仍标注未审计、不建议生产 |
| HyperPlonk | multilinear PLONK + sumcheck 论文 | PCS 实例决定最终属性 |
| S-two | M31 Circle STARK + flat AIR | 具体版本的 ZK 状态需单独核对 |
| WHIR | constrained RS IOPP / uni+ML PCS | 论文参数有 proven/conjectured 模式 |
| Binius | binary tower-field SNARK 路线 | 适合 bit-oriented computation |
| Nova/HyperNova | folding-based IVC | final compression 与 ZK 分开看 |
不要据这张表推断安全审计状态；它只定位数学架构。
13. 场景化建议
场景 A：固定电路、大量 proofs、链上验证
优先评估 KZG-PLONKish：
- universal setup 可跨 circuit 上限复用；
- proof 小；
- pairing precompile 友好。
同时评估是否需要 PQ、ceremony 风险与 circuit upgrade 上限。
场景 B：通用 zkVM、CPU/GPU prover
优先评估 small-field AIR：
- FRI / Circle FRI；
- lookup/LogUp memory model；
- recursion tree；
- 若链上结算，再评估短 wrapper。
场景 C：隐私 client-side proof
首先排除未启用 ZK 的 validity prover，再测：
- peak memory；
- proof upload；
- browser/mobile primitives；
- witness-independent proof shape；
- setup 下载。
场景 D：巨大结构化 table
研究 Lasso/Jolt、Caulk/Baloo 或 LogUp decomposition，而不是直接物化 Plookup table。
场景 E：长期状态机/rollup folding
研究 Nova/HyperNova/ProtoStar/Halo accumulation；明确 final decider、state continuity 与 non-uniform instructions。
场景 F：bitwise hash/二进制电路
比较：
- prime-field byte/nibble lookup；
- binary tower/Binius；
- 为目标 hash 定制 AIR。
14. 实现审计：transcript 与 parsing
- 协议/version/domain separator 是否唯一？
- VK/circuit digest 是否吸收？
- public input 的长度、顺序、编码是否吸收？
- challenges 是否严格晚于依赖 commitments？
- hash-to-field 是否规范、无偏且跨平台一致？
- group/field elements 是否 canonical？
- 是否拒绝 trailing bytes、重复 sections、整数溢出长度？
- Merkle leaves 是否带 type/column/width/domain tags？
- recursive proof 是否绑定 depth、inner VK 与 accumulator type？
- prover/verifier 是否共享一份 transcript specification test vectors？
15. 实现审计：代数约束
- 每个 selector/flag 是否 boolean 或 range constrained？
- integer overflow/signedness 是否被显式证明？
- unused/padding rows 是否关闭且无自由影响？
- rotations 在 first/last row 是否安全？
- permutation 是否为双射，labels 是否无碰撞？
- grand product 起点/末端/recurrence 是否齐全？
- lookup tags、tuple arity、dummy rows 是否一致？
- LogUp inverses、multiplicities、terminal sums 是否齐全？
- quotient degree、chunks、SRS bound 是否一致？
- public outputs 是否进入 constraints，而非只被应用层读取？
16. 实现审计：PCS 与递归
- KZG ceremony/SRS/VK 是否验证且版本化？
- IPA generators 是否独立、domain-separated？
- FRI domains、index mappings、final degree 是否检查？
- query 去重后有效 security 是否正确？
- subgroup/on-curve/infinity 是否严格检查？
- batch opening challenge 是否绑定完整 ordered claim list？
- recursive verifier 与 native verifier 接受集合是否等价？
- base case 与 state chaining 是否完整？
- accumulated claims 是否全部进入 final decider？
- wrapper 是否改变 setup、ZK、PQ 与 public-input semantics？
17. 部署前的最小证据包
一个可审计 proof system 发布至少应提供：
- protocol specification 与 challenge dependency graph；
- arithmetization/constraint definition；
- security theorem 和 concrete parameter derivation；
- transcript/serialization specification；
- test vectors，包括 invalid proofs；
- setup provenance 或 transparent parameter derivation；
- benchmark harness 与完整配置；
- audit reports和已知限制；
- ZK leakage statement；
- upgrade/version compatibility policy。
没有这些材料时，“128-bit、zero-knowledge、post-quantum、production-ready”都只是待验证声明。
18. 最终心智模型
flowchart LR
R["Relation"] --> A["Arithmetization"]
A --> I["Polynomial IOP"]
I --> P["PCS / IOPP"]
P --> F["Fiat-Shamir"]
F --> Z["ZK masking"]
Z --> C["Recursion / compression"]
C --> D["Deployment verifier"]
每个箭头都有自己的 completeness、soundness、knowledge 与 leakage 条件。任何一层换实现，最终属性都可能变化。
19. 一页结论
- 选算术化看计算形状，不看项目热度。
- 选 PCS 看 setup、proof bytes、verifier 环境、recursion 与 PQ 目标。
- lookup、custom gate 与 columns/rows 是 degree、memory、MSM/FFT 的交换。
- FRI soundness 必须用具体参数定理；字段位数或查询数都不能单独代表 security。
- transparency、post-quantum、zero-knowledge、succinctness 是四条不同轴。
- recursion/folding 把验证成本推迟或压缩，最终 decider 与 state chaining 不能遗漏。
- 当前项目名往往代表 toolkit 或组合，必须记录完整 proof stack 和版本。
参考
本篇使用的论文与官方文档汇总见资料索引。建议对生产选型直接阅读目标实现的 protocol specification、安全审计与参数生成代码，而不是只阅读二手对比文章。
上一篇：Plonky 系列对照与迁移 · 下一篇：论文与官方资料索引 · 返回：总目录