作者：roasbeef

来源：https://delvingbitcoin.org/t/post-quantum-lightning-layer-by-layer/2479

几个星期以来，陆续有人直接或间接问我，量子计算机的出现会如何影响闪电网络。我搜索了一番，发现还没有针对这个话题的具体回答，于是我知道得自己写一篇了！

想要回答量子计算机可能如何影响闪电网络设计得问题，方便的起点是先查看闪电网络有哪一些层级，用到了依赖于传统的安全假设的密码学，需要修改。

因此，我们可以找出直接依赖于椭圆曲线（EC）密码学的 BIP ，然后反过来看看如何将它们替换成后量子的密码学原语。

遍查 BOLT（闪电网络基础规范），以下文档都直接用到了椭圆曲线密码学：

• BOLT 11+12

  • 带有签名的发票格式，依赖于 Schnorr 签名来鉴别签发发票者的身份

• BOLT 8

  • 加密的 P2P 通信，用到了 静态+临时 的 EC 密钥，以及 ECDH（椭圆曲线上的 Diffle-Hellman 密钥交换），来派生一系列临时的通信密钥

• BOLT 7

  • P2P gossip 消息，会用到一系列的 Schnorr 签名

• BOLT 4

  • Sphinx 算法派生的混淆包裹，利用了椭圆曲线密码学的交换律来制作紧凑的混淆包裹。这种 “小小技巧” 是乘以多个盲化因子，用来给每一跳一个新的临时 EC 密钥。有相当大的节约作用，因为这样一来我们就不必直接在包裹中为每一跳放置一个 EC 密钥。

• BOLT 2 + 3 + 5

  • 实际的闪电通道格式，其中的多签名部分使用了 Schnorr/ECDSA 签名；而脚本中的支付哈希值是 RIPEMD 160 哈希值（我们后面再详说）。

总结完毕。虽然每一层都需要 一定程度 的变更，但整体的协议层级和流程基本上是不变的。

签名+公钥 体积比较

在详细论述每一层之前，我们先看一个方便的表格，它对比了各种可行选项的 签名+公钥 的体积差异：

SLH-DSA-128-24 是一个新提出的变种 签名，实现了更小的签名体积，代价是每个签名密钥的签名次数上限会降级（从 SLH-DSA-128s 的 2⁶⁴ 次降低到 2²⁴ 次）。

单方案时代一去不返

椭圆曲线密码学（ECC）最令人眷恋的地方就是它的普适性。完全相同的 ECC 群参数既可以用于数字签名，又可以用于非交互的密钥交换， 还能搭配一整套其它有趣的密码学协议（例如：musig2、适配器签名、点时间锁合约（PTLC），静默支付，等等）。

不幸的是，在后量子大陆，同样的情形无法再保持，因为 哈希链条/哈希树 以及繁琐的 格（lattices）这样的原语，无法继承 EC 群给予我们的数学对称性和结构。

后果之一是，从功能性的角度看，不再有一种后量子的密码系统，可以给予我们所需要的一切。有可能最终我们需要推出 —— 不是一种，也不是两种，而是 —— 三种不同的密码系统，才能实现我们今天用 ECC 做到的 基准 功能（为通信使用 ML-KEM、为链外签名使用 ML-DSA、为链上签名使用 SLH-DSA）。

我们后面会详细说，现在只举一例：假设我们希望转向纯粹基于格的密码学；我们需要运行某种密钥交换（当前就是 ECDH），也需要对需要鉴别身份的数据生成数字签名；在 ECC 大陆上，一个密钥就足以满足这两项要求：同一个密钥，既可以用于 Noise 协议中的静态密钥交换，也能用来签名我们的 gossip 宣告消息。

