零知识：我该如何实现它？

来源| 0xparc.org作者| gubsheep翻译|双花(@doublespending )校对| ECN推荐阅读：“知识身份零(为什么需要)”？ ”这是解释为什么密码学的新进展对数字身份原语很重要的一系列文章。 第一篇文章解释了“为什么”； 本文说明“怎么做”。 在上一篇文章中探讨了zkSNARKs等新型加密工具对构建新一代数字身份基础架构不可或缺的原因。 本文详细介绍了构建基于ZK的身份系统原型所需的技术？ ZK身份项目的规模比任何组织都大得多。 标准的设定、基础设施的建设、原语的反复、APP设计的问题逐渐浮出水面，需要各种各样的利益相关者和各领域的专家的贡献。 考虑到ZK身份机制对许多人具有潜在影响，并且严重依赖公共物品——开源基础设施、工具、标准和合作，一个有机的、社区主导的“生态系统”自下而上，而不是一个公司自上而下推进，这一点尤为重要； 同时，需要特别关注发展的可持续性和激励设计。 单个公司在这种动态生态下成功的可能性也越来越小因为在技术堆栈中各级独立发展的技术正在迅速变化。 相反，我们需要培养和构建由模块化、敏捷、半独立、具有相同愿景的团队组成的生态系统。0xPARC ZK工作组致力于通用ZKID然后邀请其他积极考虑这个问题的人来我们，互相切磋。 ZK身份的组件

ZK工具必须允许数字系统的参与者声明身份和信用。 具体而言，这些声明可以归结为执行签名验证、密钥生成、散列、加密等与零知识区域相关密码运算的数学命题。 可以将这些“组件”组合在一起，以便为更复杂的声明生成ZKP。 作为一个简单的例子，请参见文章Shuming hao123 @ QQ.com (33590 XP arc.org/blog/ZK-group-sigs )。 某些运算和密码方案使用zkSNARKs实现时比其他技术更高效。 从长远来看，SNARK友好的密码标准将被目前不存在的新身份提供商采用。 例如此外，使用SNARK友好加密方案的公钥签名方案的块链(或更具表现力的系统，诸如[帐户抽象] )。 然而，为了进行原型验证并在短期内发挥作用，我们的工具需要与现有的加密id系统清洁集成的——，例如以太网的当前ECDSA签名方案，或者与便于在其他场景中进行配对的椭圆曲线相组合的最近的加密标准。 我们认为，为zkid APP构建实用程序堆栈需要在四个方面取得重大进展： ZK APP堆栈的设计模式、密码原语的ZK电路实现、电路安全工具、开发者工具和基础设施。 稍后将概述这四个方面

