ZK证明和ZK-EVM如何工作（无需数学）

零知识（ZK）证明正在为 web3 的最新创新提供动力。它们已经被应用在诸如 Polygon 的 zkEVM 等产品中，为以太坊带来可验证的扩展性，以及 Polygon ID 中，用于在不泄露任何个人信息的情况下验证你的身份。

一句话概括：ZK 证明允许你证明某事，而无需揭示这件事本身。这有几个现实世界的应用，例如在不提供完整驾照/护照信息的情况下验证你的年龄。

但这是如何真正实现的呢？为了实现这一点，幕后发生了什么？在这篇文章中，我将涵盖你需要了解的关于 ZK 证明的一切，但会省略数学部分。

让我们开始吧！

ZK 证明是如何工作的？

为了在不泄露声明本身的情况下证明声明的有效性，需要两个参与方：

1. 证明者（Prover）：试图证明某事的人。

2. 验证者（Verifier）：试图验证该声明是否“真实”的人。

有时，还有第三方参与，即颁发者（Issuer），颁发者向证明者授予证书（例如许可证），验证者信任该证书作为信息来源。

让我们看一个例子……我想向一个网站证明我已年满 18 岁，而无需上传我的护照照片。在这种情况下，有：

• 证明者：我，试图证明我已达到法定年龄的个人。

• 验证者：网站所有者，试图验证我是否已达到法定年龄。

• 颁发者：政府，向我提供护照；网站所有者信任该文件以证明我的年龄。

通常，我需要将我的整个护照的屏幕截图上传到网站（我真的不想这样做），仅仅是为了证明我已超过 18 岁。

Steph 制作的一个有趣的例子是将此应用于海绵宝宝。海绵宝宝想证明他的名字实际上是海绵宝宝，但为了做到这一点，他需要向验证者（警察……或者我猜，警察鱼）提供他的完整许可证。

他的许可证包含敏感信息，如他的出生日期、地址、性别等；所有这些对于证明他的名字都不是必要的；但是，唉，他别无选择。

如果海绵宝宝可以证明他的名字，或者如果我可以用某种方式证明我已超过 18 岁，而无需交出这么多敏感信息，那就太好了。

这是一个典型的例子，说明 ZK 证明如何为世界提供真正的价值。使用 ZK 证明，我现在能够向验证者证明我身份的一部分（或任何其他内容），而无需提供我身份的任何方面，或任何支持文件来证明这一事实。

这样，我就永远不会将敏感的个人信息传输给第三方存储在数据库中；容易受到攻击和泄露；这是我们目前每次注册网站时几乎都会冒的风险。

这一切听起来很棒。但是如何在不泄露任何信息的情况下证明某事呢？为此，我们可以更深入地了解 ZK 证明是什么。

ZK 证明由什么组成？

所以，我们想证明某事，而不泄露我们如何知道这件事，甚至这件事是什么。这怎么可能？

在我们回答这个问题之前，ZK 证明分为两大类：

1. 交互式

2. 非交互式

我们在 web3 中关心的是非交互式的，但让我们快速了解一下在 ZK 的上下文中，“交互性”指的是什么。

交互式 ZK 证明

想象一下，有一个环形洞穴，里面有一扇门，需要一个秘密密码才能进入。

你作为证明者的目标是向你的朋友，验证者证明你知道秘密密码，称为“见证（witness）”，而不告诉他们实际密码。

你不想告诉你的朋友密码，所以相反，你将证明你知道它；首先，随机进入洞穴的一侧；不要让他们看到。

此时，你的朋友不知道你在哪一侧。但是作为一个挑战，他们喊出“A！”或“B！”；要求你从 A 侧或 B 侧退出。

在这个简单的例子中，这可能导致两种结果：

1. 你进入了 A 侧，所以你需要密码才能通过通往 B 侧的门：

2. 你进入了 B 侧，所以你不需要密码；你可以直接走出去：

_为了参考，这被称为 阿里巴巴洞穴故事。_

这是一个简单的例子，因为你是否需要密码来满足你朋友的挑战的可能性是 50/50；因此，只进行一次挑战不足以确定地证明你知道密码。

这意味着你需要完成更多次挑战迭代，正确地从 A 侧或 B 侧退出，直到你的朋友满意；或者在理论世界中，直到你不可能伪造对见证（秘密代码）的了解。

因此，这是交互式的；你（证明者）和你的朋友（验证者）来回交互。你的朋友创建一个挑战（challenge），你创建一个响应（response）。这个循环重复，直到验证者满意为止，此时，验证者已经证明了对见证的了解。

