比特币如何抵御量子计算机？三种格基签名方案对比

原文作者：Blockstream 团队

原文编译：Saoirse，Foresight News

Blockstream Research 发布了一份关于比特币格基签名的综合研究报告。本文总结了研究内容、主要发现及相关建议。完整报告可在此查阅。

数字签名是授权比特币交易的核心机制，目前使用的 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。Gärtner 在 CRYPTO 2025 上的最新成果基于成熟假设，论文中的尺寸与 Falcon 相当。该家族工程化困难的根源在于实现安全性：BLISS 因非恒定时间高斯采样而被侧信道攻击破解；后续方案尚未完全解决此问题，最新成果也表明保护采样步骤更加困难。在问题解决之前，此类方案仅具有理论吸引力，不适合部署。

格基签名与哈希基签名可以互补。格基签名可以作为混合方案的组成部分。例如，在 SHRINCS 中，无状态恢复路径目前使用数 KB 的 SPHINCS+ 签名；将其替换为 Falcon（或 Falcon-WS）签名将更小且验证更快，显著降低不频繁恢复路径的开销，而不影响日常使用路径。

研究结论

格基候选方案的排名很明确：Hawk 在 Anthropic 团队攻击后退出竞争；Dilithium 实现难度最低，且是唯一具有密钥派生研究基础的方案，但其尺寸对比特币的链上成本不友好；Falcon 结合了紧凑尺寸、快速验证和成熟的安全假设；其主要弱点——签名端的浮点运算——已有可行的工程解决方案。如果今天必须为比特币选择一种格基签名方案，我们会选择 Falcon-1024。

目前，我们的观点与哈希基签名报告一致：保守的短期路线仍是哈希基签名，其安全假设最成熟、风险最低，适合作为过渡方案。一旦 FN-DSA 正式定稿，拥有稳定的规范、经过审计的代码库和硬件钱包支持，Falcon 将带来比纯哈希基签名显著的改进；也可以采用混合部署，让两种签名系统相互补充。