客户端零知识证明：挑战和解决方案

原文标题：ZKP on the Client-side: Challenges & Our Solutions

TLDR

在客户端构建一个良好的零知识证明系统比看起来要困难得多。然而随着ZKP发展至今，客户端生成ZKP并进行链上验证已经成为可能。2024将会是客户端零知识证明系统走向大众视野的一年。这篇文章将从技术角度讲述为什么客户端零知识证明如此困难，和OpenID3是如何解决对应的挑战的。

包含去中心化社交网络，全链游戏，隐私身份验证和隐私KYC/AML，新型DeFi应用在内的Web3个赛道，客户端零知识证明将提供非常重要的基础设施。

我是OpenID3的密码工程师。OpenID3作为客户端零知识证明的先导者之一，希望在这篇博客里简单聊聊客户端零知识证明为何如此困难，同时聊聊OpenID3是如何解决这些问题的。

构建零知识证明系统是种什么样的体验？

我们今天所拥有的 零知识证明系统（ZKP）主要服务于扩展以太坊的扩容。发展至今，确实有一些很棒的客户端应用，但大多基于其他系统的运行，或由简单电路组成，或不太关心用户体验。

当我参加行业活动时，介绍自己是一名 ZKP 工程师时，最常见的反应是我是否为 zkSync 工作，或我们是否正在构建另一个 zkRollup Layer2。一段时间后，就有点烦人了。这有点像说你住在新加坡，人们就开始问他们是否真的有鞭刑。不管怎样，我只是想大致描述一下这里的场景：大多数 ZKP 系统并不是为客户端应用构建的。

为什么不呢？有几个主要的考虑因素，在我深入介绍工程师们考虑的重要方向之前，先介绍几个ZKP的基础组成。

1. Prover/Verifier 证明者和验证者：直白来说就是，证明者程序花费大量运算资源证明一些特定程序和对应的输入，从而使得验证者程序可以简单快速的证明证明者是诚实的。对于大多数 ZKP 系统来说，验证者通常是智能合约。
2. Circuit & Witness 电路和见证：证明者拥有的信息称为见证人，定义好的程序成被称为电路。给定电路和见证就可以生成证明。
3. Public & Private Witness 公开见证和私有见证：在构建电路的时候，见证默认是私有的，某些情况下一些信息会被标记成公开的。这些公开的信息有助于验证人验证电路或者执行智能合约的逻辑。
4. Application & Aggregation Proof 应用证明和聚合证明：大多数ZKP都需要聚合。将多个应用证明聚合在一起就生成了聚合证明。聚合证明可以让验证者批量验证ZKP，可以节约Gas Fee和减少链上信息污染。

现在，在了解了这些基本概念之后，ZKP 工程师通常会考虑以下几点：

1. Prover Time & Memory Consumption 证明者时间和内存消耗
2. Verifier Cost: 验证者成本。
3. Size 大小：文件和钥匙大小涉及多个种类，包括：
   1. Proof Size 证明大小，通常和Gas Fee正相关
   2. Executable Size: 打包后程序大小
   3. Parameter Size: 某些ZKP系统需要进行可信设置，可信设置文件大小与电路复杂度正相关。
   4. Key Size: 钥匙大小。一些验证系统的证明者钥匙会非常巨大。在OpenID3的早期，我们曾经尝试使用Halo2构建电路，所生成的证明者钥匙高达3GB。

客户端 ZKP

zkRollup证明系统和典型的客户端证明系统，关注的优先级是不同的。同样，如果不做出妥协，通常很难实现所有优势。ZKP在客户端和服务器端有着本质的区别。一般来说，zkRollup证明系统运行在服务器端，可以掉配近乎无限的计算资源和超高速网络。然而在客户端，运算资源十分有限，用户网络极有可能很不稳定，用户也不会耐心地等待并不断刷新网页。

于是：

• 证明者时间和内存消耗是客户端 ZKP 的第一要务，而在服务器端则要宽容得多；
• 文件大小。对于我们编写的某些电路，可信参数可以大到 20MB，对于某些ZKP系统，其生成的WASM可执行文件可以达到几百MB。我们无法将这些文件发送给客户，并期望客户对下载文件的漫长等待有耐心。任何大于3MB的的可执行文件、密钥、参数都将难以被用户接受。
• 链上验证成本。验证 Rollup 的成本可以由海量用户分担，但客户端 ZKP 证明通常需要每一个去用户承担成本。
• 延迟。zkRollup不需要对每个块进行聚合证明计算，但客户端ZKP需要在系统能够完成的情况下尽快进行。用户不会等待几天才能在链上验证他们的证明，相反，几分钟将是用户可接受时间的极限。

