SPHINCS-：EVM上高效的无状态后量子签名验证

特别感谢 Vitalik Buterin、Jean-Philippe Aumasson、Justin Drake、Chelsea Komlo、Mauro Toscano、ZKnox 以及 EF PQ 与密码学团队的同事们，感谢你们的所有讨论、审阅和反馈。

引言

量子计算机最终将破解 ECDSA——当前保护以太坊和比特币账户的签名方案。Babbush 等人 [1] 最近的资源估算将这个时间线提前到比之前预期更近，使得执行层的后量子签名验证成为紧迫问题。本文介绍 SPHINCS-，一个基于 SPHINCS+ 和近期关于紧凑哈希签名的工作衍生出的、针对 EVM 优化的变体家族。我们的目标很简单：在不依赖预编译或协议变更的情况下，最小化纯链上验证成本。

我们展示了 SPHINCS 变体的 Solidity 实现（与 NIST 关于有限签名参数集的草案一致）已经能够在以太坊上以实际可行的成本（150K Gas）验证标准化的后量子签名。我们还提供了验证器的形式化证明（使用 lean 4 和 Verity）。这对于希望在以太坊上获得 FIPS 合规性的组织来说是个好消息。然后我们探索了更激进的非标准变体，这些变体用基于 EVM 原生 keccak 的构造替换标准哈希组件，并将签名预算缩小到区块链钱包相关的范围。在这些变体中，我们研究了验证器 Gas、签名者工作量、签名大小和每密钥签名预算之间的权衡。

1. 想法的起源

与 Vitalik 讨论以太坊后量子密码学时，我们发现一个简单的观察：EVM 已经有了成本很低的 KECCAK256 操作码，而 SPHINCS+ 完全由类似的哈希函数构建。用 KECCAK256 替换标准的 SHAKE256 将使验证器能够在链上原生运行，无需预编译。

NIST 将 SPHINCS+ 标准化为“SLH-DSA” [3]，其签名预算为 $2^{64}$，这远远超出了区块链钱包的使用量。根据 dune，自合并以来，以太坊主网每个活跃地址的年度交易数（99.9 百分位）平均约为 431 笔。因此，我们探索了同样的方案，但使用了更保守的签名预算。

其余的要素来自近期关于压缩 SPHINCS+ 签名的工作。其中，Drake 等人 [4] 描述了一种目标数字和 Winternitz 编码，消除了校验和开销。Kudinov 和 Nick [5] 在他们关于比特币哈希签名的报告中进一步系统化了这一点，详细介绍了 WOTS+C 校验和研磨、FORS+C 和 PORS+FP 计数器研磨/强制剪枝，并展示了如何在降低签名计数预算的情况下，将签名大小压缩到远低于 SLH-DSA 的水平。同一工作线中，Nick 提出了 SHRINCS [6] 和 SHRIMPS [7]，证明了有状态/无状态混合方案可以将基于哈希的签名在主设备上降至 324 字节，在独立备份设备上降至约 2.5 KB。通过组合这些想法，我们可以得到一个 EVM 原生的基于哈希的签名方案，其参数针对验证器进行了激进优化，使得后量子签名在以太坊上变得实用。

我们利用 Blockstream 研究参数搜索工具来探索 SPHINCS+ 变体，并将其适配到 EVM（查看此仓库以探索参数权衡）。本文描述了参数空间，解释了每个参数对 EVM 验证器和签名者的作用，并介绍了最终的变体家族。特别感谢 Tom Wambsgans 帮助我进行探索。

2. 背景：SPHINCS+ 如何工作

哈希函数是单向的：正向计算容易，反向不可行。基于哈希的签名利用这种非对称性，通过哈希提交秘密值，然后稍后揭示选定的秘密作为签名。三个构建块使其变得实用：哈希链，通过揭示单向序列中的位置来编码选择；Merkle 树，将多个一次性公钥压缩为单个根；以及有限次方案，允许一个密钥在必须退役之前签署少量消息。SPHINCS+ 将这些部分堆叠成一个基于哈希的无状态签名方案，构建在超树（hypertree）之上。叶子是 FORS 实例（“随机子集森林”），提供有限次签名。它们上方是 XMSS 树层，每层使用 WOTS+（Winternitz 一次性签名）来认证下一层。

