Blockstream 研究院发布了一份针对比特币格基签名的完整研究报告，对 Dilithium、Falcon、Hawk 三种后量子签名方案进行了系统比较，并给出部署建议。报告由 Blockstream Team 撰写，Saoirse 为 Foresight News 编译。
报告指出，数字签名是比特币授权交易的核心机制，当前使用的 Schnorr 与 ECDSA 签名成本很低。但自 1994 年 Shor 证明足够强大的量子计算机可以破解这两类签名后，比特币长期安全模型就必须考虑后量子迁移问题。虽然这类量子计算机何时出现仍有争议，但报告认为，相关部署方案需要在风险真正到来之前就准备好。
为什么关注格基签名
报告把格基签名列为现有签名机制的重要候选替代方案。文中提到，格密码已有超过一个世纪的研究历史，用于密码学也发展了近三十年。在后量子密码体系中，格基签名的一个主要优势是公钥与签名总尺寸最低可以小于 1.6 千字节；同时，其代数结构在未来还有机会支持多签、门限签名和简洁证明。
这份研究面向不了解格密码的读者，介绍了三种方案的设计思路和算法流程，并从安全性、性能、实际部署能力以及钱包密钥派生等角度评估它们是否适合真正部署到比特币链上。
比特币评估签名方案的四项标准
报告称，比特币对签名方案的选择有自身约束，这次评估围绕四个核心维度展开。
链上成本
最关键的指标之一，是公钥与签名的总大小。因为输出被花费时，这两部分都会写入链上，全节点需要下载并存储每一个字节。验证开销也同样重要，每一笔签名都需要由全网节点验证，验证越慢，网络负担越重。
实现复杂度
方案能否被安全实现，是报告反复强调的重点。若设计依赖浮点运算或者精细的高斯采样，实现出错或遭遇计时分析等侧信道攻击时，都可能泄露密钥。报告认为，想让比特币平稳迁移，实现复杂度不能被忽视。
部署风险
在真正集成到比特币时，还会遇到共识层哈希函数选型、跨平台签名结果可复现性、以及硬件钱包内存限制等现实问题。报告举例称，多数候选方案使用 SHAKE，而比特币使用 SHA-256，这类差异都会增加部署难度。
发展潜力
绝大多数比特币钱包采用 BIP-32 分层确定性机制。通过单个主公钥，在不接触私钥的情况下可以衍生出无穷多子公钥。报告指出，目前标准化的后量子签名方案都不原生支持这一能力，因此研究重点之一，就是考察补上这项能力需要多大代价，以及一些非标准变体是否能提供额外收益。
安全等级为何至少要选 3 级
在比较尺寸前，报告先讨论了目标安全等级。NIST 将安全等级划分为 1 至 5 级，等级越高，安全性越强，但密钥与签名也会更大。
Blockstream 研究团队认为，比特币至少应采用 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。报告称，在三种方案中，Falcon 的体积最精简。1 级安全的 Falcon-512，公钥加签名总计 1563 字节；5 级安全的 Falcon-1024，总计 3073 字节。报告特别指出，安全余量更高的 Falcon-1024，体积甚至仍小于 3 级的 Dilithium。
在设计上，Falcon 走的是另一条路径：它基于 NTRU 格的哈希签名模式。签名者的私钥是一组短基，消息被哈希映射为空间中的一个点，签名者再利用短基找到格上距离该点很近的向量。这个点与其邻近向量共同构成签名，验证则只需检查该向量属于对应格且距离足够近。
报告指出，真正的难点在于，寻找邻近向量的过程不能泄露基的信息。早期方案 GGH 与 NTRUSign 直接选择最近格点，每次签名都会暴露一部分几何信息。Falcon 使用 GPV 框架，通过高斯分布采样邻近向量，从而在理论上保证采样输出与基相互独立，消除泄露风险，但这也使采样器实现变得复杂得多。
采样器正是 Falcon 在工程层面的主要短板。其运算发生在复数傅里叶域，需要浮点计算。不同处理器、编译器和编译优化选项，都会造成浮点输出结果不一致。报告认为，这不仅是兼容性问题，也是安全问题：GPV 的安全证明要求对同一摘要不能输出两组不同的短向量，一旦签名变成确定性签名，平台带来的浮点舍入差异就会破坏这一前提。
报告同时指出，已有可行的工程解决办法。确定性 Falcon 可以用整数模拟代替硬件浮点，使所有平台输出完全一致的签名。代价是签名速度下降约 15 倍，密钥生成速度下降约 2 倍。
研究团队仍认为，这是比特币可以接受的代价。原因在于验证环节不受影响：Falcon 的验证过程全程采用整数运算，结果确定，而且是几种候选方案中验证速度最快的。报告称，这种非对称特性对比特币较为有利，因为签名只在钱包花费交易时执行一次，而每笔签名都要由全网全节点验证。签名端慢 15 倍属于低频成本，换来跨平台可复现和整数运算，属于合理取舍。因此，浮点问题被定义为可通过工程手段解决的障碍，而不是致命缺陷。
不过，报告也列出两点注意事项。第一，受结构限制，Falcon 没有 3 级参数，只能在 1 级和 5 级之间选择。基于安全余量考虑，报告推荐 Falcon-1024。第二，Falcon 的签名会消耗较多内存。1024 参数集的采样器依赖预计算树，占用约 90 千字节内存。硬件钱包可以通过逐分支动态重建该树，把内存占用压缩到 16 千字节，但签名耗时会翻倍。报告认为，这会带来实际成本，但仍在可接受范围内。
Hawk：已因攻击退出竞争
Hawk 原本试图结合另外两种方案的优点。报告给出的数据是，Hawk-512 的签名只有 555 字节，比 Falcon 更小；签名端全程整数运算，最低内存占用只有 6 千字节。它也是 NIST 附加签名竞赛第三轮中唯一保留下来的格基候选，因此报告原本给予了较大篇幅介绍。
但其代价在于安全假设不够成熟。Hawk 没有沿用经过数十年密码分析检验的 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 公钥派生实现，这也是最值得继续研究的问题之一。
FN-DSA 标准尚未定稿
NIST 虽已选定 Falcon，但 FN-DSA 草案还没有正式发布。报告认为，只有标准化完成后，经过审计的实现、测试向量和硬件支持才会逐步完善，而这些都能降低比特币在共识层集成该方案的风险与难度。因此团队建议，在 FN-DSA 正式发布前保持等待，现阶段 Falcon 仍处于可能变化的状态。
Falcon-WS 变体具研究价值，但不在官方标准内
报告还提到 Falcon-WS 变体。该方案通过放宽内部参数，并以拒绝采样作补偿，把 1 级总大小压缩到 1114 字节，5 级压缩到 2387 字节，比原版 Falcon 进一步缩小。研究团队认为，这个方向值得继续研究，但它不会纳入官方标准，还需要更多密码分析验证。现有研究已发现其衍生方案的强不可伪造性证明存在漏洞，不过普通不可伪造性不受影响。
新方案未必适合直接部署
报告也讨论了未来是否会出现更优方案。除前述方案外，Fiat-Shamir 系列最早可追溯到 2013 年的 BLISS。文中提到，CRYPTO 2025 会议上 Gärtner 提出的最新成果基于较成熟的假设，纸面尺寸可以接近 Falcon。
不过，研究团队认为，这一系列长期难以工程落地的根本原因仍是实现安全。BLISS 曾因高斯采样不是恒定时间而遭到侧信道破解，后续方案也没有彻底解决这一风险；最新成果甚至提示采样环节的防护难度更高。在这些问题被解决前，这类方案只具理论吸引力，不适合部署到比特币中。
格基签名也可与哈希签名结合
报告没有把格基签名和哈希签名视为二选一。研究团队提出，格基签名可以作为混合方案的组成部分。例如在 SHRINCS 中，无状态恢复路径目前使用的是数 KB 大小的 SPHINCS+ 签名；若替换成 Falcon 或 Falcon-WS，体积会更小、验证会更快，低频恢复路径的成本也会明显下降，而日常使用路径不受影响。
研究结论：若现在必须选，倾向 Falcon-1024
在最终结论部分，Blockstream 给出的排序较为明确。Hawk 在遭 Anthropic 团队攻击后已经退出竞争；Dilithium 的实现难度最低，也是唯一在密钥派生研究上有一定基础的方案，但链上体积对比特币并不友好；Falcon 则在紧凑体积、快速验证和较成熟安全假设之间取得了更平衡的表现，而它最大的短板——签名端浮点运算——已经存在可行的工程解决路径。
报告写道，如果现在必须为比特币选择一种格基签名方案，团队会选择 Falcon-1024。
不过，就当前阶段而言，Blockstream 的总体看法仍与其哈希基签名报告一致：短期更保守的路线仍然是哈希基签名，因为其安全假设最成熟、整体风险最低，更适合作为过渡方案。待 FN-DSA 正式定稿，并具备稳定规范、经过审计的代码库和硬件钱包支持后，Falcon 相比纯哈希签名预计会带来更明显的改进；也可以采用混合部署方式，让两类签名体系互补。