前言

正如我们之前的文章中所介绍的（Numen｜零知识证明引论Part1），ZKP（零知识证明）的本质是一个证明系统，证明者（Prover）和验证者（Verifier）双方需要在一系列逻辑电路的基础上对原问题的解构造证明和进行验证。

随着越来越多的Layer 2 协议（zkSync、Scroll等）、基于交易见证的特殊公链（Filecoin、Aleo等）选择构建在ZKP之上，再加上此前各类基于ZKP的匿名币项目，区块链在于ZKP相结合的过程，由于其系统的复杂性，将产生越来越多的不安全因素。

本文旨在从安全角度出发，总结ZKP与区块链相结合的过程中可能产生的漏洞，从而希望为ZKP项目的安全服务提供参考。

ZKP的特性

在了解一个系统的安全性之前，我们需要对该系统的特性进行分析，所有的安全服务都应该是先确保系统特性的满足。

一个零知识证明系统，需要同时满足证明系统的完备性（completeness）、可靠性（soundness）以及本身的特点——零知识性（zero knowledge）。

1.完备性：对于真实的陈述，证明者总能成功地向验证者证明其正确性。

2.可靠性：对于错误的陈述，恶意证明者无法欺骗验证者。

3.零知识性：在验证过程中，验证者不会获得证明者关于数据本身的任何信息

如果一个证明系统不满足完备性，则说明系统有可能在一些极端条件下无法通过正确的证明，从而产生拒绝服务的状态。

如果一个证明系统不满足可靠性，攻击者就可以轻易的伪造证明或构造特殊的证明结构来欺骗验证者，从而可能产生非常严重的权限绕过问题。

如果一个零知识证明系统不满足零知识性，那么有可能在交互的过程中泄露原始参数，从而导致攻击者可以基于泄露的数据构造攻击证明，或导致证明者作恶。

所以零知识证明系统的三个性质，是决定该系统是否安全有效的关键，在安全服务的过程中需要特别注意。

具体安全关注点

针对基于ZKP协议的区块链项目，主要需要关注以下关键的安全方向：

1. 零知识证明电路

项目中使用的ZKP电路，需要确保其安全性、有效性、可扩展性等方面满足需求。关注点包括电路设计、密码学原语实现、随机性保障等。

电路设计错误：由于目前没有很好的检查工具，在设计ZKP电路时，可能会出现一些逻辑错误，导致证明过程不符合零知识、完全性或可靠性等安全属性。

比如在2018年，Zcash的开发团队在其Sapling升级中引入了一个新的zk-SNARK证明系统。在升级过程中，他们发现了一个电路设计错误，该错误可能导致无限制伪造ZEC代币。尽管该漏洞并未被利用，但它凸显了电路设计错误的严重性。

密码学原语实现错误：ZKP电路依赖于一系列密码学原语（例如哈希函数、加密算法等）。如果这些原语的实现存在错误，可能导致整个证明系统的安全性受损。

这一类的案例比较多，不仅可能出现在零知识证明系统中，BNB Chain跨链桥的merkle tree 任意构造漏洞就是在实现merkle tree验证原语的过程中产生出错误，直接导致了586,000,000美元的损失。

随机性缺失：零知识证明通常依赖于随机数生成器（RNG）生成随机数。如果随机数生成过程存在问题，可能导致证明的安全性受损。

比如2018年，Dfinity的开发团队在审计其基于zk-SNARK的隐私方案时，发现了一个随机数生成漏洞。该漏洞可能导致攻击者通过特定输入破解电路的零知识特性。

2. 合约安全

该项主要是针对Layer2或者通过智能合约实现的隐私币项目而言。智能合约的安全性不言而喻，除了常见的重入、注入、溢出、权限绕过等漏洞外, 对于ZKP项目，智能合约在资产跨链、验证proof等方面起到至关重要的作用，在跨链消息验证和proof验证方面的漏洞，会直接导致可靠性失效。

例如早些时候发现的semaphore的验证合约漏洞，直接导致可输入假名实现双花的攻击。

3. 数据可用性

检查项目如何解决数据可用性问题，确保链下数据能够在需要时被安全、有效地访问和验证。关注数据存储、验证机制、传输过程等方面。

2019年，Plasma链上发生了一起数据可用性问题。由于Validator在某段时间内无法访问链下数据，用户在这段时间内无法提交交易或提取资金。这个案例表明了数据可用性问题对Layer 2项目的潜在影响。

除了使用数据可用性证明来重新构建数据可用性外，我们也可以在主机防护，数据状态监控方面加强保护。

4. 经济激励

评估项目中的激励机制，确保其可以刺激验证者、用户等参与方合理参与并维护整个系统的安全性和稳定性。关注激励模型设计、奖励分配、惩罚机制等方面。

5. 隐私保护

如果项目涉及隐私保护，审计其隐私方案的实现。确保用户数据在传输、存储和验证过程中得到充分保护，同时维持系统的可用性和可靠性。

虽然零知识性的证明需要引入模拟、倒带等复杂的概念，我们仍然可以基于协议通信的流程，来推断是否有证明者的隐私被泄露，对于恶意验证者，我们也可以通过验证者的交互数据内容，来推算是否有重新构建证明者只是的可能性。

6. 性能优化

评估项目中的性能优化策略，例如交易处理速度、验证过程效率等。审计代码实现中的优化措施，以确保项目能够满足性能需求。

7. 容错和恢复机制

审计项目在面对意外情况（如网络故障、恶意攻击等）时的容错和恢复策略。确保在可能的情况下，系统能够自动恢复并维持正常运行。

8. 代码质量

审计项目代码的整体质量，关注代码的可读性、可维护性和健壮性。评估代码中是否存在不规范编程实践、冗余代码、潜在错误等问题。

Numen可以为ZKP项目做什么

Numen在ZKP项目的安全服务方面，可以为项目方和用户提供全方位的安全保护。

我们除了具备丰富的智能合约代码审计经验外，也具备对电路编码逻辑的审计，能够同时采用人工和自动化的方式审计约束条件和见证（Witness）生成的正确性，尤其对欠缺约束计算漏洞具有深刻的理解和捕捉能力，我们针对重要的逻辑，会通过手动组装自定义逻辑见证的方式来模拟多种攻击行为进行测试。

针对Sequencer/Prover代码和验证合约，我们也具备Fuzz和安全测试能力，能够同时对节点实体和节点数据提供防护能力。

除了安全服务，我们的两个安全产品也可以在项目上线后，为项目提供实时的保护：
ImmunX是Numen研发的Web3链上安全监控和防护系统，目前已经具备链上安全态势感知、风险告警、链上追踪等能力，如果与Sequencer合作，也可以实现我们在Layer1区块链中的攻击阻断服务。目前我们与Binance已达成合作协议，帮助其实现BNB Chain的风险感知。

Leukocyte是一个具备CWPP（Cloud Workload Protection Platform）和ASA（Adaptive Security Architecture）能力的主机安全防护产品，应用场景覆盖云主机，物理主机和虚拟机，可以提供针对服务器层面的资产，风险，威胁和响应闭环管理，有效保障服务器安全可靠运行。

总结

当我们在谈论ZKP项目安全的时候，我们首先要明确该项目将ZKP用于何处，对于Layer2、隐私币、公链的安全侧重点是不一样的。但无论如何，都要确保ZKP的三个性质：完备性、可靠性和零知识性的有效性。