要签名消息 $M$，你首先用随机数和你的公钥信息对其进行哈希。使得：

H_msg(Randomizer, PK.seed,PK.root, M) => ( md , idx_tree , idx_leaf )

这个哈希给你三样东西：一个消息摘要 md，以及两个索引，它们选择超树的哪个子树和哪个叶子将执行实际签名。

把超树想象成一个巨大的文件柜。消息告诉你使用哪个抽屉 idx_tree 和哪个文件夹 idx_leaf。然后消息摘要被分割成 $k$ 个 $a$ 比特的块，每个块作为一个值，选择该文件夹中的一个秘密。揭示这些秘密，就构成了你的签名。

请注意，使用 $d=1$ 参数时，你没有子树，所以 idx_tree 总是给出外部树。

你可以在 https://sphincsminus.org/ 直观地看到它是如何工作的。

签名包含：

1. 一个 FORS 签名：$k$ 个秘密叶子值加上 $k$ 个 Merkle 认证路径，压缩成一个 FORS 公钥。
2. $d$ 个 WOTS+ 签名：每超树层一个，每个由 $l$ 个哈希链组成。
3. $d$ 个 Merkle 认证路径：每超树层一个，每个高度为 $h/d$。

验证器自底向上遍历这个结构：验证 FORS 打开，将其压缩为 FORS 公钥，将其用作第一个 WOTS+ 层的消息，沿着 Merkle 认证路径到达下一层，重复 $d$ 次直到到达根。每一步都是一次哈希计算。验证器计算的总哈希次数决定了链上 Gas 成本。

2.1 标准化

NIST 已经标准化了多个 PQ 签名方案，包括基于格的 ML-DSA [2] 和仍在草案中的 FN-DSA (Falcon)。基于哈希的签名是一个有吸引力的替代方案：其安全性完全依赖于哈希函数的性质，这些性质已被充分理解且假设最少，这些原语比格构造更容易理解。

3. 参数及其作用

3.1 哈希输出大小：$n$ => 每个哈希产生多少字节

所有哈希计算的输出大小。标准 SLH-DSA 提供 $n=16/24/32$ 字节（128/192/256 位）。

对 EVM 的影响： 每个 Merkle 节点、WOTS+ 链值和 FORS 叶子都是 $n$ 字节。$n=16$ 时，签名大小是 $n=32$ 时的一半。

安全性： $n$ 将原像安全性上限设为 $8n$ 位。$n=16$ 提供 128 位，足以满足我们的目标。

我们的选择： $n=16$。128 位安全性的最小值，可能的最小签名。

3.2 超树层数：$d$ => 堆叠了多少棵树

XMSS 子树的层数。标准 SLH-DSA 使用 $d=7$ 到 $d=22$。

对 EVM 的影响： 验证器执行 $d$ 次 WOTS+ 验证和 $d$ 次 Merkle 认证路径遍历。$d$ 加倍大约会使超树部分的验证工作量加倍。

对签名者的影响： 每一层需要构建一个完整的 $2^{h/d}$ 叶子子树。$d=2$ 时，签名者构建两个子树；$d=3$ 时，构建三个。这是主要的签名成本。

我们的选择： $d=2$。最小化链上 WOTS+ 验证次数。每次扫描都确认 $d=2$ 对 EVM Gas 最优。

3.3 超树高度：$h$ => 一个密钥可以产生多少签名

总超树高度。决定签名容量 $q_s$。该方案支持 $2^h$ 个 FORS 实例。

对 EVM 的影响： 验证器遍历 $h$ 个 Merkle 认证节点（每层 $h/d$ 个，共 $d$ 层）。$h$ 增加 4 会增加约 800 Gas，成本适中。

