声明的方法进行计算。 3. 数据压缩 Filecoin 运用 ZKP 构造了时空证明系统，能证明用户在本地存储了特定文件，目前已经证明存储的文件已经达到 18 EiB。 Mina 是另一个例子，在很多高速区块链系统中，交易的数据十分庞大，系统需要保留所有的区块以备共识协议的验证，所以系统对硬件的要求极高，永久保存意味着区块链节点将需要不断增大磁盘空间和数据索引能力。这时候可以借助 ZKP，将验证数据压缩，Mina 通过递归零知识证明，将账本压缩到 11 KB，但依旧可以验证区块的正确性。 ZKP 证明系统 证明系统是 ZKP 的底层算法实现，可分为交互式和非交互式两种： 1. 交互式证明系统 交互证明系统由两方参与，分别称为证明者（Prover，简记为 P）和验证者（Verifier，简记为 V），其中 P 知道某一秘密（如公钥密码体制的秘密钥或一个二次剩余 x 的平方根），P 希望使 V 相信自己的确掌握这一秘密。交互证明由若干轮组成，在每一轮，P 和 V 可能需根据从对方收到的消息和自己计算的某个结果向对方发送消息。比较典型的方式是在每轮 V 都向 P 发出一个询问，P 向 V 做出一个应答。所有轮执行完后， V 根据 P 是否在每一轮对自己发出的询问都能正确应答，决定是否接受 P 的证明。 2. 非交互式证明系统 在上述交互式证明系统中，P 和 V 不进行交互，证明由 P 产生后直接给 V，V 对证明直接进行验证，这种证明系统称为非交互式证明系统（NIZK）。 我们在区块链中使用的证明系统一般都是 NIZK，区块链中的节点就是验证者 V ，终端用户或者二层网络（Layer2）就是证明者 P。 文末参考链接 [1] 描述了近十年来公开发表的 NIZK 方案及特点。 在实际工程应用中我们主要关注的是性能和通用性，因此我们对一些常见证明系统进行更细致的分类对比，见文末参考链接 [2]： Bulletproofs 特点：简洁证明大小，无需可信设置，但证明生成和验证耗时相比较长。 代表项目：Bulletproofs, Halo, Halo2。 SNARKs (Succinct Non-interactive ARguments of Knowledge) 特点：简洁证明大小，证明验证耗时相比较短，但需要对每一个电路进行可信设置。 代表项目：Groth16。 SNORKs (Succinct Non-interactive Oecumenical (Universal) aRguments of Knowledge) 特点：简洁证明大小，只需要进行一次可信设置即可用于所有电路。 代表项目：Sonic, PlonK, Marlin, Plonky2。 STARKs (Succinct (Scalable) Transparent ARguments of Knowledge) 特点：证明十分庞大，不需要进行可信设置，具有良好的可扩展性。 代表项目：STARK。 以上分类也不是绝对的，比如 Halo/Halo2 项目，它们在设计时也借鉴了很多 Plonk 的思路，另外，SNORKs 通常会被归入到 SNARKs，因为它们都需要可信设置。 3. 性能对比 电路编程 电路是 ZKP 系统的业务逻辑实现，开发 ZKP 应用需要进行电路编程，为什么 ZKP 逻辑代码被称为“电路”？主要有以下几个原因： ZKP 证明的代码会被转换成一系列简单约束条件的表达式 R1CS，然后使用拉格朗日插值法，转换为一个巨大的多项式 QAP，最终以门电路的形式被约束。 与硬件电路类似，所有分支的代码将被一起执行。 与硬件电路类似，ZKP 证明电路中没有递归和复杂的循环，循环的数量只能是恒定的。 我们不需要从头去用密码学实现 ZKP 应用，有很多开发库已经实现了这些底层证明系统，我们只需要关注业务逻辑的实现。当然每一种库都有不同的抽象程度，有的需要去学习描述电路的表达式，有的只需要按流程定义好代码就可以轻松实现。 1. 常用开发库 libsnark 用 C++ 语言实现了通用证明系统、基础电路库和应用示例。 证明系统：BBFR15、BCCT12、BCCT13、BCGTV13、BCIOP13、BCTV14a、BCTV14b、CTV15、DFGK14、Groth16、GM17、GGPR13、PGHR13。 链接：https://github.com/scipr-lab/libsnark。 gnark 用 Go 语言实现的证明系统，提供高级 API 来设计电路。 证明系统：Groth16 、PlonK。 链接：https://github.com/consensys/gnark。 bellman Rust 实现的证明系统，它提供电路接口、 基础结构以及一些基本电路实现，例如布尔和数值抽象。 证明系统：Groth16。 链接：https://github.com/zkcrypto/bellman。 snarkjs Javascript 和 WASM 实现的证明系统，可用于可信设置、生成证明并验证证明。snarkjs 使用 iden3 自己的 circom 编译器对 DSL 定义的电路进行编译。 证明系统：Groth16 、PlonK。 链接：https://github.com/iden3/snarkjs。 ethsnarks 使用 Python 实现，可以在用户浏览器生成证明，使用以太坊智能合约做为验证者。目前项目开发不活跃，相同的场景下使用 Circom 可能是更好的选择。 证明系统：Groth16。 链接：https://github.com/HarryR/ethsnarks。 bulletproofs 使用 Rust 实现的证明系统，具有单一和聚合范围证明、强类型多方计算，正在开发中用于证明任意语句的可编程约束系统 API。 证明系统：bulletproofs。 链接：https://github.com/dalek-cryptography/bulletproofs。 halo2 一个基于 Rust 的实现的证明系统，由 ZCash 团队维护。Halo2 特定于 PLONKish，可以非常直接地控制电路在算术运算中的表示方式，非常适合编写高度优化的电路。 证明系统：Halo2。 链接：https://github.com/zcash/halo2。 2. 开发流程 以 gnark 为例，一个典型的工作流程如下图： 1）用代码描述需要解决的问题。 2）编译成 R1CS 约束系统。 3）对 R1CS 进行可信设置，得到 Proving key 和 Verify key。 4）证明者使用 R1CS 和 Proving key 计算私密数据，生成证明 Proof。 5）验证者使用 Verify key 验证 Proof。 电路编程专用语言 1. 基于以太坊平台 Cairo Cairo 是一种用于编写可证明程序的编程语言，其中一方可以向另一方证明某个计算已正确执行。Cairo 和类似的证明系统可用于为区块链提供可扩展性。StarkNet 将 Cairo 编程语言用于其基础设施和编写 StarkNet 合约。 证明系统：STARK。 链接：https://www.cairo-lang.org/docs/。 Zokrates ZoKrates 采用 DSL 描述电路，提供了一些常用的电路库，它可以帮助你在 DApp 中使用可验证的计算，从用高级语言规范您的程序到生成计算证明，再到在 Solidity 中验证这些证明。 证明系统：GM17、Groth16、Marlin。 链接：https://zokrates.github.io/。 Circom Circom 语言采用 DSL 描述电路，可以配合 snarkjs 在用户浏览器生成证明，使用以太坊智能合约做为验证者。 证明系统：Groth16 、PlonK。 链接：https://iden3.io/circom。 Noir Aztec 基于 Rust 的隐私编程语言，采用 DSL 描述电路，允许安全、无缝地构建隐私保护零知识电路。 证明系统：PlonK。 链接：https://noir-lang.org/index.html。 zkEVM 与 EVM 一样，zkEVM 是一个虚拟机，它作为程序操作的结果在状态之间转换，但是 zkEVM 通过生成证明来证明计算的每个部分的正确性。本质上，zkEVM 使用一种机制来证明执行步骤遵循规则。 目前有 zkSync、Polygon、Scroll、Starkware 等团队正致力于 zkEVM 的实现，已取得重大进展。 2. 基于公链平台 zkApp (Mina) zkApps 是 Mina Protocol 的智能合约，由零知识证明提供支持。zkApps 可以在链下执行任意复杂的计算，同时只收取固定费用以将生成的零知识证明发送到链以验证此计算，这与其他在链上运行计算并使用基于可变 gas 费用的区块链相反模型。zkApps 使用 Typescript 编写。 证明系统：PlonK。 链接：https://docs.minaprotocol.com/zkapps。 LEO (Aleo) Leo 是一种函数式静态类型编程语言，专为编写私有应用程序而构建。它专为开发人员设计，可以直观地在 Aleo 区块链上构建，为私有的、去中心化的生态系统提供基础。 证明系统：Marlin。 链接：https://leo-lang.org/。 ZKP 常见安全问题 在过去几年，慢雾安全团队已为多个知名 ZKP 产品进行了电路及应用安全审计，包括 ZKSwap、Zkdex、Zksafe 等，发现了多个中高危漏洞，对基于 Circom、libsnark 等流行框架开发的应用有较为深入的理解。慢雾安全团队在 ZKP 应用审计中发现常见的安全问题有： 信任参数风险 为了使用 zk-SNARKs，需要一组公共参数，称为公共参考字符串（CRS）。但是这些参数的创建也会产生一些私有参数，如果某一方获得这些私有参数，他们就可以伪造证明。 另外，生成 CRS 的流程需要经过审计，确保不会有随机数后门，或者私有参数不会被蓄意保留。使用 zk-SNORKs 时也需要确保结构化参考字符串（SRS）是可信的。 可信配置阶段的安全隐患问题可以使用安全多方计算（MPC）来解决，MPC 的特点是只要任何一个参与者能诚实参与，那么通过这套多方计算系统最终得到的计算结果就是可信的。 静态代码安全 这部分主要是由于编码不规范造成的安全问题，例如：参数未校验、返回值未处理、数值溢出、边界未检查等，如果编写电路的语言是 C/C++，那么还会存在内存溢出风险。 供应链攻击风险 供应链的风险主要来自使用了存在漏洞的代码库，例如：旧版本的仓库。通常 ZKP 应用还需要配合客户端或者 Web 前端使用，而这部分也很容易遭受多种方式黑客攻击。 逻辑错误 逻辑错误是电路实现中最容易出现的错误，需要结合需求文档检查电路的设计是否符合需求。 双花攻击 错误的设计可能导致双花攻击，例如：某些 ZKP 库存在延展性风险，攻击者可利用已知的 Proof 生成不同 Proof，如果设计不当会导致双花攻击。 证明伪造 有效的证明是 ZKP 首要解决的问题，确保满足完备性和可靠性，即“假的真不了，真的假不了”，所以如果一个电路可以创建假证明，通常是由于底层库出现漏洞，通常我们会建议项目方使用公开的经过审计的 ZKP 库，并使用稳定的发行版。 侧信道攻击 如果电路设计不当，不同的隐私信息可能存在不同的计算特征，攻击者可能通过公开的输入或者证明猜解出私有输入数据。 电路约束失效 不恰当的电路表达式可能导致变量未被约束。 特殊值攻击 一些特殊的输入值可能绕过系统的验证逻辑，例如：0、null 等。 隐私输入猜解 对于 Tornado Cash 等应用，如果输入的信息可以被猜解，那么会导致严重的隐私泄露问题，这时需要对输入数据进行严格审计，确保不能被猜解。 RugPull 风险 一些项目可能存在特殊的管理员权限，一旦权限被非法使用会导致项目资金和用户资产被窃取。 智能合约风险 一些 ZKP 证明使用智能合约进行验证，例如：Circom、ZoKrates 等。智能合约可能出现重入、重放、逻辑错误等风险，详情可查看慢雾安全团队的智能合约安全审计服务。 针对上面列举的 ZKP 安全问题，慢雾安全团队在攻防实战中总结出了一套安全解决方案，结合黑盒/灰盒/白盒多种测试手段，推出了面向区块链行业的 ZKP 电路审计服务。 总结 零知识证明是解决区块链隐私性、计算扩展和数据压缩问题的有效方法，目前有很多的实现方案，这些实现方案具有不同的性能参数指标和安全基准。开发者在开发零知识证明电路时需要注意根据需求选择合适的框架，并确保在项目上线前对应用的安全性进行过全面安全审计。 最后，感谢领先的一站式数字资产自托管服务商 Safeheron 提供的专业技术建议。 参考链接： [1]. https://en.wikipedia.org/wiki/Zero-knowledge_proof [2]. https://github.com/matter-labs/awesome-zero-knowledge-proofs [3]. https://docs.google.com/presentation/d/1gfB6WZMvM9mmDKofFibIgsyYShdf0RV_Y8TLz3k1Ls0/edit 来源：金色财经lg...
北美站