首先，我们的工作成果必须能够接触到最终用户，实现有影响力的生产级APP。 在开发ZK工具和组件的同时，需要找到使用和组合它们的最佳方法。 以下是几个开放性的问题。 什么是身份的正确抽象呢？ 以太网地址、以太网地址集合、多符号、智能构建钱包、ENS名称、不同加密方式的密钥对、秘密生物学特征、证书集或[高层结构] 65https://eips.ether er？ 人们关心的一般身份证是什么？ 上述所有工作为我们提供了作出有关身份的可靠声明的语言； 现在我们必须学习如何用这个语言表达。 例如，直接参照链上散列数据进行操作的声明是否有意义或者，如果大多数声明只是可信第三方有效认证的简单证明，会更简单吗？ 可以用ZK证书发表引用以太体的历史状态的声明吗？ 如果可能的话，证明工具应该很容易得到什么样的历史声明？？ 未来的ZK钱包和身份提供者应该提供什么工具，遵循什么标准？ 例如，Metamask和硬件钱包当前支持使用私钥进行数字签名，建议不要直接对私钥进行操作。 但是另外，在SNARK上进行的ECDSA签名验证比公开密钥生成昂贵得多——这是因为想要ZK证明其ETH地址的用户在慢得多的证明时间(基于有效签名认证的证明方式)和低的安全性(将其私钥从钱包明文复制到ZK证明生成程序中)。 如果钱包软件最终支持本机生成ZK证书，则此问题将得到部分解决。 目前正在与Metamask Snaps团队进行实验。 支持ZK身份的APP应用必须遵循什么样的接口？ 设计链上和链下APP应用时必须考虑ZK身份系统。 例如，有意使用ZK身份系统的NFT封闭社区可能会在NFT智能约定中存储token的密码累加器和token所有者数据中选择所需的族。 这使用户更容易生成关于社区成员资格的声明。 有必要制定有意提供成员证明的小组标准。 谁可以生成ZK证书？ 落地APP生成证明的位置差异很大、特定的ZK证明是否可以在硬件钱包、移动设备、浏览器或消费者台式计算机上生成，或者只能在专用的证明服务器上生成。 解决这些问题的最好方法是开始开发！ 我们希望在未来几年内形成一个强大的开发人员社区，以各种方式开发APP。 事实上，我们现在可以利用现有的基础设施来开发一些zkid APP应用程序。 这是一项高附加值的工作，除了提供有意义的APP外这些项目还为工具和基础设施的开发提供信息指导。 以下是一些ZK身份的初步生产级应用候选人隐私空投。 许多defi APP应用的典型策略是在链中公开用户地址的Merkle路由使用户可以在树中发布的地址处调用函数来申请空投。 stealth drop (https://github.com/nalinbhardwaj/stealth drop )是ETHUni和0xPARC社区的项目，增加了隐私层，用户只需证明持有树内的ETH地址所对应的私钥就可以申请空投。 链上的快照投票聚合。 现在此外，许多“DAO”完全使用链接投票机制——用户对投票进行签名，并将签名发送给集中的服务提供商(即快照)以进行统计。 这带来了两个问题。 第一，投票可能会被中心化机构审查、之前的投票数据可能会丢失、无法使用、无法审计。 第二，投票公开进行，投票系统容易受到共谋攻击。 我们可以使用ZK结构进行签名验证，并将投票结果“包装”在投票者签名的单一ZK证书中此证书可以不信任地生成并在链上提交。 一些分布式中心化机制的权限适度结构(即向更广泛的证明方网络分配权限并发布令牌所有者快照的Merkle路由)也与可扩展性相兼容。 匿名可信证明。 这些id工具可用于证明组成员的身份，而无需透露确切的id。 例如，证明你对黑暗森林行星的所有权，不公开身份参加NFT封闭社区，但是匿名作为大V投稿，不透露你的账号就证明推特上至少有100万以上的粉丝； 或者证明你是立法机关的成员，在以后的投票中匿名附议。 其中也有在我们的报道《ZK 群签名》中更详细讨论的APP