在 NIST 的后量子（PQ）密码学大陆上，没有任何一个已被接受的方案支持这种通用性。相反，为了实现类似密钥交换的构造，唯一的选择是 ML-KEM（模格密钥封装机制）。ECDH 是一种非常优雅的 KEM（密钥封装机制），因为秘密值可以在完全不交互的情况下派生出来。ML-KEM 则相反，它实际上是一种混合加密协议，发起方用接收方的公钥来加密一个随机秘密值。如果我们固执于格密码学，那么为了制作签名，主流的选择就是 ML-DSA（基于模格的数字签名算法）。

你可能会以为，既然它们都是基于格的算法，那么 公钥/私钥 肯定是一样的咯。不是！两种方案都基于多项式环（polynomial rings）上的模格（module lattices） ，但除此之外，其它几乎所有 参数/原语 都是不一样的。

要混合，还是不要混合？

除了完全转向后量子密码学，实际上，我们也能稍微后撤几步。混合的后量子密码学（Hybrid Post Quantum cryptography）结合了传统的和后量子的密码学，使得只要其中一种方案是安全的，那么最终的方案就依然是安全的。毕竟，也许在未来，PQ 才是被打破的那一个。而且，也许传统的方案不是因为量子计算机而失败的，而是因为其它的密码分析技术的创新。

那么下面我们会看到，除了洋葱路由（oinion routing）之外，其它领域都可以利用新的 TLV 或者现有的版本号插件字段，逐渐采用混合方法。当前，我们可以添加这些混合密钥作为可选的 TLV，照常验证它们；等到以后，我们再 拒绝 不包含 PQ 封装/签名 的消息。

混合 KEM

关于 KEM，已经有大量文献展示了如何 安全地结合传统的和 PQ KEM，从而派生出一个新的混合共享秘密值。这种构成一个 传统+PQ KEM 的技术通常叫做 “Combiner（结合器）”，或者 “KEM 结合器”。实践中有许多办法可以实现这种技术，取决于所需要的安全属性。我不会在本文中列出所有选择，但如果你感兴趣，可以看看我最近在 bitcoin dev 邮件组中发表的帖子，关于后量子的 BIP 324 变体的一种设计选择。

空间/带宽 方面，简单来说，你需要传输 传统+PQ 两个公钥 以及 “胶囊”（加密后的共享秘密值）过去，才能确立一个共享秘密值。从 PQ 角度看，传统密码学的结构是非常紧凑的，所以 额外 传输传统密钥和胶囊并不会损失什么效率。

混合的数字签名

关于混合的数字签名，我们不需要任何时髦的组合技术。只需要同时包含传统签名和 PQ 签名就可以了。重复一次，传统签名相比 PQ 签名是非常小巧的，所以在 空间/带宽 方面没有什么损失。

关于 PQ KEM，只有一种真实选择。但是签名，我们有基于哈希函数的签名（SLH-DSA）和基于格的签名（ML-DSA）。在开展写作本文所需的调查之前，我一直有种印象，就是我们会在所有地方都直接选择 SLH-DSA，因为它够简单。然而，在开展一些调查之后，我认为，在某些层级上， ML-DSA 比 SLH-DSA 更加适合。正是因此，我才在上文说也许最终我们会部署三种不同的方案 ……

有了这些背景知识，我们再逐层分析设计要求和约束，看看 BOLT 需要哪些变更才能抵抗量子计算攻击。

表示层：BOLT 11 + 12

在整个协议栈的“最顶端”，我们有 BOLT 11+12 。我们可以用 OSI 模型来类比，将它类比为 “表示层”。为了简化，我在这里将只讨论 BOLT 11 ；因为当我们分析 BOLT 4 时，将提到一部分 BOLT 12 机制（Offer 和洋葱消息）。

BOLT 11 传统密码学

BOLT 11 发票是用 ECDSA 来签名的，利用 ECDSA 的公钥复原机制来避免直接将公钥放在发票里面。使用 SHA2 来承诺一个描述哈希值，以及用在 支付哈希值/秘密值 。

拟议的 BOLT 11 后量子密码学

关于签名，不使用旁门左道，我们有 ML-DSA（基于格的）和 SLH-DSA（基于哈希函数的，也就是 SPHINCS+）。

