七天蒸发四成，全因一个藏了四年的错误

简介

核心要点：

• Zcash Orchard 屏蔽池电路存在严重 soundness 漏洞，可能让 ZEC（Zcash 原生代币）在 Orchard 池内被不可检测地伪造。漏洞自 2022 年 5 月 Orchard 上线以来潜伏超过四年，于 2026 年 6 月 3 日通过紧急网络升级（NU6.2）修复。

• 根本原因是 halo2 ECC 标量乘法 gadget 中缺少一个等式约束：代码用了 assign_advice() 而非 copy_advice()，内部基点没有被锚定到外部实际基点，破坏了 diversified address 与 nullifier 之间的密码学绑定。

• 漏洞通过 human-in-the-loop AI 审计模式发现：领域专家构建审计框架，AI 模型（Anthropic Opus 4.8）执行电路级检查。即使经过多轮专业审计且在链上长期运行的代码，仍可能隐藏严重漏洞——安全审计需要随分析工具的进步持续投入。

过去一周（2026/06/01 – 2026/06/07），链上发生了多起安全事件，但最引人关注的是 Zcash Orchard 屏蔽池严重 soundness 漏洞的披露，以及由此对 Zcash 生态和 ZEC 价格产生的影响。虽然没有发现实际利用的证据，但披露本身引发了紧急网络升级，ZEC 价格跌幅超过 40%。

表 1：本周关注的安全事件概览

本周看点：Zcash Orchard Soundness Bug

这是迄今在生产环境中发现的最严重的 ZK 漏洞之一：一个约束缺失存在四年多、经历多轮专业审计后才被 AI 辅助审计捕获。这类漏洞（零知识电路中的 under-constrained relation）可能潜伏在任何基于 ZK 电路构建的协议中。

2026 年 6 月 4 日，Zcash 公开披露了 Orchard 屏蔽池电路中的一个严重 soundness 漏洞。零知识证明电路中缺少一个约束，破坏了防双花的密码学绑定，可能让同一笔隐私 note 被反复花费而无人察觉。漏洞自 2022 年 5 月 Orchard 上线起就存在，2026 年 5 月 29 日由安全研究员 Taylor Hornby 通过 AI 辅助审计发现，6 月 3 日紧急网络升级 NU6.2 完成修复。目前未发现利用证据。

背景

Zcash 是一个以隐私为核心的 Layer-1 区块链，原生代币为 ZEC。和 Bitcoin 不同（Bitcoin 交易信息完全公开），Zcash 通过零知识证明支持隐私交易，可以隐藏收发地址和金额。Zcash 有多个屏蔽池（shielded pool），每个池对应不同一代的隐私协议。Orchard 是最新一代屏蔽池，于 2022 年 5 月随 NU5 升级上线，使用 halo2 零知识证明系统验证交易。用户发起隐私交易时扮演 prover 的角色：用 Orchard 电路构造零知识证明，向网络证明交易有效（自己拥有这笔 note、nullifier 计算正确、金额平衡），同时不泄露任何私有数据。网络节点作为 verifier，只需验证证明是否成立，无需看到底层数据。Orchard 电路定义了有效证明必须满足的约束条件。本次漏洞出在这个电路实现中，涉及 Zcash 四个核心概念：密钥、地址、Note 和 Nullifier。

密钥。 Zcash 的密钥体系比多数区块链复杂。一个 spending key（钱包私钥）派生出多个子密钥：ask（spend authorizing secret key）、nk（nullifier deriving key）和 rivk（随机化因子）。再由这些子密钥计算出 ak（authorizing public key）和 ivk（incoming viewing key，ivk = Commit(ak, nk, rivk)）。ivk 用来识别和接收转入的资金。

地址。 创建 Orchard 地址时，用户选一个 diversifier d（11 字节），由此得到 diversified base point g_d = DiversifyHash(d)。地址就是 (d, pk_d)，其中 pk_d 通过椭圆曲线标量乘法计算：pk_d = [ivk] g_d。地址因此与用户的 viewing key 产生密码学绑定。

Note。 Note 就是一笔资产记录，代表收到的资金。为了保护隐私，链上存的不是 Note 本身，而是 Note commitment cm（对 pk_d、金额等数据的密码学承诺）。Note 锁定到接收方地址。

Nullifier。 花费 Note 时要揭示一个 nullifier nf，由 Note 数据和 nullifier key nk 计算：nf = Extract_P([(F_nk(ρ) + ψ) mod p]G + cm)。核心安全性质是：同一笔 Note 只能产生一个 nullifier。nullifier 一旦出现在链上，对应 Note 就算花掉了。如果同一笔 Note 能产生不同的 nullifier，就能被反复花费而不被发现。

绑定链。 上述概念通过一条密码学绑定链相连：

图 1：Orchard 的密码学绑定链；红色标出漏洞破坏的关键环节

图中红色节点（pk_d、nk）标出了漏洞破坏绑定链的关键位置：电路必须强制约束 pk_d = [ivk] g_d，把花费者绑定到正确的 ivk，进而绑定到正确的 nk。一旦这条绑定断裂，花费者就能伪造 ivk，进而每次花费使用不同的 nk。不同的 nk 为同一笔 note 产生不同的 nullifier，双花就此成为可能。

电路如何约束这条绑定。 pk_d = [ivk] g_d 是一个椭圆曲线标量乘法（Q = [k]P），通过 double-and-add 算法实现。在零知识电路里，验证者不直接跑算法，而是约束每一步中间关系。正确的标量乘法电路必须（在其他约束之外）保证内部循环基点等于预期输入基点（P_loop = P_input）。少了这个约束，电路可能放行一次基点错误的标量乘法，整条绑定链随之失效。

