English version · 区块链学习导航 · 上一篇
区块链学习 · 文章 BC018
零知识证明可以让验证者在证明系统规定的安全模型下，检查一个定义精确的声明，同时不取得私密支持信息。真正有用的问题，不是孤立地问“这是不是零知识”，而是：究竟检查什么声明，哪些输入公开，哪些信息保持私密，以及什么假设把声明连接到应用？
本篇是一堂声明设计实验课。我们会规定一个虚构分配声明，测试缺失条件，并检查成功证明仍然会透露什么。文章不会构造或生成实际密码学证明。手工检查玩具算术，只是在演示预期关系，不是在证明真实实现具有零知识性质。
更广的数学背景，可参考数学如何运作：密码学（英文）。本篇发展另一项技能：审查证明的声明与隐私边界。
选择适合你的阅读路线
本篇目录
- 一、把声明与支持它的见证分开
- 二、定义一个虚构分配声明
- 三、列出公开输入与见证清单
- 四、先测试关系，再讨论隐私
- 五、删除一个条件，声明会变弱
- 六、“零知识”不会抹掉公开推论
- 七、三类保证，各有职责
- 八、分配声明没有建立什么？
- 九、有意识地绑定背景与新鲜性
- 十、分别审查实现与成本主张
- 十一、声明审查练习
- 常见问题
- 来源与下一步阅读
如果术语还陌生，先区分公开输入与私密见证。然后通过分配例子，观察一个声明怎样变成约束清单。应用审查可重点看缺失条件、公开披露、重放，以及最后的声明卡。
你只需基础整数运算，不涉及个人记录、金融交易、秘密密钥或生产证明工具。
一、把声明与支持它的见证分开
证明系统使用明确的关系，也就是规定哪些公开与私密输入组合有效的规则。公开输入选定本次检查的具体声明；私密支持资料通常称为见证（witness），有些实现还把中间值包括在这个词里。
例如，“我知道一个输入，它的哈希等于这个公开摘要”，把公开摘要与私密输入分开了。它不需要隐藏摘要存在，也不需要隐藏验证者正在检查这个关系。
halo2 Book 的证明系统章节区分关系、电路实现、公开输入和见证，也把普通可靠性与知识可靠性分开。如果应用需要证明者确实知道支持资料，而不只是存在某种合适资料，这个区别就很重要。
不要把每个零知识证明都描述成隐藏声明本身。许多应用会有意公开声明和公开输入，同时保护见证。协议是否还保护其他信息，要看精确构造与安全定义。
二、定义一个虚构分配声明
一个虚构工作坊把十二张演示卡分到两个托盘，每个托盘可以有 0 至 9 张，数量必须是整数。工作坊希望公开总数，并证明分配符合限制，却不公开两个数量组成的精确有序数对。
把第一个托盘的数量叫 x，第二个叫 y。预期算术条件是：
- x 是 0 至 9 的整数。
- y 是 0 至 9 的整数。
- x 加 y 等于公开总数 12。
单看这些条件，任何人都很容易满足，例如选择 6 和 6。如果应用需要说明某个先前已记录的分配，就必须连接到那个分配，而不是只证明存在某个方便的数对。
因此，我们加入对有序数对的公开承诺 C。这个概念实验明确假设：使用一套适当规定、具有所需隐藏性和绑定性的承诺方案，包括其秘密随机量与编码规则。不能拿七个可猜数对之一的普通哈希，代替这个假设。
见证包含 x、y，以及打开 C 所需的私密信息。关系必须检查：这个见证确实打开特定公开承诺，并满足范围与总和条件。练习没有实际承诺值，也没有密码学证明；承诺是设计中明确假设的组件。
三、列出公开输入与见证清单
声明卡记录以下公开输入：承诺 C、总数 12、上限 9，以及精确规定的关系或验证程序标识。应用还记录本次声明对应哪个工作坊轮次、哪条被接受承诺记录。
私密见证包含有序数量 x、y，以及所需承诺打开信息。真实电路可能根据操作表示方式，还需要额外中间见证值。这些实现细节仍然必须支持预期关系。
现在用普通语言写声明：“存在处于允许范围内的整数数量，它们能打开这个被接受承诺，并且总和为 12。”如果应用要求证明者知道这种打开信息，就必须选择并验证具有相应知识属性的系统，不能只凭“证明”二字推断。
把应用接受条件放在数学声明旁边：C 是本轮登记的承诺吗？验证者使用预期关系版本吗？提交是否获授权？按照真实协议，这些检查可能在证明内部或外部进行，但不能直接省略。
这样的清单可以避免一个常见误区：某个值与证明出现在同一网页，不代表它已绑定进证明，或已被接受应用检查。
四、先测试关系，再讨论隐私
公开总数为 12 时，允许的有序数对是：
- 3 与 9。
- 4 与 8。
- 5 与 7。
- 6 与 6。
- 7 与 5。
- 8 与 4。
- 9 与 3。
共有七对。因为两个托盘名称不同，所以顺序有意义。七对都符合范围与总和，但在绑定性假设下，只有与特定承诺一致的打开信息，才应满足完整关系。
纸上检查可以采用 4 和 8，并假设承诺打开检查成功。4 在允许范围内，8 也在允许范围内，总和为 12。这只是在假设下展示有效算术见证。把数字展示给全班，不是零知识协议，而是检查预期约束的方法。
接着试 2 和 10：总和为 12，但第二个范围条件失败。再试 4 和 7：两个范围都通过，总和却失败。正确验证预期关系的程序，不能因为多数检查通过，就接受其中任何一个。
这些小型反例很有价值，因为再先进的证明系统，也不能补救应用要求它证明错误关系的问题。
五、删除一个条件，声明会变弱
先删去承诺打开条件。证明者便可选择任何方便的有效数对，不管之前记录了什么。证明可能正确建立一个更弱的算术声明，却没有建立应用原本想要的特定分配联系。
再保留承诺，但删除范围条件。整数数对 20 与负 8 的总和也为 12。如果余下关系允许这些值，证明就不再建立每个托盘数量都合规。
表示方式还可能带来另一种缺口。许多电路在有限域上运算，而不是在普通无界整数上运算。另用一个模数为 101 的玩具域来看，100 加 13 的余数是 12。这个模等式成立，但两个数量都违反预期的 0 至 9 范围。
生产设计必须正确实现预期整数约束与编码。在我们的玩具中，有效数量总和最多为 18，小于 101，因此规定范围也会阻止这一种回绕混淆。这只是可以手算的说明，不是选择生产有限域或范围证明实现的指南。
最后，假设应用没有检查关系版本。某个旧版、较弱关系的有效证明，可能被误当成符合较强新政策的证明。验证密钥、电路身份、公开输入结构和应用接受政策，都必须对应预期声明。
六、“零知识”不会抹掉公开推论
总数为 12，两个数量都在 0 至 9 之间，观察者已经知道每个数量至少为 3。这个结论只来自公开约束，不是证明有缺陷造成的泄漏。
现在把公开总数改为 18，范围不变。只剩有序数对 9 与 9。即使理想的零知识协议，也不能隐藏应用有意公开的声明在逻辑上已经强制确定的信息。
因此，隐私审查必须检查公开输入、输出和重复查询。即使每次证明都满足形式化零知识定义，足够多的相关问题仍可能缩小可能范围。跨重叠群体公布总数的政策，也许会披露设计者没有预期的信息。
适当隐藏的承诺，也是与证明零知识性质不同的独立假设。如果应用公开一个很小候选集合的普通摘要，别人可能无需攻击证明，就能逐个测试候选。私密见证无法修复另一个字段已经披露的信息。
所以，正确隐私问题是：从整个获准公开的交互记录和周围数据，观察者能推断什么？“见证从未直接打印出来”是有用事实，却不是完整答案。
七、三类保证，各有职责
完备性关心诚实参与者在系统规定条件下使用有效输入时能否被接受。可靠性限制作弊证明者让验证者接受错误声明的能力。零知识关心：除允许的声明及公开信息已经表达的内容外，验证者还会不会了解到私密支持信息。
这些属性有精确定义，在不同系统中可能采用完美、统计或计算意义。ZKProof 社区参考文档第 0.3 版讨论这些区别。该版本日期为 2022 年 7 月 17 日，并明确标注为未完成草案，不是已经完成的通用标准。
术语还按照对手计算能力等假设，区分严格意义的 proof 与 argument。入门文章常把两者广义称作“证明”；技术评估应检查实际保证，不能从产品标签自行推断。
对本工作坊而言，可靠地证明一个规定错误的关系，仍然是错误证据。保护隐私的证明，也可能公开一个信息过多的总数。数学上完备的构造，也可能被实现错。每一层要回答的问题不同。
八、分配声明没有建立什么？
假设工作坊操作员没有清点实物托盘，而是把虚构数量写入承诺。有效证明可以建立与这些被承诺数字的一致性，却不能观察托盘，也不能认证操作员诚实测量。
如果现实准确性重要，应用需要适当来源或证明材料流程，并承认其信任假设。零知识证明可以帮助检查已认证数据的属性，而不披露全部内容；但它不会仅因自身存在，就创造最初的认证或观察。
同样，关于 C 的证明，不代表 C 是当前被接受承诺。区块链应用必须把证明连接到适当记录状态，并执行更新规则。旧证明对旧公开输入仍然有效，却可能不适合今天的请求。
证明也不保证所有必要底层文件可以取得、用户界面诚实，或证明者机器从未在别处披露见证。如果流程把见证发送给远程证明服务，该服务可能收到它。对最终验证者保密，不自动等于对生成路径中的所有服务保密。
这些是设计问题，不是拒绝技术的理由。声明与边界符合任务时，一个有用证明可以显著减少披露。
九、有意识地绑定背景与新鲜性
设想为工作坊 A 轮生成的证明，被复制到 B 轮。如果接受应用只检查通用算术关系，就可能漏掉声明对应不同承诺或用途这个事实。
设计应明确：哪些背景绑定进关系或外围已认证协议，哪些接受状态阻止不适当重复使用。仅在证明旁显示轮次标签，不会建立绑定；仅在界面添加公开字段，也不保证验证程序真的检查它。
知识声明尤其需要谨慎。某人转交另一个人原先生成的可转移证明，不应自动被认证为原证明者。halo2 Book在讨论知识可靠性时，提醒了重放等协议问题。
本实验不自创防重放机制，而是写明需求：“应用必须核验正确承诺与轮次，并执行规定的授权和重复使用政策。”真实协议随后必须说明怎样实现。
由此可见，声明卡比“证明但不透露”的口号更有用。它准确显现数学关系在哪里结束，应用决定从哪里开始。
十、分别审查实现与成本主张
电路是关系的实现，不是那句自然语言本身。审查者需要证据说明：约束确实表达了预期范围、总和、承诺打开和公开输入绑定。只测试普通例子，可能漏掉未受约束的变量或边界错误。
证明系统还有自己的参数与设置假设。有些构造需要谨慎生成设置材料，其他构造采用不同设置模型。“零知识”这类广义名称，不会消除全部信任假设。评估之前，先选定实际构造。
性能同样具体。生成、验证、内存、证明大小、公开输入大小和链上成本，可能呈现不同特点。证明短，不代表生成便宜；隐私也不蕴含简洁性。性能主张应写明系统、工作负载和测量条件。
对于虚构分配任务，应先问：隐私收益是否值得额外实现与审查负担？如果数量早已公开且无敏感性，普通签署报告可能足够。如果保密重要，就对照真实披露需求比较证明方案，不要只因为名称先进就采用。
十一、声明审查练习
对每个接受提示，指出过度结论，并改成范围更准确的说法。
提示 A：“证明通过，因此两个实物托盘必定装有被承诺的准确数量。”
答案：证明检查关于被承诺值的规定关系。实物观察需要另有证据。
提示 B：“总数为 18，每个数量最多为 9，但因为证明是零知识，所以无法推断任一个数量。”
答案：公开约束强制两个数量都为 9。不需要从证明额外取得信息，也能推导这一点。
提示 C：“总和检查通过，因此两个数量都有效。”
答案：只有预期范围约束也被正确执行，才能这样说。20 与负 8 说明只检查总和为什么不够。
提示 D：“上个月承诺的有效证明，可以授权本月更新。”
答案：没有适当背景、授权和状态检查，就不能。旧公开输入下的数学有效性，不建立当前适用性。
提示 E：“证明者使用了云服务，所以见证对所有人都保持私密。”
答案：应检查见证被发送到哪里、在哪里处理。对验证者的零知识，不自动向已经收到见证的证明服务隐藏它。
提示 F：“用了先进证明系统，因此电路一定实现了预期政策。”
答案：关系到电路的转换需要单独审查。强系统也能非常可靠地证明一个较弱或错误的声明。
常见问题
这是把见证加密了吗？
不是。目标是在证明模型下，不披露私密支持信息也能核验声明。它不只是一个以后由验证者解密的密文。
每个零知识证明都非常小吗？
不是。零知识是隐私属性，简洁性与效率是具体构造的其他属性。
证明能证明输入数据真实吗？
它在假设下证明规定关系。现实来源、被接受状态和应用授权，需要关系或外围协议实际检查的证据。
七个数对练习生成了零知识证明吗？
没有。它列出有效算术见证，并测试预期声明。真实证明需要规定构造、实现、参数和安全分析。
来源与下一步阅读
来源核对日期为新加坡时间 2026 年 10 月 12 日。分配关系、七个有序数对、总数 18 的推论，以及模 101 反例，均为原创教学例子。承诺方案是明确假设，不是已经实现的算法。
- halo2 Book：Proof systems：关系、电路、见证和知识可靠性术语。
- ZKProof 社区参考文档 v0.3：日期为 2022 年 7 月 17 日，明确标注未完成的社区草案，讨论安全与实现区别。
- 数学如何运作：密码学：已有广义基础文章。
声明依赖某个被接受承诺中的成员关系时，可以返回包含证明文章。下一篇讨论多重签名与门限签名，转向另一个问题：多个参与者怎样共同控制授权。