不公开余额也能验证？Zero-Knowledge Proof 在交易所 PoR 里到底证明什么

Summary

Zero-Knowledge Proof（零知识证明，ZK Proof）是一种密码学方法，可以让一方证明某个 Statement 是真的，同时不向验证者公开用于证明这个 Statement 的私密数据。

在 Crypto 领域，ZK 常用于隐私、Blockchain Scaling 和 Verifiable Computation。交易所也可以把 ZK 用到 Proof of Reserves（PoR） 中，例如证明客户负债数据满足指定计算规则，而不需要公开每一个用户的具体余额。

但是 ZK 有一个特别重要的边界：

ZK Proof 只证明系统里明确编码的 Statement。

它不能自动证明所有客户负债都被纳入，也不能单独证明交易所真的拥有足够储备，更不能证明交易所有完整偿付能力。

Key Facts

Zero-Knowledge Proof 到底是什么？

Zero-Knowledge Proof

中文通常称为：

零知识证明

简称：

ZK Proof

。

它允许一个人：

证明自己知道某个秘密，或者证明某个 Statement 成立

同时：

不把用于证明的秘密直接告诉验证者。

整个过程通常有两个角色。

Prover

即：

证明者

负责生成 Proof。

Verifier

即：

验证者

负责检查 Proof 是否有效。

一个最简单的 ZK 思路

假设 Alice 知道一个密码。

Bob 想确认：

Alice 到底知不知道这个密码？

最直接的方法是：

Alice
↓
把密码告诉 Bob
↓
Bob 验证

问题是：

Bob 现在也知道密码了。

ZK 想解决的是：

Alice 知道密码
↓
Alice 生成 Proof
↓
Bob 验证 Proof
↓
Bob 得到结论：
"Alice 的确知道密码"

但是 Bob 不知道：
密码到底是什么

真实的 ZK Cryptography 要复杂得多。

但核心思想就是：

Verify without revealing.

Zero-Knowledge Proof 需要满足哪些基本性质？

经典 ZK 系统通常强调三个核心性质。

Completeness

如果 Statement 本来就是真的，而且 Prover 正确执行协议：

Verifier 应该接受 Proof。

Soundness

如果 Statement 是假的：

作弊的 Prover 应该极难让 Verifier 相信它是真的。

Zero-Knowledge

Verifier 最终应该知道：

Statement 成立

但不应该因此得到不必要的 Private Information。

这就是：

Zero Knowledge

的核心。

Witness 是什么意思？

Witness

可以理解为：

证明者拥有、但不希望公开的私密信息。

例如 Statement 是：

“我知道一个数字，能够满足这个方程。”

那么：

Public:
Equation

Private Witness:
Secret Number

Prover 使用 Secret Number 生成 Proof。

Verifier 可以验证：

的确存在满足条件的数据。

但不需要知道 Secret Number 本身。

Public Input 和 Private Input 有什么区别？

在 ZK System 中经常会区分：

Public Input

Verifier 可以看到的信息。

例如：

Published Total Liability
10,000 BTC

Private Input

不会直接公开的信息。

例如：

Alice Balance
Bob Balance
Carol Balance
...

ZK 可以尝试证明：

这些 Private Balances 按照指定规则计算后，确实等于 Public Total。

同时不公开每个客户的余额。

这就是 ZK 对 PoR 很有价值的原因。

Interactive Proof 和 Non-Interactive Proof 有什么区别？

早期 Zero-Knowledge Protocol 可能需要 Prover 和 Verifier 多次互动。

例如：

Prover
↓
Verifier Challenge
↓
Prover Response
↓
Another Challenge
↓
Another Response

这种叫：

Interactive Proof

。

现代 Blockchain 更常见的是：

Non-Interactive Proof

Prover 生成一个 Proof 之后，其他人可以直接验证，不需要不停来回通信。

zk-SNARK 是什么？

zk-SNARK

全称：