这构成了交互式 ZK 证明的三个部分：

1. 见证：证明者想要证明其了解的秘密信息。

2. 挑战：只有了解见证的人才可能能够回答的问题；尽管可能只是幸运的猜测。

3. 响应：证明者对挑战的响应；包含（但愿）正确的答案。

步骤 2 和 3 重复，直到验证者满意为止。

最终，一旦验证者满意，循环就会中断；并且验证者不再生成另一个挑战，而是接受证明者了解见证。

虽然这个过程有效，但它需要在证明者和验证者之间进行多轮通信；这是低效的，并且在区块链的上下文中不太适用。

交互式证明还有另一个很大的限制；即使在验证者满意之后，该证明也将无法进行独立验证；这意味着只有验证它的一方才能信任它，而不是其他人。

由于这些原因，创建了非交互式 ZK 证明。

非交互式 ZK 证明

非交互式 ZK 证明只需要从证明者到验证者的一轮通信。证明者使用一种算法来计算 ZK 证明，并将其发送给验证者，验证者也使用另一种算法来检查它。

非交互式 ZK 证明的另一个好处是，它们也可以供其他人验证；这意味着它不仅从验证者的角度得到证明，而且可以供每个人自己验证；适用于区块链。

这些能够证明信息和验证证明的“算法”是什么？好吧，答案是；这取决于。有很多算法，但在区块链的上下文中通常使用两种 ZKP 系统；ZK-SNARK 和 ZK-STARK。

什么是 ZK-SNARK？

ZK-SNARK 意味着零知识简洁非交互式知识论证（Zero-Knowledge Succinct Non-Interactive Argument of Knowledge）。

• ZK：希望到现在你已经可以猜到这是什么意思（零知识）。

• 简洁（Succinct）：它们很小，并且可以被验证者快速验证。

• 非交互式（Non-interactive）：我们之前讨论过这一点。证明者和验证者之间只需要一轮通信。

• 论证（Argument）：从理论上讲，极不可能“愚弄”该系统。

• （知识）（(Of) Knowledge）：如果没有访问秘密信息（见证）的权限，就无法构建它。

它们使用一种称为椭圆曲线配对的密码学原语作为创建和验证这些证明的方法（我们不会在这里深入研究数学）。

关于 ZK-SNARK，一个需要注意的关键点是，在初始设置阶段，证明者和验证者必须同意使用一个“共享密钥”，称为公共参考字符串（Common Reference String，CRS）。任何有权访问此共享密钥的人都可以验证这些证明。

这个共享密钥使得 ZK-SNARK 成为可能；虽然这也是它们最大的缺点，因为它创建了所谓的“受信任环境”。

用于创建 CRS 的值，有时称为“有毒废物”，需要在生成 CRS 后销毁。如果它们没有被销毁，整个系统将面临风险；因为不诚实的证明者将能够计算出虚假证明；因此，用户必须相信该值已被销毁。

关于 ZK SNARKs，还有一点值得一提的是，它们不是“抗量子”的；这意味着它们在未来容易受到量子计算机的攻击；尽管它们将来可能会升级为抗量子的。

什么是 ZK-STARK？

ZK-STARK 意味着零知识可扩展透明知识论证（Zero-Knowledge Scalable Transparent Argument of Knowledge）。

• 可扩展（Scalable）：它们不是“简洁”的，而是可扩展的；这意味着与 ZK-SNARK 相比，它们可以更有效地生成和验证具有更大见证的证明。

• 透明（Transparent）：不需要受信任的设置。它们依靠可公开验证的随机性来生成共享密钥。

这种透明性的提高通常会带来生成比 ZK-SNARK 大得多的证明的权衡；除非处理非常大的数据集。证明的大小从 288 字节增加到几百 KB。

它们不使用椭圆曲线，而是使用 多项式 ; 我绝对没有资格告诉你关于它的事情。Vitalik 有一个关于这个主题的三个部分系列：1，2，3。

ZK STARKs 解决了我们讨论的关于 ZK-SNARKs 的两个问题，它们：

1. 不需要“受信任的环境”。

2. 在理论上是后量子安全的；这意味着它们将来不会受到量子计算机的攻击。

ZK-STARKS 比 ZK-SNARKs 更新，Vitalik 称它们为“ 更新、更闪亮的表亲”！🤠 所以，作为一个快速回顾：

zkEVM 是如何工作的？

