AlphaProof Code 證明 Signal 的加密正確無誤——達到編譯後二進位檔的層級

六百五十萬行 Lean，在四週內產出，由沒有人類協助撰寫的代理團隊完成。這是 Google DeepMind 於 2026 年 11 月 10 日為 AlphaProof Code 公布的頭條數字；AlphaProof Code 是一套用於形式驗證的代理式框架，該實驗室用它來機器檢查 Signal 協定的密碼學核心——而且不尋常地是在已編譯的 AArch64 二進位檔層級進行檢查，而非其上的設計文件。 執行這項工作的模型則是另一個問題。 一組 API 金鑰，以供應商牌價、0% 加成計費 證明代理的引擎並不是我們提供的服務。

這個框架不是一個你能呼叫的模型。它是一套協作框架（harness）：由人類專家決定哪些條件必須成立，再由多個模型的組合把這些目標轉化成 Lean 規格，接著由一群撰寫證明的代理——部落格稱其引擎為 Gemini Carbon——補齊證明，直到 Lean 的核心（kernel）接受為止。與公告一同發布的，是位於 github.com/google-deepmind/code-verification 的成品集，以及一篇技術論文；這篇論文對成果界線的說明，遠比部落格文章坦率得多。以下大部分內容都來自那篇論文，因為有趣的數字都在論文裡。

究竟實際證明了什麼，又是相對於什麼而證明的？

目標是 libsignal v0.105.4 搭配 spqr v1.6.0，由原版 rustc 1.98.1 建置、靜態連結 musl，並輸出為單一 AArch64 Linux 可執行檔。這個細節比任何基準測試都更重要：這些證明針對的是會在手機上執行的位元組，而不是某個被信任編譯器會忠實轉譯的 Rust 函式。團隊驗證了約 560 KB 的 libsignal 原始碼、約 140,000 條 AArch64 指令，而他們的做法是撰寫指令集的 Lean 模型——包含 467 條指令與 31 個系統呼叫，共 7,578 行——然後證明真實的 ELF 映像在該模型下載入並執行時，仍維持這些安全屬性。

這些性質正是協定工程師會要求的。十個符號定理涵蓋前向保密、遭入侵後安全性、發起者與回應者保密性、身分驗證，以及 PQXDH 定理 1 的五個推論。主要結果名為signal_session_secure_placed。另外還有一條計算性路線，具有具體界限，而且這兩條路線使用不同的對手模型：符號側（Dolev–Yao，透過 DyLean 框架）甚至涵蓋能在握手後破解 Diffie–Hellman 的量子攻擊者，而計算側只涵蓋古典對手。

六百萬行的去向

「超過六百萬行」是部落格的說法，準確但粗略。論文中的細分才是實用的，值得把它當成成本表來讀，而不是當成炫耀。

• 二進位檔的證明 — 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。另有十八個 panic 進入點同樣是假定而非證明。

所以，這個主張並不是「一切都已被證明」。這個主張是：密碼協定邏輯、會話狀態機，以及從該邏輯到實際執行指令的精化，都已被證明；而底層的原語則像每個驗證專案信任其原語那樣被信任。值得注意的是，Rust 編譯器並非位於可信基礎之中——團隊透過在機器碼層級進行推理，避免了需要信任它，這也是讓他們得以完全繞過經驗證編譯器的同一招。作為規模參照，論文引用 seL4 約 20 人年、CompCert 約 6 人年。

兩個 bug，是故意放回去的

一個只會說「正確」的驗證系統是無法測試的。因此，團隊把兩個先前在 Signal 程式碼中發現並修復的漏洞——一個弱狀態錯誤和一個小子群錯誤——重新引入到一份隔離副本中，並重新執行整條流程。在這兩種情況下，AlphaProof Code 都產生了經機器檢查的證明，證明有缺陷的版本不滿足安全性定理：符號陳述化約為 ¬Sec(Asm_bug)。

該論文補充了一個行銷頁面會刪掉的但書：要反駁針對那些錯誤的計算定理「困難得多」，而且仍未被解決。換句話說，負面測試在符號軌道上運作順暢，但在計算軌道上還行不通。這正是讀者在把該框架當作錯誤偵測器之前應該知道的那種不對稱。

代理程式是如何執行的

五位研究人員在四週內各自不間斷地運行代理。證明撰寫本身由 40 到 80 個代理組成的團隊完成，每隊在單一機器上運行 24 到 72 小時，團隊編排器之上還有一名監督代理。一名守門代理會用comparator對照一份保留未公開的規格副本以及 Lean 的核心，檢查每份提交——藉此防範代理證明出某個被巧妙弱化的版本，而非原先所要求的內容。

人工工作主要前置集中在規格上。每份規格都在開始證明工作前由專家審查過，而代理自身的稽核流程標記了約 1% 的程式碼庫需要人工關注。沒有任何人工撰寫證明程式碼。論文對工程層面也直言不諱：一次乾淨建置可能耗費數小時；早期只要小幅編輯原始碼或重新編譯二進位檔，就迫使進行大幅證明修復；而且無論是 AI 生成的證明或證明技術本身，都「還有很大的最佳化空間」。

這些證明並未涵蓋的內容

這些限制的篇幅長到足以成為論文最重要的一節，而且它們被直白地陳述。SPQR 的治癒特性並未建立任何後量子保證——棘輪定理假設攻擊者會選擇 SPQR 金鑰。載荷隱私未被證明。對於從未提升的握手，其第一則訊息未證明回應者認證。此模型允許每次提升僅有一個工作階段、固定訊息長度、無多裝置狀態，以及首次使用即信任的身分金鑰。

還有一個上界會變得空洞。每次嘗試的 8 位元組 MAC 偽造項至少為 2⁻⁶⁴，且會隨訊息數與 epoch 數呈平方成長，這意味著對於單一約 25,000 則訊息的工作階段，或對於 2²⁰ 個各含 2¹⁰ 則訊息的工作階段，該上界就不再說明任何事。而此證明的主體是團隊建置的 libsignal-cli，並以全新行程執行——不是手機上的 Signal 應用程式。有數個環境假設是以非正式方式論證，而非經過證明。

沒有 API、沒有價格，也沒有可呼叫的模型

這是會讓任何從模型排行榜前來的人失望的部分。AlphaProof Code 是一個研究框架，也是一組已發佈的產物。它沒有 API 端點、沒有按 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 會檢查它們，而論文會確切告訴你它們假設了什麼。