Zero-Knowledge Succinct Non-Interactive Argument of Knowledge

。

可以拆开理解。

Zero-Knowledge

可以证明 Statement，同时尽量不泄露 Private Witness。

Succinct

Proof 通常比较小，而且可以高效验证。

Non-Interactive

Prover 和 Verifier 不需要多轮互动。

Argument of Knowledge

提供密码学证据说明：

Prover 确实掌握满足条件的 Witness。

为什么 zk-SNARK 很常见？

它的优势通常包括：

• Proof Size 小
• Verification 高效
• Privacy 强
• 可以证明复杂计算

因此广泛用于：

• Privacy
• ZK-Rollups
• Identity
• Authentication
• Proof of Reserves
• Verifiable Computation

。

什么是 Trusted Setup？

部分 zk-SNARK Proof System 需要：

Trusted Setup

来生成后续生成和验证 Proof 所需的 Public Parameters。

简单理解：

Trusted Setup
↓
Public Parameters
↓
Proof Generation
+
Verification

问题在于：

如果 Setup 过程中某些本应该销毁的 Secret 信息被保留，某些系统可能出现安全风险。

怎么降低 Trusted Setup 风险？

一种常见方法是：

Multi-Party Computation Ceremony

让多个参与者分别贡献 Randomness。

目标是：

即使不能信任所有参与者，只要至少有一个参与者诚实地销毁自己的 Secret Contribution，系统仍然可以保持相应安全性。

所有 zk-SNARK 都需要同一种 Trusted Setup 吗？

不是。

zk-SNARK 是一整类 Proof Systems。

不同设计可能采用：

• Circuit-Specific Setup
• Universal Setup
• Updatable Setup
• Different Cryptographic Assumptions

所以不能简单认为：

“SNARK = 一定使用完全一样的 Trusted Setup。”

还是要看具体实现。

zk-STARK 是什么？

zk-STARK

全称：

Zero-Knowledge Scalable Transparent Argument of Knowledge

。

这里最关键的两个词是：

Scalable

和：

Transparent

。

为什么 zk-STARK 叫 Transparent？

因为 STARK 可以使用：

Publicly Verifiable Randomness

，而不需要传统意义上的 Trusted Setup Ceremony。

所以简单比较：

Some zk-SNARK systems
→ Trusted Setup

zk-STARK
→ Transparent Setup

这可以减少一类 Trust Assumption。

zk-SNARK 和 zk-STARK 有什么区别？

可以简单比较：

所以：

SNARK 和 STARK 不是简单的“谁高级谁低级”。

需要看具体应用场景。

Crypto 为什么需要 ZK？

因为很多场景同时需要：

Privacy
+
Verification

。

通常我们为了验证一个事实，就需要看到数据。

ZK 试图改变这一点：

可以验证某些事实，而不公开所有数据。

所以它被用于：

• Private Transactions
• Blockchain Scaling
• Digital Identity
• Authentication
• Compliance
• Proof of Reserves

。

ZK 怎么帮助 Blockchain Scaling？

如果每个 Blockchain Node 都重新执行所有计算，成本会很高。

ZK 可以把大量计算放到链下，然后生成：

Validity Proof

。

例如：

Thousands of Transactions
↓
Off-Chain Computation
↓
ZK Proof
↓
Blockchain verifies Proof

这也是很多：

ZK-Rollup

的核心逻辑。

ZK 为什么特别适合 Proof of Reserves？

PoR 有一个很明显的矛盾。

交易所想证明：

Customer Liabilities 算对了。

但不能把：

Alice
4 BTC

Bob
200 ETH

Carol
$3,000,000 USDT

全部公开。

因为这是严重的 Privacy Problem。

ZK 就可以让交易所尝试证明：

客户余额满足某些计算规则

同时不公开每个客户的具体余额。

ZK 在 PoR 里能证明什么？

具体取决于：

ZK Circuit

怎么设计。

