零知识证明专题第15期：ZK 漏洞编年史：从理论假设到工程实现的安全威胁模型

摘要

2026年5月底，安全研究者Taylor Hornby向Zcash基金会提交了一份报告。报告指出，自2022年上线的Orchard隐私池存在电路约束缺失：同一笔shielded note的nullifier可被重复生成并花费。因为Zcash的隐私保护机制，外部观察者无法从公开的链上数据确认此前是否已被利用。消息公开后，ZEC价格在48小时内下跌近50%，市值蒸发超过40%。触发了一次紧急网络硬分叉升级。

这不是一次普通的代码缺陷公告。它发生在由顶级密码学家主导、经过正式审计、在主网运行近四年的成熟系统上。Orchard事件的核心警示在于：零知识证明的最强特性——隐私——在漏洞场景下会成为最强的攻击掩护。即使电路通过了审计，即使系统已经稳定运行多年，一个微小的约束遗漏仍可能成为不可见的后门。

从2022年Trail of Bits披露Frozen Heart系列漏洞开始，到2026年的Orchard事件，ZKP工程化的过程不仅是数学定理的优雅落地，更是一段安全认知不断升级的历程。学术研究用完备性、可靠性和零知识性为ZKP系统背书，但这些属性仅仅存在于理想形式化模型之中。一旦进入编译器、进入约束系统、进入哈希函数的具体实例化与智能合约的集成，信任链条就延伸到了代码的每一行和每一个部署决策上。

本节将系统梳理三大攻击向量：协议层的不安全Fiat-Shamir变换、电路层的欠约束问题、以及应用集成层的信任边界崩溃。通过事件驱动的线索，建立从密码学理论到工程交付的全链路威胁模型，并为开发者输出一份可落地的安全自检清单，助力ZKP技术从研究原型走向可信的生产基础设施。

timeline
    2022 : Frozen Heart 漏洞披露
         : Trail of Bits 发现多个ZKP系统的Fiat-Shamir变换实现错误
    2023 : Veridise 审计发现 circom-pairing 高危缺陷
         : 某知名ZK桥项目险些遭受重大攻击
    2024 : 0xPARC 启动 zk-bug-tracker
         : 社区开始系统收集ZKP漏洞模式
    2025 : zkFuzz 论文发表（arXiv 2504.11961）
         : 引入TCCT理论模型，自动化检测电路漏洞
    2026 : Zcash Orchard 完备性漏洞披露
         : 历经四年的电路约束遗漏
         : ZEC 价格下跌50%，触发紧急硬分叉

上述时间线不仅记录了事件序列，更揭示了一个结构性演变：2022至2023年的漏洞集中于协议层，2024至2025年社区开始关注电路层，2026年的Orchard事件将视野推进到了已审计系统的长期安全性层面。这种演进表明，威胁重心正从理论层面的公理违反，逐步迁移到工程实现中的微小疏漏——后者更隐蔽、更难以通过常规手段发现，但在生产环境中的破坏力同样致命。

二、协议层：当 Fiat-Shamir 不再是安全的黑暗森林

2.1 Frozen Heart：从教科书到代码的断层

2022年4月，Trail of Bits发布了一份影响深远的评估报告，他们将之命名为Frozen Heart系列漏洞。这个名字本身带有隐喻：Fiat-Shamir变换是非交互式零知识证明系统的核心，而Frozen暗示某些实现只是机械地执行了变换的表象，却未完整地遵循其内在安全要求。

Fiat-Shamir变换的学术规范要求：在生成挑战值时，哈希输入必须覆盖所有公开数据，包括公开输入和协议各轮中已发布的所有承诺值。任何遗漏都意味着攻击窗口。攻击者可以精心挑选witness和公开输入，令哈希输出落在对自己有利的数值上，从而构造出一个形式上有效却缺乏知识支撑的证明。

Trail of Bits在审计中发现，多个生产级ZKP系统未能将公开输入或完整承诺序列纳入挑战值的哈希计算。受影响对象包括部分PlonK、Bulletproofs和Girault方案的开源实现。这类漏洞的特殊性在于攻击者无需掌握任何secret witness，仅通过操控公开输入和承诺值，就能为任意陈述构造假证明。在涉及资产验证的场景中，攻击者实质上等效于免密提取。

