你可能曾经听说过ZK证明或零知识证明。但为什么它会突然变成一个热词？它是什么？什么是ZK-rollups?什么是ZK-SNARKS?以上问题都会在本文中得到解答，抓紧了快上车！
什么是零知识证明(ZeroKnowledgeProof)？
零知识证明可以让一方(证明方)在不透露任何实际信息的情况下向另一方(验证方)证明某保密信息或声明是真的。
术语“零知识“本身就表明了不需要揭露任何信息，证明方就可以向验证方证实ta所知道的保密信息以及ta的声明都是真的。
那为什么需要零知识证明呢？当我们不想披露任何信息，但需要说服其他人相信我们知道的保密信息和提出的声明是真的时候。
目前有两种零知识证明：
1.交互式的(Interactive)
2.非交互式的(NonInteractive)
举例说明交互式的零知识证明
假设你需要通过ZKP(零知识证明)证明你的年龄大于或等于18岁，但不揭露具体年龄。我们需要第三方机构为你的年龄担保，具体如下：
第三方说：”已接收您出生证明的复印件，我们已经得知您的年龄为21岁。现在为您提供一串数字密码，请将它保存到保密与安全的地方。稍后您会用到它。“
”你持有的那串数字密码将会被哈希算法处理22次，然后得出一个最终年龄哈希代码给你(没错，处理次数必须为年龄+1，才能使得整个操作行得通)。也就是说，你拿到那串数字密码之后，会有22次哈希处理过程才能获得最终的年龄哈希代码。“
“我们将您的姓名、时间戳与最终年龄哈希代码一起打包。这个证明包将提供给他人验证。“
好了，那么当你想要向其他人证明你的年龄超过18岁时，你只需要证明从你拿到数字密码到最终年龄哈希代码之间的哈希算法处理次数大于18就可以了。
那么怎么证明呢？你只需要向他人展示最后的18次哈希算法处理记录。你需要自己进行前4次哈希算法处理(对数字密码进行哈希算法处理4次)，然后将结果提供给其他人：第四次哈希值。
他们会对第四次哈希值再处理18次(现在对你的数字密码总共进行了22次哈希算法处理)，最终他们能够得出最终年龄哈希代码并且使用证明包对它进行验证。
实际上，验证者是在说："发送我们一个值，我们会对其进行18次哈希算法处理，然后这个哈希值将与你提供的年龄哈希代码进行对比。"如果你低于18岁，最终年龄哈希代码的哈希算法处理次数就没有18次，我们对你提供的那个初始哈希值进行18次哈希算法处理后，就会与最终年龄哈希代码不一样。
这里是另一个绝佳例子?
《一个很棒的零知识证明例子》-MathOverflow
https://mathoverflow.net/questions/22624/example-of-a-good-zero-knowledge-proof
?但是这种交互式方法有一些局限：
1.每次验证都需要进行整个冗长的过程。而上述例子只是简单的哈希算法处理，想象一下如果需要对实际加密算法进行计算会如何。
2.证明方与验证方都需要同时在场，不管是在线还是面对面。
接下来是非交互式的零知识证明
1986年，Fiat与Shamir发明了Fiat-Shamirheuristic(启发式)算法，这是第一个基于交互式零知识证明来构建数字签名的算法。
Fiat-Shamirheuristic算法通过使用承诺方案(CommitmentScheme)可变为非交互式零知识证明。这就是所谓的ZK-SNARKs，也可以称为简洁的非交互式零知识证明(Zero-KnowledgeSuccinctNon-InteractiveArgumentofKnowledge)。
要使Fiat-ShamirHeuristic算法更加强大，需要使用承诺(commitment)。承诺方案在许多加密协议中都是基本组成部分。承诺方案允许承诺者发布一个值(即承诺)，然后将它们绑定到某消息上而不披露它们(隐藏)。
Pederson承诺与Polynomial承诺是ZK证明使用的两个最著名承诺方案。
但大约到2013年，ZK-SNARKs才实际可行和实现，并真正用于应用中。
我推荐你们阅读VitalikButerin写的?一篇解释zk-SNARKs如何可行的概论，这篇文章写得很棒，解释了ZK-SNARKs是如何实现的。只阅读一遍可能还不能理解整篇文章。多阅读3、4次，一旦你了解了ZK-SNARKs的原理，你会激动到全身起鸡皮疙瘩。
?跟AI与Web3一样，我们似乎无法避免后量子世界到来，因此我们需要确保为ZK-SNARKs选择使用的加密函数不能被量子计算机暴力破解。这就是为什么我们还需要改进，以保证后量子安全性。
如果想要了解更多信息，可以观看由ACM发布的谈话?
提高非交互式零知识证明在后量子签名中的应用
https://www.youtube.com/watch?v=V0FfpVQzajk
现在终于明白ZK证明是什么了，但是它们应用到什么地方呢?？
在概念上它们有两个主要用例：
扩容区块链交易
个人数据隐私保护，例如在医疗卫生领域
区块链扩容-ZKRollups
Rollup是一种扩容解决方案，在L1外执行交易，但在L1上发布交易数据。这种工作办法可以让rollup对网络进行扩容，但依然受到以太坊共识的安全保护。
将计算转移到链下进行，实际上可以处理更多交易。因为只需要将rollup交易的一些数据放进以太坊区块中。
要做到这一点，rollup交易在另一条链上执行，而这条链甚至可以运行一个rollup特定版本的EVM。
执行完rollup上的交易后，下一步是将这些交易打包成一个batch，然后发布到以太坊主链上。
整个过程基本是执行交易、提取数据、压缩，将其rollup到一个个batch中然后发到主链上，因而得名——”rollup“。
以太坊怎样得知这些数据是有效的、而不是由恶意份子出于牟利目的而提交的呢?？
每个rollup都会在L1部署一组智能合约，来负责处理存款、取款交易以及验证证明。
证明也是主要区分不同类型rollups的因素。
Optimisticrollups使用欺诈证明。与之相对，ZKrollups采用有效性证明。
在ZKrollups中，发布到L1的每个batch包含一个叫做ZK-SNARK的加密证明。当提交交易batch至L1之后，L1上的合约可以快速验证ZK-SNARK证明，无效的batch会被直接拒绝。
关于ZK与Optimisticrollups还有很多其他内容，比如它们的实现方法和限制。在这里我只是简短地介绍了一下它们的概念。
许多项目都在开发基于ZKrollups的以太坊扩容方案。一些比较知名的项目有dYdX、Loopring、PolygonMiden、PolygonHermez等等。
隐私——日常生活应用
假设有两个公司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的重要产品，为用户提供隐私交易功能。
最普遍的几种zkp系统的对比
来源：MatterLabs的github代码库
zk-STARK(zero-knowledgescalabletransparentargumentofknowledge)代表零知识的可扩展、透明知识证明，zk-SNARK(zero-knowledgesuccinctnon-interactiveargumentofknowledge)代表零知识的简洁、非交互式知识证明。
这两种零知识技术都是非交互式的，这意味着代码可被部署且自动作用。
Zk-SNARKs底层依靠椭圆曲线保证安全性。在密码学中，椭圆曲线在这样一个基本假设下运行：根据一个公开已知的基本点来找到一个随机椭圆曲线元素的离散对数是不可行的。也就是说，Zk-SNARKs也需要信任设置。
信任设置是指密钥的初始创建事件，它会被用于生成隐私交易的证明以及验证那些证明。
如果用于创建信任设置的密钥的保密信息没有被销毁，那么这些保密信息可能会被利用通过虚假验证来伪造交易。
SNARKs的另一个限制是，在前文中我们已经知道了：它们在后量子世界中的可行性。
?另一方面，在一个网络中开始使用STARKs的话，不需要信任设置。这些都可认为是抗量子的。虽然STARK的证明大小要比SNARK大得多。
但是STARKs现仍处于初期阶段，开发者们得不到太多支持，所以基于ZK-STARK的产品还需要一些时间才能成熟。
本文到这里就结束了。这只是一篇简短的关于ZK证明在Web3世界是怎样运作的介绍。
来源|ravjot.hashnode.dev
作者|RavjotSingh
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。