跳到正文
Financial Context Wiki

零知识证明

准确理解零知识证明：完备性、可靠性、模拟、见证、设置假设、区块链用途与验证风险。

更新于

仅供教育参考，不构成投资或安全建议。有效证明只在证明系统的假设下保证已编码的陈述。

直接答案

零知识证明（ZKP）让证明者在不泄露用于建立陈述的秘密见证的情况下，使验证者相信该陈述为真。其形式化保证不是“交互记录中完全没有信息”，而是除公开陈述本身能够推出的信息外，合规验证者学到的内容都可以在不知道见证的情况下模拟出来。

证明系统需要分别考察三个性质：完备性，即持有有效见证的诚实证明者会被接受；可靠性，即虚假陈述仅以可忽略概率被接受；零知识性，即见证在规定的威胁模型下保持隐藏。许多实用系统属于计算型论证：可靠性只针对计算能力受限的攻击者成立，并依赖明确列出的密码学假设。

零知识性也不同于简洁性和有效性。证明可以是零知识但验证成本很高，可以很简洁却公开数据，也可以正确证明一个已编码关系，但该关系并不符合应用原本想执行的规则。

1
执行

证明者执行一批交易或计算，得到状态变化。

工作原理

先定义公开陈述 x、私密见证 w 和精确关系 R。证明者生成证明，验证者使用公共参数或验证密钥进行判断。预期的可靠性主张可概括为：

Verify(vk, x, proof) = 1 => exists w: R(x, w) = 1

该式只说明已编码关系存在合适见证。它不会公开见证，也不会认证链下输入，更不能证明 R 已覆盖应用想要执行的所有业务规则。

  • 交互式与非交互式。 早期 ZK 协议交换挑战和响应。非交互式系统把证据装入一个证明，通常依赖设置材料、随机预言机模型或两者。
  • 设置模型。 Groth16 的证明很小，但需要针对电路的结构化设置。PLONK 类系统可使用通用、可更新的结构化参考字符串。STARK 构造不需要结构化可信设置，但通常证明更大，并依赖哈希和低度测试。
  • 算术化与承诺。 实现会把程序转换成代数约束，对由见证推导的值作承诺，再用随机化检查，让验证者无需重做计算或查看见证便能检验结果。
  • 知识证明。 有些系统还主张通过证明提取器形式化地说明，被接受的证明者“知道”一个见证。这是独立性质，不能仅从“零知识”标签推断。

示例

假设 x 包含一个承诺和 100 units 的门槛，w 包含被承诺的余额与致盲因子。关系会检查承诺能否正确打开，以及余额是否至少为 100 units。有效的零知识证明可以确认这项关系而不披露准确余额。

但结果本身不能证明证明者拥有该账户、资金未被占用，或同一承诺没有重复使用。这些主张需要额外约束和公开输入。

在隐私型加密货币中，电路可以在隐藏部分交易细节的同时强制检查授权、价值守恒与防重复。在有效性 Rollup 中，证明可以确认一批状态转换；系统仍可能公开交易数据，因此“ZK Rollup”不自动等于私密交易。

风险

  • 不完整或错误的电路可能完美证明错误规则。
  • 缺失域分离、链标识、根或承诺，可能把证明绑定到错误上下文。
  • 对需要可信设置的系统，设置被攻破或“有毒废料”未销毁会破坏可靠性。
  • 证明器、验证器、交互记录、曲线、哈希、编译器或智能合约的缺陷可能使理论保证失效。
  • 公开输入、证明时间、交易图、费用和网络元数据可能泄露形式化 ZK 陈述之外的信息。
  • 见证生成、浏览器、硬件或远程证明服务中的侧信道可能在生成证明前暴露秘密。
  • 验证证明并不提供数据可用性、排序器活性、结算最终性、抗审查性或安全升级。
  • 不同证明系统的密码学假设和具体安全余量不同；不能只按证明大小或验证速度评定安全性。

常见误区

  • “零知识意味着不公开任何数据。” 公开陈述和有意暴露的输出仍然可见，证明模型之外的元数据也可能泄露。
  • “证明有效就代表应用正确。” 它只表示已编码关系被接受，电路、集成和策略错误仍然可能存在。
  • “所有 ZK 系统的信任假设相同。” 设置仪式、曲线、哈希、交互记录模型和升级控制均有实质差异。
  • “ZK 就是加密。” 加密隐藏数据以供获授权者解密；ZK 证明无需发送见证供人解密便能建立主张。

相关主题

来源

导航

搜索知识库...