AlphaProof Code：AI 把 Signal 的加密代码证到了机器码

2026 年 11 月 10 日，Google DeepMind 在官方博客发布 AlphaProof Code，并公布了一项长期被视为安全领域大挑战的结果：AI 智能体在人的指导下，为 Signal 协议的实际实现代码给出了形式化证明。这里的「实际代码」指的不是协议设计，也不是为了便于证明而改写过的版本，而是编译后运行在设备上的机器码。

DeepMind 称，这是首次有 AI 把一套广泛部署的加密协议验证到这种深度，也是首次有方法（无论是否使用 AI）对这类协议的实际实现完成形式化验证。这个「首次」来自官方表述，我们未能独立复核其证明。

它到底是什么

AlphaProof Code 是一个多 LLM 的智能体框架，把形式化验证拆成研究团队式分工：人负责决定「证什么」，智能体团队负责「把证明写出来」。

• 规格写作：人和模型一起把 Signal 的安全目标翻译成 Lean 定理与定义；每一个定理都经人类专家审阅后才进入基线
• 机器码语义：用 Lean 写了一份 AArch64 用户态语义，把编译后的 ELF 二进制作为字节序列加载进来，描述它所有可能的运行
• 证明合成：由 Gemini Carbon 驱动的智能体团队写证明，官方称共生成超过六百万行 Lean；论文给出的数字约为 6.5 million 行
• 把关：证明只有在 Lean 内核检查通过、且与人类批准的规格逐字一致时才被接受；证明智能体本身不被信任，逻辑错误会被内核拒绝

关键点在于「可信面」很小：需要人去读、去信的是规格与语义，论文说约 26,000 行，其中 18,000 行是规格与定义，8,000 行是 AArch64 语义。剩下几百万行证明由机器检查，不需要人逐行阅读。这也是这套东西真正的可读性所在。

这次证了什么

验证对象是 libsignal，Signal 协议的官方 Rust 实现。流程是把未修改的 Rust 代码用标准编译器编译成 AArch64 机器码，再在 Lean 里证明这份二进制满足规格。

• 覆盖范围：Signal 的抗量子握手 PQXDH 与 Triple Ratchet
• 安全属性：前向保密、认证、妥协后安全、握手保密；符号模型下还包括对未来量子攻击者的握手保密
• 深度：证明直接落在编译后的机器码上，而不是停在协议设计层
• 规模：一个证明团队通常有 40 到 80 个 agent，在一台机器上跑 24 到 72 小时；论文说整个验证过程用了四周，而过去这类工作需要专家团队数年

为了证明它分得清「正确代码」和「有 bug 的代码」，团队把两个真实的、此前已修复的 libsignal bug 重新注入隔离版本。两次都产出了机器可检查的证明：带 bug 的版本不满足安全定理。

Signal 的 CTO Ehren Kret 在官方博客里的评价是：让 AI 智能体把线上代码翻译成合法的 Lean 定理是一项重大突破。

为什么值得关注

形式化验证一直是个成本问题。论文举了两个参照：经过形式化验证的 seL4 微内核花了二十人年，CompCert 编译器花了六年。对绝大多数软件来说，这个成本不可接受，所以验证通常只出现在最关键的少数系统里。

AlphaProof Code 的思路不是让 AI 替代人做安全判断，而是把人力从「写证明」移到「写规格、审规格」。证明由智能体生成，正确性由 Lean 内核兜底，人只需要对规格负责。这个分工如果站得住，形式化验证的边际成本会明显下降。

另一层意义在「设计到实现」的缝隙。多数协议验证停在抽象模型，而真实漏洞经常出在实现与设计的偏差里。这次证明直接对着编译产物，官方因此把它称为从协议级安全保证到未修改实现的第一座桥。

动手实测：竞赛题为什么没跑起来

评分给出的写作角度是「用 AlphaProof Code 证几道竞赛题，记录可读性与耗时」。我们按这个方向找了一圈，结论是：现在跑不了。

• 官方公开的是 Signal 验证的 Lean 工件与论文，仓库 google-deepmind/code-verification 的定位是「在机器码层面验证 Signal 的安全」，不是给任意题目出证明的通用工具
• 仓库里没有「输入一道竞赛题、输出 Lean 证明」的入口；README 讲的是如何构建并检查 Signal 这套开发，不是如何调用一个证明服务
• 构建门槛也不低：需要 Lean 4（经 elan 安装，工具链锁定在 v4.34.0）、Rust 1.98.1、protoc、ld.lld 与 Zig；README 明说检查全部证明要数小时，峰值内存约 15–34 GiB
• 我们实际核对到的可验证信息：仓库是公开的 Lean 项目，创建于 2026 年 10 月 26 日，2026 年 11 月 10 日还有推送；目录分为 Computational、Symbolic、LibsignalBinary 与 arm64-semantics 四块，对应两套安全模型与共享的二进制规格

所以这篇没有「竞赛题耗时表」，也没有「证明可读性打分」。不是不想测，而是没有可复现的入口；硬编一组数字会违背这个站点的基本规矩。

能给的「可读性」判断来自公开结构：6.5 million 行证明不是给人读的，真正需要人审的是那 26,000 行规格与语义。对想评估这套方法的人来说，应该读的是规格写得好不好、假设是否合理，而不是去读证明。

边界与保留

• 证明的可信度依赖几样东西：Lean 内核、规格本身、密码学原语的假设，以及一些被 hook 的外部函数契约；规格写错，证明再漂亮也只证明了错的东西
• 论文说明这套机器码语义不建模线程、信号、vDSO、动态链接和当前目录以外的文件；依赖这些的程序不在覆盖范围内
• 这是一套需要人类深度参与的流程，不是「一键验证」产品；官方开源的工件是这次 Signal 验证的成果，不等于一个可直接复用的通用验证器
• 本文的「首次」与效果数字均来自 DeepMind 官方博客与论文，我们没有独立重跑证明，也没有审计 Lean 开发本身

本文基于以下公开报道整理。

参考来源

• Google DeepMind：Introducing AlphaProof Code（2026-11-10）
• AlphaProof Code：Verifying Signal’s Security at the Machine-Code Level（论文与工件）（2026-11-10）
• google-deepmind/code-verification：Lean 开发仓库（2026-10-26）

本文由 AI 辅助整理，数字与说法均来自上方公开来源；证明结果未经我们独立复核。