当前，我们使用公钥复原机制来避免在发票中包含公钥，从而省下了 33 字节。对于后量子签名，除了签名变得大得多，在绝大部分方案中，公钥也相对打了许多。

PQC 部分的 签名+公钥 的体积增加，对 BOLT 11 编码方案构成了挑战。因为 BOLT 11 严格采用了 bech32 编码，所以最大字段长度是：1023 * 5 比特 = 5115 比特 = 639.375 字节。即使使用最小的参数，ML-DSA 方案和 SLH-DSA 方案的签名都会超过这个限制。因此，即使要继续使用 BOLT 11，其格式也需要彻底改变。

SLH-DSA vs ML-DSA

BOLT 11：SLH-DSA

SLH-DSA 实际上支持一种公钥复原。因为一个签名或多或少就是一连串的 哈希链条 或者 默克尔树 启封（opening），只要你将所有东西放在一起哈希，你就会得到一个候选的根植。然后，你可以将这个候选根植与一个公钥种子相结合，派生出真正的公钥。对于 SLH-DSA，如果我们使用最近出版的 SLH-DSA-128-24 变种（单个签名密钥最多只能生成 2^24 格签名，后文详说），那么公钥是 32/64 字节，而签名是 3.8 KB 。根据这些数字，直接包含公钥与通过签名来恢复公钥，并没有多大差别。

SLH-DSA -128-24 确实给了我们体积小得多的签名（相比 ML-DSA），但它有 2^24 次签名的数量限制，大概就是 1600 万次。相比之下，标准的 SLH-DSA -128s 会产生大约 8 KB 的签名，这种 -24 变种给出了可观的节约。

根据 用户/商家/节点/商业 的规模，1600 万次签名可能也不是那么多。假设有一个火爆的 店铺/网站，甚至是一家交易所，每个小时会产生 1000 条发票，那么在两年内，就会完全用尽 1600 万条签名的限制！

因此，如果从某种角度看基于哈希函数的签名更加可取，我们就要想办法容纳 8 KB 大小的签名、走向普通的 SLH-DSA -128s 方案。

BOLT 11：ML-DSA

转向 ML-DSA，我们可以关注 ML-DSA-44，其公钥体积是 1.3 KB、签名体积是 2.4 KB（私钥体积是 2.5KB）。并且我们不会像 SLH-DSA -128-24 那样撞上签名数量限制，牺牲则是更大的实现复杂性。取舍的结果是，我们最终会得到大约 4 KB 的 签名+公钥 体积。

支付请求 QR 码约束

关于 QR 码，在字节模式下，实际上可以编码的最大数量为 2953 字节。看看前面提到的 签名+公钥 体积数字，显然，没有任何一种 PQ 方案能像今天的构造一样编码在 QR 码中。我们需要选择另一种形式，或者将多个 QR 码前后拼接，就像一个微电影一样，从而传输更多数据。

传输层：BOLT 8

接下来，我们看看传输层。当前我们使用 Noise 协议握手，它利用了一种新颖的多次 DH 握手，来混合一系列静态的和临时的密钥，得到一个最终的共享秘密值。我们使用 Noise_XK 也因为它给了我们一定的信息隐藏效果（发起方必须知道响应者的身份）。

如前所述，在 PQ 大陆上，我们无法使用同样的一系列 DH 操作，因为我们只有一种 KEM，而它实际上是用一个静态的长期密钥来加密一个秘密值。

这一点的影响之一是，现在我们需要额外广播一个 KEM 密钥，因为同一个密钥无法既用于验证 签名/发票，又 用于建立加密连接。

PQ Noise

幸运的是，关于 PQ Noise 我们已经有准备好的方案了。 这篇 gist 的意思是，将现有的 ee（临时+临时）、 es（临时+静态）以及 ss（静态+静态）操作转化成相应的 KEM 操作。更大的转变在于，静态密钥的交换，以及来自响应者的 es 交换，现在也需要携带一条密钥确认消息。整体上的流程几乎不变，但需要传输额外的消息，并且我们每一次握手都要携带更多的信息。

