一份关于零知识证明的不完整指南：为什么 ZK 如此重要？
关于 ZK
用一句话形容零知识（ZK）证明：ZK proof 是证明者说服验证者某些陈述是真实的，但除了陈述是真实的之外不透露其他信息的一种方式。ZK 是为匿名而设计的。想象一下，我们可以证明我们有一个有效的 ID，而无需验证者知道我们的真实姓名或 ID。
这里有一个更生动的例子。爱丽丝和鲍勃正在玩数独。爱丽丝想向鲍勃展示她找到了答案。但是，她不想透露任何关于答案的信息，因为 Bob 仍在研究它。你将如何设计这个证明？
答案很简单。我们把数独写成卡片，面朝下。鲍勃可以随机选择一列、一行或一个块。爱丽丝拿走那一列、那个行或那个块，然后洗牌。Bob 可以通过检查 1-9 的卡片来验证正确性。通过不断地执行这一步，鲍勃可以说爱丽丝知道答案，但鲍勃在验证后不知道答案。
如果您仍然无法理解，请观看此视频。UCLA CS 教授将在五个不同的层次上解释 ZK。你一定会理解它。
常见的零知识证明系统
在全面检查 ZK 证明系统之前，请注意 ZK-SNARK 指的是一类方案的名称，而 ZK-STARK 是特定方案的名称。
让我们从 ZK-SNARK 开始。SNARK 代表简洁的非交互式知识论证。SNARK 不同于其他 ZK 证明系统，因为它的信任设置阶段，“N”代表了：
简洁：证明大小和验证时间小于原始计算（语句）。
非交互：证明者和验证者不需要为每一轮来回通信。相反，证明者和验证者需要完成初始设置阶段。即使他们错过了设置阶段，公共验证者也可以稍后加入验证。
论据：具有极大计算能力的证明者可以通过生成错误的证明来欺骗验证者。发生这种情况时，公钥/私钥加密也会被破坏。
知识：证明者需要知道一些秘密才能进行证明。
ZK-SNARK 的问题在于信任建立阶段。信任设置阶段生成一个参考字符串。如果参考字符串泄露，任何人都可以做假证明。此外，在多方之间协调这种信任建立阶段也很复杂。参考字符串只能在一个程序（电路）中使用。因此，不可能让 ZK-SNARK 具有用于一般计算的单一信任设置。另一个问题是参考字符串不可升级。如果我们升级程序，我们需要重新运行信任设置阶段。
为了解决这个问题，有两种方法：
透明设置：信任设置阶段设置一个 CRS（通用参考字符串）。如果 CRS 泄露，ZK 证明系统不会受到伤害。Fractal、Halo、SuperSonic 和 ZK-STARK 使用这种方法。这种方法的问题是证明的大小可能以 kB 为单位。这对于区块链领域来说太大了。
通用设置：设置创建一个秘密参考字符串，但它是结构化的。因此，它不仅可以在一个程序中使用。Marlin、SuperSonic-RSA 和 Plonk 使用这种方法。
业界常用的 ZK 证明系统如下：
Groth16：在 Zcash 中使用。它速度快，证明规模小，验证时间恒定，但信任设置阶段需要为每个程序运行。
Sonic：支持通用设置。SRS（结构化参考字符串）与受支持程序的大小成线性关系。证明大小是固定的，但验证成本很高。另一方面，它使一般计算成为可能。
分形：允许递归。证明尺寸很大。
Halo：支持递归。它并不简洁，因为验证时间是线性的。大多数 ZK 应用程序都基于 Halo2。
SuperSonic：第一款实用的透明 ZK-SNARK。
Marlin：结构化引用字符串（SRS）；通用且可更新；比 Sonic 更好的证明和变化时间，但比 Groth16 慢。
Plonk：通用设置；多方按顺序加入设置阶段。这使许多参与者很容易加入信任设置阶段；PLONK 使用 Kate 承诺而不是多项式承诺（回想一下，ZK-SNARK 的第一步是将计算转换为多项式问题）。Plonk 是现代流行的。许多 ZK 证明系统都基于 Plonk，它们被命名为 Plonkish。
这是基于这项研究的基准。CRS 是通用参考字符串。SRS 是在信任建立阶段生成的结构引用字符串。证明大小决定了基础层的存储成本——证明者和验证者的运行时间会影响计算资源。
来源：比较通用 zk-SNARKs
您可以在以下研究中找到更多基准：
使用 isekai 对零知识证明进行基准测试
零知识证明：STARKs vs SNARKs
社区提案：（零知识）证明系统的基准框架
不同 zk-SNARK 的比较
总结一下，如果你看到一个新的零知识证明系统，你应该关心什么数字？