现在我们已经描述了 ZK 证明安全性的更广泛问题，让我们继续讨论问题 2。
在分析两方协议时，有三种情况需要考虑：
（显然，我们对第四个潜在案例不感兴趣，因为没有诚实的一方需要保护其安全利益；我们不在乎不诚实的当事方会做什么。）
案例 A：完整性
的定义 完整性 知识证明对应于案例 A，其中双方都是诚实的。如果真的 y=f (x)，那么我们希望该协议 “永远” 成功。这并不是真正的安全条件，它只是说协议正确地实现了它应该做的事情的一种方式：如果各方说实话，一切都按应有的方式运作。这与在识别协议中说虚假拒绝率为 0 相同，即合法用户不会被拒绝。
案例 B：正确性
这个 正确性 协议对应于案例 B：如果证明者试图欺骗验证者相信这一点 y'=f (x) 如果实际上这是错误的，那么验证者应该以概率为1来检测到这一点；也就是说，证明者 “永远不会” 成功欺骗验证者。
密码学家有时会以特殊的方式使用诸如 “概率1”、“永远” 和 “从不” 之类的术语。几乎所有实用的密码系统都在某种程度上使用概率论，并且允许的错误概率非常小。因此，在稳健性的背景下，“总是” 代表概率 1-eps，“从不” 代表概率 0+eps，其中 eps = 2^ -100 或更小。这表明这是多么不可能，一次赢得超级百万大奖的机会约为2 ^-28.17，因此 2 ^-90 的概率小于连续三次赢得该大奖。确实不太可能。
案例 C：隐私
这个案例是最有趣的。验证者在知识证明方面不诚实意味着什么？换句话说，对于验证者是否可能试图违规，证明者的利益是什么？好吧，这取决于上下文。
零知识的最初概念， 由 Goldwasser、Micali 和 Rackoff 于 1985 年推出，是对隐私的非常具体的定义，这意味着验证者无法通过协议获得有关证明者证人 T 的有用计算信息 笔录， 定义为交换的消息集。（更准确地说，笔录应该是可模拟的。）
但是，在过去的几年中，人们开始使用零知识来引用简洁的证明来进行可验证的计算。严格来说，这是对术语的滥用，但流行语的力量如此之大，因此说反对它们是没有用的。
这如何转化为 ZK 汇总的特定设置？好吧，验证器很高兴Prover计算出来了 y = F (x) 对他来说，而 Prover 没有特别的理由保留处决的踪迹 T 秘密。重要的是外包计算的结果是正确的。Prover 实际找到答案的方式 y （使用 T) 不是需要保密的东西。
换句话说，ZK Rollups 是一个注重简洁而不是隐私的设置示例。无论如何，所有交易都要在第 1 层公开发布；因此无需对数据保密。通常，Prover 不妨发布 T (以来 T 无论如何都很大），因此验证器甚至可能无法读取和处理所有内容。这正是简洁证明Z的用武之地，它使验证器的读取和处理变得可行。
但是，除了可验证的外包计算之外，还有更通用的设置，在这些设置中，Prover 可能希望将某些算法保密。例如，假设 Prover 声称他开发了一种新颖的、非常有效的算法 F 针对一些非常困难的计算问题，并想说服验证者相信情况确实如此。
在此设置中，证明者可能希望生成一个不仅简洁而且还能保持不变的证明 F 和 T 私人。Prover 实际上可能会选择保留输出 y 私密的，从而说服验证者相信这一点 知道 一个答案，但没有实际说明它是什么。零知识有时可能令人难以置信。
因此，总而言之，“零知识” 一词实际上可以表示三种不同的东西：
(1) 一个 私人的 证据（其原始含义），
(2) 一个 简洁 证据（其通俗含义），以及
(3) 两者的结合。
实际上，SNARKs和zkSNARKs之间有一个细微的区别：第一个对应于解释（2），而第二个对应于解释（3）。Starks 和 zkStarks 也是如此。
完全透明和完全可审计性
有人可能会问：第三方怎么样？允许外部观察员在多大程度上监视证明者和验证者？Prover 和 Verifier 必须加密他们的通信吗？
答案很简单。在 ZK 汇总和可验证计算的背景下，没有任何秘密。我们所做的一切都是公开的，供所有人查看、验证和复制。没有加密，没有秘密。这意味着一个非常强大的特性： 完全透明，完全可审计。
消息完整性和软件正确性
但是透明度仍然意味着我们需要警惕对消息和软件的恶意修改。
就电文完整性而言，在每一项通信上使用数字签名，以保证其来源和内容，并能够确定责任归属，这纯粹是一种良好做法。所以这解决了消息传递部分。
第二个问题是软件的正确性。从加密的角度看协议时，我们通常假设在软件组件的实现过程中没有发生错误。但是我们知道，在实践中，这样的错误很常见。例如，回想一下爱德华·斯诺登的泄密事件向世界表明，系统的底层密码学几乎永远不会被破解；问题在于软件漏洞、错误和错误。因此 ZKM 正计划在系统投入生产之前对其源代码进行严格的审计。
只关注验证器
从密码学的角度来看，在这次审计中，我们只需要关注验证器的正确性，以避免错误的证据被错误地接受的情况。
Prover 中的软件错误可能会导致不完美的完整性，这是不可取的，但不是灾难性的。这是因为实现错误可能会导致Prover发送给验证器的消息出现错误，从而导致后者拒绝证明。或者这些错误可能会导致隐私（机密性）的丧失，正如我们之前看到的那样，这在我们的设置中并不是真正的问题。
因此，我们看到，为了保证协议的正确性特性，我们只需要专注于验证器的正确实现即可。对于其他设置来说，这是个好消息，在这些设置中，我们甚至无法控制 Prover。（这是未来文章的主题。）
最后一点：请注意，我们没有讨论 菲亚特-沙米尔转型 使最终协议成为非交互式协议。这种转变使我们的安全分析的有效性更易于理解，但又足够复杂，值得单独发表一篇文章。敬请关注！
—
本文的作者 Jeroen van de Graaf 是 ZKM 的高级研究顾问
你读过 ZKM 白皮书了吗？在以下地址查看 https://ethresear.ch/t/zkmips-a-zero-knowledge-zk-vm-based-on-mips-architecture/16156
想与我们的核心 ZKM 团队讨论这篇文章和其他与 ZK 相关的话题吗？加入我们的 Discord 频道： Discord.gg/bck7HDGCNS
最初发表于 https://www.zkm.io。
现在我们已经描述了 ZK 证明安全性的更广泛问题，让我们继续讨论问题 2。
在分析两方协议时，有三种情况需要考虑：
（显然，我们对第四个潜在案例不感兴趣，因为没有诚实的一方需要保护其安全利益；我们不在乎不诚实的当事方会做什么。）
案例 A：完整性
的定义 完整性 知识证明对应于案例 A，其中双方都是诚实的。如果真的 y=f (x)，那么我们希望该协议 “永远” 成功。这并不是真正的安全条件，它只是说协议正确地实现了它应该做的事情的一种方式：如果各方说实话，一切都按应有的方式运作。这与在识别协议中说虚假拒绝率为 0 相同，即合法用户不会被拒绝。
案例 B：正确性
这个 正确性 协议对应于案例 B：如果证明者试图欺骗验证者相信这一点 y'=f (x) 如果实际上这是错误的，那么验证者应该以概率为1来检测到这一点；也就是说，证明者 “永远不会” 成功欺骗验证者。
密码学家有时会以特殊的方式使用诸如 “概率1”、“永远” 和 “从不” 之类的术语。几乎所有实用的密码系统都在某种程度上使用概率论，并且允许的错误概率非常小。因此，在稳健性的背景下，“总是” 代表概率 1-eps，“从不” 代表概率 0+eps，其中 eps = 2^ -100 或更小。这表明这是多么不可能，一次赢得超级百万大奖的机会约为2 ^-28.17，因此 2 ^-90 的概率小于连续三次赢得该大奖。确实不太可能。
案例 C：隐私
这个案例是最有趣的。验证者在知识证明方面不诚实意味着什么？换句话说，对于验证者是否可能试图违规，证明者的利益是什么？好吧，这取决于上下文。
零知识的最初概念， 由 Goldwasser、Micali 和 Rackoff 于 1985 年推出，是对隐私的非常具体的定义，这意味着验证者无法通过协议获得有关证明者证人 T 的有用计算信息 笔录， 定义为交换的消息集。（更准确地说，笔录应该是可模拟的。）
但是，在过去的几年中，人们开始使用零知识来引用简洁的证明来进行可验证的计算。严格来说，这是对术语的滥用，但流行语的力量如此之大，因此说反对它们是没有用的。
这如何转化为 ZK 汇总的特定设置？好吧，验证器很高兴Prover计算出来了 y = F (x) 对他来说，而 Prover 没有特别的理由保留处决的踪迹 T 秘密。重要的是外包计算的结果是正确的。Prover 实际找到答案的方式 y （使用 T) 不是需要保密的东西。
换句话说，ZK Rollups 是一个注重简洁而不是隐私的设置示例。无论如何，所有交易都要在第 1 层公开发布；因此无需对数据保密。通常，Prover 不妨发布 T (以来 T 无论如何都很大），因此验证器甚至可能无法读取和处理所有内容。这正是简洁证明Z的用武之地，它使验证器的读取和处理变得可行。
但是，除了可验证的外包计算之外，还有更通用的设置，在这些设置中，Prover 可能希望将某些算法保密。例如，假设 Prover 声称他开发了一种新颖的、非常有效的算法 F 针对一些非常困难的计算问题，并想说服验证者相信情况确实如此。
在此设置中，证明者可能希望生成一个不仅简洁而且还能保持不变的证明 F 和 T 私人。Prover 实际上可能会选择保留输出 y 私密的，从而说服验证者相信这一点 知道 一个答案，但没有实际说明它是什么。零知识有时可能令人难以置信。
因此，总而言之，“零知识” 一词实际上可以表示三种不同的东西：
(1) 一个 私人的 证据（其原始含义），
(2) 一个 简洁 证据（其通俗含义），以及
(3) 两者的结合。
实际上，SNARKs和zkSNARKs之间有一个细微的区别：第一个对应于解释（2），而第二个对应于解释（3）。Starks 和 zkStarks 也是如此。
完全透明和完全可审计性
有人可能会问：第三方怎么样？允许外部观察员在多大程度上监视证明者和验证者？Prover 和 Verifier 必须加密他们的通信吗？
答案很简单。在 ZK 汇总和可验证计算的背景下，没有任何秘密。我们所做的一切都是公开的，供所有人查看、验证和复制。没有加密，没有秘密。这意味着一个非常强大的特性： 完全透明，完全可审计。
消息完整性和软件正确性
但是透明度仍然意味着我们需要警惕对消息和软件的恶意修改。
就电文完整性而言，在每一项通信上使用数字签名，以保证其来源和内容，并能够确定责任归属，这纯粹是一种良好做法。所以这解决了消息传递部分。
第二个问题是软件的正确性。从加密的角度看协议时，我们通常假设在软件组件的实现过程中没有发生错误。但是我们知道，在实践中，这样的错误很常见。例如，回想一下爱德华·斯诺登的泄密事件向世界表明，系统的底层密码学几乎永远不会被破解；问题在于软件漏洞、错误和错误。因此 ZKM 正计划在系统投入生产之前对其源代码进行严格的审计。
只关注验证器
从密码学的角度来看，在这次审计中，我们只需要关注验证器的正确性，以避免错误的证据被错误地接受的情况。
Prover 中的软件错误可能会导致不完美的完整性，这是不可取的，但不是灾难性的。这是因为实现错误可能会导致Prover发送给验证器的消息出现错误，从而导致后者拒绝证明。或者这些错误可能会导致隐私（机密性）的丧失，正如我们之前看到的那样，这在我们的设置中并不是真正的问题。
因此，我们看到，为了保证协议的正确性特性，我们只需要专注于验证器的正确实现即可。对于其他设置来说，这是个好消息，在这些设置中，我们甚至无法控制 Prover。（这是未来文章的主题。）
最后一点：请注意，我们没有讨论 菲亚特-沙米尔转型 使最终协议成为非交互式协议。这种转变使我们的安全分析的有效性更易于理解，但又足够复杂，值得单独发表一篇文章。敬请关注！
—
本文的作者 Jeroen van de Graaf 是 ZKM 的高级研究顾问
你读过 ZKM 白皮书了吗？在以下地址查看 https://ethresear.ch/t/zkmips-a-zero-knowledge-zk-vm-based-on-mips-architecture/16156
想与我们的核心 ZKM 团队讨论这篇文章和其他与 ZK 相关的话题吗？加入我们的 Discord 频道： Discord.gg/bck7HDGCNS
最初发表于 https://www.zkm.io。
