一张生成的标题卡,标题为“AlphaProof Code”,副标题为“650 万行 Lean,四周,五位研究人员”,三张数据卡分别写着“650 万行证明”、“已验证 560 KB 的 libsignal”和“140,000 条 AArch64 指令”,一个扁平线条盾牌图标,其勾选标记位于代码文件矩形旁,页脚写着“数据由 Google DeepMind 于 2026 年 11 月 10 日报告。”;OrcaRouter 标志位于扩展画布的右下角。
Engineering & Research

AlphaProof 代码在编译后二进制文件的层面上证明了 Signal 的加密是正确的

作者

Rowan Sterling

发布日期

最新模型 · 20查看全部模型 →
基准测试:Artificial Analysis · 每日更新
返回全部文章

六百五十万行 Lean 代码,在四周内产出,由没有任何人类协助编写的智能体团队完成。这是 Google DeepMind 于 2026 年 11 月 10 日发布的 AlphaProof Code 的头条数字;AlphaProof Code 是一个用于形式化验证的智能体框架,该实验室用它来机器检查 Signal 协议的密码学核心——而且不同寻常的是,是在编译后的 AArch64 二进制层面进行检查,而不是其上的设计文档。完成这项工作的模型则是另一个问题。一个 API 密钥,按提供商标价、0% 加价证明智能体的引擎并非我们所提供的服务。

这个框架不是你可以调用的模型。它是一套承载框架:由人类专家决定哪些条件必须成立,多个模型的组合再把这些目标转化为 Lean 规范,然后由一组组编写证明的智能体——博客称 G​emini Carbon 为引擎——补全证明,直到 Lean 的内核接受它们。与公告一同发布的是一套工件集(位于 github.com/google-deepmind/code-verification),以及一篇技术论文;相比博客文章,这篇论文对结果边界的表述要坦率得多。下文大部分内容都来自那篇论文,因为有趣的数字都在论文里。

A headless-Chromium capture of the Google DeepMind blog post 'Introducing AlphaProof Code: a breakthrough in verifying complex software at depth', dated November 10, 2026, bylined Pushmeet Kohli and Swarat Chaudhuri, showing the subheading about formally verifying the code of Signal's cryptographic protocol.

实际证明了什么,又是针对什么证明的?

目标是 libsignal v0.105.4 与 spqr v1.6.0,由原版 rustc 1.98.1 构建,静态链接 musl,并生成单个 AArch64 Linux 可执行文件。这个细节比任何基准测试都重要:证明针对的是会在手机上运行的字节,而不是信任编译器能忠实翻译的某个 Rust 函数。团队验证了大约 560 KB 的 libsignal 源代码、约 140,000 条 AArch64 指令,他们通过编写指令集的 Lean 模型——共 7,578 行,涵盖 467 条指令和 31 个系统调用——然后证明真实 ELF 映像在该模型下加载并执行时保持安全属性。

这些性质正是协议工程师会要求的。十个符号定理涵盖前向保密性、妥协后安全性、发起方与响应方保密性、认证,以及 PQXDH 定理 1 的五个推论。主要结果命名为 signal_session_secure_placed。还有一条带有具体界的计算性路线,而这两条路线使用不同的敌手模型:符号侧(Dolev–Yao,经由 DyLean 框架)甚至涵盖在握手之后攻破 Diffie–Hellman 的量子攻击者,而计算侧仅涵盖经典敌手。

A generated single-column breakdown card headed 'AlphaProof Code - the proof breakdown' with six rows reading 'Binary proofs: 5.3M lines', 'Computational proofs: 860,000 lines', 'Symbolic proofs: 350,000 lines', 'Bug-refutation proofs: 140,000 lines', 'Allocator proofs: 70,000 lines' and 'Trusted specs: about 26,000 lines', with the footer 'Line counts per the DeepMind technical paper; every proof checked by the Lean kernel.'

六百万行去了哪里

