Zcash 被发现一个存在四年可被无限增发的 Bug，代币直接暴跌 30%。这件事更可怕的是，这个 bug 是研究员使用 Opus 4.8 自动化审计、自主发现的。 作者有一套叫 zcash-full-stack-auditor 的 agent 框架。5 月 28 日（也就是 Opus 4.8 发布当天）他启动了对 halo2（Zcash 的零知识证明库）实现的自动化审计，范围涵盖 Orchard 电路。框架先跑一个"初始化阶段"，把相关代码位置、规范条款、安全属性、失败模式全部枚举出来。 5 月 29 日下午约 2 点，初始化完成后他启动了"审计阶段"——框架给清单里每一项分配相应类型的审计 agent，这次跑的就是 Opus 4.8，调成了 max effort。 当天约下午 6 点，一个审计 agent 报出了 Orchard 电路里的一个严重漏洞，声称可以双花（double-spend）Orchard 笔记。作者当晚晚些时候才注意到这条发现，随后逐步验证、上报、做 PoC： 1. 他先让 Claude 针对一个类似"多样化地址完整性"（diversified address integrity）的简化电路写了第一个 PoC，确认漏洞大概率为真，当晚 11:53 通过 Signal 上报给 Daira Emma Hopwood 和 Kris Nuttycombe。 2. 再让 Claude 针对真实 Orchard 电路写第二个 PoC，演示了"对同一笔记揭示多个不同 nullifier"从而双花，周六凌晨 2:06 交付，并建议紧急停用 Orchard。 3. 最后开发了一个 RPC 测试，把一笔 Orchard 笔记的价值不断翻倍，直到 regtest 钱包余额超过 1000 万 ZEC，证明增发攻击确实可被利用（regtest 用的是和主网完全相同的规则和零知识证明验证，交易没有广播到测试网或主网）。 值得注意的是关于"可发现性"的部分：作者之前用同一套框架但跑的是 Opus 4.7 xhigh，并没有找到这个 bug；后来确认 4.7 只有在被非常具体地指引时才找得到。即便是 4.8，用比较泛化的提示时也只在 4 次测试里命中 1 次。一个可能的差异是这次他把 halo2 book 喂进了初始化阶段（以往只喂协议规范和 ZIP）。漏洞自 Orchard 上线起就存在了 4 年多，且上线前做过深入的人工审计都没发现——说明它对人类相当难找。 Opus 4.8 扮演了什么角色 它基本上是整条链路的核心，从发现到验证都深度参与： 自主发现：在 max effort 下运行的审计 agent 自己定位到了这个严重漏洞，这是整个事件的起点。 独立推导数学：漏洞在于电路对标量乘法的基点 base 没有施加约束，攻击者可以任意选取这个 base。给定目标的 pk_d、g_d、ivk，需要反推出 base 应该设成什么值才能让 [ivk]g_d 等于 pk_d。报告里明确写道这步代数完全是 Opus 4.8 自己算出来的，作者没给任何提示，并说自己没有 AI 的话会花很长时间。 写 PoC 和 RPC 测试：两个 PoC 和最终那个增发测试都是 Claude 写的。开发 RPC 测试约花了 6 小时，期间 Opus 4.8 几乎不太需要人工指导，作者只给了两点提示（如何处理 action bundle 被重排序、以及 prover 生成证明时的多次 pass）。 辅助分析与缓解：作者还让 Claude 对漏洞曝光窗口内的链上交易做了统计分析，查是否有被实际利用的迹象（结论不确定，因为屏蔽交易本身方差就高）；长期缓解建议里也用 AI 跑了一遍"能否把某个 assign_advice 的值改成别的而不违反任何约束"的检查。 一个有意思的行为细节：报告说 Opus 4.8 对自己找到的是不是真漏洞极度怀疑——它倾向于认为上游代码经过审计所以应该是对的，或者觉得自己看的是被人故意植入后门的版本，需要作者"推一把"才肯认真对待这个发现。