来源 | ravjot.hashnode.dev
作者 | Ravjot Singh
你可能曾经听说过 ZK 证明或零知识证明。但为什么它会突然变成一个热词？它是什么？什么是 ZK-rollups? 什么是 ZK-SNARKS? 以上问题都会在本文中得到解答，抓紧了快上车！
什么是零知识证明 (Zero Knowledge Proof)？
零知识证明可以让一方 (证明方) 在不透露任何实际信息的情况下向另一方 (验证方) 证明某保密信息或声明是真的。
术语 “零知识“ 本身就表明了不需要揭露任何信息，证明方就可以向验证方证实 ta 所知道的保密信息以及 ta 的声明都是真的。
那为什么需要零知识证明呢？当我们不想披露任何信息，但需要说服其他人相信我们知道的保密信息和提出的声明是真的时候。
目前有两种零知识证明：
1.交互式的 (Interactive)
2.非交互式的 (Non Interactive)
1️⃣举例说明交互式的零知识证明
假设你需要通过 ZKP (零知识证明) 证明你的年龄大于或等于18岁，但不揭露具体年龄。我们需要第三方机构为你的年龄担保，具体如下：
第三方说：”已接收您出生证明的复印件，我们已经得知您的年龄为 21 岁。现在为您提供一串数字密码，请将它保存到保密与安全的地方。稍后您会用到它。“
”你持有的那串数字密码将会被哈希算法处理 22 次，然后得出一个最终年龄哈希代码给你 (没错，处理次数必须为年龄 +1，才能使得整个操作行得通)。也就是说，你拿到那串数字密码之后，会有 22 次哈希处理过程才能获得最终的年龄哈希代码。“
“我们将您的姓名、时间戳与最终年龄哈希代码一起打包。这个证明包将提供给他人验证。“
好了，那么当你想要向其他人证明你的年龄超过 18 岁时，你只需要证明从你拿到数字密码到最终年龄哈希代码之间的哈希算法处理次数大于 18 就可以了。
那么怎么证明呢？你只需要向他人展示最后的 18 次哈希算法处理记录。你需要自己进行前 4 次哈希处理 (对数字密码哈希算法处理 4 次)，然后将结果提供给其他人：第四次哈希值。
他们会对第四次哈希值再处理18次 (现在对你的数字密码总共进行了 22 次哈希处理)，最终他们能够得出最终年龄哈希代码并且使用证明包对它进行验证。
实际上，验证者是在说："发送我们一个值，我们会对其进行 18 次哈希算法处理，然后这个哈希值将与你提供的年龄哈希代码进行对比。" 如果你低于18岁，最终年龄哈希代码的哈希算法处理次数就没有18次，我们对你提供的那个初始哈希值进行18次哈希处理后，就会与最终年龄哈希代码不一样。
这里是另一个绝佳例子 👇
▶但是这种交互式方法有一些局限：
1.每次验证都需要进行整个冗长的过程。而上述例子只是简单的哈希算法处理，想象一下如果需要对实际加密算法进行计算会如何。
2.证明方与验证方都需要同时在场，不管是在线还是面对面。
2️⃣ 接下来是非交互式的零知识证明
1986 年，Fiat 与 Shamir 发明了 Fiat-Shamir heuristic (启发式) 算法，这是第一个基于交互式零知识证明来构建数字签名的算法。
Fiat-Shamir heuristic 算法通过使用承诺方案 (Commitment Scheme) 可变为非交互式零知识证明。这就是所谓的 ZK-SNARKs，也可以称为简洁的非交互式零知识证明 (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge)。
要使 Fiat-Shamir Heuristic 算法更加强大，需要使用承诺 (commitment)。承诺方案在许多加密协议中都是基本组成部分。承诺方案允许承诺者发布一个值 (即承诺)，然后将它们绑定到某消息上而不披露它们 (隐藏)。
Pederson 承诺与 Polynomial 承诺是 ZK 证明使用的两个最著名承诺方案。
但大约到 2013 年，ZK-SNARKs 才实际可行和实现，并真正用于应用中。
我推荐你们阅读 Vitalik Buterin 写的 一篇解释 zk-SNARKs 如何可行的概论，这篇文章写得很棒，解释了 ZK-SNARKs 是如何实现的。只阅读一遍可能还不能理解整篇文章。多阅读 3、4 次，一旦你了解了 ZK-SNARKs 的原理，你会激动到全身起鸡皮疙瘩。
▶ 跟 AI 与 Web3 一样，我们似乎无法避免后量子世界到来，因此我们需要确保为 ZK-SNARKs 选择使用的加密函数不能被量子计算机暴力破解。这就是为什么我们还需要改进，以保证后量子安全性。
如果想要了解更多信息，可以观看由 ACM 发布的谈话👇
现在终于明白 ZK 证明是什么了，但是它们应用到什么地方呢 🤔？
在概念上它们有两个主要用例：
- 扩容区块链交易
- 个人数据隐私保护，例如在医疗卫生领域
区块链扩容 - ZK Rollups
Rollup 是一种扩容解决方案，在 L1 外执行交易，但在 L1 上发布交易数据。这种工作办法可以让 rollup 对网络进行扩容，但依然受到以太坊共识的安全保护。
将计算转移到链下进行，实际上可以处理更多交易。因为只需要将 rollup 交易的一些数据放进以太坊区块中。
要做到这一点，rollup 交易在另一条链上执行，而这条链甚至可以运行一个 rollup 特定版本的 EVM。
执行完 rollup 上的交易后，下一步是将这些交易打包成一个 batch，然后发布到以太坊主链上。
整个过程基本是执行交易、提取数据、压缩，将其 rollup 到一个个 batch 中然后发到主链上，因而得名 —— ”rollup“。
以太坊怎样得知这些数据是有效的、而不是由恶意份子出于牟利目的而提交的呢🤔？
每个 rollup 都会在 L1 部署一组智能合约，来负责处理存款、取款交易以及验证证明。
证明也是主要区分不同类型 rollups 的因素。
Optimistic rollups 使用欺诈证明。与之相对， ZK rollups 采用有效性证明。
在 ZK rollups 中，发布到 L1 的每个 batch 包含一个叫做 ZK-SNARK 的加密证明。当提交交易 batch 至 L1 之后，L1 上的合约可以快速验证 ZK-SNARK 证明，无效的 batch 会被直接拒绝。
关于 ZK 与 Optimistic rollups 还有很多其他内容，比如它们的实现方法和限制。在这里我只是简短地介绍了一下它们的概念。
许多项目都在开发基于 ZK rollups 的以太坊扩容方案。一些比较知名的项目有 dYdX 、Loopring 、Polygon Miden 、 Polygon Hermez 等等。
隐私 —— 日常生活应用
假设有两个公司 A 和 B 想要使用区块链作为运行与通信的媒介。
A 向 B 转移资产。并且他们想让这笔交易只有他们双方知道。没错，区块链会带来透明度、互操作性、数据安全性、完整性还有其他优点，但是公司怎么会想让内部运行信息在公众面前显示呢？零知识证明就是最佳选择。
比如你想隐私地给你的海外朋友转账，你会怎么做呢？选择零知识证明。
ZK 证明还可以在医疗健康、保险、电子投票、身份管理等领域产生深远影响。
在医疗健康方面，ZK 证明可以保证 DNA 数据、个人信息、医疗报告、基本病史信息、药物溯源、临床试验、医疗健康供应链、器官移植的隐私安全。
在保险方面，ZK 证明可以保证保险单和保险凭证数字信息、个人信息、车辆信息、理赔信息的隐私安全。
使用区块链与 ZKP 的身份管理具有深刻意义。每个关联 KYC (了解你的客户) 的应用、学校、大学、支付软件都要询问我们的 ID 图像，例如驾照、护照、投票 ID 、国家 ID。我们敏感的个人数据就这样给他们了，我们甚至都没有意识到这一点。通过 ZKP，我们可以保证以上所有 ID 信息的隐私安全，只需透露必要信息给供应商、应用与官方即可。实际上，使用 ZKP 我们可以完全改进这些 ID 的发行方式。
我们可以使用 ZK 证明对这些信息进行加密处理。当需要给到一些信息时，用户授权并提供所需信息，而其他详细资料可以保持隐藏。
这些都是在 2013 年后，ZK-SNARKs 在实际应用上足够有效率才开始被开发者使用。这也是为什么未来出现的 ZKP 应用会有很多发展空间。
2016 年上线的 Zcash 是一个成功应用 ZK-SNARKs 的重要产品，为用户提供隐私交易功能。
ZK-SNARKs vs ZK-STARKs
最普遍的几种 zkp 系统的对比
zk-STARK (zero-knowledge scalable transparent argument of knowledge) 代表零知识的可扩展、透明知识证明，zk-SNARK (zero-knowledge succinct non-interactive argument of knowledge) 代表零知识的简洁、非交互式知识证明。
这两种零知识技术都是非交互式的，这意味着代码可被部署且自动作用。
Zk-SNARKs 底层依靠椭圆曲线保证安全性。在密码学中，椭圆曲线在这样一个基本假设下运行：根据一个公开已知的基本点来找到一个随机椭圆曲线元素的离散对数是不可行的。也就是说，Zk-SNARKs 也需要信任设置。
信任设置是指密钥的初始创建事件，它会被用于生成隐私交易的证明以及验证那些证明。
如果用于创建信任设置的密钥的保密信息没有被销毁，那么这些保密信息可能会被利用通过虚假验证来伪造交易。
SNARKs 的另一个限制是，在前文中我们已经知道了：它们在后量子世界中的可行性。
👉另一方面，在一个网络中开始使用 STARKs 的话，不需要信任设置。这些都可认为是抗量子的。虽然 STARK 的证明大小要比 SNARK 大得多。
但是 STARKs 现仍处于初期阶段，开发者们得不到太多支持，所以基于 ZK-STARK 的产品还需要一些时间才能成熟。
本文到这里就结束了。这只是一篇简短的关于 ZK 证明在 Web3 世界是怎样运作的介绍。
感谢阅读！
ECN的翻译工作旨在为中国以太坊社区传递优质资讯和学习资源，文章版权归原作者所有，转载须注明原文出处以及ethereum.cn，若需长期转载，请联系eth@ecn.co进行授权。