Featured image of post 零知识证明入门——从直觉例子到 zk-Rollup
Web3 区块链 安全防护

零知识证明入门——从直觉例子到 zk-Rollup

零知识证明听起来玄学，但工程理解并不难。本文用直觉例子 + 真实场景把 ZKP、zk-SNARK、zk-Rollup 讲清楚

让 ZKP 变得直观的一个例子

零知识证明（Zero-Knowledge Proof，ZKP）听起来像是数学教授的玄学。但它要解决的问题，可以用一个生活化的场景描述：

小明给小红打电话：“我有这个保险柜的密码。” 小红怎么验证小明真的知道，又不想小明把密码告诉她？

朴素方案：小明把密码报给小红——但泄漏了密码。

零知识证明的方案：

  1. 小红把保险柜搬到一个房间里，柜子里放一张写着随机字符串的纸
  2. 小明进房间打开柜子，把纸上的字符串记下，再锁上柜子出来
  3. 小明把字符串报给小红——他能报出来，证明他确实开过柜子，但他没说密码

这就是 ZKP 的本质：

证明者（Prover）向验证者（Verifier）证明『某件事是真的』，过程中不泄漏任何额外信息。

本文从直觉到实战，把零知识证明、zk-SNARK、zk-Rollup 讲清楚——不需要数学基础。

一、零知识证明的三个性质

正式定义里 ZKP 必须满足三个性质：

  1. 完备性（Completeness）：如果命题为真，诚实的证明者一定能让诚实的验证者相信
  2. 可靠性（Soundness）：如果命题为假，作恶的证明者几乎无法让验证者相信（概率忽略不计）
  3. 零知识性（Zero-Knowledge）：验证过程不泄漏除"命题为真"以外的任何信息

第三点是最关键、最反直觉的——证明的过程绝对不能让验证者知道任何具体内容。

二、最经典的例子：Ali Baba 洞穴

1
2
3
4
5
6
7

                洞口
                 |
              [岔路口]
              /     \
           A         B
              \     /
            [魔法门 - 需要密语]

小明（Prover）声称知道魔法门的密语。小红（Verifier）想验证。

验证流程

  1. 小红站在洞口外，不能看见岔路口
  2. 小明随机走 A 或 B 路径
  3. 小红走到岔路口，喊"从 A 出来"或"从 B 出来"
  4. 小明按要求出来
  5. 重复上述流程 N 次

为什么这是 ZKP

  • 完备性：小明真的知道密语 → 100% 能按要求出来
  • 可靠性：小明不知道 → 每次只有 50% 几率猜对，重复 30 次后猜对的概率是 (1/2)³⁰ ≈ 十亿分之一
  • 零知识性：小红观察整个过程，只看到"小明能按要求出现"——没学到密语

这个洞穴比喻出自 Quisquater、Guillou、Berson 1990 年发表的 How to Explain Zero-Knowledge Protocols to Your Children （CRYPTO ‘89 论文集）。零知识证明本身的正式定义则更早——由 Goldwasser、Micali、Rackoff 在 1985 年的《The Knowledge Complexity of Interactive Proof-Systems》里给出。

三、互动式 vs 非互动式

上面的洞穴例子是互动式——验证需要双方反复来回。互动式 ZKP 有几个限制：

  • 验证者必须在线
  • 不能给第三方公开验证
  • 不适合区块链场景

非互动式零知识证明（NIZK） 解决这些——Prover 一次性产出一个证明，任何人拿到都能验证。

1
2

Prover:    ----proof----> Verifier
                          (独立验证，无需 Prover)

NIZK 的关键技术是 Fiat-Shamir 变换——把 Verifier 的随机挑战换成对 Prover 提交的某种 hash，用 hash 的不可预测性替代真实的随机交互。

NIZK 是区块链应用 ZKP 的基础。

四、zk-SNARK：高效的 NIZK

ZKP 在理论上几十年前就有了，但实际能用是从 zk-SNARK 开始。

zk-SNARK = Zero-Knowledge Succinct Non-interactive ARgument of Knowledge

逐字解读：

  • Zero-Knowledge：零知识
  • Succinct：证明体积很小（几百字节）
  • Non-interactive：非互动
  • Argument of Knowledge：能"证明知道某个秘密"

它的实战意义——你能把任何复杂计算（如"这笔交易合法"）压缩成几百字节的证明，验证只要毫秒级。

Zcash：第一个商用案例

Zcash（2016）是第一个用 zk-SNARK 做"完全隐私交易"的区块链——

  • 链上看到的是加密的发送方、接收方、金额
  • 但每笔交易都附一个 SNARK 证明，证明这笔交易合法（没双花、有足够余额、签名正确）
  • 验证者验证 SNARK，无需知道任何细节

链上数据完全隐私——但合法性能被任何节点验证。这是 ZKP 工程化最有代表性的应用之一。

五、ZKP 在以太坊：zk-Rollup

以太坊主网 TPS 低、Gas 贵——这是公链扩容的核心问题。Layer2 是主流方向，zk-Rollup 是其中最被看好的一种。

zk-Rollup 的工作流：

  1. Sequencer 在 L2 收集大量交易（数千笔）
  2. 在 L2 执行所有交易，得到新状态
  3. 生成一个 SNARK 证明——“我执行的所有交易都合法，新状态由旧状态正确得出”
  4. 把证明 + 新状态根提交到 L1
  5. L1 验证 SNARK——验证通过则更新状态