“超过六百万行”是博客里的说法,准确但粗略。论文中的拆分才是有用的,而且值得把它当作一张成本表来读,而不是当作炫耀:

• 二进制程序的证明——530 万行,占工作量的绝大部分,涵盖机器码语义以及从符号模型向下到可执行程序的精化。

• 计算证明——约 860,000 行。

• 符号证明——约 350,000 行。

• 缺陷反驳证明——约 140,000 行,针对下文所述的两个故意重新引入的漏洞。

• 分配器证明——约 70,000 行。

如果算上注释和空行,将近七百万行;论文是这样统计的,而博客没有。无论哪种算法,真正重要的比例都在于证明与被证明对象之间:用 650 万行 Lean 来确立一个 560 KB 二进制文件的性质。这个比例才诚实地衡量出这项技术离日常应用还有多远,也正是当有人问形式化验证是否已经变得廉价时应该引用的数字。

可信基础比证明更小,而这正是关键所在。

证明的可靠性取决于其所假设的前提。论文在这一点上表述得很具体,而正是这种具体性使其有别于新闻稿。可信规范约为18,000行(含文档为28,000行),AArch64语义约为8,000行,机器码的Lean编码约为95,000行。有三十七个例程以契约替代验证——SHA-256与SHA-512压缩、AES-256-CBC、X25519、Edwards曲线运算、Kyber1024与ML-KEM-768,以及libcrux HMAC。另有十八个恐慌入口点同样是被假设而非被证明的。

因此,这一主张并不是“所有东西都已被证明”。这一主张是:密码协议逻辑、会话状态机,以及从该逻辑到实际执行指令的精化,都已被证明;而底层的原语则像每个验证项目信任其原语那样被信任。值得注意的是,Rust 编译器不在可信基中——团队通过在机器码层面进行推理,避免了需要信任它,这也正是让他们能够完全绕开经过验证的编译器的同一个技巧。作为规模参照,论文提到 seL4 大约为 20 人年,CompCert 约为 6 人年。

A headless-Chromium capture of the AlphaProof Code technical page at google-deepmind.github.io/code-verification, headed 'AlphaProof Code: Verifying Signal's Security at the Machine-Code Level', dated 2026-11-10, listing the nine authors, the code repository link and the opening of the abstract describing roughly 6.5 million lines of machine-checked Lean resting on about 26,000 lines of trusted specifications.

两个 bug,是故意放回去的

一个只会说“正确”的验证系统是无法测试的。因此,团队取来两个此前已在 Signal 的代码中发现并修复的漏洞——一个弱状态漏洞和一个小子群漏洞——将它们重新引入一个隔离副本,并重新运行了流水线。在这两种情况下,AlphaProof Code 都生成了机器校验的证明,证明有缺陷的版本不满足安全定理:符号陈述归结为 ¬Sec(Asm_bug)。

论文补充了一条营销页面本会删掉的注意事项:反驳计算定理对于这些缺陷而言“困难得多”,而且被留作未决问题。换句话说,这种否定性检验在符号轨道上运行得很干净,但在计算轨道上尚不可行。这正是读者在把该框架当作缺陷检测器之前应当了解的那种不对称性。

智能体是如何运行的

四周内五名研究人员,每人都不间断地运行智能体。证明撰写本身由40到80个智能体组成的团队完成,每个团队在一台机器上运行24到72小时,团队编排器之上还有一个监督智能体。一个把关智能体会用比较器对照规范的留出副本以及Lean内核检查每次提交——这是为了防止智能体证明一个被微妙弱化的问题版本。

人工工作主要前置在规格说明上。每份规格说明都在证明工作开始前由专家审核,智能体自身的审计检查将约 1% 的代码库标记为需要人工关注。没有任何人编写证明代码。论文对工程实现也很直白:一次干净构建可能要花数小时,早期哪怕是对源代码的小改动或重新编译的二进制文件,都会迫使进行大规模证明修复,而且无论 AI 生成的证明还是证明技术本身,都“有很大的优化空间”。