例如，它可能证明：

所有被纳入的 Balance 都符合指定规则。

或者：

所有 Input Balances 按照指定规则求和。

或者：

Public Liability Total 确实由 Private Customer Balances 正确计算出来。

例如：

Private Customer Balances
↓
ZK Circuit
↓
ZK Proof

Verifier knows:
"Rules were satisfied"

Verifier does NOT know:
Individual balances

。

为什么 ZK 对 Negative Balance 很重要？

中心化交易所可能提供：

• Margin
• Futures
• Borrowing
• Lending

所以用户可能存在：

Customer A
+10 BTC

Customer B
-8 BTC

如果简单净额计算：

10 + (-8)
=
2 BTC

在某些情况下可能压低 Liability。

ZK Circuit 可以被设计成：

对 Balance 设置特定 Constraint。

例如要求：

Balance Calculation 必须满足指定非负或会计规则。

这里最关键的一句话：ZK 只证明你让它证明的东西

这是理解 Zero-Knowledge Proof 最重要的原则。

假设一个 Circuit 证明：

所有被纳入的 Balance 都是 Non-Negative。

Proof 成功只能证明：

被纳入的数据确实满足这个规则。

它不能自动证明：

所有 Customer Account 都被纳入了。

这是完全不同的 Statement。

Correct Calculation 不等于 Complete Data

假设 ZK Proof 可以证明：

Liability Total 确实等于所有 Input Records 的正确加总。

很好。

但还有另一个问题：

Input Records 本身完整吗？

因此：

Correct Calculation
≠
Complete Inputs

。

ZK 能证明所有 Liabilities 都被纳入吗？

不能自动证明。

假设交易所真实有：

10 Million Customer Accounts

但放进 ZK System 的只有：

9.5 Million

。

ZK Proof 可以对这 9.5 Million Records 做出完全正确的数学证明。

但 Proof 本身可能不知道：

还有 500,000 个账户应该被放进来。

因此：

Valid ZK Proof
≠
Complete Liability Set

。

ZK Proof 和 Merkle Tree 有什么区别？

两者解决的问题不同。

Merkle Tree

主要解决：

这条 Record 有没有被纳入这个 Data Set？

Zero-Knowledge Proof

可以解决：

这些 Private Data 是否满足某个数学 Statement？

Merkle Tree 和 ZK 为什么经常一起出现？

因为它们互补。

例如：

Customer Account
↓
Merkle Proof
↓
My Balance Was Included

同时：

Private Liability Data
↓
ZK Proof
↓
Calculation Rules Were Satisfied

。

一套 PoR 可以同时提供：

Inclusion Verification

和：

Constraint Verification

。

ZK 能证明交易所有储备资产吗？

不能单独证明。

PoR 有两边：

Liabilities

Customer Balances

Assets

Exchange Reserve Wallets

ZK Liability Proof 主要处理前者。

储备资产还需要单独验证：

• Wallet Addresses
• On-Chain Balances
• Wallet Control

因此：

Valid ZK Liability Proof
≠
Proof of Reserve Assets

。

ZK 能证明交易所控制 Wallet 吗？

不能自动证明。

如果交易所声称某些 Wallet 是 Reserve Wallet：

仍然需要证明它确实控制这些钱包。

可以通过：

• Cryptographic Signature
• Signed Message
• Independent Verification

等方式验证。

ZK 能证明储备没有被抵押吗？

不能。

就算：

Reserve Assets Exist

同时：

Liability Calculation Is Valid

仍然可能不知道 Reserve Assets 有没有：

• Pledged as Collateral
• Lien
• Borrowing
• Other Security Interests

所以：

ZK 不会自动消除 Asset Encumbrance Risk。

ZK 能证明 Customer Assets 已经隔离吗？

不能。

Asset Segregation 是：

法律和运营结构问题。

它关心：

Customer Assets 是否和 Exchange Corporate Assets 分开？