安全影响： 更大的 $h$ 意味着更多的 FORS 实例（共 $2^h$ 个），因此签名碰撞到同一实例的可能性更小。由于 FORS 重用是签名计数高时的主要退化机制，增加 $h$ 可以让一个密钥在安全级别降至目标之前签署更多签名。给定签名计数下的确切安全级别是 $h$、$k$ 和 $a$ 的联合函数；请参见 §5 中各变体的 $\text{sec}_N$ 列以获得具体数字。

对签名者的影响： 当 $d=2$ 时，子树大小为 $2^{h/2}$。从 $h=16$ 到 $h=24$，子树大小从 256 个叶子增加到 4096 个叶子，签名工作量增加 16 倍。

权衡： $h$ 是控制签名速度与高签名计数安全性之间的主要旋钮。更大的 $h$ 对验证器成本影响很小（每增加 1 单位高度约 200 Gas），但会显著增加签名者工作量。

3.4 FORS 树：$k$ 和树高度：$a$ => 有限次签名的结构

FORS 使用 $k$ 棵独立的二叉树，每棵高度为 $a$（$2^a$ 个叶子）。签名揭示每棵树的一个叶子及其认证路径。

对 EVM 的影响： 验证器计算 FORS 部分大约需要 $(k-1)(1+a) + 2$ 次哈希。使用 FORS+C 时，签名者强制最后一个索引为零，从签名中消除一棵树，节省 $(1+a)n$ 字节和 $(1+a)$ 次哈希。

安全性： FORS 一次性安全性为 $k \cdot a$ 位。对于 128 位：$k \cdot a \ge 128$。更高的 $a$ 意味着重用下的退化更慢（每次重用揭示树的更小部分）。

对签名者的影响： FORS+C 研磨需要期望 $2^a$ 次尝试。更高的 $a$ 意味着指数级更多的研磨。

3.5 Winternitz 参数：$w$ => 链长度与链数量之间的权衡

WOTS+ 系统的基。验证器完成 $l$ 条哈希链到达位置 $w-1$。

对 EVM 的影响： 对 Gas 影响最显著的参数。链数 $l$ 由 $n$ 和 $w$ 决定。对于 $n=16$：

更高的 $w$ 意味着更少的链（更小的签名）但更长的链（每条链更多哈希）。公式由下式给出：l = ceil(security_bits / log2(w))

Gas 优化发现：在简单的 calldata 下限模型下，高 $w$ 变体看起来很有吸引力。但一旦对真实验证器执行进行建模，链工作量就占主导地位。$w=8$ 胜出，因为虽然链更多（43 条），但链很短（最多 7 步）。感谢 Emile 发现这个家族。这是参数搜索中最重要的教训：必须对实际验证器执行进行建模，而不仅仅是操作码 Gas 加上 calldata。

3.6 目标数字和：$S_{wn}$ => 签名者研磨以缩小验证器的难度

在 WOTS+C 中，签名者进行研磨，直到数字和恰好等于 $S_{wn}$，替换标准的 WOTS 校验和。

对 EVM 的影响： 验证器每层计算 $l(w-1) - S_{wn}$ 步链。$S_{wn}$ 越高 = 步数越少 = 越便宜。线性关系。

对签名者的影响： 更高的 $S_{wn}$ 意味着更少的有效编码，更多的研磨。这是一个平滑的旋钮，在签名者工作量和验证器节省之间进行权衡。

安全影响： 无。$S_{wn}$ 不影响密码学安全性。它只在签名者和验证者之间转移成本。

3.7 总结

参数       验证器成本        签名者成本         安全性
--------  -------------  -----------          --------
n=16     最小化 calldata  --                   128 位上限
d=2       2 次 WOTS+ 验证  2 次子树构建         --
h 增加    +200 Gas/单元   每 4 单元 x16 倍   更多签名保持在 128 位
k 增加    更多 FORS 树    --                  更高的 k*a
a 增加    更长的认证路径  指数级研磨          重用下退化更慢
w=8      短链（7 步）     43 条链，适中        --
S_wn 增加 更少的链步数   更难的研磨          无