证明未涵盖的内容

这些局限性篇幅足够长,足以成为论文中最重要的部分,而且它们被直白地陈述出来。对于 SPQR 的自愈性质,并未建立任何后量子保证——棘轮定理假定攻击者选择 SPQR 密钥。载荷隐私未被证明。对于从未被提升的握手的首条消息,响应方认证未被证明。该模型允许每次提升一个会话、固定消息长度、无多设备状态,以及首次使用信任(TOFU)身份密钥。

还有一个会变得空洞的界。8 字节 MAC 伪造项每次尝试至少为 2⁻⁶⁴,并随消息数和纪元数呈二次增长,这意味着对于大约 25,000 条消息的单个会话,或 2²⁰ 个各含 2¹⁰ 条消息的会话,该界就不再说明任何东西。而且证明的对象是该团队构建的、作为全新进程运行的 libsignal-cli——而不是你手机上的 Signal 应用。若干环境假设只是被非正式地论证,而非被证明。

没有 API,没有价格,也没有可调用的模型

这正是会让任何从模型排行榜而来的人感到失望的部分。AlphaProof Code 是一个研究框架和一套已发布的工件。没有端点,没有按 token 计费的价目表,没有候补名单,也没有权重:仓库里包含的是 Lean 开发、AArch64 语义、libsignal 绑定以及规范,而不是检查点。博客称这些工件已开源;落地页未声明许可证,任何人在计划基于它构建之前都值得核实这一点。

完成这些工作的模型是另一个问题。论文指出证明代理使用的是 G​emini 4 Carbon,并称 Claude Opus 5.5 与其他模型一起用于起草和审查规范。Claude Opus 5.5 目前已在 OrcaRouter 的目录中,价格为每百万输入 token 4 美元、每百万输出 token 20,供应商标价以 0% 加价透传——因此,如果你想要的实际结论是“用论文所用的模型跑一个规范起草循环”,那部分就是一次普通的 API 调用,而供应商调价会在当天落到我们这边。证明代理所用的引擎并非我们所提供的服务,本文任何内容也不意味着我们自行托管 AlphaProof Code。

为什么这比 Signal 的结果影响更大

Signal 验证本身就很了不起——这是首次对广泛部署协议的实现以任何方法(无论是否使用 AI,据 DeepMind 所说)进行形式化验证,也是 AI 首次在如此深度上验证一个已部署的密码协议。但真正可迁移的主张在于工作流程。一个五人团队在四周内,借助规范审查环节和一个智能体把关者,产出了一套证明语料库;这在以前会是一个多年项目。如果这一比例哪怕只是大致成立,能够负担得起验证的系统集合就会改变:医疗设备固件、电网软件,以及目前只能靠代码审查和祈祷的那类代码。

它是否成立尚未经过检验。Signal 的加密技术规范得异常完善,团队还让 Signal 自己的工程师审查了方法论,而底层原语是外包出去的,并未经过验证。下一个系统不会如此配合。论文自身的表述框架——将形式化验证与 CodeMender 这类自动化防御代理搭配——正是这套主张的诚实形态:验证告诉你什么是真的,而必须有别的东西去修复不真的部分。

看什么

有三件事能让它从一篇里程碑式论文变成一项工业化技术。第二个独立代码库,由 Google 之外的人验证,理想情况下其规范必须从零编写,而不是改编自现有分析。一个成本数字——智能体小时、加速器小时、美元——因为“四周和 40 到 80 个智能体组成的团队”不是任何工程经理能用来做预算的单位。还有对计算轨道路径上缺陷的反驳,论文对此留而未决,而这正是系统只能证明性质,与系统还能通过计算告诉你某个特定二进制文件已损坏之间的区别。

在那之前,请阅读工件仓库,而不是公告。证明就在那里,Lean 会检查它们,而论文会确切告诉你它们假设了什么。