如果我们觉得转向完全 PQ 的 Noise 也没问题，那么基本上就没什么事了，因为我们可以使用现成的解决方案。不过，如果我们还是喜欢混合方法，那么就需要作出额外的设计抉择。

混合 PQ Noise

想要关于混合 KEM 协议的更加细致的解释，请看我最近在 bitcoin dev 邮件组中发表的帖子。

大体上我们有两种选择：

1. 在我们现有的传统 Noise 握手 内 升级到 PQ KEM 握手
2. 使用一种非 Noise 的混合结合器握手

两种选择都需要我们广播一个新的 PQ KEM 密钥。

第一种选择允许我们利用所有现存的 Noise 代码，只需要在初次握手建立之后，补充一种 PQ KEM，比如 ML-KEM-768 。然后，我们要将新的 PQ 派生共享秘密值混合到现有的会话状态中，然后轮换密钥。我们已经在握手传输和应用数据之间设计了清晰的域分隔（domain separation），所以不需要担心会用让敏感信息依赖于传统安全性。

第二种选择可以说更加优雅，因为我们一次性完成 传统+KEM 。不过，这就要么需要放弃 Noise，要么需要将普通的和 PQ Noise 握手模式组合成一种新的合并手握。

发现层：BOLT 7

当前，得益于神奇的 ECC，所有 gossip 消息最大也不过几百字节。而在 PQ 大陆，我们只能继续高呼咒语：“使用 PQC 之后，一切都会变大”！

Gossip 身份认证：ML-DSA vs SLH-DSA

如今，要用节点 ID 密钥来签名的东西有：发票、node_announcement、channel_announcement，以及 channel_update。 NIST 建议了 1600 万条签名消息的硬上限。

上面的草图已经说明，如果一个节点每小时签名 1 千条消息，那么在两年内就会用尽限额。如果我们将 channel_update 和 channel_announcement 消息也考虑进去，情况就更加糟糕了。为了简化，我们只考虑 channel_update 消息，因为这是当前网络中数量占比最多=高的信息。

假设一个节点有 1000 条通道，每隔 10 分钟就要为每一条通道签名一条 channel update（通道基本信息更新）消息（例如，gossip v2 可能会使用基于区块高度的速率限制），那么在 4 个月内就会超过这个 2^24 的数量限制。

这是一种相对保守的估计，因为闪电网络中也有开设了超过 1k 条通道的节点，而且这还没有将新通道的流失率考虑在内。因此，我并不认为这种减少了用量的 SLH-DSA（SLH-DSA-128-24）是一种严肃的候选方案。

如果不使用 SLH-DSA-128-24，那么 ML-DSA 签名的体积就小很多（如前所述）。从功能角度考虑，两种签名方案都给了我们想要的东西（暂时不考虑像 musig2 多签名这样高级的东西）。

在剩下的部分，在比较体积时我们都只考虑完全 PQ 方案，因为传统的 EC 签名的体积，跟 PQ 同行相比简直是微不足道（64 字节的 Schnorr 签名，只占一个 2,420 字节的 ML-DSA-44 签名的大约 3%），所以即使考虑混合方案，相差也不过是个四舍五入的水平。

node_announcement

我们先从节点宣告消息开始，因为它包含了身份认证密钥的初始集合，是能够连接一个节点的前提，也是能够验证该节点的宣告消息的前提。

今天，我们很幸运，能够在节点宣告消息中只包含一个 EC 公钥，加上其它 特性/地址 信息就可以了。而在 PQ 大陆，（如前所述）我们需要为加密的 p2p 通道包含一个密钥，还要 为签名的 gossip 宣告包含另一个身份认证密钥。

一个 ML-KEM-768 公钥是 1.1 KB，这是新版本的 BOLT 8 的唯一选择，所以我们就不展开了。这增加了一个需要在 node_announcement 中广播的 新的公钥。

