关于为什么密码学的新进展可能对数字身份基元很重要。上一篇DAOrayaki介绍了“DAOrayaki｜为什么Web3需要ZK身份？”；这篇文章介绍“如何实现”。
在上一篇文章中，我们讨论了为什么新的加密工具，如zkSNARK，将对构建下一代数字身份基础设施至关重要。在这篇文章中，我们将深入到细节中——为了建立基于ZK的概念验证的身份系统，需要进行哪些技术工作？
ZK身份的“大项目”比任何一个组织都要大得多。制定标准、建立基础设施、迭代身份基元和应用设计问题将逐渐发生，并需要各种不同的利益相关者和专业领域的投入。鉴于ZK身份机制有可能影响到许多人，并且在很大程度上依赖于公共物品——开源基础设施、工具化、标准、协调——因此，重要的是，这项工作要从一个有机的、社区驱动的“生态系统”中自下而上地产生，而不是从一个公司自上而下地产生，并且要特别注意可持续发展和激励设计。
在这样一个动态的生态系统中，一个孤立的公司也越来越不可能成功，因为在堆栈的各个层面独立开发的技术正在迅速变化。相反，我们将需要培养和协调一个由模块化、快速发展和半独立的团队组成的生态系统，共享一个共同的整体愿景。
ZK身份的构件
ZK身份识别工具必须使数字系统的参与者能够提出关于身份和名誉的声明。具体来说，在零知识中，这些声明可以归结为执行签名验证、密钥生成、散列和加密等加密操作的数学陈述。我们可以把这些“构件”组合在一起，为更复杂的要求建立零知识证明：举个栗子，请看我们关于ZK群签名的文章。
一些操作和加密方案可以在zkSNARK中比其他方案更有效地实现。从长远来看，SNARK友好的加密标准可能会被今天还不存在的新身份提供者所采用——例如，基于SNARK友好的加密技术的公钥/私钥签名方案的区块链。但是，为了证明概念并在短期内发挥作用，我们的工具需要与现有的加密身份系统很好地整合——例如，以太坊目前的ECDSA签名方案，或者，围绕配对友好的椭圆曲线形成的更多最新加密标准。
我们相信，为ZK身份应用建立一个可用的工具栈需要在四个方面取得重大进展。ZK应用设计模式，实现ZK电路的加密基元，电路安全工具，以及开发者工具和基础设施。我们在下面总结了每个领域。
ZK应用程序和设计模式
首先，我们工作的产出应该是触及终端用户并赋能有影响力的生产级应用。在开发ZK工具和构件的同时，我们必须弄清楚使用和组成它们的最佳方式。这里有几个开放的问题：
彭博社：Tether间接拒绝了乌克兰屏蔽俄罗斯用户的请求:3月14日消息，据彭博社报道，稳定币发行商Tether（USDT）无视乌克兰政府呼吁停止与俄罗斯人进行所有交易的要求。Tether早些时候在一份官方声明中表示，“Tether正在持续监控市场，以防止可能违反国际制裁的不规则动向。” 但并未表示将中断同俄罗斯人的交易。对此，彭博社解释称，“Tether并未直接拒绝乌克兰参与制裁俄罗斯的请求，而是通过官方声明间接表达了‘拒绝’的意图。”
此前消息，乌克兰副总理Halo Fedorov呼吁Tether和Bitfinex停止与俄罗斯人的所有交易。[2022/3/14 13:54:40]
身份的正确抽象含义是什么？它是一个以太坊地址，一个以太坊地址的集合，一个多签，一个智能合约钱包，一个ENS名称，一个不同的加密方案中的密钥对，一个秘密的生物识别，一组证明，一种更高层次的构建，或是完全不同的东西？
哪些是人们关心的常见身份声明？所有上述工作给了我们一种语言，用于提出关于身份的可信的声明；现在，我们必须学习如何真正用这种语言说话。例如，直接引用和操作链上存储的散列数据的声明是否有用，或者如果大多数声明只是由半可信的第三方提供的有效证明，是否会更容易？在ZK证明中引用历史上的以太坊状态的声明是否实用——如果是这样，证明工具应该使哪类历史声明容易获得？
未来的ZK钱包和身份供应商应该有哪些工具和标准？例如，Metamask或硬件钱包目前支持用私钥进行数字签名，一般建议私钥不应该由用户直接操弄。然而，ECDSA签名验证在SNARK中的执行成本比公钥生成要高得多——这意味着希望对其以太坊地址进行ZK证明的用户将不得不在更慢的证明时间和更低的安全性之间做出选择。如果钱包软件最终提供对ZK证明生成的本地支持，这个问题可以得到部分解决，我们目前正在与MetamaskSnaps团队进行实验。
支持ZK身份的应用程序需要遵照哪些接口？链上和链下的应用程序将需要在设计时考虑到ZK身份系统。例如，希望使用ZK身份系统的NFT门卡社区可能希望在NFT智能合约中也存储一个代币和代币所有者数据的加密累加器，以便用户更容易生成关于社区成员身份的声明。我们需要为希望进行成员资格验证的团体开发标准。
谁可以生成ZK证明？可行的应用各不相同，这取决于某些ZK证明是否可以在硬件钱包、移动设备、浏览器、消费者台式电脑上生成，或者只在专用证明服务器上生成。
回答这些问题的最好方法就是开始建设！我们希望在未来几年内开始形成一个强大的开发者社区，用各种不同的方法来构建应用程序。
事实上，一些ZK-Identity应用程序可以在今天用现有的基础设施状态建立。这是很有意义的工作——除了提供有用的应用，这些项目还将为工具和基础设施的发展提供参考。以下是一些ZK身份认证的初步生产应用的候选项目。
隐私空投。许多DeFi应用的一个常见策略是在链上发布用户地址的Merkle树根，并允许用户通过调用树上发布的地址的函数来申请空投。Stealthdrop是来自ETHUni和0xPARC社区的一个项目，它在此基础上增加了一个隐私层，允许用户从任何地址领取空投，只需证明他们拥有与树上的以太坊地址相对应的某个私钥的证据。
链上快照投票汇总。今天，许多“DAO”完全使用链下投票机制，用户签署投票并将这些签名发送到中央服务提供商进行统计。这带来了两个问题：首先，投票可能被中心机构审查，过去的投票数据可能会丢失或不可用/不可审计。第二，投票是公开进行的，使投票系统容易受到共谋的影响。我们可以使用签名验证的ZK结构，将投票结果“卷起来”，形成一个单一的选民签名的ZK证明，可以无需信任地生成和提交上链。如果牺牲一些可扩展性，也可以将权力从中心机构部分分配给中间结构。
匿名但可信的证明。这些身份证明工具可用于证明在一个群体中的成员身份，而不透露你的确切身份——例如，证明黑暗森林星球的所有权，并加入一个NFT门卡社区，而不透露你的身份；作为一个匿名但受欢迎的Twitter用户发一个帖子，证明你有至少100万以上的Twitter粉丝，而不透露你的账户；或证明你是一个立法机构的成员，在即将进行的投票中匿名示意共识。其中一些应用在我们的ZK群签名文章里有更多讨论。
加密身份基元的ZK电路
在堆栈中再深入一层，我们需要高效的、经过审计的ZK电路的实现，用于核心密码基元和它们的数学运算。下面是一些关键操作的举例，按非常粗略的依赖性从上往下排序。
非原生域运算：zkSNARK的运算是在素数域中进行的——例如，snarkjs默认的所有信号都是以254位的BabyJubJub素数为模。然而，加密操作要求我们对可能大得多的数字进行操作——例如，secp256k1操作要求我们对两个256位数字的乘积取模于第三个256位数字。这些电路中涉及的最昂贵的操作是范围检查，约束优化的一个策略是更加谨慎地确定我们何时需要精确地执行范围检查。
适合SNARK的散列函数：散列函数在用户必须做出加密承诺的应用中非常有用。在散列函数不需要与现有标准集成的方案中，我们可以选择设计和实现专门为在SNARK证明中有效而设计的散列函数。两个这样的函数包括MiMC和Poseidon。
对SNARK不友好但标准化的散列函数：在许多应用中，为了与现有系统兼容，我们必须使用对SNARK不友好的散列函数。例如，为了证明一个以太坊地址所对应的私钥的知识，我们需要一个ZK电路来实现keccak。我们需要做大量工作，以实现、优化和审计这些散列函数。
阿里云：成立“数字政务创新联盟”与“数字政府行业咨询协创中心:11月5日消息，据阿里云官微消息，阿里云联合数字政通、万达信息、数梦工场、南威软件、太极股份、时代凌宇等行业头部合作伙伴，成立“数字政务创新联盟”。与中国信通院产业与规划研究所、中国软件评测中心、国家工业信息安全发展研究中心信息化所、长城战略咨询等机构，共同发布《'云上数字政府'系列参考指引》，并发起成立“数字政府行业咨询协创中心”。(金十)[2022/11/6 12:21:27]
椭圆曲线加点：椭圆曲线密码学是建立在椭圆曲线群上的；因此，我们必须为椭圆曲线群法则建立ZK实现。这些操作很昂贵，这是ZK身份系统的一个性能瓶颈；巧妙地使用PLONK和更好地实现BigNum运算可能有助于提高性能。
ECDSA密钥生成和签名验证：用于ECDSA密钥生成和签名验证的ZK电路实现将使我们能够建立一种与现有基于ECDSA的身份系统兼容的身份声明语言。构建这些基元需要我们以有效的方式将椭圆曲线点加法和散列函数合并实施。
椭圆曲线配对：适合配对的椭圆曲线使我们能够获得双线性映射，实现多项式承诺、BLS聚合签名验证、递归SNARK验证、VerkleTrees等等。椭圆曲线配对的ZK电路的高效实现将实现大量新的加密操作。
加密累加器包含检查：一旦我们有了用于多项式承诺验证的ZK电路，Verkle树包含证明就可以在SNARK中得到验证。Merkle树包含证明今天是可以验证的，而且对于用SNARK友好的散列函数构建的树来说是实用的。MPT包含证明使我们能够在SNARK中验证轻型客户证明。在所有这些情况下，累加器包含证明验证允许SNARK访问被rollup进全局系统状态的简洁承诺的数据，如果你提供你要访问的数据、系统状态根和包含证明作为SNARK的输入，那么验证者只需要验证你的简洁证明并检查根是否正确，而不是全部系统状态。
递归SNARK验证：递归SNARK是通过在zkSNARK内部实施椭圆曲线配对和/或多项式承诺验证而实现的。这开启了身份声明中可编程性和复杂性的一个新维度。
所有这些的电路都可以首先为R1CS编写，并在不久的将来为基于PLONK的证明系统进一步优化。
开发者工具和基础设施
ZK电路工程的开发工具化是一个重要的话题。目前，ZK开发人员需要相对较高的数学背景和技术水平，他们必须在相对较底层的开发环境中进行编写，依靠人工或临时脚本来管理文件，并将电路通过开发管道从设计转化为生产。此外，已经完成的开发工具化的工作分散在多个研发团队、rollup公司等。
这里要特别指出的是，专门针对PLONK的强大工具栈的重要性。PLONK消除了对每个电路做可信设置这一步骤，由于自定义约束条件，大大加快了某些电路的编译和证明生成，并为递归SNARK验证铺平了道路。然而，PLONK的工具化目前处于比Groth16工具化更早的发展阶段，因为证明器的优化程度要低得多，对高级协议功能的支持还没有在某些系统中实现。此外，在IR的标准和定制约束语言的设计方面还有很多工作要做。像AZTEC、ElectricCoinCo、iden3、ZK-Garage等团体都在努力建设这些工具。
除了PLONK工具链之外，以下是ZK开发工具化的几个活跃的工作领域。
更高级的领域特定语言。目前用于编写SNARK的语言是非常低级的，需要开发者手动编写约束条件。我们对生产级的高级DSL感兴趣，它们更容易开发），甚至可以智能地执行约束优化。额外的好处包括用户定义的数据类型/注释，以及更好的证人生成系统。再往下看，能够实现测试、验证或电路静态分析自动化的DSL可能会增加我们对自己编写的代码的信心。
更智能的开发环境。编写、分析和测试电路是一个困难的过程。语法高亮，在开发过程中检测编译时的错误，类似IntelliSense的工具使用的包括AST/见证分析、注释，以及shell/REPL环境的组合，可能会迅速提高迭代速度。ZK学习小组的参与者被KevinKwok的ZKREPL项目大大加快了速度，该项目包含了以上描述的一些功能。
构建、测试和部署工具；自动化和管道管理。目前，ZK的开发者必须手动管理pau文件、key文件、构建配置、构建文件和发布分发过程。snarkjs教程目前列出了开发人员必须执行的26个步骤，以创建和验证一个zkSNARK，涉及对20多个文件的手动操作。对于如何以可访问和可审计的方式发布协议参数，还没有被广泛接受的最佳实践。必须为不同的环境手动维护不同版本的电路。像ProjectSophon的hardhat-circom和WeijieKoh的circom-helper这样的工具是伟大的第一步，有助于大幅简化工作流程，但还有很多工作要做。
中间表征的共同标准。不同的团队使用不同的语言和工具来编写ZK电路：circom,arkworks,libsnark等等。用不同的工具链编写的电路最好能编译成一个共同的中间表征，这样，生成证明、验证证明、审计协议设置和其他常见的任务就可以与工具链无关了。对于Groth16来说，一个IR取决于一套标准的商定的加密参数和R1CS表征。对于PLONK来说，这个问题要复杂一些，因为库的开发者需要弄清楚如何表示自定义的约束等等。作为工作在这个问题领域的一个例子，黑暗森林第三方客户端的开发促使KobiGurkan和gakonst编写了ark-circom，将arkworks和circom的生态系统连接了起来。
更容易使用和更有效的编译器和证明器。缓慢的关键编译和证明拖慢了开发和测试。优化编译和证明，并使这些过程的库易于开箱即用将节省开发人员的时间。ZPrize是一个旨在加速这项工作和更多工作的行业倡议。
共享的可信设置基础设施。生产级的zkSNARK应用程序现在很难启动，因为协调可信设置的难度很大。ZCash、AZTEC协议、Tornado和Semaphore都不得不编写定制的可信设置基础设施。在建立更多可重复使用的可信设置工具化上面已经有一些尝试，但运行这些仪式仍然是非常耗费人力的。但是请注意，随着我们转向不需要每个电路的可信设置的协议，长期来说这可能不会成为一个问题。
用于处理SNARK递归的工具。支持递归验证的SNARK使我们能够建立“可编程的”SNARK，其中SNARK代码可以通过插入验证密钥到其他SNARK子模块而被“迅捷”修改。此外，递归SNARK还允许开发者将证明生成并行化。在实践中支持这种功能是一个困难的问题，可能会在未来几年内努力解决......
审计和核查
上面列出的电路很复杂，而且极难手工验证。巧妙的约束优化实际上使问题更加复杂——高度优化的电路很难推理，而且如果你在做一些棘手的事情，很容易在实现过程中漏掉一个约束条件。此外，由于ZK应用的性质，可能无法判断ZK电路中的错误是否已经被人利用了。
编写让你对完整性有信心的测试是相当容易的：证明你可以从输入中正确地生成证人和证人的有效证明。要获得对健全性的信心则比较困难。要做到这一点，你必须验证有一个唯一的证人满足SNARK对给定输入的约束系统——一个恶意的验证者不能用一个有问题的证人来代替，从而产生一个由于缺少约束而产生的有效证明。比这更难的是证明电路与规范的等价性，即形式验证。
目前，大多数在生产中使用ZK电路的团队所采取的方法是委托人工审核，尽管这些审核的质量并不稳定，而且能够进行审核的人的总数也非常少。我们可以合理地确定，像Tornado.Cash这样的应用程序可能是安全的。然而，我们的概念验证groth16ECDSA的实现依赖于数千行的circom代码，电路大小为数十万或数百万的约束。更复杂的基元将更难验证，而PLONK的自定义约束将增加额外的复杂性。
我们为ZK应用安全空间提出了一些方法。在未来，我们将发表一篇文章，对我们所知道的这个领域的现有方法进行更深入的概述。
建立一个审核者社区。团队往往很难找到具有ZK应用开发专业知识的专家来审阅他们的电路和代码。我们可以鼓励现有的专注于ZK的团队，如rollup公司的工程师以及应用开发人员，来”交换”审核者，我们也可以共同开始培训审核者。
建立电路工程和审核的最佳实践。随着生态系统的成熟，我们将希望为构建、注释、记录和审核ZK电路制定最佳实践。这可以在不同程度上进行，自然语言的规范或正式规范都有助于使电路更加清晰。列举常见的缺陷和错误也可以帮助工程师和审核者。
对电路基元的正确性进行手动证明。对于重要的基元，例如散列函数或ECDSA电路，也许可以为这些基元手动写出正确性证明，用证明检查器来检查。然后，其他电路构建者将能够以更大的信心使用这些基元。
自动化的证人唯一性验证。Ecne是第一个自动化的R1CS证人唯一性验证器。这个项目使我们能够验证ZK电路是否有任何缺失的约束，这是在建立ZK系统的信心方面迈出的重要一步。我们希望能支持和鼓励更多类似方向的工作。
基于求解器的形式验证方法。一些团队正在探索证明ZK电路与形式化规范的等价性的自动方法。这一领域的工作也需要我们开发一套通用的基准，以及一种用于指定ZK电路的语言。
参考
ZK群签名：https://0xparc.org/blog/zk-group-sigs
配对友好：https://electriccoin.co/blog/new-snark-curve/
账户抽象：https://eips.ethereum.org/EIPS/eip-2938
签名方案：https://www.secg.org/sec2-v2.pdf
更高层次的构建：https://eips.ethereum.org/EIPS/eip-2938
MetamaskSnaps：https://docs.metamask.io/guide/snaps.html
Stealthdrop：https://github.com/nalinbhardwaj/stealthdrop
共谋：https://twitter.com/vitalikbuterin/status/1329012998585733120
ZK群签名文章：https://0xparc.org/blog/zk-group-sigs
BabyJubJub素数：https://iden3-docs.readthedocs.io/en/latest/iden3_repos/research/publications/zkproof-standards-workshop-2/baby-jubjub/baby-jubjub.html
MiMC：https://byt3bit.github.io/primesym/mimc/
Poseidon：https://www.poseidon-hash.info/
keccak：https://github.com/vocdoni/keccak256-circom
https://github.com/0xPARC/circom-secp256k1/blob/master/circuits/secp256k1.circom
合并实施：https://github.com/0xPARC/circom-secp256k1/blob/master/circuits/eth_addr.circom
数学背景：https://www.notion.so/Prerequisite-Understanding-Questions-cc6898f0fad04d9fbc7b8d33c34a865d
https://github.com/iden3/circom
AZTEC：https://medium.com/aztec-protocol/the-hunting-of-the-snark-3-3-c0a6e17c6d92
ElectricCoinCo：https://zcash.github.io/halo2/concepts/arithmetization.html
iden3：https://iden3.io/
ZK-Garage：https://github.com/ZK-Garage
概念验证：https://github.com/agajews/circom-dsl
约束优化：https://akosba.github.io/papers/xjsnark.pdf
ZKREPL：https://zkrepl.dev/
hardhat-circom：https://github.com/projectsophon/hardhat-circom
circom-helper：https://www.npmjs.com/package/circom-helper
circom：https://github.com/iden3/circom
arkworks：https://github.com/arkworks-rs
libsnark：https://github.com/scipr-lab/libsnark
ZCash：https://electriccoin.co/blog/completion-of-the-sapling-mpc/
AZTEC协议：https://github.com/AztecProtocol/Setup
Tornado：https://github.com/tornadocash/trusted-setup-server
Semaphore：https://github.com/appliedzkp/semaphore-phase2-setup
电路：https://github.com/tornadocash/tornado-core/tree/master/circuits
Ecne：https://github.com/franklynwang/EcneProject
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。