Arch Day 197
Arch Day 197: ZK证明基础 — SNARKs vs STARKs与PM视角
零知识证明(Zero-Knowledge Proofs)让你可以证明你知道某件事，但不透露那件事是什么——在Web3中，这意味着隐私保护、链下计算验证和扩容三大核心应用。PM不需要理解数学，但必须理解ZK能证明什么、不能证明什么、以及成本多少。
2026-10-13
第七阶段 - Web3专题深度ZK证明SNARKsSTARKs零知识PM视角
日期: 2026-10-13 (Day 197) 阶段: 第七阶段 - Web3专题深度 标签: #ZK证明 #SNARKs #STARKs #零知识 #PM视角
核心概念
一句话定义
零知识证明(Zero-Knowledge Proofs)让你可以证明你知道某件事，但不透露那件事是什么——在Web3中，这意味着隐私保护、链下计算验证和扩容三大核心应用。PM不需要理解数学，但必须理解ZK能证明什么、不能证明什么、以及成本多少。
知识点详解
1. ZK证明直觉理解
经典比喻: 色盲朋友和两个球
你有一个红球和一个绿球。你的朋友是色盲，认为两个球一样。
你想证明两个球颜色不同，但不告诉他哪个是红哪个是绿。
方法:
1. 朋友把两个球藏在背后
2. 他可以选择交换或不交换
3. 他拿出来，你告诉他"换了"还是"没换"
4. 如果球颜色一样，你有50%概率猜错
5. 重复100次都猜对 → 99.99...%确信球颜色不同
6. 但朋友始终不知道哪个是红哪个是绿
这就是零知识证明: 证明了事实(颜色不同)，不泄露信息(哪个是哪个)
2. SNARKs vs STARKs核心对比
| 维度 | zk-SNARKs | zk-STARKs |
|---|---|---|
| 全称 | Succinct Non-interactive Argument of Knowledge | Scalable Transparent Argument of Knowledge |
| 证明大小 | ~288 bytes(极小) | ~50-200 KB(较大) |
| 验证时间 | ~10ms(快) | ~50ms(慢一些) |
| 证明时间 | 较慢(需要FFT) | 较快(hash-based) |
| 可信设置 | 需要(Trusted Setup) | 不需要(Transparent) |
| 抗量子 | 否(基于椭圆曲线) | 是(基于Hash) |
| 代表项目 | Zcash, Tornado Cash, Groth16 | StarkNet, RISC0, Plonky3 |
| 适用场景 | 链上验证成本敏感 | 安全性要求最高/长期 |
3. 可信设置(Trusted Setup)解释
为什么SNARKs需要可信设置？
SNARKs需要一组"公共参数"来生成和验证证明。
这些参数的生成过程需要一些"随机秘密值"。
如果任何人知道这些秘密值 → 可以伪造证明。
解决方案: 多方计算仪式(MPC Ceremony)
├── 多个参与者各自生成随机数
├── 按顺序贡献到公共参数中
├── 每个人销毁自己的随机数
├── 只要有1个人真的销毁了 → 整个系统安全
例子:
├── Zcash Powers of Tau: 87人参与
├── Hermez(现zkSync Era): 176人参与
└── Polygon zkEVM: 公开仪式
STARKs为什么不需要？
→ 完全基于公开的Hash函数(如Poseidon)
→ 没有"秘密参数"的概念
→ "Transparent" = 任何人可验证设置过程
4. ZK证明能做什么？(PM决策框架)
| 能力 | 说明 | 实际应用 |
|---|---|---|
| 证明计算正确 | "我正确执行了这个程序" | zkRollup(证明L2交易有效) |
| 证明拥有权 | "我拥有满足条件的私钥" | zkLogin(证明身份不泄露身份) |
| 证明集合成员 | "我在这个集合中" | Privacy Pools(证明不在黑名单) |
| 证明范围 | "我的年龄>18" | zkKYC(证明合规不泄露个人信息) |
| 证明状态 | "这个状态转换是合法的" | zkVM(验证任意程序执行) |
ZK不能做什么(PM常见误解)：
| 误解 | 现实 |
|---|---|
| "ZK让一切变快" | 证明生成很慢(秒到分钟级)，只有验证快 |
| "ZK让一切变便宜" | 链上验证便宜，但证明生成需要大量算力 |
| "ZK = 完全隐私" | ZK证明了计算正确，隐私需要额外设计 |
| "ZK可以证明链下数据" | ZK只能证明"给定输入的计算结果"，输入数据的真实性需要预言机/zkTLS |
5. ZK证明系统演进
| 代际 | 时间 | 代表 | 特点 | 缺陷 |
|---|---|---|---|---|
| 第一代 | 2012-2016 | Pinocchio, Groth16 | 首个实用SNARK | 需要每电路可信设置 |
| 第二代 | 2018-2020 | PLONK, Marlin | 通用可信设置(一次性) | 仍需可信设置 |
| 第三代 | 2020-2023 | Halo2, Plonky2 | 递归证明+无/轻设置 | 证明较大 |
| 第四代 | 2024-now | Plonky3, SP1, Jolt | zkVM(证明任意程序) | 性能仍在优化 |
6. 证明成本经济学
ZK证明成本结构:
证明生成(Prover端):
├── CPU/GPU算力: 主要成本
├── 内存: 大电路需要TB级内存
├── 时间: 秒到分钟(取决于电路复杂度)
└── 典型成本: $0.001-$0.10/证明
链上验证(Verifier端):
├── Gas: SNARK验证~200K gas ≈ $0.50(L1)
├── STARK验证~500K gas ≈ $1.25(L1)
└── L2验证: 便宜100x+
经济等式:
证明成本 + 链上验证Gas < 重新执行计算的成本
→ 当交易量>N时，ZK比链上执行更便宜
→ zkRollup: 把1000笔交易压缩成1个证明
→ 成本: $1(证明) + $0.50(验证) = $1.50 / 1000笔 = $0.0015/笔
→ vs L1: $0.50/笔 → 节省333x
面试题
问题：作为PM，你怎么判断一个产品是否需要ZK？
回答：
我用三个过滤条件判断：
1. 是否需要"证明而不泄露"？ 如果产品需要验证用户的某个属性(年龄>18、资产>$10K、不在制裁名单)但不想收集底层数据→ZK是正确选择。如果可以直接验证(用户上传证件、公开链上余额)→不需要ZK。
2. 是否有大量重复计算需要压缩？ zkRollup的核心价值是"1000笔交易生成1个证明"→如果你的产品有大量类似交易(DEX swap、转账)→ZK扩容有意义。如果交易量小或交易异构→ZK成本不划算。
3. 用户愿意等多久？ 证明生成需要时间(当前1-30秒)。如果产品需要实时响应(如高频交易)→ZK可能不适合。如果可以异步(如KYC验证、投票)→ZK可以。
决策矩阵：
- 隐私+高吞吐量 → zkRollup(Scroll, zkSync)
- 隐私+低频 → zkApp(zkLogin, zkKYC)
- 不需要隐私+高吞吐量 → Optimistic Rollup可能更简单
- 不需要隐私+低频 → 不需要ZK
追问准备：
- Q: SNARKs还是STARKs？→ 如果链上验证成本敏感(如L1)选SNARKs(证明更小)；如果长期安全性重要(量子威胁)选STARKs
- Q: ZK证明的用户体验挑战？→ 证明生成时间导致"等待感"，需要设计异步UX(后台生成+通知完成)