而 ZK Proof 主要证明：

Mathematical Statement。

不是同一个问题。

ZK 能证明交易所有 Solvency 吗？

不能。

即使你已经有：

Correct Liability Calculation
+
Verified Reserve Wallets

仍然可能不知道交易所有没有：

• Bank Debt
• Corporate Loans
• Tax Liabilities
• Legal Claims
• Vendor Debt
• Asset Encumbrance
• Other Creditors

所以：

ZK Proof
≠
Complete Balance Sheet

同时：

ZK PoR
≠
Proof of Solvency

。

一个简单的 ZK PoR 例子

假设交易所有三个用户：

Alice
2 BTC

Bob
5 BTC

Carol
3 BTC

总负债：

10 BTC

但交易所不希望把：

Alice、Bob、Carol 的余额

全部公开。

它可以把这些余额作为：

Private Inputs

。

例如：

Private Inputs
2
5
3

Rules
Balances satisfy required constraints

Public Claim
Total = 10 BTC

然后生成一个 ZK Proof。

Verifier 可以知道：

这些 Private Inputs 按照 Circuit Rules 可以得到 10 BTC。

但不用知道每个人具体有多少。

如果交易所故意漏掉 Carol 呢？

假设真实数据是：

Alice
2 BTC

Bob
5 BTC

Carol
3 BTC

但交易所只向 Circuit 输入：

Alice
2 BTC

Bob
5 BTC

ZK Proof 仍然可能完全正确地证明：

2 + 5
=
7

。

它不会自动知道：

Carol 应该存在。

所以：

Proof Correctness
≠
Input Completeness

。

这就是用户理解 ZK PoR 时最重要的限制之一。

什么是 ZK Circuit？

ZK Circuit

可以理解为：

Proof System 需要验证的一组数学规则。

例如一个 PoR Circuit 可能规定：

Rule 1
Balance satisfies constraint

Rule 2
Balances are summed correctly

Rule 3
Published total equals calculated total

。

最终 Proof 证明：

这些规则全部成立。

为什么 Circuit Design 非常重要？

因为：

没有写进 Circuit 的规则，Proof 不会自动帮你检查。

假设 Circuit 只要求：

Published Total
=
Sum of Inputs

却没有机制证明：

All Customer Accounts
Were Included

那么它就不能给出 Liability Completeness Assurance。

ZK Circuit 会不会有 Bug？

会。

密码学本身可以非常严谨。

但真正上线的是：

Software + Circuit + Implementation

。

仍然可能出现：

• Logic Bug
• Implementation Error
• Missing Constraint
• Incorrect Assumption
• Security Vulnerability

所以判断一套 ZK PoR 时，还要看：

• Open-Source Code
• Technical Documentation
• Independent Audit
• Verification Tool

。

Verification Key 是什么？

很多 Non-Interactive ZK Systems 会提供 Public Information，让其他人验证 Proof。

例如：

Proof
+
Public Inputs
+
Verification Key
↓
Verifier
↓
Valid / Invalid

具体形式会根据 Proof System 不同而变化。

普通用户可以自己验证 ZK Proof 吗？

如果交易所真正开放验证材料：

可以。

例如可能提供：

• Proof Files
• Public Inputs
• Verification Software
• Open-Source Tools
• Technical Documentation

用户或 Independent Researcher 可以自己跑 Verification。

这明显比只在官网写：

ZK Verified ✓

更有意义。

真实交易所已经在 PoR 里使用 ZK 了吗？

是。

截至 2026 年 8 月，OKX 的公开 Proof of Reserves Archive 仍然提供：

zk-STARK v2

Proof Files。

它分别提供：

• Reserves
• Liability Reports

相关验证材料，同时也提供 Reserve Wallet Address Verification。

这正好说明：

ZK 不是用来替代所有 PoR 验证的。

更完整的思路是：

ZK Liability Verification
+
Reserve Asset Verification

。