既然我们已经介绍了零知识证明的工作原理以及 web3 世界中出现的两种常见 ZKP 形式，那么让我们来探索由 ZKP 驱动的最新创新之一；zkEVM（零知识以太坊虚拟机）。

zkEVM 有几种不同的形式；正如 Vitalik 在他的博客文章“ 不同类型的 ZK-EVM”中所概述的那样。我将在本文中引用的是 Polygon zkEVM。

zkEVM 的目标是提高以太坊区块链的可扩展性，同时保持安全、去中心化和 EVM-兼容性。

细节很复杂，但核心原则与我们迄今为止讨论的相同。与所有 ZKP 系统一样，有：

1. 证明者：生成有效性证明，表示用户提交的一批交易的真实性。

   • 首先，它创建多个 ZK-STARK 证明。

   • 它使用 STARK 递归 将 ZK-STARK 捆绑在一起，以创建一个 ZK-STARK。

   • 这个 ZK-STARK 很大，所以它会通过 CIRCOM 组件，该组件输出到 SNARK 构建器。

   • 顾名思义，SNARK 构建器生成一个 ZK-SNARK 有效性证明；这有助于将 Gas 成本从 5M 降低到 350K。

2. 验证者：部署在以太坊上的 PolygonZkEVM 智能合约是 ZK 证明的验证者。

zkEVM 中的数据流

下面是 Polygon zkEVM 中数据的简化流程图。

我已将其分解为按时间顺序排列的部分，以使其更易于理解。

提交交易

作为用户，你可以像往常一样使用任何其他 EVM 链（例如以太坊）提交交易；通过签署交易并通过 JSON RPC 发送它们。

运行 zkEVM 软件的排序器节点会接收这些交易，并确定它想要处理哪些交易，并且有一些激励机制可以正确地执行此操作。

批量处理交易

排序器将交易批处理在一起，并将它们提交给存储在以太坊主网上的 PolygonZkEvm 智能合约（以及以太坊 Goerli 测试网上的一个单独实例）。

这些批次此时不一定是正确的或经过验证的。

验证交易

使用 ZKP，PolygonZkEVM 智能合约在此设置中充当验证者。它想要验证它刚刚收到的批次是否有效；它通过将该批次发送到聚合器节点来实现这一点。

生成 & 验证 ZK 证明 / 有效性证明

PolygonZkEVM 智能合约将它刚刚收到的批次发送到聚合器节点，聚合器节点是运行 zkEVM 软件的另一台机器，它与 ZK 证明器通信。流程如下：

• 聚合器从智能合约接收批次

• 聚合器将批次发送到 ZK 证明器

• ZK 证明器创建多个 ZK-STARK -> 单个 ZK-STARK -> ZK-SNARK

• ZK-SNARK（有效性证明）被发送回聚合器

• 聚合器将有效性证明发送回 PolygonZkEVM 智能合约

• PolygonZkEVM 智能合约验证有效性证明

  • 如果有效性证明有效，则接受它。

  • 如果它无效，则拒绝它。

读取 ZK EVM

为了使 ZK EVM 有用，去中心化应用程序（dApp）需要从中读取信息；这就是同步器发挥作用的地方。

它从以太坊智能合约读取事件，存储来自聚合器的 ZK 有效性证明和来自排序器的批次的知识。

这样，应用程序可以通过 JSON RPC 轻松地获得汇总状态的视图。

总结

零知识证明是密码学的实际应用，可能是更注重隐私的未来的基础；这在诸如 Polygon ID 等产品中得到了证明。

在区块链的上下文中，ZKP 被用于通过提供一种新的方式来验证批量事务，而不会像我们今天在其他 rollup 解决方案中看到的那样，通常会损失安全性和 EVM 兼容性；从而改善诸如 Polygon 的 zkEVM 等产品中以太坊的可扩展性。

在这篇文章中，我们介绍了：

• 什么是 ZK 证明，以及为什么它们很重要。

• ZK 证明是如何工作的，包括 ZK-SNARK 和 ZK-STARK。

• 这些证明如何在区块链世界中使用。

如果你想学习如何应用这些概念，我之前的一篇博客文章介绍了如何在 Polygon zkEVM 上构建你的第一个智能合约和去中心化应用程序：

https://learnblockchain.cn/article/19722

这就是这篇文章的全部内容！在 Twitter 上关注我，每周获取更多像这样的教育内容：我的 Twitter。

• 原文链接： blog.jarrodwatts.com/how...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～