Sui安全篇｜详解零知识证明 (ZKP) Groth16的可塑性

Sui Move允许用户使用Groth16进行高效验证任何非确定性多项式时间（Non-deterministic Polynomial time ，NP）状态。Groth16是一种高效且广泛使用的零知识简洁非交互知识证明（Zero-Knowledge Succinct Non-interactive Argument of Knowledge ，ZK-SNARKs），这是一种非常有用的零知识证明系统。

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

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方面，不太可能进行任何修改来适应这些更强的属性的保证，而是鼓励开发者融入适当的应用安全措施。