为什么 zk-Rollup 比 Optimistic Rollup 强

维度Optimistic Rollupzk-Rollup
安全模型假设没有作弊，挑战期内可证伪数学证明，每次都验证
提款延迟7 天（挑战期）即时
验证成本仅作弊时验证每次都验证
证明生成成本低（不需要）高（需要 zk 电路）
适合 EVM容易难（zkEVM 是新课题）

zk-Rollup 的劣势是『证明生成成本高 + EVM 兼容难’——但生态正在快速进化（zkSync、StarkNet、Linea、Scroll 都是 zk 系 L2）。

六、ZKP 还能用来做什么

ZKP 的应用远不止隐私交易和扩容：

1. 隐私身份认证

证明"我已成年"——不告诉对方具体年龄。 证明"我是某机构员工"——不告诉对方公司全部员工列表。

2. 私有投票

证明"我投了一票"——不告诉投了谁、不让人知道我是谁。

3. 数据隐私查询

证明"我的某项数据满足条件 X"——不暴露数据。

4. zkML（机器学习）

证明"模型 M 在输入 X 上得到了输出 Y"——不暴露模型权重或输入。

5. zk Bridge / zk Light Client

跨链桥用 ZKP 证明源链状态——避免传统跨链桥的多签信任假设。

6. zk Email / zk Login

证明"我有这个邮箱的访问权"——不暴露邮箱内容。

七、零知识证明的"证"和"建电路"

工程上做 ZKP 不是写一段普通代码——而是把要证明的命题翻译成『算术电路』。

1
2
3
4
5

要证：x² + y² < 100
↓ 翻译
电路：(x*x) + (y*y) - 100 < 0
↓ 用 zk DSL 写
ZKP 框架编译电路 + 生成证明

主流框架：

框架特点
CircomDSL 写电路，配 snarkjs 生成证明
Halo2Rust 写电路，无需 trusted setup
CairoStarkNet 用，专为 STARK 设计
NoirAztec 出品，类 Rust 语法
Risc Zero通用 zkVM，能跑任意 Rust 代码
SP1通用 zkVM，类似 Risc Zero

一个 Circom 例子

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

template IsAdult() {
    signal input age;
    signal input minAge;
    signal output ok;

    component lt = LessThan(8);
    lt.in[0] <== minAge;
    lt.in[1] <== age + 1;
    ok <== lt.out;
}

写一段电路、编译出 wasm 和 r1cs 文件、用 snarkjs 给"输入"生成证明、上链验证。

八、ZKP 的代价和限制

ZKP 听起来万能，但代价不小：

1. 证明生成慢

复杂电路可能要几分钟到几小时才能生成一个证明——证明者侧的算力消耗大。

2. 证明体积小，但验证仍要 Gas

zk-SNARK 验证大约 200-500K gas——比传统验证贵，但比 Optimistic Rollup 的"挑战 + 仲裁"安全得多。

3. Trusted Setup 风险

部分 SNARK 方案（Groth16）需要 trusted setup——一组人共同生成参数，只要有一个参与者诚实，参数就安全。但这增加了信任成本。Halo2、PLONK、STARK 都不需要。

4. 电路开发门槛高

写电路是一种新范式——和写普通代码差别很大。需要的 bug 排查能力、性能调优能力都不同。

5. 工具链还在演进

调试器、IDE、profiler 工具都在快速发展中——但远不如传统编程成熟。

九、ZK-SNARK vs ZK-STARK

SNARKSTARK
证明大小小（KB 级）中（数十 KB 到 MB）
验证速度快中
证明生成中快
Trusted Setup多数需要不需要
抗量子✗✓（基于 hash）
用例Zcash、zkSync v2、LineaStarkNet、Polygon Miden

工程上：SNARK 适合"证明 + 验证"链上场景（小证明、低 Gas），STARK 适合"高吞吐 + 强抗量子"场景。

十、了解了 ZKP，对工程意味着什么

作为应用开发者，你未必需要写电路——但你需要：

  1. 理解 ZKP 的能力边界——什么场景能用 ZKP，什么场景不能
  2. 知道 zk 系 L2 的取舍——zkSync / StarkNet / Linea 在什么场景胜过 Optimistic Rollup
  3. 理解隐私 / 合规的新可能——ZKP 让"既符合监管又保护用户隐私"在技术上可行

理解 ZKP 的工程价值不在于"会用 Circom"，而在于在产品设计时知道 ZKP 是一项可选武器。

小结

把全文压一句：

零知识证明让你能『证明你知道某件事，但不暴露具体内容』——把『可验证』和『隐私』这对看似矛盾的需求统一起来。

工程视角：

  • SNARK 是当下主流，但 STARK / Halo2 在崛起
  • zk-Rollup 被普遍认为是以太坊扩容最有前景的方向之一——但目前生态还在追赶 Optimistic
  • 隐私身份、隐私投票、zkML 是未来 5 年最有想象力的方向
  • 学 ZKP 不是必须会写电路——理解它的能力边界，知道何时使用，已经是巨大进步

零知识证明在 2010 年还主要停留在学术研究阶段，到 2020 年才在 Web3 工程中真正落地。**它正在重塑互联网中『可验证』和『隐私』的边界 **——值得每个工程师入门了解一次。

© 2016 - 2026 牛哥聊技术
使用 Hugo 构建
主题 Stack 由 Jimmy 设计