风险面远超单一项目。Bulletproofs原始论文本身在Fiat-Shamir变换的表述上存在不够精确之处，导致学术标准参考实现与商业系统同时被波及。一个密码学构造中的微小疏忽，通过论文引用、代码复刻和开源依赖，可以扩散到数十个下游项目。漏洞的传播具有网络效应，在校正了上游实现后，下游项目未必会同步意识到自身存在同源风险。

2.2 攻击条件与影响面

受影响系统的共性是：将公开输入或电路参数排除在挑战值生成过程之外。攻击者由此控制challenge的生成，进而构造伪证明。这属于协议层面的彻底绕过，不需要攻破任何基础密码学假设，如离散对数。

flowchart LR
    subgraph 安全实现
        A1[公开输入 public_inputs] --> H1[哈希函数]
        B1[承诺值 commitments] --> H1
        C1[协议参数 params] --> H1
        H1 --> Ch1[挑战值 challenge]
        Ch1 --> P1[后续证明步骤]
    end
    subgraph 错误实现
        A2[公开输入] -.->|遗漏| X
        B2[部分承诺值] --> H2[哈希函数]
        C2[参数] --> H2
        D2[遗漏值] -.->|攻击者控制| F2[构造恶意输入]
        H2 --> Ch2[可操控的 challenge]
        Ch2 --> P2[通过伪证明]
        F2 --> Ch2
    end
    style H1 fill:#9f9
    style H2 fill:#f99
    style X fill:#333,stroke:#333,stroke-dasharray: 5 5

左侧绿色路径展示了安全实现：所有公开值进入哈希函数，挑战值不可操控，证明系统的可靠性保持。右侧红色路径展示了错误实现的致命缺口：遗漏的公开输入或承诺值落入攻击者控制范围，使得挑战值可被预测或引导。攻击者构造恶意输入并输入到哈希之前的位置，生成一个看似合法的证明，验证系统因哈希未覆盖攻击者控制的部分而无法识别差异。

2.3 为何漏洞如此普遍

Fiat-Shamir变换在概念上极其简洁：用哈希值替代随机挑战。但工程实现的正确答案高度依赖上下文细节：需要哈希哪些公开值？顺序是否标准化？参数化电路中如何处理变化的公共输入维度？多轮协议中每轮挑战是否向前包含所有中间承诺？

这些问题的答案分散在多篇论文、多种开源实现和不同项目的自定义优化中。正是这种不规范性为错误提供了土壤。更危险的是，Fiat-Shamir漏洞不会导致运行时崩溃或测试失败——它使得错误证明也能被正常接受。这是一种静默的破坏：没有异常日志，只有一个数学上的缺口等待被利用。

三、电路层：从少了一条约束到无限伪造

3.1 欠约束：头号杀手

zkSecurity在超过一百次ZK系统审计之后总结出一条经验：欠约束电路是最常出现的安全缺陷类别。其根源在于ZK电路编程与常规编程存在本质差异。

在传统编程中，对变量赋值即意味着计算完成。在ZK电路中，赋值仅告诉证明者该值应该是什么，并不保证所有被探索的witness空间中的合法赋值都满足该等式。约束以多项式等式的形式存在，才是将信号锁定在位置上的机制。如果一个中间计算结果仅被赋值给信号，却不通过R1CS或PLONK等式强制等于其输入推导出的函数输出，攻击者便可以在生成证明阶段填入任意值，系统仍然接受。

Circom语言中几种反复出现的工程陷阱具体包括：

• 赋值未约束：a使用左箭头符号赋值b乘c，但后续没有生成a严格等于b乘c的约束，a成为自由信号；
• 位宽未绑定：电路模块假设输入在特定位范围，但未通过约束强制执行，攻击者利用模域溢出制造语义异常；
• 悬空信号：组件输出出现在约束集合中，但顶层电路未进一步引用或约束，导致形式上存在但实质上悬置；
• 模板参数传递错误：不同实例化之间参数不一致导致约束冗余或遗漏。

0xPARC维护的zk-bug-tracker已经收录了Tornado Cash早期代码以及多个DeFi协议的Merkle路径实现中的真实案例。社区知识库的积累是对抗重复犯错的重要防线。

3.2 Zcash Orchard：四年未察觉的完备性缺口