不过，至于节点身份密钥（用于签名更新信息），我们又一次遇到了选择哪种签名算法的问题。基于前文的推理，体积为 3 KB 的 SLH-DSA 签名类型似乎对于绝大部分节点都是不合适的。

出于完整型，下表包含多种可能组合的体积比较（多种 ML-KEM 参数，然后搭配 ML-DSA/SLH-DSA/ SLH-DSA -128s）：

每一行都带有 ML-KEM 条目，因为这是新的 BOLT 8 加密通信的要求。带有 -24 的行则表示 SLH-DSA 的新变体（限制签名次数为 2^24 次的那个）。

channel_announcement

然后，是通道宣告消息。今天，它包含 4 个公钥和 4 个签名。使用 Taproot gossip，我们可以删去 3 个签名，只传输一个聚合签名。而在 PQ 大陆，我们（还！）没有这么好的技术。

给定公钥和签名的数量，我们才能真正看出这种消息的体积膨胀程度（相比 node_announcement）：

底部的两行假设了一种未来的情形：比特币软分叉成包含 SLH-DSA 的某一种变体，从而在通道宣告消息中形成混合的 签名/公钥 对。

我暂时跳过 announcement_signatures，因为它不会被 gossip 到广大的网络中（不会像其它消息一样占用 gossip 带宽）。你可以从上表猜出来，新版的消息将是旧版的 30 ~ 90 倍。

zk_channel_announcement 用于签名聚合

关于 公钥/签名 的压缩，有一种选择是用一个 STARK 证据来替代普通的签名。这个 STARK 证据可以证明，给定的一个哈希值实际上是一条有效的 channel_announcement 的 sighash 的 N 个有效签名的承诺，等等。这样的证据甚至还能再往前走一步，在宣告消息中包含一个区块哈希值（或者区块头），并且断言：存在一笔交易，其 pkScript 是一个有效的闪电通道注资输出，用到了承诺中的公钥，等等。甚至还能再进一步，gossip 一个闪电通道状态根，以及一个递增的 批处理的+聚合的 STARK 证据，证明这个根下的所有通道都是有效的。然后，一条 channel_announcement 就只是对这个状态根的索引，并包含该根的一个默克尔树包含证据。

channel_update

在本节中，我们重复了上文的分析，但 channel_update 消息不一样。即使是对签名用法的保守估计（中等用量的 节点/商家/交易苏），都表明，限制了使用量的 SLH-DSA 变种并不适合。不过，为了完整，我还是制作了一个表格。

PQ 总体消息体积 + P2P 带宽

为了汇总本节的内容，我制作了下表，展示了使用不同签名组合时所有宣告消息的总体消息体积。“Mix” 列假设比特币会软分叉为在共识层使用 SLH-DSA 方案，而闪电网络链外则使用 ML-DSA-44 。

最 “保守” 的选择（在所有地方都使用 SLH-DSA-128）意味着消息的体积是所有其它选择的正好两倍。 如果只看这张表，那么 ML-DSA-44 显然是赢家。

PQ P2P 带宽

考虑了所有的签名类型，可以得出结尾，所有 gossip 消息整体上要多花费一个数量级的带宽。这对整个网络的带宽用量的一些影响是可预测的。

下表假设我们有 20k 条公开的通道，每一条每一天都发送 R 条通道更新消息：

每天占用字节量 = 20,000 × R × 消息体积

