How Bitcoin Can Resist Quantum Computers: A Comparison of Three Major Lattice-Based Signature Schemes
- Core Insight: Blockstream Research evaluated the deployment feasibility of three post-quantum lattice-based signature schemes (Dilithium, Falcon, Hawk) on Bitcoin, concluding that: Hawk has exited the competition due to security flaws, Dilithium is simple to implement but its signatures are too large, and Falcon strikes the best balance among security, size, and verification speed. If deployment is needed today, Falcon-1024 is the recommended choice, but hash-based signatures should still be used as a transitional measure in the short term.
- Key Elements:
- Evaluation criteria: on-chain costs (public key + signature size), implementation complexity (whether floating-point operations are required), deployment risks (hash function compatibility, hardware wallet memory), and development potential (BIP-32 key derivation support). Bitcoin recommends adopting the NIST Level 3 security standard, given that assets may be locked for long periods and cryptanalytic techniques continue to advance.
- Dilithium highlights: fully integer-based operations, lowest implementation difficulty, and already integrated into mainstream cryptographic libraries; ML-DSA-65 has a total size of 5,261 bytes (approximately 55 times that of a native Bitcoin signature), and is the only one of the three with foundational key derivation research (DilithiumRK), but the related variants have not yet reached deployable standards.
- Falcon advantages: smallest size (Falcon-1024 totals 3,073 bytes), fastest verification speed, and deterministic integer operations; its drawback is that the signing side requires floating-point sampling, which can be solved through integer emulation (at the cost of signing being 15x slower), and its standard (FN-DSA) is not yet finalized, with no viable BIP-32 derivation scheme currently available.
- Hawk's failure: once notable for its 555-byte minimal signature and fully integer operations, it was discovered by the Anthropic team to have a structural flaw (halved SVP dimension) just before finalization, severely weakening key recovery security. It has been withdrawn from the NIST process, reflecting the necessity of choosing conservative security levels.
- Hybrid scheme potential: lattice-based signatures (such as Falcon) can complement hash-based signatures, serving in stateless recovery paths like SHRINCS, significantly reducing size and speeding up verification without affecting the daily operational path.
原文作者：Blockstream Team
原文編譯：Saoirse，Foresight News
Blockstream 研究院發布了一份針對比特幣格基簽名的完整研究報告。本文對研究內容、核心發現以及相關建議進行總結，完整報告可點擊查閱。
數位簽名是比特幣授權交易的核心機制，如今承擔該功能的 Schnorr 與 ECDSA 簽名成本極低。1994 年 Shor 證明，一台性能足夠強大的量子計算機就可以破解這兩類簽名。雖然這類機器何時能夠問世仍存在廣泛討論，但我們需要在問題真正到來之前，就制定一套可行的後量子簽名部署方案。
格基簽名方案是替代現有簽名的熱門候選。格密碼已有超過一個世紀的研究歷史，其密碼學應用也發展了近三十年。在後量子密碼體系中，格基簽名具備諸多優勢：公鑰與簽名的總尺寸最低可小於 1.6 千字節，同時其代數結構未來有希望支持多籤、門限簽名以及簡潔證明。
本報告研究了 Dilithium、Falcon、Hawk 三種方案。面向不瞭解格密碼的讀者，我們闡述各方案的設計思路，完整介紹算法流程，並從安全性、性能、實際部署（例如錢包密鑰派生）等維度展開分析。三者之中，究竟哪些方案可以真正部署到比特幣鏈上？
評估維度
比特幣對簽名方案的選型有著自身約束，本次評估圍繞四項核心標準展開：
- 鏈上成本：最重要指標之一為公鑰與簽名的總大小。輸出被花費時，公鑰和簽名都會記錄在鏈上，全節點需要下載並存儲每一個字節。驗證開銷同樣關鍵：每一筆簽名都要經過全網節點驗證，驗證速度慢會給整個網絡帶來負擔。
- 實現複雜度：方案能否安全實現至關重要。如果設計需要浮點運算或者精細的高斯採樣，一旦實現出錯，或是遭遇計時分析這類側信道攻擊，就可能洩露密鑰。想要實現平穩遷移，實現複雜度是不可忽視的因素。
- 部署風險：比特幣實際集成時還會遇到各類現實阻礙：共識層面的哈希函數選型（候選方案大多使用 SHAKE，比特幣使用 SHA‑256）、跨平台簽名結果的可重現性，以及簽名程序是否適配硬件錢包的內存限制。
- 發展潛力：絕大多數比特幣錢包採用 BIP‑32 分層確定性機制：通過單個主公鑰，無需接觸私鑰，就可以衍生出無窮多子公鑰。目前標準化的後量子簽名方案都不原生支持該特性，因此我們研究為其補充該能力所要付出的代價；同時也考察各類非標準的方案變體，它們或許能帶來更多收益。
應當選擇何種安全等級？
對比尺寸之前，先要確定目標安全等級，該選擇並沒有看上去那麼簡單。NIST 將安全等級劃分為 1‑5 級；等級越高安全性越強，但對應的密鑰與簽名體積也會更大。
我們認為比特幣至少應當採用 3 級安全標準。比特幣輸出可能數十年不被花費，如果密碼分析技術進步導致方案實際安全等級下降，資產就會被削弱後的密鑰鎖定，長期暴露在風險之下。格密碼假設已經經受了近三十年公開密碼分析，對比特幣採納橢圓曲線時的研究積澱還要更久。但格密碼複雜的代數結構，仍存在不少可供未來攻擊利用的突破口，我們不應當把遙遠未來的安全賭注全部押在上面。
各大主流產品也做出了相同判斷。蘋果的 iMessage PQ3 協議直接捨棄 1 級格密碼參數，全程使用 3 級與 5 級參數；Cloudflare 在後量子 TLS 部署中使用 ML‑KEM‑768（3 級），表示雖然 1 級目前看起來安全，但需要為未來數十年的密碼分析預留安全餘量。而比特幣的安全時間跨度比以上兩者還要更長。
提升安全等級是需要付出代價的。舉例來說，Dilithium 從 2 級提升至 3 級，總大小會增加約 1.5 千字節。報告對比了全部安全等級下的參數集，讀者可以自行權衡取捨。Hawk 的遭遇證明，保守的安全考量絕非紙上談兵。
候選方案詳解
Dilithium：設計簡潔的方案
Dilithium 被 NIST 標準化為 FIPS 204 標準中的 ML‑DSA，它將 Schnorr 簽名的承諾‑挑戰‑響應範式，遷移到模塊格算術之上。
它最大的特點是簡潔。Dilithium 全部運算均為整數運算：環運算、矩陣向量乘法、哈希、取整，沒有浮點運算，也不需要離散高斯採樣。更容易編寫出安全、恆定時間的實現。它也是落地最廣泛的候選方案，已經集成進 OpenSSL、BoringSSL、AWS‑LC 以及 Apple CryptoKit。
代價是體積偏大。3 級安全的 ML‑DSA‑65，公鑰 1952 字節，簽名 3309 字節，合計 5261 字節，約為比特幣原生公私鑰 + 簽名總大小的 55 倍，在同安全等級的三個方案中體積最大。
對比特幣而言 Dilithium 最有價值的一點：它是三者中唯一一個接近實現 BIP‑32 風格密鑰派生的方案。可重隨機化密鑰構造 DilithiumRK，僅依靠公開信息就可以由父密鑰生成子密鑰。報告分析了三種變體，其中包含我們提出的 DilithiumRKS，派生邏輯完全放在錢包軟件內部，鏈上只需要標準驗證器處理普通 ML‑DSA 簽名。但三者均尚未達到上線標準：其中兩種變體需要修改驗證器，DilithiumRKS 本身還缺少完整的不可偽造性證明；全部方案都依賴全網共用的矩陣，雖然在 Module‑LWE 假設下形式上安全，但會把所有密鑰的安全綁定到同一個實例上。我們認為現階段基於 Dilithium 的公鑰派生僅屬於概念驗證，無法投入實際部署。
Falcon：體積緊湊的方案
Falcon 被 NIST 選定，標準化名稱為 FN‑DSA，三者之中它最為精簡。1 級安全的 Falcon‑512 公鑰加簽名合計 1563 字節；5 級安全的 Falcon‑1024 合計 3073 字節。安全餘量更高的 Falcon‑1024，體積甚至小於 3 級的 Dilithium。
Falcon 採用與 Dilithium 不同的思路：基於 NTRU 格的哈希‑簽名模式。簽名者的私鑰是格的一組短基；消息被哈希映射到空間中的一個點，簽名者利用短基找到格上距離該點很近的向量。點與該鄰近向量共同構成簽名；驗證僅校驗向量屬於該格，並且距離足夠近。實現難點在於尋找向量的同時不能洩露基的信息。早期方案 GGH、NTRUSign 直接就近取格點，每一次簽名都會洩露一部分幾何信息。Falcon 採用 GPV 框架，從高斯分佈中採樣鄰近向量，可證明採樣輸出與基相互獨立，消除洩露風險，但採樣器的實現難度大幅提升。
採樣器是 Falcon 工程層面的短板。它在複數傅里葉域運算，需要浮點計算。不同處理器、編譯器、編譯優化選項，都會造成浮點輸出結果不一致。這不只是兼容性問題，更是安全隱患：GPV 安全證明要求，對同一摘要，簽名者絕不輸出兩組不同的短向量；一旦簽名變為確定性簽名，平台帶來的浮點捨入差異就會破壞該條件。存在可行的解決辦法：確定性 Falcon 可以用整數模擬替代硬件浮點，在所有平台輸出完全一致的簽名。代價是簽名速度下降約 15 倍，密鑰生成速度下降約 2 倍。
重要的是，驗證環節不受影響：Falcon 驗證全程整數運算、結果確定，同時也是候選方案中驗證速度最快的。這種不對稱特性對比特幣十分友好：簽名由錢包在花費交易時執行一次，而每一筆簽名都要被全網全節點驗證。簽名環節慢 15 倍屬於低頻開銷，換來跨平台可重現、整數運算，在我們看來是合理取捨。因此浮點問題屬於可以通過工程手段解決的障礙，而非致命缺陷。
兩點注意事項：受結構約束，Falcon 沒有 3 級參數，只能選擇 1 級或者 5 級。基於安全餘量考量，我們推薦 Falcon‑1024。第二點，簽名會消耗大量內存：1024 參數集的採樣器依賴預計算樹，佔用約 90 千字節內存。硬件錢包可以逐分支動態重建該樹，把內存佔用壓縮至 16 千字節，但簽名耗時會翻倍。硬件設備簽名變慢是實際成本，但尚可接受。
Hawk：宣告失敗的方案
Hawk 的目標是融合另外兩套方案的優勢：Hawk‑512 簽名僅有 555 字節，比 Falcon 體積更小；簽名端全部整數運算，最低內存佔用僅 6 千字節。它也是 NIST 附加簽名競賽第三輪中唯一留存的格基候選，報告中用大量篇幅介紹該方案。
代價在於安全假設。它沒有沿用經過數十年密碼分析檢驗的 NTRU、SIS 問題，而是依賴格同構問題以及 one‑more‑SVP 假設，這兩類假設研究歷史相對較短。
就在報告定稿前夕，Anthropic 的 Straznickas 和 Weis 發現 Hawk 格構造存在結構性缺陷：密鑰恢復實際需要求解的 SVP 問題維度，只有設計者設想的一半。候選參數集的密鑰恢復安全位被大幅削弱。研究者針對用於密碼分析的挑戰參數 HAWK‑256 完成完整端到端密鑰恢復攻擊；即便遭受攻擊，正式提案的 HAWK‑512、HAWK‑1024 依舊無法被現實攻破。Hawk 團隊確認攻擊有效，並將方案從 NIST 流程撤回；團隊表示，如果通過翻倍參數修復漏洞，Hawk 原本引以為傲的體積優勢就會徹底消失。
報告依舊保留 Hawk 相關章節，因為該攻擊針對特定數域的代數特性，並非全盤否定這套設計範式。重新設計是否能夠規避漏洞，尚無定論。Hawk 事件也直觀印證了我們堅持保守安全餘量的理由：一個方案即便體積優秀、速度可觀，並且走完標準化多輪流程，一篇論文就可以使其預估安全等級大幅下降。
各方案對照表
上表所有方案（包括 SPHINCS+）均為無狀態簽名：簽名者無需記錄過往簽名。XMSS 這類有狀態哈希簽名可以做到簽名尺寸更小，但需要維護簽名狀態；可查閱哈希基簽名專題報告了解對比。
落地仍存諸多阻礙
Falcon 缺少可用的密鑰派生方案。目前公開唯一一套 BIP‑32 風格 Falcon 派生方案，會對私鑰基做重隨機化，簽名範數上限被急劇放大，鏈上簽名膨脹至約 23.7 千字節。並且該方案的參數達不到自身安全條件，如果修復該問題，體積會進一步暴漲。目前沒有可行的 Falcon 公鑰派生實現，也是報告提出最有價值的待解決問題。
Falcon 標準尚未定稿。NIST 雖然選定 Falcon，但 FN‑DSA 草案還未正式發布。標準化完成之後，才會帶來經過審計的實現、測試向量與硬件層面支持。廣泛落地能夠降低比特幣共識層集成的風險與難度。我們建議等待 FN‑DSA 正式發布，在此之前 Falcon 仍處於變動狀態。
Falcon‑WS 變體：該變體放寬內部參數，依靠拒絕採樣做補償，1 級總大小壓縮至 1114 字節，5 級壓縮至 2387 字節，相比原版 Falcon 體積進一步下降。該方向具備研究價值，但不會納入官方標準，需要更多密碼分析驗證。已有研究發現其衍生方案的強不可偽造性證明存在漏洞（普通不可偽造性不受影響）。
未來是否會出現更優秀的方案？除去上述方案，Fiat‑Shamir 系列最早源自 2013 年的 BLISS，CRYPTO 2025 會議 Gärtner 提出的最新成果，基於成熟假設，紙面尺寸可以比肩 Falcon。該系列難以工程落地的根源在於實現安全問題：BLISS 就曾經因為高斯採樣非恆定時間遭到側信道破解；後續方案均沒有徹底解決該隱患，最新成果也提示採樣環節防護難度更高。在問題解決之前，這類方案只具備理論吸引力，不適合部署。
格基簽名與哈希簽名可以互補。格基簽名可以作為混合方案的組件。例如 SHRINCS 中，無狀態恢復路徑目前使用數 KB 大小的 SPHINCS + 簽名；替換為 Falcon（或 Falcon‑WS）簽名，體積更小、驗證更快，低頻的恢復路徑開銷大幅降低，日常使用路徑不受影響。
研究結論
格基候選方案的優劣排序十分明確：Hawk 遭 Anthropic 團隊攻擊後退出競爭；Dilithium 實現難度最低，也是唯一擁有密鑰派生相關研究基礎的方案，但體積對於比特幣鏈上開銷並不友好；Falcon 兼顧緊湊體積、快速驗證、成熟安全假設；它最主要的短板 —— 簽名端浮點運算，已經存在可行的工程解決方案。如果現在必須為比特幣挑選格基簽名方案，我們會選擇 Falcon‑1024。
就當下而言，我們的觀點與哈希基簽名報告保持一致：短期保守路線依舊是哈希基簽名，安全假設最為成熟，風險最低，適合作為過渡方案。待 FN‑DSA 正式定稿，擁有穩定規範、審計過的代碼庫、硬件錢包支持之後，Falcon 相比純哈希簽名會帶來顯著提升；也可以採用混合部署，讓兩類簽名體系互相補充。