2022年上线的Orchard采用Halo2证明系统替代此前的Groth16和Sapling方案，采用基于Action转移的屏蔽交易模型。其核心安全假定之一：每笔已花费note对应的nullifier在数学上唯一且不可重算。nullifier充当唯一标识符，在花费时被记录到全局集合以防止双花。

2026年6月初的公开披露指出：halo2_gadgets库中的nullifier生成电路遗漏了一条约束。这导致同一note可被不同witness组合导出相同的nullifier，甚至在某些边界情况下原应被驳回的nullifier也能通过验证。由于shielded pool的隐私属性，外部观察者无法通过公开的nullifier倒推原始note内容。即使已经发生了无限增发，也没有密码学手段确认这一点。

隐私即攻击掩护的悖论是隐私增强系统面临的最严峻质疑：系统越隐私，外部审计的可见性越低，漏洞一旦存在就越难被被动发现。Zcash社区立即启动紧急硬分叉，将用户资金迁移至修复版本。Orchard事件不单是一个技术缺陷，更揭示了ZK系统中一种根本张力：最强隐私性与最弱外部可审计性需要全新的安全方法论来平衡。

3.3 Circom 典型漏洞模式统计

Hacken、Veridise和zkSecurity在独立审计实践中交叉观察到，大约七成已知电路级漏洞可归入以下五类：

1. 赋值后未约束，缺少严格的等式锁定；
2. 输入位宽未限制，未使用二进制展开或范围约束；
3. 公共输入未被纳入Fiat-Shamir哈希或挑战计算；
4. 常量被误编译为可变信号；
5. 模板复用时参数错误导致约束遗漏。

graph TD
    A[目标：证明某note属于Merkle树] --> B[Merkle路径验证电路]
    B --> C1[路径H(left,right)]
    C1 --> D1[约束存在：hash严格等于H(left||right)]
    D1 --> E[最终根哈希]
    B --> C2[中间值mid仅用赋值操作给出]
    C2 --> D2[缺少约束mid严格等于正确计算值]
    D2 --> F[攻击者替换mid为任意值]
    F --> G[构造不同的left和right组合]
    G --> H[生成与E一致的伪造根]
    H --> I[系统验证通过]
    style D1 fill:#9f9
    style D2 fill:#f99

上图以Merkle成员资格证明场景为例，展示了欠约束如何打开伪造窗口。左侧安全路径通过约束等式锁定每一步中间哈希值，最终推导的根哈希被强制与真实路径一致。右侧危险路径中，某步中间值仅通过赋值而非约束获取，攻击者可以替换该中间值为有利于自己的数值，组合出一条并不存在于原Merkle树中的路径，却生成与合法树根一致的伪造证明。这种攻击不需要攻破底层哈希函数，也不违反离散对数假设，它仅仅利用了设计中尚未被锁定的自由度。

四、应用层：当ZK本身没有问题，集成才是

4.1 Tornado Cash 审计中的集成陷阱

MixBytes对Tornado Cash的审计报告是ZK应用安全研究的经典案例。报告揭示了一条关键教训：即使底层电路逻辑完全正确，智能合约层面的nullifier管理、Merkle根更新和事件日志泄露都可能构成独立攻击路径。

Tornado Cash的电路证明了存取款者知道对应note的秘密并能导出nullifier，但智能合约必须在此基础上独立执行三种关键状态校验：

• nullifier是否已存在于消费集合中，防止双花；
• 当前Merkle根是否属于合约维护的合法历史序列；
• 合约在事件输出中是否无意间泄露了可追踪的时间或金额关联。

这三种职责不能由ZK证明替代。证明只声明计算被正确执行，合约必须保证状态转换符合业务规则。将电路逻辑当作唯一安全边界而忽略合约层守卫，是ZK桥和ZK DeFi项目中最危险的反模式之一。

4.2 信任假设的跨层传递

生产环境中ZK系统的实际安全性取决于最弱环节，形成明显的短板效应：

• 可信设置：Groth16等方案的SRS需要setup ceremony中的toxic waste被彻底销毁。即使Zcash的Powers of Tau仪式在多轮多方计算中被广泛认为是密钥销毁最彻底的实例，后续项目若自定义MPC，其参与者选择和实现本身即可能成为攻击面。
• 密钥分发与验证：开发者发布的证明密钥和验证密钥是否确实源自已审计源码的确定性编译产物。用户与合约之间目前普遍缺乏自动化的链上链下一致性校验流程。
• 依赖库漏洞：Orchard事件中的缺陷位于halo2_gadgets这一基础模块。任何复用Orchard电路的项目若引入了同样有缺陷的版本，同样会暴露。
• 跨链桥场景：2024年至2026年间多起ZK桥安全事件的根因并非证明伪造，而是桥合约逻辑过于简单地认为证明有效即可执行状态转移，未独立核验源链共识最终性和重入防护。电路可能正确证明了资产锁定，但合约未处理同一证明在另一条链上的重放或时间窗口被利用的问题。

