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

日期：2023年04月15日 13:07 浏览量：1

来源| 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电路实现、电路安全工具、开发者工具和基础设施。稍后将概述这四个方面

。 ZK APP和设计模式

首先，我们的工作成果必须能够接触到最终用户，实现有影响力的生产级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密码原语的ZK电路

技术堆栈中，需要进一步提高核心密码原语的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的hard hat-circom (https://github.com/projectsophon/hard hat-circom )和Weijie Koh的circom-helper ) 3359www但是，还有许多工作要做。中间层表示的共同标准。为每个团队使用不同的语言和工具创建ZK电路。 circom、arkworks、libsnark等。理想情况下中选择所需的族。以不同工具链编写的电路必须编译为通用IR，以便生成证书、验证证书、审计协议设置以及执行其他常见任务，而无需考虑工具链。对Groth16来说，IR取决于普遍认可的密码参数和用R1CS表示的标准集。对于PLONK，此问题有点复杂，因为库开发人员需要明确如何表示自定义约束等。作为研究这个领域的一个例子、Dark Forest第三方客户端的开发激发了Kobi Gurkan和gakonst开发ark-cirom的动机，连接了arkworks和circom的生态。易于使用、更高效的编译器和证明器。慢密钥的编译和证明会延缓开发和测试。优化编译和证明，并打开这些流程的包装以开发现成的库。这意味着在大型服务器上部署远程验证器必须很简单)将节省开发人员的时间。 ZPrize是加速推进这项工作的行业倡议。 ((• (PLONK前)共同享有可靠的初始化基础设施。由于很难信任初始化协调，目前很难发布生产级别的ZK snark APP应用程序。 Zcash、AZTEC协议、Tornado和Semaphore需要创建定制的可靠初始化基础架构。虽然有一些尝试来构建可重用的可靠初始化工具，但是执行这些仪式仍然需要很大的工作量。请注意从长期来看，这可能不是问题，因为它切换到不需要对每个电路进行可靠初始化的协议。 ((• (PLONK后) SNARK递归工具。使用支持递归验证的SNARK，可以构建“可编程”SNARK中选择所需的族。在此，您可以通过插入其他SNARK子模块的授权密钥将SNARK代码更改为“即时”。递归SNARK还允许开发人员并行执行证明生成。很难真正支持这个功能

，可能在未来几年内就会解决.审计和验证

中描述的电路非常复杂，很难手动验证。巧妙的约束优化实际上加剧了这个问题。深度优化电路很难理解，在处理棘手的工作时，容易忽略实现中的某些约束。另外，在ZK APP性质上无法判断ZK电路的错误是否在外部使用。编写测试使您确信零知识证明满足“完整性”(completeness )是很简单的。证明方可以根据输入准确生成证言和证言的有效证明。我确信零知识证明更难满足可靠性(soundness )。为此，必须验证给定输入是否存在满足SNARK约束的系统。恶意证明者不能通过错误的证言(生成不满足约束的有效证书)渡海。比可靠性的证明更难的是证明电路和规格的等价性，也就是形式化验证。目前，生产中使用ZK电路的团队大多采用人工委托审计的方法，尽管这些审计质量参差不齐，但能审计的人非常少。可以确信，像Tornado.Cash电路(总共只有100行circom代码)这样的APP应用应该是安全的。但是，本公司的groth16的ECDSA原型实现依赖数千行circom码，规模有数十万或数百万个受约束的电路。更复杂的原语更难验证，PLONK的自定义约束更复杂。我们为ZK APP的安全空间提出了几种方法。将来，我将发表一篇博文，对我们所知道的这个领域的目前方法进行更深入的概述。建立评委社区。团队通常很难找到有ZK APP应用开发经验的专家来审查电路和代码。可以鼓励现有的专注于ZK的团队(例如rollup公司的工程师或APP应用程序开发人员)“付费”提供评论同时，也可以一起训练审计员。确立电路开发和评审的最佳实践。随着生态的成熟，我们希望开发用于构建、注释、归档和审阅ZK电路的最佳实践。实现这个目标的手段各不相同，自然语言规范或形式规范有助于使电路更清晰。列举常见的错误和错误(并开发捕获它们的基本工具)也有助于工程师和审阅者。手工证明电路原语的正确性。对于散列函数和ECDSA电路等重要原语，可以手写这些原语的正确性证明，这些证明可以由检查者进行检查。其他电路开发者可以更自信地使用这些原语。验证自动验证的唯一性。 Ecne是首次R1CS目击的唯一自动化验证器。在这个项目中，我们可以验证ZK电路是否存在缺少的约束。这是对ZK系统有信心的重要步骤。我们希望支持和鼓励更多类似的工作。基于求解器的形式化验证方法。一些团队正在寻找证明ZK电路等同于形式规格的自动化工具。这项工作需要开发一种语言来明确描述一组通用的基准，以及部分或全部ZK电路。感谢Lakshman Sankar、Yi Sun、Kobi Gurkan和Wei Jie Koh的反馈和校对。特别感谢ECN社区的翻译志愿者@doublespending为本文的翻译做出了贡献。