本文作者：Mysten Labs，Kostas Chalkias 与 Mahdi Sedaghat
https://www.sui.io/blog/suis-post-quantum-signature-schemes
要点总结
Sui 选择的是 NIST Level 3 的 ML-DSA-65，而不是成本更低的安全级别。如今，AI 辅助密码分析已经能够攻破一些经受多年人工审查的格基密码方案，而选择更高安全余量所增加的成本几乎可以忽略：ML-DSA-65 的验证性能与 Ed25519 基本相当。
两种方案，来自两个不同的数学体系。 SLH-DSA 金库运行在 Move 中，而非协议层，因此即使格基密码出现突破，也不会影响基于哈希的安全路径；同时，Sui 还能在无需协议升级的情况下适应外部标准的变化。
现有用户不会受到影响。 私钥仍保持 32 字节，因此钱包备份方式无需改变。后量子账户采用自愿选择模式，地址别名允许现有账户在保留原地址和资产的同时，将授权密钥切换为抗量子密钥。
在最近发布的《Sui 正在为量子时代做准备》一文中，我们介绍了 Sui 在后量子安全方面的发展方向：使用 ML-DSA-65 进行原生账户认证，使用 SLH-DSA-SHA2-128s 保护高价值金库，同时提供一条能够保留现有地址和恢复短语的迁移路径。
而这篇文章要讲的是背后的“为什么”，并从密码学家的角度深入解释这些选择。为什么选择 ML-DSA-65，而不是成本更低的安全等级？为什么尽管 Falcon 的签名更小，我们仍没有选择它？为什么 SLH-DSA 被放在智能合约中，而不是协议层？为什么我们没有直接采用现有库，而是自己编写了 Rust 封装实现？在这个过程中，我们又发现了什么？如果你读完上一篇文章后想知道这些决策背后的技术逻辑，这篇文章就是答案。
这些决策真正的难点，其实并不在于选择哪种算法。NIST 几年前就已经基本解决了这个问题。对于签名来说，候选范围实际上只有两个：ML-DSA（FIPS 204）和 SLH-DSA（FIPS 205）。真正需要大量工作的，是之后的一系列问题：选择哪个安全等级、采用哪种实现、如何验证代码、如何处理已经存在的密钥，以及哪些技术上看似诱人的捷径最终决定不采用。
先介绍一下我们的背景。我们在后量子系统上的研究早于 Sui 多年：2017 年在 R3 的 Corda 中推出生产级无状态后量子方案，这是分布式账本领域首个无状态、可多次使用的抗量子签名；随后几年与 Mike Hearn 研究适用于区块链的后量子密码结构；在 Meta 构建 Winterfell——首个开源 STARK 证明器；以及对 PQ-EdDSA、HashWires 和 Truncator 的研究。
针对 Sui 的具体迁移策略，我们早在 2025 年 4 月发布的《如何在量子计算时代保障 Sui 的安全性》中，就从签名、哈希、加密和零知识证明等方面进行了规划。下面介绍的是其中的签名部分，如今相关决策已经最终确定。
准确定义威胁
Shor 算法可以直接破解 RSA 和椭圆曲线密码学。 Grover 算法对哈希函数只能带来平方级加速，而增加哈希输出长度即可抵消这种影响。因此对于区块链来说，量子风险几乎全部集中在签名上，而不是哈希。
区块链的特殊之处并不在算法本身，而在于公钥的暴露方式。在大多数系统中，公钥位于某种访问边界之后，攻击者必须先突破系统，攻击倒计时才真正开始。但在链上，账户完成第一笔交易时，公钥就会被永久公开。与“现在收集、以后解密”类似，针对签名的攻击甚至不需要现在就拥有量子硬件，只需要存储数据和耐心等待：今天收集公开密钥，等未来量子硬件成熟后再伪造签名。这个收集窗口几年前就已经打开，而且量子计算能力的预测一直在朝着同一个方向变化Google 对分解 2,048 位 RSA 密钥所需资源的估算，从 2019 年的约 2,000 万个量子比特下降到 2025 年的不足 100 万个。每一次修正，都意味着所需机器变得更小、更便宜，而不是更昂贵。
这也重新定义了迁移期限。美国在 2026 年 6 月发布的第 14412 号行政命令中，要求联邦机构在 2030 年 12 月前完成后量子密钥建立迁移，并在 2031 年 12 月前完成数字签名迁移，这比 NIST 仍处于草案阶段的 2035 年迁移时间表更早。而对于链上密钥来说，实际期限还要更早，因为风险是向过去累积的：一个第一天就公开的密钥，从第一天开始就已经处于暴露状态，而不是等截止日期到来时才开始暴露。
为何选择 ML-DSA-65，而不是 ML-DSA-44
NIST 将后量子方案划分为五个安全等级。每一级都对应一个暴力破解基准，而不是抽象的安全位数：
Level 1：破解难度至少相当于恢复 AES-128 密钥
Level 3：相当于 AES-192
Level 5：相当于 AES-256
偶数等级则根据哈希碰撞定义：Level 2 对应 SHA-256，Level 4 对应 SHA-384。
ML-DSA 提供三组参数：
ML-DSA-44：Level 2
ML-DSA-65：Level 3
ML-DSA-87：Level 5
一个安全等级代表的是当前已知最佳攻击方式之下的安全底线。因此选择哪个等级，本质上是在回答一个问题：如果未来最先进的攻击方法进一步改善，我们需要留下多大的安全余量？
Sui 最终选择将 Level 3 的 ML-DSA-65 集成为协议原生签名方案，而不是成本更低的 ML-DSA-44。
其中一个重要原因，是 Anthropic 最近发现的针对 HAWK 签名方案的攻击。HAWK 是一个经过深入研究、接受过大量密码分析审查的格基密码方案。需要强调的是，HAWK 与 ML-DSA 基于不同的格问题，因此针对 HAWK 的攻击并不能直接应用于 ML-DSA。但真正值得关注的是它带来的启示：AI 辅助密码分析已经开始发现那些经过人类多年审查仍未被发现的问题。
这改变了我们应该为格基密码假设保留多少安全余量的判断。Level 1 在安全估算发生变化时留下的空间较小，而 Level 3 提供了更大的缓冲，而且事实证明，这部分额外安全余量带来的成本非常小。
还有两个次要原因。首先，Chrome 和 Cloudflare 在目前已经保护大量 Web 流量的后量子密钥交换中，也选择了 Level 3，因此这个等级已经拥有更多实际部署经验。其次，在与受监管金融行业讨论密钥建立机制时，Level 3 也更符合这些机构的安全预期。
硬件支持也是我们考虑的重要因素。我们直接针对 HSM 和硬件钱包厂商 SDK 验证了 FIPS 204 兼容性。我们还在超低功耗的 DePIN 级设备上测试了 ML-DSA，这类设备代表 NFC 后量子钱包所面临的受限 CPU 和 RAM 环境，也是算法过于沉重时最先暴露问题的场景。
整个生态也正在趋向类似选择。Ledger 最近已经在其 SDK 中加入官方 ML-DSA（FIPS 204）的初步支持，并与 NIST 标准逐位兼容。我们也验证了 Ledger 与我们的实现之间能够双向完成签名互操作。
与此同时，我们还在持续监控针对 ML-DSA 的密码分析进展。这种持续存在的不确定性，也是我们优先将 SLH-DSA 作为智能合约方案推出，并推荐用于高价值金库的原因之一：它的安全性依赖于哈希函数，而不是格基密码。因此，即使未来出现影响 ML-DSA 安全估算的格基密码研究突破，也不会影响 SLH-DSA。
为什么没有选择 Falcon？
另一个格基候选方案是 Falcon（FN-DSA，即未来的 FIPS 206），它最大的优势是签名更小。FN-DSA-512 在 Level 1 下的签名大小仅为 666 字节，而 Level 3 的 ML-DSA-65 签名大小为 3,309 字节。
尽管如此，我们仍然没有选择 Falcon，原因包括：
没有 Level 3。 Falcon 仅提供 Level 1 和 Level 5 两个安全等级（分别为 FN-DSA-512 和 FN-DSA-1024）：要么选择我们刚刚提到的、余量较小的 Level 1，要么为了获得更大的安全缓冲而承担 Level 5 的成本，而后者会使各项指标大约翻倍。
尚未完成标准化。 FIPS 206 目前仍未最终定稿；相比之下，FIPS 204 自 2024 年起就已经正式定稿。
缺乏标准化的种子到密钥派生方式。 这会破坏目前能够让钱包备份方式保持不变的 32 字节种子特性。
浮点高斯采样。 Falcon 在签名过程中，需要使用浮点 FFT 运算进行离散高斯采样，而这套机制普遍被认为比 ML-DSA 所需的任何实现都更难正确完成。相比之下，ML-DSA 从头到尾都采用整数运算。
安全实现难度更高。 在高斯采样机制下，要确保恒定时间执行、抵御故障攻击和缓存攻击，以及保证随机数质量，都有更高的实现要求。
侧信道防护更加困难。 由于涉及高斯采样和 FFT 运算，普遍认为 Falcon 在抵御时序攻击、缓存攻击和故障攻击方面，比 ML-DSA 更难做到安全可靠。
验证速度。 在更高安全等级下，Falcon 的验证速度慢于我们的 ML-DSA 测试结果。具体来说，在同一台机器上，FN-DSA-1024 的验证时间为 49.8 微秒，而 ML-DSA-65 仅为 23.2 微秒。也就是说，在具备足够安全余量的情况下，Falcon 参数集的验证速度大约比我们选择的方案慢 2 倍。
硬件生态。 许多 HSM 厂商、智能卡、TPM 和安全元件都优先支持 ML-DSA：它更早完成标准化、更容易实现，同时也是企业客户重点要求支持的方案。根据我们获得的反馈，Falcon 的硬件支持正在改善，但普及程度仍然不及 ML-DSA。
最后同样重要的是生态与工具。 目前，ML-DSA 在密码库、SDK、测试向量、合规套件以及经过认证的实现等方面都更加成熟。这能够降低工程实现风险，尤其是在将其作为协议原生功能时。
因此，更小的签名大小不足以抵消这些缺点。
为什么 SLH-DSA 运行在 Move，而不是协议层
对于高价值资产，我们通过 Move 智能合约金库提供基于哈希的 SLH-DSA-SHA2-128s（FIPS 205），而不是将其作为协议原生签名方案。这并不是因为我们不信任 SLH-DSA。恰恰相反。基于哈希的密码学是两个体系中理解得更加充分的一类，SHA-256 也已经被广泛应用。我们咨询的一些硬件钱包团队甚至更偏爱基于哈希的方案，因为工程师对它们的理解更加深入。
之所以将其放在合约中，主要有三个原因：
成本特征。 SLH-DSA 的验证成本明显高于 Ed25519，而且其签名体积较大，无法通过缓存有效降低开销。对于 ML-DSA 来说，公钥是可以重复使用的部分，因此缓存能够带来明显收益；而 SLH-DSA 没有类似的优化空间。
标准变化风险。 Bitcoin、Ethereum 以及下一轮 NIST 标准很有可能最终收敛到比目前更少的一组签名方案。无论 Bitcoin 和 Ethereum 社区最终选择哪种方案，包括目前正在讨论的各种基于哈希的方案，我们都希望能够快速实现兼容。Sui 与 Ethereum 的桥，以及面向 Bitcoin 的 Hashi，让这一需求更加实际：如果采用合约内实现，那么在 Sui 上支持兼容后量子密码的 Bitcoin 钱包，无需发布新的 Sui 核心版本；如果采用原生方案，那么每当外部目标标准发生变化时，都可能需要进行一次协议升级。
实现范围。 在 Move 中实现 SLH-DSA，主要涉及 Merkle 树相关操作，相比新增一个原生认证器，其实现范围更小、代码也更清晰易懂。同时，它无需通过分叉或协议升级即可上线，因为所需的字节处理和哈希原语已经存在于 Move 语言中。
这两种方案建立在不同的数学体系之上，而这正是设计的关键所在。如果格基密码的安全假设被攻破，并不会影响基于哈希的安全路径，反之亦然。
对于最高价值的账户，Sui 现有的 2-of-2 多签机制还允许用户同时要求一个传统签名和一个后量子签名才能授权交易，因此任何一种方案都不会单独成为安全体系中的单点故障。这也正是近期由 Bernstein 发起的讨论中所主张的混合安全方案。
这两种方案都遵循 NIST 标准化的后量子密码算法（ML-KEM、ML-DSA、SLH-DSA），以及 CISA、NSA 和 NIST 联合制定的量子安全准备路线图。
性能测试
上述选择最终都离不开成本。我们通过 fastcrypto 在 Apple M2 Max 上进行了测试。
这里真正重要的是两点。
验证性能与 Ed25519 基本持平，实际上还略胜一筹，因此验证节点处理每个签名所需的 CPU 成本并不会增加。这一点非常重要，因为 Sui 是全球速度最快的 L1 之一，即使完成后量子迁移，也必须继续保持这一领先优势。真正重要的指标是验证成本，因为不同环节的计算成本发生在不同位置：密钥生成和签名针对每笔交易在链下进行，由签名者自己的设备完成；而验证则需要每个验证节点对每笔交易执行。从绝对数值来看，签名速度确实更慢，但在客户端设备上仅需约 66 微秒，即使在浏览器中也只是毫秒级，用户基本感受不到这种差异。
私钥仍然保持 32 字节，因为它本质上是一个种子。钱包可以继续按照现在完全相同的方式进行备份和恢复，而新的密钥则通过一条新的标准派生路径，从用户现有的同一恢复短语中生成。
真正需要付出的代价是数据体积：每笔交易的相关数据大约会增加到原来的 50 倍。这是整个行业为了获得抗量子能力都需要承担的成本，也是我们目前优化工作的重点。不过，对于 Sui 来说，有两个因素可以缓解这一问题。首先，Sui 的交易大小上限最高可达 128 KB，因此相比交易大小限制更加严格的区块链拥有更大的空间。其次，我们此前已经上线并实际运行过包含大型签名的方案，包括多签和 zkLogin。此外，可编程交易区块（PTB）允许一个签名同时授权多个操作，因此平均到每个操作上的额外开销，实际上低于单纯从单个签名大小推算出的结果。未来还可以采用类似目前 zkLogin 的公钥缓存机制：用户只需提交一次自己的公钥，之后的交易只需要发送签名即可。不过，这项功能不会在最初版本中启用。我们希望第一版实现保持相对保守，并在之后经过充分考虑后再逐步开启这一优化。
还需要说明的是，上述数据仅代表一种测试配置。要进行更完整、严谨的性能报告，还需要覆盖验证节点端的 Rust 执行路径、普通开发者配置，以及通过 TypeScript 技术栈进行的浏览器端签名。我们计划之后公布更加完整的测试数据。关于 NIST 各候选签名方案更全面的对比，可以参考 nist-sigs-zoo。
另外，Sui 关于执行扩展的 Remora 研究，也让后量子迁移过程中涉及的吞吐量扩展问题变得更加容易处理。这两条研究路线从一开始就是有意协同推进的。
实现方式，以及为什么我们选择自己做
几乎每种编程语言都有大型密码学库，并且其中已经包含 ML-DSA，因此直接引入一个现成的库似乎是最显而易见的选择。但我们采取了不同的做法：开发了 mysten-mldsa-native-rs，这是我们基于 mldsa-native 编写的轻量级 Rust 封装。mldsa-native 是 Linux Foundation 旗下 pq-code-package 项目维护的一个紧凑、经过形式化验证的 ML-DSA 实现。它与 aws-lc 等多个行业主流密码学库使用的是同一个核心，只是没有附带大型库中的其他组件。
之所以这样做，关键在于这部分代码位于共识执行路径上。每个验证节点都需要对每笔交易运行验证代码，因此我们希望尽可能缩小实现范围，让代码易于阅读和审计，同时避免提供可能被错误配置的选项。这个封装只提供一种模式：FIPS 204 默认模式，采用 hedged signing（对冲式签名），即每次签名都使用新的随机性，从而增强对故障攻击和随机数重复使用问题的抵抗能力。它本身不包含随机数生成器，因此每项操作都可以在测试环境中复现。私钥也只有一种序列化形式，即 32 字节种子，这使钱包能够继续按照当前完全相同的方式进行备份和恢复。
正如前面所提到的，我们的实现速度很快。这主要得益于上游针对 Apple/ARM 和 x86 服务器硬件提供的经过验证的汇编实现。系统会在运行时根据不同机器自动选择对应的实现，从而确保同一个二进制文件能够在混合的验证节点硬件环境中正确运行。无论采用哪种底层实现，最终生成的签名都是完全相同的。区别只在于性能：汇编后端的运行速度大约是可移植 C 实现的 2.5 倍。
一个很少有人讨论的失败点
新密码学真正危险的地方，往往不是数学，而是代码以及匆忙的实现。
今年，一个领先的 STARK 证明器被披露存在健全性漏洞：验证节点信任的某个值并没有真正绑定到证明 transcript 中，因此恶意证明者可以伪造错误陈述的证明，而验证节点仍会接受。这个漏洞从 2024 年开始就存在于开源代码中，经历了外部审计和形式化验证，却一直没有被发现。最终在 2026 年 6 月由 AI 审计工具发现，所幸此前没有遭到利用。
ML-DSA 本身也已经出现过类似的案例。仅在 2026 年，这一签名方案的 3 个独立代码库中就披露了 4 个实现层面的漏洞：
libgcrypt 的签名流程中存在越界写入漏洞（CVE-2026-41990）；
RustCrypto 的 ml-dsa crate 在 hint 计算过程中存在时序侧信道漏洞，可能导致签名密钥信息泄露（CVE-2026-22705）；
同一 crate 中还存在一个验证漏洞，会错误接受包含重复 hint 索引的签名（CVE-2026-24850）；
wolfSSL 面向嵌入式设备的后量子代码中存在故障注入漏洞（CVE-2026-3503）。
其中，最值得认真关注的是那个验证漏洞：按照 FIPS 204 标准，一个有效签名只有一种合法编码方式。如果某个实现错误地接受了第二种编码，那么一个签名是否有效，就可能取决于你询问的是哪个节点。而在区块链上，这可能直接导致链分裂。
与此同时，在同一时期，ML-DSA 底层数学本身被攻破的次数为零。
换句话说，目前数学基础依然稳固，真正的风险更多存在于代码实现层面。
我们之所以反复提到这个例子，是因为它为我们发布的任何东西提供了一个非常重要且合理的风险判断基准；HAWK 的研究结果也指向了同样的方向。过去我们长期信赖的审查机制——包括人工审计、形式化方法，以及代码经过多年的公开检验——都没有发现这些问题，而 AI 辅助分析却发现了它们。
这进一步说明，我们需要：
在选择安全参数时预留足够的安全余量；
尽可能保持较小、易于审计的实现范围；
将跨实现验证作为构建过程中的必要门槛；
对最新、成熟度相对较低的组件，采取更加谨慎、循序渐进的上线策略。
这也正是我们接下来要讨论下一部分内容的原因。
我们暂时不会按下的按钮
我们其实有一条比当前所采用方案更理想的捷径，但我们暂时不会选择它。
Sui 上的每个 Ed25519 密钥都由一个经过哈希保护的种子派生而来。量子计算机即使破解了椭圆曲线密码体系，也只能恢复出签名标量，却无法反推出生成该签名标量的原始种子。我们的研究论文 Post-Quantum Readiness in EdDSA Chains（Baldimtsi、Chalkias、Roy 和 Sedaghat，eprint 2025/1368）利用这种不对称性，将其转化为一种抗量子的所有权证明：用户可以通过零知识证明自己持有原始种子，从而授权一个新的后量子密钥，同时保留原有地址，并且整个过程中无需暴露任何秘密信息。
这种方案拥有一些比通过新派生路径进行迁移更好的特性。它适用于公钥已经暴露的账户；也可以追溯应用于多年前就已经派生出来的密钥；甚至还适用于那些未来永远不会再签署任何交易的休眠账户。这是其他迁移方案无法覆盖的一类账户，而对于不支持确定性种子派生的区块链来说，这类账户甚至根本无法通过这种方式迁移。这正是 EdDSA 区块链相比 ECDSA 区块链所拥有的结构性优势，也是这篇论文专门研究 EdDSA 的原因。
那么，既然这个方案这么好，为什么现在不直接启用？因为这个“按钮”本质上是一个零知识证明系统。如果现在将其上线，就意味着账户安全需要依赖这套证明系统，而这套技术本身比它要保护的签名体系更加年轻。结合上一部分提到的实现风险，这正是我们选择谨慎的原因。
等待所付出的代价其实很小，因为这个“按钮”不会过期。一个种子不会因为时间流逝而变得不再保密。等到零知识证明系统积累了足够的安全验证和信任之后，我们仍然可以构建并启用这套证明机制。与此同时，我们会先通过更直接的方式完成迁移：通过新的派生路径支持原生后量子账户，并利用地址别名帮助现有账户迁移。
因此，我们目前将 zkPQ-EdDSA 视为一个未来必要时可以启用的紧急安全开关，而不是首发功能。这里还有一个值得注意的设计特性：由于 Sui 上的 ML-DSA 私钥同样是一个 32 字节种子，因此未来如果有需要，同样的“种子持有证明”机制也可以进一步应用到后量子账户本身。
迁移机制
在两项安全升级中，Sui 都会提供新的标准派生路径，并且采用账户级自愿选择。现有账户无需转移资金。已经部署的地址别名（Address Aliases）允许账户将授权密钥更新为后量子密钥，同时：地址不变，资产留在原地。对于现有用户来说，目前真正承担迁移任务的是这一机制，而不是前面提到、目前仍被推迟的零知识证明方案。
对于抗量子金库，提款采用两笔交易模型，简单转账则可能只需要一笔。对开发者和机构来说，实际意义非常明确：抗量子账户会像 zkLogin 和 Passkeys 一样，作为新增的可选功能逐步上线。不会强制迁移，现有功能不会发生变化。启用它只是一项常规协议功能升级，而不是对共识机制或现有状态的修改。
行业目前走到了哪里
我们并不是唯一在做这件事的团队，也不希望成为唯一一个。Near 今年夏天已经推出 ML-DSA-65 作为可选密钥类型，与 Sui 选择了相同的方案和安全等级，这也是一个有价值的独立信号。Ethereum 的共识路线图更倾向于基于哈希的方案。Bitcoin 目前有多个活跃提案，但尚未作出最终决定。
我们认为 Sui 真正领先的地方，并不是选择了哪种算法，而是架构设计：
两种方案对应两种威胁模型；
金库可以在无需协议升级的情况下适应外部标准；
用户能够保留原有地址。
当前状态与时间表
核心实现已经完成并进行了性能测试。目前计划：
抗量子金库：今年登陆主网；
原生 ML-DSA-65 账户：年底前登陆测试网；
原生账户认证：最晚目标为 2027 年第一季度登陆主网。
钱包、SDK 和 CLI 支持将同步推出。
独立外部审计目前正在进行中。我们无法保证所有审计都能完全按照计划完成，而相比上线一个未经充分审计的认证器，我们宁愿推迟日期。因此，本文介绍的是当前方向，最终时间仍可能根据审计结果和测试网反馈进行调整。
相关审查所需要的一切都已经公开，包括 FIPS 204、FIPS 205、经过形式化验证的 mldsa-native C 实现、Mysten 的原生 Rust 封装 mysten-mldsa-native-rs，以及我们目前刻意暂缓上线的 Post-Quantum Readiness in EdDSA Chains 开源实现。
比起获得赞赏，我们更希望这项工作能接受审视。我们有意将实现范围控制得尽可能小，有意将交叉验证设为构建的强制门槛，也有意暂缓采用迁移捷径。如果你从事后量子签名、硬件钱包或证明系统相关工作，并认为其中某项决策存在问题，我们非常希望听到你的意见。
一个彩蛋
派生路径是钱包将一个助记词转换成多个密钥时遵循的规则：它由一小串按顺序逐步应用的数字组成，因此，同一个助记词在任何设备上都能生成相同的密钥。Sui 上所有基于助记词的密钥都通过这样的路径派生，而其中的第一个数字——用途编号——用于标识签名方案。
目前，Sui 上的 Ed25519 密钥采用以下派生路径：
m/44'/784'/0'/0'/0'
其中，784' 代表 Sui，44' 是用途编号；ECDSA 签名方案则分别使用 54' 和 74'。后量子密钥将采用：
m/94'/784'/0'/0'/0'
这里的 94 并不只是序列中的下一个数字，它代表的是一个年份。巧合的是，Peter Shor正是在 1994 年发表了让这一切变得必要的算法。为纪念这个巧合，每一把 Sui 量子安全密钥的派生路径中，都将带有这场倒计时开始的年份。