漏洞分析

出问题的 ECC gadget 用于约束 pk_d = [ivk] g_d，其中 Q = pk_d、k = ivk、P = g_d。漏洞代码在 halo2 仓库的 variable-base 标量乘法实现中（incomplete.rs L309-L310）：

零知识电路中，所有 cell 的值都由 prover 填入；电路本身无法在 cell 之间复制或推送值，只能定义约束供 verifier 检查。标记 BUG 的两行用 assign_advice() 把基点坐标 x_p、y_p（即私有电路输入的 witness 值）写入电路的 advice 列（prover 私有输入区）。这个函数填值但不创建与外部基点的约束关系。代码中确实存在另一个约束保证循环各迭代的基点值互相一致——prover 不能每轮用不同基点。但 prover 可以用一个统一的任意基点跑完所有迭代，电路不会拒绝，因为没有约束将循环内的基点值锚定到外部传入的实际 g_d 上。

正确的做法是用 copy_advice()，它在填值的同时加一个等式约束（拷贝约束），强制要求填入的值等于实际基点 g_d。由于 g_d 因地址而异（由每个地址的 diversifier 派生），电路不能将其写死，必须通过约束确保循环内使用的基点与上游计算出的 g_d 一致。

结果是电路并没有真正约束 pk_d = [ivk] g_d。恶意 prover 可以在循环内部塞一个任意基点（而非正确的 g_d），电路照样放行：内部计算代数上自洽，但已经脱离了协议指定的 diversified base point。这给了 prover 额外的自由度：每次选择不同的 nk，计算出对应的 ivk = Commit(ak, nk, rivk)，再利用未约束的标量乘法让伪造的 ivk 通过验证。由于 nullifier 依赖 nk，每次花费产生不同的 nullifier：

共识层只检查 nullifier 是否已经出现过。每次花费都产生一个全新的、看起来合法的 nullifier，双花对网络完全不可见。

修复方案是在循环首次迭代（row == 0）中增加 copy_advice() 调用，创建拷贝约束将循环内的基点锚定到外部传入的实际 base。后续迭代仍使用 assign_advice()，但已有的迭代间一致性约束会将锚定传播到所有迭代。

影响与应对

利用场景。 恶意 prover 可以反复花费同一笔 Orchard note，每次生成不同的 nullifier。零知识证明隐藏了私有电路输入，伪造的 nullifier 和正常的看起来没有区别。攻击在链上不留确定性的密码学证据，无法最终判定漏洞是否曾被利用。

漏洞自 2022 年 5 月 Orchard 上线（NU5 升级）起就存在，持续暴露超过四年。Zcash 的 turnstile 记账机制限制了伪造价值从 Orchard 池流出到 transparent 或 Sapling 池的数量，约束了对整体供应量的实际影响。但伪造的 note 可能在屏蔽池内部不被察觉地存在，且屏蔽池的隐私特性决定了无法用密码学手段证明漏洞是否曾被利用。

注：turnstile 仅在某个池的总流出超过总流入时才会触发。攻击者可以长期小额提取伪造价值而不触及这一上限。只有当合法用户集体提取的总量超过池内实际持有量时，差额才会暴露。

发现与应对。 2026 年 5 月 29 日，安全研究员 Taylor Hornby（受 Shielded Labs 委托）借助 AI 辅助审计框架，配合 Anthropic 前一天刚发布的 Opus 4.8 模型，发现了该漏洞。此前用旧模型审计同一电路时并未发现。Hornby 当天报告给 ZODL。6 月 2 日（UTC）紧急软分叉暂停了 Orchard 交易，6 月 3 日（UTC）NU6.2 升级（区块 3,364,600）上线修正后的电路，恢复 Orchard 功能。6 月 4 日公开披露后，ZEC 跌超 40%，清算金额超 1 亿美元。

结论

Zcash Orchard 漏洞的根本原因是标量乘法电路中缺少一个等式约束，导致 prover 可以绕过基点绑定、伪造 nullifier 实现双花。和传统智能合约漏洞不同（后者通常可以通过代码审查或测试发现），零知识电路的 soundness 漏洞要求理解电路实际证明了什么与应当证明什么之间的差距——这种微妙差异即便经过四年多的专业审计，也未被资深密码学专家发现。

halo2 库在整个 ZKP 生态中广泛使用，类似的 under-constrained relation 可能潜伏在其他基于这些密码学构件的项目中。采用零知识证明的协议应把余额完整性检查（如 turnstile 记账）作为标配，给未发现的 soundness 漏洞兜底：没有 Zcash 的 turnstile 机制，屏蔽池内伪造的价值将可以不受限制地流入整体供应。Shielded Labs 已宣布将对 Orchard 电路做形式化数学验证。

这次发现是 human-in-the-loop 的典型案例：资深安全研究员构建审计框架、引导调查方向，AI 负责逐一检查电路约束。两者缺一不可：旧模型的 AI 审计没能发现漏洞，多年的专家人工审查也没能发现。Hornby 本身就是 Zcash 安全专家——领域经验决定了 AI 的审计范围能否命中要害。相关研究也印证了这一点：AI 模型在安全分析能力上进步迅速，但仍需要专家把 AI 引向正确的目标并验证结果。专家与 AI 的交互协同——而非单纯依赖 AI——才是最有效的工作模式。