zk-SNARK 和 zk-STARK 哪个更适合 PoR？

普通用户不需要看到：

zk-STARK

就默认认为一定比：

zk-SNARK

更好。

真正应该问：

• 它到底 Proof 什么？
• Methodology 是否公开？
• 是否可以 Independent Verification？
• Setup Assumption 是什么？
• Customer Balance 怎么处理？
• Liability Completeness 怎么处理？
• Reserve Assets 怎么验证？

所以：

Implementation 比 Acronym 更重要。

“zk-STARK Verified”一定比“Merkle Verified”高级吗？

不能这样判断。

Merkle Tree 更擅长：

Inclusion Verification

ZK 更擅长：

Mathematical Constraint Verification

一套 PoR 完全可能同时需要两者。

因此：

zk-STARK
>
Merkle Tree

不是一个有意义的通用结论。

ZK Proof 和 Encryption 有什么区别？

Encryption

主要解决：

怎么把数据隐藏起来？

ZK Proof

解决：

怎么在不公开数据的情况下，证明数据满足某个条件？

例如：

Encryption:
"我把余额加密起来。"

ZK:
"我不告诉你余额，
但可以证明余额满足这条规则。"

ZK Proof 和 Hash 有什么区别？

Hash

把 Data 转换成固定长度 Digest。

ZK Proof

可以证明：

Private Data 满足某个更复杂的数学 Statement。

ZK 的表达能力通常明显高于普通 Hash。

ZK Proof 和 Digital Signature 有什么区别？

Digital Signature 更接近证明：

持有某个 Private Key 的人签署了这条信息。

ZK Proof 可以证明：

我拥有满足某种条件的数据。

而且不一定要公开这些数据。

Zero-Knowledge 真的什么信息都不透露吗？

这个名字容易让人误会。

Zero-Knowledge 的意思不是：

Verifier 什么都不知道。

而是：

除了 Statement 本身所必然透露的信息之外，不额外泄露 Witness。

例如你证明：

我的账户余额大于 $1 million。

Verifier 仍然学到一个事实：

你的余额大于 $1 million。

只是它不知道：

到底是 $1.1 million 还是 $10 million。

所以：

你选择证明什么 Statement，本身也会影响 Privacy。

ZK 会让整个系统完全 Trustless 吗？

不会自动做到。

即使使用 ZK，你仍然可能需要相信或验证：

• Source Data 是否正确
• Input 是否完整
• Circuit 是否正确
• Software 有没有 Bug
• Verification Parameters 是否可信
• Wallet Attribution 是否正确
• Reserve Assets 是否真实
• Legal Ownership 是否成立

所以：

ZK
≠
No Trust Assumptions Anywhere

。

看到“ZK Proof of Reserves”应该怎么判断？

不要只看到：

zk-SNARK ✓

或者：

zk-STARK ✓

就结束。

建议继续检查。

1. 到底在证明什么 Statement？

这是最重要的问题。

证明的是：

• Balance Constraint？
• Liability Total？
• User Inclusion？
• 还是其他东西？

2. 覆盖哪些 Assets？

例如：

• BTC
• ETH
• USDT
• USDC
• 其他资产

。

3. 覆盖哪些 Products？

是否包括：

• Spot
• Margin
• Futures
• Earn
• Lending
• Staking

？

4. 用户能自己验证账户吗？

有没有：

• Merkle Proof
• Account Verification
• User-Level Inclusion

？

5. Proof Files 能不能下载？

Independent Researcher 能不能自己 Verify？

6. Verification Software 是否公开？

只有一个：

ZK Verified
✓

远远不够。

7. Liability Completeness 怎么证明？

这是关键。

一个数学上正确的 ZK Proof：

仍然可能建立在不完整的 Inputs 上。

8. Reserve Assets 怎么验证？

继续查：

• Wallet Addresses
• On-Chain Balance
• Wallet Control

。