五、威胁模型：从理论到部署的四级安全边界

基于前文分析，本文提出ZK系统的四级分层威胁模型作为安全评估框架：

当前社区的工具投入高度集中于L1与L2交界。L3形式化验证尚处起步阶段：2025年推出的Lean4基ZKP专用语言Clean，以及2026年zkSecurity对SP1 Hypercube进行形式化证明时发现新缺陷的案例，均显示该领域快速成长，但距离主流可用仍需时间。

模型的核心洞见在于：上层安全认证不是自动向下传递的。通过L1智能合约审计的zk-rollup，仍可能在L2层存在未约束电路；通过L3形式化验证的共识协议，其L1部署仍可能因合约重入问题被攻破。层级之间的一致性，例如已审计电路的验证密钥与链上部署内容的哈希匹配，本身也是独立的安全要求。

六、工具生态：自动化的能力边界

6.1 主要工具概览

• Circomspect：Trail of Bits开发的Circom静态分析器，通过模式匹配自动识别常见欠约束模式，包括赋值未约束和位宽缺失。对标准模板和常见用法覆盖率较高，已可作为持续集成流程的一部分。
• ECNE：2022年由斯坦福等研究团队提出，约束系统自动形式化验证框架，尝试在R1CS或QAP层面自动证明完备性。对复杂自定义约束仍需要人工辅助。
• zkFuzz：2025年发表的模糊测试框架，引入TCCT理论模型，将软件模糊测试理念迁移到ZK电路中。通过大量对抗性witness探测那些验证应当拒绝但错误放行的情况。其难点在于语义级异常判断需要精心设计的测试预言。
• Clean：2025年开发的Lean4基ZKP电路领域特定语言，将电路语义嵌入定理证明器。目标是将电路编写与安全属性证明统合在同一可验证框架内，代表L3证明安全部分自动化的长期方向。
• zkSecurity审计框架：基于过百次审计经验积累的模式库和分级威胁模型，是当前最系统化的工程安全审计方法论来源。

6.2 自动化盲区

当前工具尚未有效覆盖以下场景：

• 跨模板或跨文件的复杂约束交互。约束分布在多个嵌套模板中时，静态分析的误报和漏报风险增大。
• 业务逻辑的语义级漏洞。电路的约束本身可以正确编码，但编码的业务规则本身存在错误，例如资产进出核算不匹配。这要求对需求规格进行形式化建模。
• 集成层漏洞。智能合约与ZK电路之间的一致性校验不在当前自动化工具范围内。
• 随机预言机的具体实例化安全。某些参数和哈希函数组合下，替代随机预言机的具体损失需要个案评估，无法由通用工具统一处理。

因此未来ZK安全最佳实践将是多层工具联合使用，人工审计填充工具之间的空白带，而非追求一键审核的银弹方案。

七、开发者安全自检清单

基于前述分析和行业实践，本文提供一份覆盖完整生命周期的自检清单。每一项都对应过去四年安全事件中的真实根因。

这份清单的核心思路是：安全不是单一环节的静态属性，而是贯穿设计、编码、集成、测试、发布和运维的连续过程。Orchard事件四年潜伏的教训说明，发布时的安全不等于运行时的安全。持续的监控和可复现的构建是降低长期风险的必要手段。

八、结语：一个时代的终结与开始

从2022年Frozen Heart的协议层冲击，到2026年Zcash Orchard的电路层危机，再到Tornado Cash和多起ZK桥事件揭示的集成层脆弱性，零知识证明的安全叙事正在经历深刻转型。

早期ZKP生态中，安全性天然被视为数学问题：方案完备可靠即可被信赖。Frozen Heart打破了这一幻觉：理论正确不等于实现安全。Orchard进一步证明：即使代码通过审计并运行四年，微小的约束遗漏仍可能成为被利用的后门。而隐私与可审计性之间的根本张力，让传统监控手段面临失效的困境。

