原文作者: gubsheep
原文标题: ZK Identity: Why and How (Part 2)
关于为什么密码学的新进展可能对数字身份基元很重要。上一篇DAOrayaki介绍了“DAOrayaki ｜为什么Web3需要ZK身份？”；这篇文章介绍“如何实现”。
在上一篇文章中，我们讨论了为什么新的加密工具，如 zkSNARK，将对构建下一代数字身份基础设施至关重要。在这篇文章中，我们将深入到细节中——为了建立基于 ZK 的概念验证（proof-of-concept）的身份系统，需要进行哪些技术工作？
ZK 身份的“大项目”比任何一个组织都要大得多。制定标准、建立基础设施、迭代身份基元和应用设计问题将逐渐发生，并需要各种不同的利益相关者和专业领域的投入。鉴于ZK 身份机制有可能影响到许多人，并且在很大程度上依赖于公共物品——开源基础设施、工具化（tooling）、标准、协调——因此，重要的是，这项工作要从一个有机的、社区驱动的“生态系统”中自下而上地产生，而不是从一个公司自上而下地产生，并且要特别注意可持续发展和激励设计。
在这样一个动态的生态系统中，一个孤立的公司也越来越不可能成功，因为在堆栈的各个层面独立开发的技术正在迅速变化。相反，我们将需要培养和协调一个由模块化、快速发展和半独立的团队组成的生态系统，共享一个共同的整体愿景。
ZK 身份的构件
ZK 身份识别工具必须使数字系统的参与者能够提出关于身份和名誉的声明（claim）。具体来说，在零知识中，这些声明可以归结为执行签名验证、密钥生成、散列（hashing）和加密等加密操作的数学陈述。我们可以把这些“构件”组合在一起，为更复杂的要求建立零知识证明：举个栗子，请看我们关于 ZK群签名（zk group signatures） 的文章。
一些操作和加密方案可以在 zkSNARK 中比其他方案更有效地实现。从长远来看，SNARK 友好的加密标准可能会被今天还不存在的新身份提供者所采用——例如，基于 SNARK 友好的加密技术的公钥/私钥签名方案的区块链（或账户抽象等更有表现力的系统）。但是，为了证明概念并在短期内发挥作用，我们的工具需要与现有的加密身份系统很好地整合——例如，以太坊目前的 ECDSA 签名方案，或者，围绕配对友好（paring friendly）的椭圆曲线形成的更多最新加密标准。
我们相信，为 ZK 身份应用建立一个可用的工具栈需要在四个方面取得重大进展。ZK 应用设计模式，实现 ZK 电路的加密基元，电路安全工具，以及开发者工具和基础设施。我们在下面总结了每个领域。
ZK 应用程序和设计模式
首先，我们工作的产出应该是触及终端用户并赋能有影响力的生产级应用。在开发 ZK 工具和构件的同时，我们必须弄清楚使用和组成它们的最佳方式。这里有几个开放的问题：
身份的正确抽象含义是什么？它是一个以太坊地址，一个以太坊地址的集合，一个多签，一个智能合约钱包，一个 ENS 名称，一个不同的加密方案中的密钥对，一个秘密的生物识别，一组证明，一种更高层次的构建，或是完全不同的东西？
哪些是人们关心的常见身份声明？所有上述工作给了我们一种语言，用于提出关于身份的可信的声明；现在，我们必须学习如何真正用这种语言说话。例如，直接引用和操作链上存储的散列数据的声明是否有用，或者如果大多数声明只是由半可信（semi-trusted）的第三方提供的有效证明，是否会更容易？在 ZK 证明中引用历史上的以太坊状态的声明是否实用——如果是这样，证明工具应该使哪类历史声明容易获得？
未来的 ZK 钱包和身份供应商应该有哪些工具和标准？例如，Metamask 或硬件钱包目前支持用私钥进行数字签名，一般建议私钥不应该由用户直接操弄。然而，ECDSA 签名验证在 SNARK 中的执行成本比公钥生成要高得多——这意味着希望对其以太坊地址进行 ZK 证明的用户将不得不在更慢的证明时间（通过有效签名证明）和更低的安全性（通过将其明文私钥复制出钱包范围外并进入 ZK 证明生成程序）之间做出选择。如果钱包软件最终提供对 ZK 证明生成的本地支持，这个问题可以得到部分解决，我们目前正在与 Metamask Snaps 团队进行实验。
支持 ZK 身份的应用程序需要遵照哪些接口？链上和链下的应用程序将需要在设计时考虑到 ZK 身份系统。例如，希望使用 ZK 身份系统的 NFT 门卡社区可能希望在 NFT 智能合约中也存储一个代币和代币所有者数据的加密累加器，以便用户更容易生成关于社区成员身份的声明。我们需要为希望进行成员资格验证的团体开发标准。
谁（或哪些设备和环境）可以生成 ZK 证明？可行的应用各不相同，这取决于某些 ZK 证明是否可以在硬件钱包、移动设备、浏览器、消费者台式电脑上生成，或者只在专用证明服务器上生成。
回答这些问题的最好方法就是开始建设！我们希望在未来几年内开始形成一个强大的开发者社区，用各种不同的方法来构建应用程序。
事实上，一些 ZK-Identity 应用程序可以在今天用现有的基础设施状态建立。这是很有意义的工作——除了提供有用的应用，这些项目还将为工具和基础设施的发展提供参考。以下是一些 ZK 身份认证的初步生产应用的候选项目。
隐私空投（private airdrop）。许多 DeFi 应用的一个常见策略是在链上发布用户地址的 Merkle 树根，并允许用户通过调用树上发布的地址的函数来申请空投。Stealthdrop 是来自 ETHUni 和 0xPARC 社区的一个项目，它在此基础上增加了一个隐私层，允许用户从任何地址领取空投，只需证明他们拥有与树上的以太坊地址相对应的某个私钥的证据（有无效检查以防止重复领取）。
链上快照投票汇总。今天，许多“DAO”完全使用链下投票机制，用户签署投票并将这些签名发送到中央服务提供商（即快照）进行统计。这带来了两个问题：首先，投票可能被中心机构审查，过去的投票数据可能会丢失或不可用/不可审计。第二，投票是公开进行的，使投票系统容易受到共谋的影响。我们可以使用签名验证的 ZK 结构，将投票结果“卷起来（roll up）”，形成一个单一的选民签名的 ZK 证明，可以无需信任地生成和提交上链。如果牺牲一些可扩展性，也可以将权力从中心机构部分分配给中间结构（即分配给更广泛的证明人网络，他们发布令牌持有人快照的 Merkle 树根）。
匿名但可信的证明。这些身份证明工具可用于证明在一个群体中的成员身份，而不透露你的确切身份——例如，证明黑暗森林星球的所有权，并加入一个 NFT 门卡社区，而不透露你的身份；作为一个匿名但受欢迎的 Twitter 用户发一个帖子，证明你有至少100万以上的 Twitter 粉丝，而不透露你的账户；或证明你是一个立法机构的成员，在即将进行的投票中匿名示意共识。其中一些应用在我们的 ZK 群签名文章里有更多讨论。
加密身份基元的 ZK 电路
在堆栈中再深入一层，我们需要高效的、经过审计的 ZK 电路的实现，用于核心密码基元和它们的数学运算。下面是一些关键操作的举例，按非常粗略的依赖性从上往下排序。
非原生域运算：zkSNARK 的运算是在素数域中进行的——例如，snarkjs 默认的所有信号都是以254位的 BabyJubJub 素数为模。然而，加密操作要求我们对可能大得多的数字进行操作——例如，secp256k1 操作要求我们对两个256位数字的乘积取模于第三个256位数字。这些电路中涉及的最昂贵的操作是范围检查（range check），约束优化的一个策略是更加谨慎地确定我们何时需要精确地执行范围检查。
适合 SNARK 的散列函数：散列函数在用户必须做出加密承诺的应用中非常有用。在散列函数不需要与现有标准集成的方案中，我们可以选择设计和实现专门为在 SNARK 证明中有效而设计的散列函数。两个这样的函数包括 MiMC 和 Poseidon。
对 SNARK 不友好但标准化的散列函数：在许多应用中，为了与现有系统兼容，我们必须使用对 SNARK 不友好的散列函数（如 SHA256 或 keccak）。例如，为了证明一个以太坊地址所对应的私钥的知识，我们需要一个 ZK 电路来实现 keccak。我们需要做大量工作，以实现、优化和审计这些散列函数。
椭圆曲线加点（point adding）：椭圆曲线密码学是建立在椭圆曲线群上的；因此，我们必须为椭圆曲线群法则（点加法）建立 ZK 实现。这些操作很昂贵，这是 ZK 身份系统的一个性能瓶颈；巧妙地使用 PLONK 和更好地实现 BigNum 运算可能有助于提高性能。
ECDSA 密钥生成和签名验证：用于 ECDSA 密钥生成和签名验证的 ZK 电路实现将使我们能够建立一种与现有基于 ECDSA 的身份系统（如 Ethereum）兼容的身份声明语言。构建这些基元需要我们以有效的方式将椭圆曲线点加法（point addition）和散列函数合并实施。
椭圆曲线配对：适合配对的椭圆曲线使我们能够获得双线性映射（bilinear map），实现多项式承诺、BLS 聚合签名验证、递归SNARK 验证、Verkle Trees 等等。椭圆曲线配对的 ZK 电路的高效实现将实现大量新的加密操作。
加密累加器包含检查：一旦我们有了用于多项式承诺验证的 ZK 电路，Verkle 树包含证明就可以在 SNARK 中得到验证。Merkle 树包含证明今天是可以验证的，而且对于用 SNARK 友好的散列函数构建的树来说是实用的。MPT 包含证明使我们能够在SNARK 中验证轻型客户证明。在所有这些情况下，累加器包含证明验证允许 SNARK 访问被 roll up 进全局系统状态的简洁承诺（“根”）的数据，如果你提供你要访问的数据、系统状态根和包含证明作为 SNARK 的输入，那么验证者只需要验证你的简洁证明并检查根是否正确，而不是全部系统状态。（译注：MPT，Merkle Patricia Trie 的缩写，是以太坊存储层的关键数据结构之一，结合了 Merkle 和 Patricia Trie 两种结构特性）
递归 SNARK 验证：递归 SNARK 是通过在 zkSNARK 内部实施椭圆曲线配对和/或多项式承诺验证而实现的。这开启了身份声明中可编程性和复杂性的一个新维度。
所有这些的电路都可以首先为 R1CS 编写（允许在短期内进行 groth16 设置和证明），并在不久的将来为基于 PLONK 的证明系统进一步优化。
开发者工具和基础设施
ZK 电路工程的开发工具化（tooling）是一个重要的话题。目前，ZK开发人员需要相对较高的数学背景和技术水平，他们必须在相对较底层的开发环境中进行编写，依靠人工或临时脚本来管理文件，并将电路通过开发管道从设计转化为生产。此外，已经完成的开发工具化的工作分散在多个研发团队、rollup 公司等。
这里要特别指出的是，专门针对 PLONK 的强大工具栈的重要性。PLONK 消除了对每个电路做可信设置这一步骤，由于自定义约束条件，大大加快了某些电路的编译和证明生成，并为递归 SNARK 验证铺平了道路。然而，PLONK 的工具化目前处于比 Groth16 工具化更早的发展阶段，因为证明器的优化程度要低得多，对高级协议功能的支持还没有在某些系统中实现。此外，在 IR 的标准和定制约束语言的设计方面还有很多工作要做。像 AZTEC、Electric Coin Co、iden3、ZK-Garage 等团体都在努力建设这些工具。
除了 PLONK 工具链之外，以下是 ZK 开发工具化的几个活跃的工作领域。
更高级的领域特定语言（DSL）。目前用于编写 SNARK 的语言是非常低级的，需要开发者手动编写约束条件。我们对生产级的高级 DSL 感兴趣，它们更容易开发（0xPARC 社区成员的一个概念验证（proof-of-concept）），甚至可以智能地执行约束优化。额外的好处包括用户定义的数据类型/注释，以及更好的证人生成系统。再往下看，能够实现测试、验证或电路静态分析自动化的 DSL 可能会增加我们对自己编写的代码的信心。
更智能的开发环境。编写、分析和测试电路是一个困难的过程。语法高亮，在开发过程中检测编译时的错误，类似 IntelliSense的工具使用的包括 AST/见证分析、注释（即把电路模板标记为“安全”或“不安全”，标记不受约束的信号），以及 shell/REPL 环境的组合，可能会迅速提高迭代速度。ZK 学习小组的参与者被 Kevin Kwok 的 ZKREPL 项目大大加快了速度，该项目包含了以上描述的一些功能。
构建、测试和部署工具；自动化和管道管理。目前，ZK 的开发者必须手动管理 pau 文件、key 文件、构建配置、构建文件和发布分发过程。snarkjs 教程目前列出了开发人员必须执行的26个步骤，以创建和验证一个 zkSNARK，涉及对20多个文件的手动操作。对于如何以可访问和可审计的方式发布协议参数，还没有被广泛接受的最佳实践。必须为不同的环境手动维护不同版本的电路（即在测试期间关闭一些约束）。像 ProjectSophon 的 hardhat-circom 和 Weijie Koh 的 circom-helper 这样的工具是伟大的第一步，有助于大幅简化工作流程，但还有很多工作要做。
中间表征的共同标准。不同的团队使用不同的语言和工具来编写 ZK 电路：circom, arkworks, libsnark 等等。用不同的工具链编写的电路最好能编译成一个共同的中间表征（IR, intermediate representation），这样，生成证明、验证证明、审计协议设置和其他常见的任务就可以与工具链无关了。对于 Groth16 来说，一个 IR 取决于一套标准的商定的加密参数和 R1CS 表征。对于 PLONK 来说，这个问题要复杂一些，因为库的开发者需要弄清楚如何表示自定义的约束等等。作为工作在这个问题领域的一个例子，黑暗森林第三方客户端的开发促使 Kobi Gurkan 和 gakonst 编写了 ark-circom，将 arkworks 和 circom 的生态系统连接了起来。
更容易使用和更有效的编译器和证明器。缓慢的关键编译和证明拖慢了开发和测试。优化编译和证明，并使这些过程的库易于开箱即用（在大服务器上设置一个远程验证器应该很容易！）将节省开发人员的时间。ZPrize 是一个旨在加速这项工作和更多工作的行业倡议。
（前 PLONK 时代）共享的可信设置基础设施。生产级的 zkSNARK 应用程序现在很难启动，因为协调可信设置的难度很大。ZCash、AZTEC协议、Tornado 和 Semaphore 都不得不编写定制的可信设置基础设施。在建立更多可重复使用的可信设置工具化上面已经有一些尝试，但运行这些仪式仍然是非常耗费人力的。但是请注意，随着我们转向不需要每个电路的可信设置的协议，长期来说这可能不会成为一个问题。
（后 PLONK 时代）用于处理 SNARK 递归的工具。支持递归验证的 SNARK 使我们能够建立“可编程的”SNARK，其中 SNARK 代码可以通过插入验证密钥到其他 SNARK 子模块而被“迅捷”修改。此外，递归 SNARK 还允许开发者将证明生成并行化。在实践中支持这种功能是一个困难的问题，可能会在未来几年内努力解决......
审计和核查
上面列出的电路很复杂，而且极难手工验证。巧妙的约束优化实际上使问题更加复杂——高度优化的电路很难推理，而且如果你在做一些棘手的事情，很容易在实现过程中漏掉一个约束条件。此外，由于 ZK 应用的性质，可能无法判断 ZK 电路中的错误是否已经被人利用了。
编写让你对完整性有信心的测试是相当容易的：证明你可以从输入中正确地生成证人和证人的有效证明。要获得对健全性（soundness）的信心则比较困难。要做到这一点，你必须验证有一个唯一的证人满足 SNARK 对给定输入的约束系统——一个恶意的验证者不能用一个有问题的证人来代替，从而产生一个由于缺少约束而产生的有效证明。比这更难的是证明电路与规范的等价性，即形式验证。
目前，大多数在生产中使用 ZK 电路的团队所采取的方法是委托人工审核，尽管这些审核的质量并不稳定，而且能够进行审核的人的总数也非常少。我们可以合理地确定，像 Tornado.Cash 这样的应用程序（其电路总共只有大约100行 circom 代码）可能是安全的。然而，我们的概念验证 groth16 ECDSA 的实现依赖于数千行的 circom 代码，电路大小为数十万或数百万的约束。更复杂的基元将更难验证，而 PLONK 的自定义约束将增加额外的复杂性。
我们为 ZK 应用安全空间提出了一些方法。在未来，我们将发表一篇文章，对我们所知道的这个领域的现有方法进行更深入的概述。
建立一个审核者社区。团队往往很难找到具有 ZK 应用开发专业知识的专家来审阅他们的电路和代码。我们可以鼓励现有的专注于 ZK 的团队，如 rollup 公司的工程师以及应用开发人员，来”交换”审核者，我们也可以共同开始培训审核者。
建立电路工程和审核的最佳实践。随着生态系统的成熟，我们将希望为构建、注释、记录和审核 ZK 电路制定最佳实践。这可以在不同程度上进行，自然语言的规范或正式规范都有助于使电路更加清晰。列举常见的缺陷和错误（并建立一些基本的工具来捕捉这些缺陷和错误）也可以帮助工程师和审核者。
对电路基元的正确性进行手动证明。对于重要的基元，例如散列函数或 ECDSA 电路，也许可以为这些基元手动写出正确性证明，用证明检查器来检查。然后，其他电路构建者将能够以更大的（对正确性的）信心使用这些基元。
自动化的证人唯一性验证。Ecne 是第一个自动化的 R1CS 证人唯一性验证器。这个项目使我们能够验证 ZK 电路是否有任何缺失的约束，这是在建立 ZK 系统的信心方面迈出的重要一步。我们希望能支持和鼓励更多类似方向的工作。
基于求解器的形式验证方法。一些团队正在探索证明 ZK 电路与形式化规范的等价性的自动方法。这一领域的工作也需要我们开发一套通用的基准，以及一种用于指定 ZK 电路（部分或全部）的语言。
参考
ZK群签名（zk group signatures） ：https://0xparc.org/blog/zk-group-sigs
配对友好（paring friendly）：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
Metamask Snaps ：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
Electric Coin Co：https://zcash.github.io/halo2/concepts/arithmetization.html
iden3：https://iden3.io/
ZK-Garage ：https://github.com/ZK-Garage
概念验证（proof-of-concept）：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