4. 校准后的 Gas 模型

我们使用 https://github.com/nconsigny/EVM-SPHINCs-Parameters 并应用 EIP-7623 和 EIP-7976 地板定价来寻找变体。我们测量了已部署变体的实际验证器执行轨迹，发现排名与原始模型不同。具有较小签名（更高 $w$ 或基于 PORS）的变体在地板模型下看起来最好，但具有较少总哈希计算的变体（$w=8$，FORS+C）在实践中更便宜。原始模型高估了签名大小，低估了执行成本。

我们根据测量轨迹拟合了一个粗略模型：

ExecGas = 36,118 + 194 * ops

其中 ops 是验证器的总哈希计算次数。这正确地恢复了各变体的 Gas 排序，并成为默认搜索指标。

这种区分很重要，因为 EIP-7623 地板：

TotalGas = max(StdCalldata + ExecGas, CalldataFloor)

一些变体受地板限制，另一些受执行限制。在验证器上增加一次哈希在执行路径上花费约 194 Gas，在地板路径上不花费；而节省一个签名字节在两条路径上都节省 16 Gas。这种不对称性解释了为什么一旦正确建模执行，$w=8$（更多链，更短，总哈希更少）就击败了 $w=32$（更少链，更长，总哈希更多）。我们还检查了 keccak 成本增加 20%，因为我们预计在接下来的硬分叉中会有 keccak 重新定价。

5. 变体家族

简而言之：C13 是针对笔记本签名者优化的变体；C11 和 C12 针对硬件钱包签名者优化；SLH-DSA-SHA2-128-24 可在强大笔记本或 HSM 上实现。

根据所选参数集，有不同的安全退化和签名时间。我们选择的变体的安全退化如下：

查看位于 https://github.com/nconsigny/SPHINCS-/tree/main/src 的验证器合约

• 家族：SPHINCS+ 构造风格可以是原始 SPHINCS+ 或 WOTS+C / FORS+C（带有研磨的紧凑构造）

• $h; d; a; k; w; l$：构造参数，参见上文 §3 的描述

• $\text{sign}_h$：密钥生成加一条签名期间的哈希函数调用次数，零内存签名者（无跨签名缓存）。数字高意味着硬件工作量大（不好）

• $\text{sec}_N$：每个密钥 $2^N$ 次签名时的安全位数

• 验证（纯）：Foundry gasleft() 对汇编块的测量

C11 和 C12 足够轻量，可以在硬件钱包上运行，在 ST33K1M5 安全元件（Ledger nano S+）上测量到的签名时间分别为 390 秒和 47.5 秒。另一方面，SLH-DSA-SHA2-128-24 是符合 FIPS 的替代方案：即使在笔记本级别的签名者上，签名者成本也要大得多。Keccak 变体以牺牲 NIST 位精确合规性为代价，换来链上验证成本降低约 34%。

6. 局限性与“leanSPHINCS”前景

SPHINCS- 是非标准的：使用 keccak256 而非 SHAKE256（破坏了 FIPS 205），签名计数有限（$2^{14}$ 到 $2^{20}$，而标准为 $2^{64}$），没有匹配的 NIST 参数集。如果 NIST 考虑独立于哈希实例化来指定超树结构和参数（例如，使用 NIST SHA-3 置换但去掉 SHAKE 的海绵填充，或使用 Poseidon），那将非常有益。或者，发布指南说明实现者如何在保持 SLH-DSA 安全属性的同时进行哈希函数替换，也会受到欢迎。

也就是说，与标准之间的差距正在缩小。NIST 正在积极研究较小的 SLH-DSA 参数集 [9 & 10]，签名限制为 $2^{24}$（rls128cs1、rls192cs1、rls256cs1），针对证书和固件签名。NIST 最近在特别出版物 800 [11] 中发布了新的参数集，其中包含我们使用的 128-24 变体的初始公开草案。SPHINCS- 在从 $2^{14}$ 到 $2^{20}$ 的同一设计空间中运行，并且这里开发的技术——keccak 替换、EVM Gas 建模、WOTS+C/FORS+C 压缩——也将适用于任何未来标准化的、小预算的 SLH-DSA 参数集。

