Blockstream 研究院发布了一份针对比特币格基签名的完整研究报告，围绕 Dilithium、Falcon 和 Hawk 三种后量子签名方案展开评估，并给出结论：如果现在必须为比特币挑选格基签名方案，团队会选择 Falcon-1024。
报告由 Blockstream Team 撰写，Saoirse、Foresight News 编译。研究聚焦一个长期问题：比特币当前依赖的 Schnorr 与 ECDSA 签名成本很低，但根据 Shor 在 1994 年给出的结果，性能足够强大的量子计算机能够破解这两类签名。因此，在相关威胁真正到来前，需要先准备可行的后量子签名部署方案。
为什么关注格基签名
报告提到，格密码已经有超过一个世纪的研究历史，相关密码学应用发展也接近 30 年。在后量子密码体系里，格基签名被视为替代现有签名机制的热门候选，原因在于它们在尺寸和功能扩展上都有吸引力：公钥与签名的总大小最低可小于 1.6 千字节，代数结构未来还有希望支持多签、门限签名和简洁证明。
这份报告面向不熟悉格密码的读者，除了介绍三种方案的设计思路和算法流程，也从安全性、性能和实际部署条件等角度做了完整比较，包括钱包密钥派生这类与比特币落地直接相关的问题。
比特币评估签名方案的四项标准
报告将评估框架分为四个核心维度。
- 链上成本：公钥与签名在输出花费时都会被写入链上，全节点需要下载并存储这些数据，因此总大小是关键指标。验证速度也很重要，因为每一笔签名都要由全网节点验证。
- 实现复杂度：如果一个方案依赖浮点运算或复杂的高斯采样，代码实现一旦出错，或遭遇计时分析等侧信道攻击，密钥就可能泄露。是否容易做出安全实现，直接影响迁移可行性。
- 部署风险：现实集成还会碰到多种障碍，例如候选方案大多使用 SHAKE，而比特币使用 SHA-256；另外还涉及跨平台签名结果能否复现、签名程序是否符合硬件钱包的内存限制。
- 发展潜力：多数比特币钱包采用 BIP-32 分层确定性机制，通过单个主公钥派生大量子公钥。目前标准化后的后量子签名方案都不原生支持该能力，因此报告特别考察了为这些方案补齐密钥派生所需付出的代价。
安全等级上，报告建议至少采用 3 级
在比较尺寸前，报告先讨论目标安全等级。NIST 将安全等级划分为 1 到 5 级，等级越高，安全性越强，但密钥和签名体积通常也会更大。
报告认为，比特币至少应采用 3 级安全标准。原因在于，比特币输出可能在数十年内都不被花费，如果未来密码分析进展让某个方案的实际安全等级下降，那么这些长期未动用的资产就会暴露在削弱后的安全边界下。
报告指出，格密码假设虽然已经接受近 30 年公开密码分析，但其代数结构依然复杂，未来仍可能出现新的攻击路径，不应把长期安全完全押注在较低安全余量上。
在这一点上，苹果和 Cloudflare 的做法被用作参照。苹果的 iMessage PQ3 协议直接放弃 1 级格密码参数，采用 3 级和 5 级参数；Cloudflare 在后量子 TLS 部署中使用 ML-KEM-768，也就是 3 级参数，并明确表示需要为未来数十年的密码分析预留安全余量。报告认为，比特币面临的安全时间跨度更长。
安全等级提高并非没有代价。报告举例称，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 的验证过程全程使用整数运算，结果确定，而且是候选方案里验证速度最快的。对比特币而言，这种不对称特征很重要：签名只在钱包花费交易时执行一次，但每一笔签名都要由全网全节点验证。报告认为，用低频的签名速度下降，换来跨平台可复现和高效验证，是合理取舍。
Falcon 也有两个现实问题需要注意。第一，它没有 3 级参数，只能在 1 级和 5 级之间选。基于安全余量考虑，报告推荐 Falcon-1024。第二，签名过程会消耗较多内存。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 公钥派生实现，这也是最值得继续研究的问题之一。
Falcon 标准尚未定稿
虽然 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
报告对三种格基候选的排序很明确。Hawk 在遭到 Anthropic 团队攻击后已经退出竞争；Dilithium 的实现难度最低，也是唯一在密钥派生方面已有研究基础的方案，但体积对比特币链上开销并不友好；Falcon 则在体积、验证速度和较成熟的安全假设之间取得了更好的平衡，而它最大的问题——签名端浮点运算——已经存在可行的工程替代路径。
因此，报告给出的直接结论是：如果现在必须为比特币挑选格基签名方案，会选择 Falcon-1024。
不过，就当前阶段而言，研究团队的总体判断与此前哈希基签名报告保持一致：短期内更保守的路线仍是哈希基签名。这类方案的安全假设最成熟、风险最低，更适合作为过渡方案。等到 FN-DSA 正式定稿、规范稳定、代码完成审计、硬件钱包支持成熟后，Falcon 相比纯哈希签名才会体现出更明显的优势；另一种思路则是采用混合部署，让哈希签名与格基签名相互补充。