毫无疑问，构建 Rollup 式的 ZKP 系统是一件非常复杂的事情，但是，构建一个功能性的客户端 ZKP 系统并不是一件

容易的事，实际上对系统功能提出了更苛刻的要求。

ZKP 系统的思考

基于以上思考，我们开始了OpenID3的构建。OpenID3是一套基于ZKP的开放协议，用来在链上证明用户的Web2社交账户所有权。OpenID3将在客户端证明用户的身份凭证，之后将ZKP发布到一个开放的ZKP聚合器网络并提交上链。期间，用户所有信息不会离开用户本地，并且可以便宜高效的在链上验证。应用场景包括：

1. 无许可(Permissionless)和去中心化的安全上链用户的Web2身份。
2. 去中心化，自托管的社交登陆钱包。

早期测试版已经在Linea网络上验证了超过400,000个身份信息。

简单来说，我们已经完成了如下成果：

1. 客户端将下载一个大小约为 2MB 的 WASM 可执行文件；
2. 客户端将在大约30秒内生成应用证明；
3. 然后，客户端会将应用程序证明传递给通用聚合器之一并放入队列中。聚合器将定期被触发。聚合器将花费大量内存和大约3分钟来聚合证明并将证明传递回客户端。聚合器还将证明的所有客户端公共输入注册到Merkle 树中，并将树根公开为聚合证明的公共见证。
4. 聚合器将在链上提交聚合证明，智能合约可以验证该证明并记录大约 250,000 Gas 的 Merkle Tree 根。 （等同于从 ETH 到某些 ERC-20 代币的 Uniswap 调用的价格）。目前一份证明包含32-64个用户证明，验证的Gas Fee将被这些用户平摊，从而每个用户为ZKP验证付出的Gas Fee基本和一次链上的ETH转账相当。
5. 用户可以提交“claim”调用并进行Merkle证明，以使用哈希消息来识别自己的身份，并将被证明ZKP的链接到他们的地址。

除了链上地址和由用户提交的身份哈希之外，聚合器、智能合约和我们对用户身份一无所知。

如何实现以及如何改进

这部分可能有点技术性，需要一些ZKP背景知识.

1. 在客户端，我们选择使用Plonky2，这是一个FRI+Plonk使用Goldilock的ZKP系统。它不需要可信设置、快速的证明时间和合理的内存消耗。我们精简了电路，以满足验证验证身份的最低要求, 编译后的 WASM blob 大约为 3MB。
2. 在聚合器端，我们首先将Plonky2证明聚合成一个“包装的”Plonky2 证明，该证明能够将大量Plonky2证明聚合成一个，验证正确的电路结构（即用户正在按照我们的预期执行确切的电路，将公共见证压缩成Merkle树以节省空间等。
3. 在Plonky2 聚合之后，我们在Gnark内部运行 Plonky2 验证器，它将证明和验证器密钥转换为链上快速可验证的形式。Gnark 聚合是主要的时间消耗者，大约需要 2 分半钟。
4. 最后，通过聚合证明，用户可以使用通用的Plonky2+Gnark验证器合约，以低廉的成本验证自己，仅需 211,000 个 Gas，加上链上调用存储的overhead，验证成本得以被控制在250，000Gas以下。

目前，OpenID3的ZKP端正在进行两项工作：

• 我们希望通过 GPU 加速等黑魔法来加快 Gnark 聚合时间，目标是不到半分钟;
• 我们正在对树状依赖进行摇动，以进一步最小化可执行文件的大小，最好是低于1MB。

写在最后

客户端ZKP是一个探索者太少的领域，我们希望与任何其他团队合作来标准化我们所采取的流程。

• 框架、DSL 可以围绕轻松组成的 Plonky2 电路进行构建，以进行应用证明。
• 我们还没有为许多流程引入折叠优化，我们期望通过聚合折叠来实现巨大的性能提升。
• 可以构建聚合器服务或通用链上验证服务，作为 ZKP 未来的关键基础设施，为更大的社区带来安全性、去中心化和出色的开发人员体验。