详解零知识证明 (ZKP) Groth16的可塑性

Move Sui 上，用户可以使用Groth16 高效、广泛使用的零知识简洁非交互式知识论证（Zk-SNARKs）（一种有用的零知识证明系统），高效地验证任何非确定性多项式时间（NP）语句。

零知识证明是增强区块链隐私和安全的关键密码方法。它允许一方（“证明者”）向另一方（“验证者”）证明某个语句为真，而不揭示任何机密细节。例如，证明者可以证明他们知道某个谜题的答案，而不揭示答案本身。

Groth16满足传统的非交互式零知识（Non-Interactive Zero Knowledge，NIZK）所具有的正确性、健全性和零知识性。此外，它还满足了更强的知识健全性，大致意味着产生验证证明的一方实际上确实知道一个有效的答案。然而，在将Groth16用作更大应用的一部分来实例化NIZK时，开发者需要确保所需的NIZK特性由原始的Groth16系统提供。应用程序可能需要NIZK的一些其他属性，包括模拟健全性、真实模拟健全性、颠覆抵抗性和模拟可提取性。文献中有很多资料表明，单独的Groth16并不满足这些属性。但当Groth16用作成员关系的零知识论证时，这些属性的缺失并不会影响系统的预期安全性或隐私性。

Groth16证明是可重混淆的，允许公开生成语句的新证明。换句话说，证明者发送的证明可以被混淆，看起来完全不同，尽管它仍然是相同语句的有效证明。事实上，重混淆在某些应用中已被用作一种特性。然而，应用程序开发者需要仔细理解这一特性，以防止在某些情况下发生双花攻击。特别是，应该在应用层中认识到，同一状态下两个不同的证明对应于相同的消费操作。

对于这一特性的类比，假设Alice和Bob共享一个名为Caesar编码本，其中 A对应K，B对应D，C对应M，以此类推，用来传递秘密消息。Alice将消息“Hello”加密为“IFOOR”。正在观察秘密传输的Eve可以进一步混淆消息，例如将所有字母都向后移动5位。新消息变为（NKTTW, 5）。Bob仍然可以通过先向前移动5位，然后反向应用密码本来解密这条消息。关键在于Alice和Bob之间的通信仍然保密，但同时，Eve可以将消息混淆得完全不同。同样的类比适用于Groth16 NIZKs，在这里我们使用证明而不是加密、秘密见证而不是秘密明文、可验证而不是解密来通信。

在许多应用中，Groth16被用于提供签名的零知识证明（Zero Knowledge Proof of Knowledge，ZKPoK）。在这类应用中，需要注意Groth16并不提供一种称为“模拟可提取性”的属性。该属性背后的直觉如下：假设有两个数独谜题，分别为SP1和相关的谜题SP2，它们都有解。一个诚实的参与者发布了一个证明pi，证明他们知道如何解决SP1。那么，一个攻击者能否在不知道完整解法的情况下，产生一个声称解决SP2的证明pi呢？需要注意的是，由于这两个谜题都有解，这样的攻击者不会违反NIZK的可靠性属性。

事实证明，满足一个较弱的模拟可提取性属性，足以安全地将大多数这类应用变成实例。幸运的是，Groth16可以较弱的满足这个概念，前提是满足一些技术要求。Andrija Novakovic和Kobi Gurkan描述了一种简单的方法，可以修改证明者，使得证明满足所有这些技术条件。snarkjs和arkworks库已经整合了这些修改，使用这些库的部署对于这些特定攻击是免疫的。

特别地是，这些技术条件强加了对仅由证明者使用的程序，即二次算术程序（Quadratic Arithmetic Program ，QAP）和Rank-1约束系统（Rank-1 Constraint System，R1CS）。Groth16验证器不需要这些作为输入，因此这些要求在证明者端可能更好地履行。此外，并非所有应用都需要这些额外的属性。因此，在Move方面，不太可能进行任何修改来适应这些更强的属性的保证，而是鼓励开发者融入适当的应用安全措施。