技术堆栈中，需要进一步提高核心密码原语的ZK电路和背后数学运算的效率，以及审计的实现。 下面是几个重要操作的示例。 大致按依赖关系排序。 非本机有限域算法： zkSNARK算法基于素数域。 例如，默认情况下，snarkjs中的所有值都是254位素数(babyjubjubprime (https://iden3- docs.readthedocs.io/en/latest/iden3_ repos )。 但是，密码操作需要对潜在的更大数字操作——。 例如，secp256k1操作需要获取两个256位字符模式的第三个256位数字结果的乘积。 与这些电路相关的最昂贵的操作是范围检查约束优化的策略之一是更仔细地确定何时需要范围检查。 • SNARK友好散列函数：散列函数在用户必须约定密码的APP应用中很有用。 在散列函数不需要与现有标准集成的情况下，您可以选择设计和实现专门用于SNARK证明的高效散列函数。 这两个函数包括mimc (https://by T3 bit.github.io/prime sym/mimc/)、Poseidon ) https://www.Poseidon-hash.info/。 SNARK不友好，但标准化散列函数：许多APP应用要求使用SNARK不友好的散列函数，诸如SHA256和keccak，以便与现有系统兼容。 例如需要kec cak (https://github.com/VOC doni/kec cak 256-circom )的ZK电路实现来证明私钥支持ETH地址。 我们必须付出巨大的努力才能实现，优化和审计这些散列函数。 椭圆曲线点加法：椭圆曲线密码学建立在椭圆曲线群之上； 因此，必须为椭圆曲线群的法则(点加)构建ZK实现。 这些运算很贵然后是ZK身份系统的性能瓶颈； 巧妙利用PLONK，实现更多的算法可能有助于提高性能。 ECDSA密钥生成和签名验证：实现用于ECDSA密钥生成和签名验证的ZK电路可以构建与现有的基于ECDSA的身份系统(如以太网)兼容的身份声明语言。 要构建这些原语，需要实现椭圆曲线的点加法和散列函数(https://github.com/0x parc/circom-secp 256 k1/blob/master/circuits/eth _ addr.circom )。 椭圆曲线对：便于配对的椭圆曲线，可以使用双线性映射——支持多项式提交、BLS聚合签名验证、递归SNARK验证、Verkle树等。 椭圆曲线对ZK电路的有效实现解锁大量新型密码运算。 密码累加器嵌入检查：如果有用于多项式承诺验证的ZK电路，则可以通过SNARK验证Verkle树嵌入证书。 Merkle树嵌入证明目前是可验证的，适用于使用SNARK友好散列函数构建的树。 MPT嵌入证书允许SNARK验证写客户端证书。 在所有这些场景中，通过验证累加器嵌入证书，SNARK可以访问汇总到简单全局状态承诺(根)中的数据——。 要访问的数据、系统状态根和嵌入证书是SNARK的输入，验证者只需验证你的简洁证明，检查路由是否正确，而不需要检查整个系统的状态。 递归SNARK验证：在zkSNARK中提供椭圆曲线对和/或多项式承诺验证，以启用递归SNARK。 这开辟了身份证中可编程性和复杂性的新领域。 这些电路都用R1CS编写，groth16证明系统最近正在研究，将在不久的将来优化为基于PLONK的证明系统。 开发者工具和基础设施

ZK电路开发工具是一个重要的课题。 目前ZK开发者需要比较高的数学背景和技术经验，必须在比较基础的开发环境中进行编码，依靠手动或特定脚本来管理文件，并通过开发管线(设计-产品)传递电路。 此外，现有的开发人员工具分布在多个研发团队、rollup企业等组织中。 这里需要特别注意的是坚固的工具箱对PLONK特别重要。 PLONK消除了对各电路进行可信初始化的需要，大大加快了部分电路的编译和证明生成过程，受自定义约束开辟了递归SNARK验证的途径。然而，相比 Groth16 ，PLONK 工具目前仍处于开发的初期阶段，其验证者优化程度偏低，高级协议特性尚未在一些系统中实现。此外，在 IR 标准和自定制约束语言设计上仍有很多工作要做。AZTEC、Electric Coin Co、ZK-Garage 等小组正努力地开发这些工具。除了 PLONK 工具链外，下面是ZK开发者工具中的一些活跃领域：• 更高层级的 DSL。当前用于编写 SNARK 的语言非常底层，需要开发者手工编写约束。我们对更容易开发，甚至集成了约束优化的生产级高层级 DSL （一个来自 0xPARC 社区成员的原型）感兴趣。另外，值得具备的功能包括用户定义数据类型/注解以及更好的见证生成系统。更进一步，支持电路测试、验证或静态分析自动化的 DSL 将会增加我们对所编写代码的信心。• 更智能的开发环境。编写、分析和测试电路是一个艰难的过程。开发过程中的语法高亮、编译时错误检查，使用 AST/witness 分析、注解（即将电路模板标记为“安全”或“不安全”，标记无约束信号）类似 IntelliSense 的工具，以及 shell REPL 环境能够快速提升迭代速度。使用了 Kevin Kwok 的 ZKREPL 项目（包含上述若干特征），ZK 学习小组的效率得到了大大地提升。• 构建、测试和部署工具；自动化和流水线管理。ZK 开发者目前必须手管理 ptau 文件、密钥文件、构建配置、构建文件以及发版流程。snarkjs 教程(https://github.com/iden3/snarkjs)目前列出了开发者创建和验证 zkSNARK 必须完成的26个步骤，涉及对20多个文件的手动操作。关于如何以可访问及可审计的方式发布协议参数，目前还没有被广泛接受的最佳实践。开发者必须针对不同的环境手动维护不同版本的电路（即在测试期间关闭一些约束）。ProjectSophon 的 hardhat-circom(https://github.com/projectsophon/hardhat-circom) 和 Weijie Koh 的 circom-helper(https://www.npmjs.com/package/circom-helper) 等工具是大幅简化工流的第一大步，但仍有许多工作要做。• 中间层表示的通用标准。不同的团队使用不同的语言和工具来编写ZK电路：circom 、arkworks、libsnark 等。理想情况下，不同工具链编写的电路应该编译为通用 IR ，以便生成证明、验证证明、审计协议设置以及其他通用任务可以与工具链无关。对于 Groth16 来说，IR 取决于普遍认可的密码参数和 R1CS 表示的一个标准集。对于 PLONK 来说，这个问题有点复杂，因为库开发者需要弄清楚如何表示自定义约束等等。作为钻研该领域的一个例子，Dark Forest 第三方客户端的开发激发了 Kobi Gurkan 和 gakonst 开发 ark-cirom 的动机，其连接 arkworks 和 circom 的生态。• 易用且更高效的编译器和证明器。缓慢的密钥编译和证明会延缓开发和测试。优化编译和证明，并开发这些流程开箱即用的库（即，在大型服务器上部署远程验证器应当简便！）将节省开发者的时间。ZPrize 是一项旨在加快该工作推进的行业倡议。• （PLONK 前）共享受信任初始化基础设施。由于信任初始化协调的困难，目前很难发布生产级 zkSNARK 应用。Zcash、 AZTEC 协议、Tornado 以及 Semaphore 都必须编写定制的受信任初始化基础设施。有一些构建可重用的受信任初始化工具的尝试，但运行这些仪式仍需耗费大量人力。请注意，长远来看，由于我们会切换到无需每个电路进行受信任初始化的协议，这可能不会是个问题。• （PLONK 后）SNARK 递归工具。支持递归验证的 SNARK 使我们能够构建“可编程” SNARK ，其中 SNARK 代码可以通过插入其他 SNARK 子模块的验证密钥来“即时”修改。此外，递归 SNARK 还允许开发者并行化证明生成。真正地支持这一功能是一个难题

上面列出电路十分复杂而且难以手工验证。巧妙的约束优化实际上加重了这个问题—深度优化的电路难以理解，如果你正在处理棘手的工作，那么在实现过程中很容易忽略某个约束。此外，由于 ZK 应用程序的性质，无法判断ZK电路中的 bug 是否已被外部所利用。编写让你确信零知识证明满足完整性（ completeness ）的测试相当容易：证明你可以为见证者正确地由输入生成见证和见证的有效证明。确信零知识证明满足可靠性（ soundness ）更加困难。为此，你必须验证给定输入存在着满足 SNARK 约束系统的见证—恶意证明者无法用一个错误的见证（生成一个并不满足约束的有效证明）瞒天过海。相比可靠性证明更难是，证明电路与规范间等价性，即形式化验证。目前，大多数在生产中使用 ZK 电路的团队采用的方法是委托人工审计，尽管这些审计的质量参差不齐，有能力进行审计的人非常少。我们可以相当肯定像 Tornado.Cash 电路(总计仅有 100 行 circom 代码）这样的应用大概是安全的。然而，我们的 groth16 的 ECDSA 原型实现依赖于数千行 circom 代码，有着规模为数十万或数百万个约束的电路。更复杂的原语将更难验证，而 PLONK 的自定义约束将增加额外的复杂度。我们为 ZK 应用程序安全空间提出了几种方法。未来，我们将发布一篇博文，对我们所了解的该领域的当前方法进行更深入的概述。• 建立一个评审员社区。团队通常难以找到拥有 ZK 应用开发经验的专家来评审他们的电路和代码。我们可以鼓励现有的专注 ZK 的团队，如 rollup 公司的工程师及应用开发者，来“有偿提供”评审，同时我们还可以开始一起培训审计员。• 建立电路开发和评审的最佳实践。随着生态的成熟，我们希望开发用于构建、注解、归档和评审 ZK 电路的最佳实践。实现该目标的手段各不相同，自然语言规范或形式规范都有助于使电路更为清晰。列举常见的 bug 和错误（并开发一些捕捉它们的基本工具）也会对工程师和评审员有帮助。• 电路原语正确性的手工证明。对于如哈希函数或 ECDSA 电路的重要原语，可以手写此类原语的正确性证明，这些证明可被证明检查者检查。其他的电路开发者将能够更有把握地使用这些原语。• 自动见证唯一性验证。Ecne 是首个 R1CS 见证唯一性的自动化验证器。该项目使我们能够验证 ZK 电路是否有任何缺失的约束，这是在我们 ZK 系统中建立信心的一个重要步骤。我们希望支持和鼓励更多类似的工作。• 基于求解器的形式验证方法。一些团队正在探索证明 ZK 电路与形式规范等效的自动化工具。这方面的工作还需要我们开发出一套通用的基准测试，以及一种用于（部分或全部）明确描述 ZK 电路的语言。致谢感谢 Lakshman Sankar、Yi Sun、Kobi Gurkan和 Wei Jie Koh 的反馈和校对。特别感谢 ECN 社区翻译志愿者 @doublespending 对本文的翻译贡献。

推荐阅读

零知识：我该如何实现它？