注意，这里统计的是入口流量，也就是一个处理所有 gossip 流量的节点在一天内要下载的数据量。并且，这还假设了从给定的一个节点处只收取一组更新。在真实的网络中，假设没有更好的 gossip 协议，这个数字要乘以 gossip 洪泛乘数（(5–10×，取决于对等节点数量和去重效率），因为每一条消息都会被冗余地发送给对等节点。

洋葱层：BOLT 4

今天我们使用 BOLT 4 所定义的 Sphinx 混淆包裹。它使用一种重复的盲化技巧来生成一个相对紧凑的最终混淆包裹。具体来说，它不是为每一跳包含一个新的 ECDH 密钥来派生共享的 洋葱/消息 秘密值，而是在包裹中包含一个密钥，然后引导每一跳以确定的方法调整现有的密钥，从而为下一跳生成密钥。如果无法实现这种技术，那么包裹的体积就要大得多，因为你需要为每一跳包含一个新的 ECDH 密钥，从而将最大跳数限制为 20 跳（包裹的体积总是固定的）。

PQ Sphinx

暂时不考虑同源密码学，ML-KEM 不支持这样的交换操作，所以我们不得不回到老方法：为每一跳包含派生共享秘密值所需的信息。目前，我们假设为 BOLT 8 加密传输和洋葱层使用同一个 ML-KEM 密钥。

感谢，David Stainton 已经为我们准备好了几乎一切。包裹的处理和生成几乎不要改变。唯一的区别在于，不是仅仅发送一个 33 字节的 ECDH 密钥，而是为每一跳发送 1 KB ML-KEM 胶囊。他们可以解开胶囊、派生出共享的私钥，然后像往常一样处理包裹。

你可以想象，这会让洋葱包裹 变得非常大。

每一跳得体积开销将增加 10-20x（包含了消息认证码 MAC）：

如果我们假设每一跳的最大载荷空间为大约 132 字节，那么可以得出以下体积比较：

请注意，在传统方案中，我们可以保持包裹的体积一直不变，不管有多少跳。这是因为我们只包含 一个 ECDH 密钥（我们可以使用盲化技巧）。然而，如果使用 ML-KEM ，我们需要为 每一跳 包含一个封装好的密钥。所以，如果要现实地比较，我们只能看 20 跳这一行。

缓解包裹体积影响的一种办法是 减少 一个包裹的最大跳数限制。在现实中，20 跳已经非常多了（整个网络的路径长度中值是 4 到 6 跳），我不确定有没有人真的用普通的软件偶然创建过 20 跳的路径。

这些体积也会直接影响盲化路径（blinded paths）和蹦床路由（trampoline）。这既是因为它们的最大跳数相对较小（它们会吞噬外层洋葱的体积），也是因为整体的洋葱消息变大了。

update_add_htlc 的影响

因为洋葱包裹会进入 update_add_htlc 消息，这种消息的总体积也会变大。幸好，我们还在处在由 BOLT 1 设定的 65 KB 消息体积限制内：

幸运的是，洋葱纠错（onion errors）不需要任何修改，因为它们依赖于已有的逐跳共享秘密值。

通道层

在通道层面，主要的决定性因素是比特币要软分叉成哪种签名类型。你可以自己代入上面列举的签名体积，看看新的交易见证数据有多大。至于脚本公钥 pkScript 的体积， SLH-DSA 很棒，因为公钥只有 32/64 字节。新的通道类型可以机械地使用 OP_CHECKPQSIG 来替代 OP_CHECKSIG（不论使用什么签名类型），然后切换 公钥 /签名类型，基本上就差不多了。

至于更加高级的签名类型，PQ 的一个缺点在于，没有类似于 PTLC 的东西，除非使用某种非常重的简洁证据。

却决于在我们真正需要 PQ 签名的时候 Bitcoin Script 有多少能耐，我们甚至可以切换成全新的、更加 PQ 原生的通道类型。

支付哈希值：RIPEMD-160 → SHA-256

使用 Grover 的量子攻击者可以用 2^80 次搜索找出一个 RIPEMD-160 哈希值的原像（SHA-256 哈希值则是 2^128 次）。使用 BHT 算法，量子攻击者可以用 2^53 次搜索找出 RIPEMD-160 的一个碰撞。今天，我们使用 RIPEMD-160（其输出只有 160 比特）而不是普通的 sha2，以节省一些字节。但是，在后量子大陆上，一切都会变大，所以为了几个字节而摆弄脚本就完全没有意义了。RIPEMD-160 是传统的密码学，所以我们将在脚本的支付哈希值重使用 sha2 。

（完）