本系列十五期内容，从技术选型、协议原理，到zkVM和证明压缩的工程实践，从密码学经济学、后量子方向，到证明市场、跨链桥、客户端零知识与Rollup开发语言，到本期以安全威胁模型收官，形成了一条从认识ZKP到可信地使用ZKP的完整路径。当回望这一终点，阻碍ZKP走向主流的关键已不再是数学可行性，过去五年研究已解决；也不是工程性能，zkVM与硬件加速正在突破。真正的瓶颈在于：开发者与使用者能否对这些复杂系统建立基于可验证证据的信任——不是盲目信赖，而是基于可验证约束、可复现构建、可监控行为的信任。

ZKP的本质是用密码学代替信任。但在实现这个终极目标前，它需要经历自身被机器与人类反复审视、验证和消解疑虑的过程。安全审计工具、形式化验证语言和社区知识库是这个过程的根基。只有当开发者和研究者在一个公开透明的安全文化中协作，零知识证明才能从少数人理解的象牙塔技术，转变为千万人使用且无需完全理解其内部运作即可信赖的基础设施。

这既是本期终点，也是整个ZKP专题十五期的终点。但从行业时间线来看，它恰恰标志着一个新阶段的起点：安全不再只是额外工作，而是融入每个开发环节的日常实践。

参考文献

1. Trail of Bits 2022-04. "Coordinated disclosure of vulnerabilities affecting Girault, Bulletproofs, and PlonK — The Frozen Heart series." Trail of Bits Blog. 2022年4月13日。该系列报道系统性披露Fiat-Shamir变换实现错误在多个主流ZKP系统（PlonK、Bulletproofs、Girault）中的影响。
2. BlockSec 2026-06-04. "Zcash Orchard Soundness Bug Analysis." 公开技术报告，详细分析Orchard屏蔽池中电路约束缺失导致的双花风险，并讨论隐私保护与漏洞可检测性的根本张力。
3. 0xPARC / zk-bug-tracker. 社区维护的ZKP已知漏洞与攻击模式数据库。GitHub: 0xPARC/zk-bug-tracker。
4. Hacken 2024. "5 Circom Security Pitfalls That Can Break Your Proofs." 工程级Circom漏洞模式总结，涵盖赋值未约束、位宽缺失、常量信号处理等常见错误。
5. Veridise 2023. "Circom-Pairing: A million-dollar ZK Bug caught early." 在ZK桥项目审计中发现的pairing电路高危漏洞分析，未经利用即被修复。
6. zkSecurity 2026. "zkao: Security That Compounds." 基于过百次审计经验的ZK安全框架与模式库，含分级威胁模型和自动化审计工具集成方案。
7. MixBytes 2021. "Audit of a ZK application on example: Tornado Cash." 对Tornado Cash合约与电路的联合审计方法论报告，揭示协议层正确性与合约层状态管理的一致性要求。
8. Pailoor et al. 2025. "zkFuzz: Foundation and Framework for Effective Fuzzing of Zero-Knowledge Circuits." arXiv:2504.11961v2。引入TCCT理论模型，将模糊测试理论拓展至ZK电路场景，提出检测欠约束与过约束的自动化方法。
9. StefanosChaliasos et al. / Awesome-ZKP-Security. 持续维护的ZKP安全资源精选列表，涵盖审计工具、论文、审计报告与形式化验证项目。GitHub: StefanosChaliasos/Awesome-ZKP-Security。
10. Zcash / Shielded Labs 2026-06-05. 官方紧急公告：Orchard电路soundness漏洞与紧急升级计划。Zcash工程博客发布。
11. Trail of Bits 2023. "Circomspect: A static analyzer for Circom." 工具首次发布及评估报告。
12. ECNE研究组 2022. "ECNE: Automated Verification of ZK Constraint Systems." 斯坦福等团队提出的约束系统自动验证框架。发表于安全领域会议。
13. Clean DSL 团队 2025. "Clean: A ZK Circuit DSL in Lean4." 基于Lean4的零知识电路领域特定语言。项目公开维护中。

声明：本文中涉及的Circom代码片段、协议流程和攻击场景仅用于教育演示与技术讲解，不构成可参考的安全实现，不应用于任何生产系统。ZK电路的设计与部署需要专业密码学审计团队的评估。