9. Assets 是否有 Encumbrance？

ZK Liability Proof 不会自动回答。

10. 数据有多新？

检查：

• Snapshot Date
• Report Date
• Update Frequency

。

Frequently Asked Questions

Zero-Knowledge Proof 是什么？

Zero-Knowledge Proof 是一种密码学方法，让 Prover 可以证明某个 Statement 成立，而不公开用于证明的 Private Data。

Crypto 里的 ZK 是什么意思？

ZK 是 Zero-Knowledge 的缩写，常见于 Privacy、Blockchain Scaling 和 Verifiable Computation。

Prover 是什么？

Prover 是负责生成 Zero-Knowledge Proof 的一方。

Verifier 是什么？

Verifier 负责检查 Proof 是否有效。

Witness 是什么？

Witness 是 Prover 用来生成 Proof 的私密信息。

zk-SNARK 是什么？

zk-SNARK 是 Zero-Knowledge Succinct Non-Interactive Argument of Knowledge。

zk-STARK 是什么？

zk-STARK 是 Zero-Knowledge Scalable Transparent Argument of Knowledge。

zk-SNARK 和 zk-STARK 有什么区别？

STARK 通常强调 Transparent Setup 和 Scalability；SNARK 通常具有较小 Proof Size 和高效 Verification。具体仍然取决于 Proof System。

zk-SNARK 需要 Trusted Setup 吗？

部分 SNARK Systems 需要，具体取决于使用的构造方式。

zk-STARK 需要 Trusted Setup 吗？

STARK 通常使用 Transparent Setup，不依赖传统 Trusted Setup Ceremony。

为什么 PoR 使用 ZK？

因为它可以验证 Private Customer Liability Data 的某些数学性质，同时避免公开每个用户的余额。

ZK 能防止 Negative Balance Manipulation 吗？

如果 Circuit 明确编码相关 Balance Constraints，就可以验证这些规则是否满足。

ZK 能证明所有客户都被纳入吗？

不能自动证明。

ZK 能证明全部 Liabilities 吗？

不能单独证明 Input Completeness。

ZK 能证明交易所有 Reserve Assets 吗？

不能单独证明，需要另外验证 Reserve Wallets 和 Assets。

ZK 能证明交易所控制 Wallet 吗？

不能自动证明。

ZK 能证明 Reserve Assets 没有被抵押吗？

不能。

ZK 能证明交易所有 Solvency 吗？

不能。

ZK Proof 和 Merkle Proof 一样吗？

不一样。Merkle Proof 更侧重 Inclusion，ZK Proof 可以证明更复杂的 Private Mathematical Statement。

Merkle Tree 和 ZK 可以一起使用吗？

可以，而且在 PoR 中两者可以互补。

“ZK Verified”代表交易所安全吗？

不代表。

Key Takeaway

Zero-Knowledge Proof 真正解决的问题是：

“如何在不公开 Private Data 的情况下，证明关于这些数据的某个 Statement 是真的？”

在 Proof of Reserves 里，可以表现为：

Private Customer Balances
↓
ZK Circuit
↓
ZK Proof

Verifier 得到：
"指定规则确实成立"

Verifier 看不到：
每个用户的具体余额

但最关键的限制是：

ZK proves
the encoded statement

而不是：

ZK proves
everything about the exchange

即使 ZK Proof 完全有效，也不能自动证明：

所有 Liabilities 都已经被纳入
→ 不能自动证明

Reserve Assets 真实存在
→ 需要单独验证

Reserve Assets 没有被抵押
→ 不能证明

Customer Assets 已经隔离
→ 不能证明

Exchange 没有其他 Corporate Debt
→ 不能证明

Exchange 有完整偿付能力
→ 不能证明

所以当交易所说：

“Our Proof of Reserves uses zero-knowledge proofs.”

真正应该问的不是：

“用了 ZK 吗？”

而是：

“这套 ZK Proof，到底在证明什么？”