未来，底层哈希函数应该对 ZK 友好，以适应 zkEVM 约束。我们将这个未来变体命名为“leanSPHINCS”。

这也正是协议级聚合进入视野的地方。近期的一份 EIP 草案，“PQ 签名和 STARK 聚合的帧类型”，允许交易声明轻量级的 (scheme, data_hash, verification_key) 依赖，而不是在链上携带签名；内存池节点和构建者在区块头中将这些离线折叠成一个单一的递归 STARK。此时，leanSPHINCS 验证在帧级别只需 3000 Gas，因为验证由证明者一次性支付，无需每个节点重新执行。问题在于对 ZK 友好的哈希要求：keccak 算术化的成本高出几个数量级，因此只有 leanSPHINCS 能在聚合电路内原生验证。基于 keccak 的 SPHINCS- 签名仍然可以通过流水线，但必须先在客户端侧进行 STARK 包装，将那个一次性证明成本转移到签名者的设备上。

与此同时，SPHINCS- 可以是一座桥梁：目前可部署的最节省 Gas 的基于哈希的 PQ 选项，无需等待任何协议变更。硬件钱包约束在 JARDIN（即将发表™）的配套文章中解决，该文章将紧凑签名时间减少到 ST 安全元件上的 3 秒。

参考文献

[1] R. Babbush 等人。“Securing Elliptic Curve Cryptocurrencies against Quantum Vulnerabilities.” arXiv:2603.28846, 2026. https://arxiv.org/abs/2603.28846

[2] 国家标准与技术研究院。“Module-Lattice-Based Digital Signature Standard.” FIPS 204, 2024 年 8 月. https://csrc.nist.gov/pubs/fips/204/final

[3] 国家标准与技术研究院。“Stateless Hash-Based Digital Signature Standard.” FIPS 205, 2024 年 8 月. https://csrc.nist.gov/pubs/fips/205/final

[4] J. Drake, D. Khovratovich, M. Kudinov, 和 B. Wagner。“Hash-Based Multi-Signatures for Post-Quantum Ethereum.” ePrint 2025/055, 2025. https://eprint.iacr.org/2025/055

[5] M. Kudinov 和 J. Nick。“Hash-based Signature Schemes for Bitcoin.” ePrint 2025/2203, 2025. https://eprint.iacr.org/2025/2203

[6] J. Nick。“SHRINCS: 324-byte stateful post-quantum signatures with static backups.” Delving Bitcoin, 2025 年 12 月. https://learnblockchain.cn/article/25055

[7] J. Nick。“SHRIMPS: 2.5 KB post-quantum signatures across multiple stateful devices.” Delving Bitcoin, 2026 年 3 月. https://delvingbitcoin.org/t/shrimps-2-5-kb-post-quantum-signatures-across-multiple-stateful-devices/2355

[8] EIP-8141: Frame Transactions https://learnblockchain.cn/docs/eips/EIPS/eip-8141

[9] J. Dang。“SPHINCS+ Smaller Parameter Sets.” NIST PQC 研讨会, 2025. https://csrc.nist.gov/csrc/media/presentations/2025/sphincs-smaller-parameter-sets/sphincs-dang_2.2.pdf

[10] Scott Fluhrer & Quynh Dang “Smaller Sphincs+ or, Honey, I Shrunk the Signatures.” ePrint 2024/018, 2024 https://eprint.iacr.org/2024/018.pdf.

[11] NIST Special Publication 800 Additional SLH-DSA Parameter Sets for Limited-Signature Use Cases Initial Public Draft https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-230.ipd.pdf

[12] ZKnox / Kohaku。“Post-quantum account pattern.” https://github.com/ethereum/kohaku/tree/master/packages/pq-account/lib

• 原文链接： ethresear.ch/t/sphincs-m...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～