证明者只知道 E(s)，但能够计算 E(t(s))， E(h(s))， E(w(s)) 和 E(v(s))。
通过乘以另一个秘密值 k 来混淆同态加密值，证明者也能够其原始信息。
本质上，验证者是在检查下面这个形式的等式，t(s)h(s)k = w(s)v(s)k
ZK-SNARKs 如何设置 ?
对于上面提到的如何生成「多项式等式」和随机设置，有一些人表示怀疑。
关于多项式等式的质疑，我能给出的最短版本是，最初要被证明的等式（比如 A > B 吗 ? 或者 A + B =C 吗 ? ）被压缩到一个回路中，即约束条件被用于创建这些多项式。
另外，你是如何选择随机数的呢 ?
在 Zcash 的第一个版本中，最初的创始成员使用了一种精心设计的方法，通过他们所谓的「仪式」来制造这种随机产生的有毒废物，完整故事请见这个链接 http://www.wnycstudios.org/story/ceremony。
「仪式」最终是一个产生随机结果的多方计算 (MPC)。换句话说，仪式的每个成员 (总共六方) 都产生了各自独特的随机密钥，这些密钥被组合成一个再次随机的密钥。最近，在 Zcash 的最新版本 Sapling 中，他们为 MPC 实施了一种新的方法论――80 多名参与者一起生成了 ZK-SNARKs 的随机私钥。在这种新方法中，只需要一方保持忠诚，私钥就不会被复制――换一种说法，这意味着仪式的所有参与方都必须变节，才能颠覆这个系统。
ZK-STARKs
相比之下，STARKs （简洁透明知识论证，succinct transparent arguments of knowledge）则因其透明和简洁密码学而被称赞。和 ZK-SNARKs 不同，STARKs 不需要一个可信的设置，因此也不需要 ZK-SNARKs 中出现的有毒废物那种事情――因此具有透明性。STARKs 能够通过使用 Arthur-Merlin 协议消除对可信设置的需要。在该协议中，验证者 Arthur 为每个问题生成随机性，而证明者 Merlin 则通过解决问题来提供证据。
STARKs 还通过使用最小的密码假设和在安全和抗冲突的哈希函数之间取得平衡，而使其密码术更简洁。这留下了潜在的后量子时代的安全风险。最小密码假设适用于交互式 STARKs，而非交互式 STARKs 则需要 Fiat-Shamir 启发式。
Starkware （http://starkware.co/）正在与 0x 合作进行一个非常棒的项目，在去中心化和中心化的通证交易所中使用 ZK-STARKs，他们就此主题发表的文章相当清晰，有兴趣的读者可以了解一下。
STARK 证明和验证的速度都比 SNARKs 和防弹证明快，只不过这个领域的第一个 STARK 项目和开发工具才刚刚浮现。
防弹证明（Bulletproof）
防弹是另一种形式的零知识系统，它不需要可信设置，但它确实比 SNARKs 和 STARKs 需要更长的证明时间。这些证明方法目前已经在门罗币中实施――实现速度快得令人咂舌，学术论文发表才 6 个月左右就开始实施。
防弹基于现有的 range proof 方法，可将多个 range proof 合为一个，且其数据比以往方法还要小。
有趣的是，防弹允许证据聚合，这意味着您可以通过多方计算，在同一时间收集和验证来自不同方的多个证据。在最近发表的文章中，Zether 防弹，被部署于智能合约隐私，而最近，摩根大通在其私有的、许可型的区块链
Quorum中添加了这些功能。
零知识证明系统面临的挑战
零知识证明要被广泛采用，还面临如下一些主要挑战：
证据设置时间（开发者工具 / 劳动力准备）
对于每个计算或场景，必须生成一组数学证明来实现编码。到目前为止，市面上出现了几种开发工具；不过这仍然需要一种具有挑战性的专业技能。零知识领域（在很大程度上密码学也如此）面临的技能差距与量子计算领域相似，因为在广泛采用之前，必须培训更多开发人员了解如何把一项应用组合起来。
证据生成和验证时间 / 规模要求
零知识要求证明方生成一个证据供验证方验证。这两项活动都需要时间，近年来（实际上是近几个月）这方面所需的时间已大大缩短，但这仍是大规模采用需要考虑的一个问题。
证据的标准化
本文已经解释了生成证据的不同方法论，但每个方法都有相似的起点。标准化是必要的，它可以使零知识证明从临时处理特定问题，发展到处理更大范围的相关问题和场景。ZK 标准组织正在致力于解决相关问题。
此文由 比特币官网 编辑，未经允许不得转载！：首页 > 比特币行情 » 一文说透密码学历史、工作原理、零知识证明及潜在影响