
Solana 需要做出哪些改变,才能为量子时代做好准备?
特别感谢 Kobi、Lostin、Quentin、Ichigo、Aseneca 和 Dean 审阅本文的早期版本。
近几个月来,各种危言耸听的说法广泛流传,声称我们只剩几年时间迁移到后量子密码学,而 Solana 将成为这种情境下最早的受害者之一。无论人们认为这件事有多紧迫,也无论是否认同这些说法,梳理一下在当前条件下 Solana 若要迁移到后量子密码学,协议需要做出哪些改变,仍然很有帮助。
量子计算简介
量子计算是一种有别于经典二进制逻辑模型的计算范式。量子计算机并非严格以 0 和 1 处理信息,而是使用量子比特——遵循量子力学规律的物理系统。一个量子比特可以同时处于多个状态(这种性质称为叠加),使量子处理器能够并行探索许多可能的解。
量子计算的重要意义并不在于加速所有计算,而在于加速非常特定的问题。尽管理论上能力强大,但当今的量子设备距离以有意义的规模运行这些算法还很遥远。
没有人知道量子计算机何时,甚至是否能达到足以威胁现代公钥密码学的规模。要破解 Ed25519 等方案,量子计算机需要数十万到数百万个稳定的量子比特、质量极高的纠错机制,以及足够长的相干时间,才能运行 Shor 算法等深层量子电路。如今,这样的机器还只存在于理论中。现有量子处理器使用的是噪声大、寿命短的物理量子比特,其错误率远高于任何有实际意义的密码破解尝试所能接受的水平。当前最先进的设备只有数百到数千个物理量子比特,而非逻辑量子比特;其量子门保真度和相干特性距离实际攻击所需水平仍有数个数量级的差距。
即便如此,量子计算的潜在长期影响依然十分重大,因此包括区块链在内的安全关键型系统必须考虑迁移到后量子密码原语需要做些什么。
量子攻击
现代密码学依赖经典计算机无法高效攻破的困难性假设。量子计算机带来了两种威胁不同密码原语的主要算法:Shor 算法和 Grover 算法。
Shor 算法可以高效破解 RSA、Diffie–Hellman,以及对 Solana 尤为关键的椭圆曲线密码学(即允许攻击者从公钥推导出私钥),其中包括 Solana 协议广泛使用的核心签名方案 Ed25519。因此,Shor 算法构成了切实的长期量子威胁。
Grover 算法只能为暴力搜索提供平方级加速。它会将 SHA-256 的有效安全强度降至 128 位,但这仍远超任何现实的威胁范围。对于对称密码学、Merkle 树和哈希计算,扩展经典硬件仍比构建能够大规模运行 Grover 算法的量子机器更具成本效益。因此,对于 Solana 的长期安全模型,Grover 算法并非现实威胁。
由于大规模量子计算机会从根本上攻破当今的公钥密码学,一个名为后量子密码学(PQC)的完整领域应运而生,旨在开发即使面对量子攻击也能保持安全的方案。
到目前为止,NIST(美国国家标准与技术研究院)已将两种后量子数字签名方案标准化:
- ML-DSA:基于格,由 CRYSTALS-Dilithium 衍生而来
- SLH-DSA:基于哈希,由 SPHINCS+ 衍生而来
两者使用的公钥和签名都远大于当今使用的椭圆曲线密码原语。因此,除非量子计算机成为迫在眉睫的威胁,否则对于 Solana 这样的高吞吐量系统,提前迁移并不现实。
此外还有 FN-DSA(基于 FALCON,设计目标是成为比 ML-DSA 更小的替代方案),但它目前仅以提案草案的形式存在,尚未成为 NIST 批准的标准。
| 方案 | 公钥大小 | 签名大小 | 安全强度 | 已支持后量子安全 |
| Ed25519 | 32 B | 64 B | 128 位 | 否 |
| ML-DSA | 1312 B | 2560 B | 128 位 | 是 |
| FN-DSA | 897 B | 666 B | 128 位 | 是 |
| SLH-DSA | 64 B | 7856 B | 128 位 | 是 |
后量子密码学仍处于非常活跃的发展阶段。很可能早在能够运行 Shor 算法攻击 Ed25519 的量子计算机出现之前,就会有更高效的方案问世。HAWK 签名等早期非标准化方法看起来很有前景,但仍处于研究阶段。
随着互联网带宽遵循尼尔森定律增长,而且 Solana 的交易大小上限已计划在 2026 年提高到 4096 字节,在为协议最终迁移做好准备的同时,推迟全面 PQ 迁移直至更高效的方案出现,是合理的选择。与此同时,也可以依赖基于成熟哈希型一次性签名方案(如 Winternitz)的金库结构,即使面对量子攻击,这类方案也能提供长期安全性。如今 Solana 上已经有此类解决方案。
本文仅关注 Solana 中依赖 Ed25519 且对共识至关重要的部分。全面的后量子迁移还会涉及其他组件,例如验证者通信、加密网络通道和对称密码学。这些领域同样需要支持 PQ 安全的替代方案或混合方案,但不在本文概述的范围内。
地址与交易签名
Solana 的外部拥有账户(EOA)以其公钥作为地址,Ed25519 的 32 字节公钥同时充当标识符和验证密钥。后量子方案会改变这一模型,而此类变化自然应通过新的地址格式和交易版本引入,而不是修改现有的 TX 格式。
- PQ 公钥要大得多,因此 32 字节地址无法再直接编码公钥。地址将改为 PQ 公钥和签名方案标识符的哈希值。
- 如果在迁移期间 PQ 地址与现有 Ed25519 地址共存,就必须构造地址空间,确保 PQ 衍生哈希值不会与 Ed25519 曲线上的点发生碰撞,从而保证这些地址不存在对应的 Ed25519 私钥。这与 PDA 使用 bump seed 来避免成为有效 Ed25519 曲线点的方式类似。
- PDA 的安全性不受影响,因为 PDA 依赖 SHA-256 的第二原像抗性,而 Grover 算法未来任何可预见的应用都无法威胁这一特性。
- 如今的交易 ID 是交易中的第一个 Ed25519 签名。由于 PQ 签名大得多,这种方式必须改变。一种自然的替代方案是将交易 ID 定义为交易载荷的哈希值,使其与签名方案无关,并具备面向未来的兼容性。
除了用户账户,Solana 中的所有权限密钥也都是 Ed25519 公钥。这涵盖协议或程序层面的各种权限:账户所有者、铸造权限、冻结权限、升级权限、质押与提取权限、验证者身份密钥,以及投票权限密钥。它们本质上都只是承担不同语义角色的 Ed25519 密钥对,因此面临与用户地址和交易签名密钥相同的后量子迁移约束。
正如 Votor 一节将介绍的那样,目前还没有与 BLS 等聚合签名相对应的 PQ 方案。如果未来出现这样的方案,我们也可以对消息正文的签名进行聚合,从而为包含多个签名的交易节省大量空间,甚至可能比 Ed25519 占用的空间更少。
Votor
Votor(即 Alpenglow 共识升级中的投票部分)采用验证者之间全互联的投票结构。验证者在每个 slot 向所有其他验证者发送投票,达到法定票数后即可形成证书。
目前,这种方式十分高效,因为 BLS 聚合能够提供紧凑的签名和聚合证书。但在 PQ 环境中,情况会发生变化。
目前还没有可实际部署、与 BLS 聚合对应的 PQ 方案。现有若干研究方向,包括 Chipmunk 等基于格的聚合思路。尽管它们从根本上看都并非不可实现,但效率仍不足以满足 Solana 的实时要求。此外还有基于 STARK 的聚合方法,原则上可以证明大量签名的有效性,但为数百个验证者签名生成证明仍然太慢……至少目前如此。
如果近期必须转向签名聚合,可以调整 Votor,大幅降低带宽影响。验证者不再向所有对等节点广播完整证书,而只将其转发给接下来的一到两位领导者,以及由少量质押权重随机选出的验证者。带宽需求会增加,但仍与当前 Alpenglow 之前的 gossip 层相当。
当然,减少验证者数量也能缓解这一问题。如果未来的协议变更或经济设计使验证者集合大幅缩小,那么 PQ 时代投票和签名处理所需的带宽与计算资源将更容易管理。更少的验证者会缩小全互联通信的规模、降低证书形成成本,并让效率不够理想的 PQ 聚合方案在实践中也更具可行性。然而,这种缩减会在去中心化和容错能力方面带来取舍,因此必须结合系统的安全目标谨慎权衡。
Rotor(Turbine)
Rotor(Turbine 协议的后继者)是 Alpenglow 升级中的数据传播协议,也是 Solana 用于快速高效传播区块的单中继网络。其工作方式是由领导者将区块拆分为更大的单元,称为 slice(或前向纠错集),每个 slice 由多个 shred 组成。slice 提供前向纠错结构,而 shred 则充当通过 Rotor 传播的 MTU 大小数据包。随后,领导者只将 shred 发送给树形结构第一层中的少量节点;每个节点验证 shred 后,再将其转发给自己的子节点。这种方式以容错形式利用多个节点的带宽,而无须领导者向所有节点广播。由于 Rotor 将这一结构与前向纠错结合,节点只需接收部分 shred 即可完整重建区块,因此系统既能抵御数据包丢失,又能保持极高的吞吐量。
为防止恶意和无效 shred 在网络中传播,每个 shred 都包含领导者签名。由于 Ed25519 签名很小,这种方式能够正常工作。PQ 签名要大得多,并且通常超过 MTU 限制,因此无法在每个 shred 中嵌入一个 PQ 签名。
由此可以得出两种现实且兼容 PQ 的方法:
A)每个 slice(FEC 集)使用一个签名
一种可行的方向是:
- 增大 slice(FEC 集)的大小
- 对验证者之间的通道进行身份验证,防止恶意节点注入无法追踪的伪造 shred
- 对该 slice 中的所有 shred 计算 Merkle 根,并让领导者只对该根签名(如今系统已经这样运作)
- 每个 shred 都包含其 Merkle 证明,但不包含签名
验证者依据已签名的根,通过 Merkle 证明验证 shred 的真实性。无效 shred 会被立即拒绝,从而保留流水线处理能力,并维持与 Rotor 基于质押权重的中继设计的兼容性。
B)整个区块使用一个签名
另一种可行的方法是:
- 领导者只对最终区块哈希(即所有 shred 的向量承诺)签名
- shred 在整个 slot 期间持续转发,不进行任何即时的签名身份验证
- 区块完成后,验证者验证这一个 PQ 签名,并检查收到的所有 shred 是否与经过身份验证的区块哈希匹配
在此模型中:
- 验证者无法在 slot 期间检测无效 shred,因为只有看到区块签名后才能验证真实性
- 区块完成后,无效 shred 会被检测出来;系统可以识别相关中继节点,并在 Rotor 内暂时将其列入黑名单
- 这种方法同样要求验证者之间使用经过身份验证的通道
这两种策略都避免了在每个 shred 中嵌入大型 PQ 签名,而这正是 PQ 环境下 Rotor 面临的主要瓶颈。
常见误解
误解 1:“如果量子计算机攻破了非对称密码学,我们面临的问题肯定不只是加密资产被攻破。”
人们经常声称,一旦量子计算机能够攻破公钥密码学,整个数字世界就会同时崩溃:银行、政府、支付网络,无一幸免。实际上,中心化系统可以更轻松地迁移到新的密码技术。银行或政府可以在内部轮换密钥、更新基础设施,并强制用户采用新的安全通道。
公有区块链却无法这样做。区块链无法在没有用户亲自签署迁移交易的情况下,集中轮换数百万用户的密钥。每位用户都必须使用当前私钥(而这恰恰是正在变得脆弱的部分)将资产转移到后量子安全地址。与任何中心化服务相比,这使去中心化系统的迁移复杂得多,也更具时间紧迫性。
误解 2:“如果你从未用某个地址支出过资金,就是安全的。”
这只对部分区块链(例如 Bitcoin)成立。在这类设计中,代币通常锁定在哈希值之后(例如 P2WPKH),只有当用户从该地址支出时,公钥才会公开。在此之前,实际公钥处于隐藏状态。但只要发生一次支出,这种保护就会消失。公钥一经公开便会永久暴露,而在后量子时代,它将成为 Shor 算法的攻击目标。
然而,Solana 使用了不同的模型:每个地址都是公钥。它没有“隐藏”层,也没有通过哈希提供的原像保护。因此,一旦出现足够强大的量子机器,Solana 上的每个外部拥有账户默认都会受到 Shor 算法的威胁。这里不存在未支出地址的安全保障。
误解 3:“量子计算机很快就会到来。”
尽管过去一年取得了令人瞩目的工程进展,量子计算机的能力仍极其有限。如今的设备只能运行玩具级的 Shor 算法,通常用来演示分解 21 之类的数字。这种任务微不足道,不具备任何真正的密码分析价值。
要攻破现代密码学,需要数十万到数百万个稳定的量子比特、极低的错误率、较长的相干时间,以及深层、经过纠错的电路。
误解 4:“Grover 算法会让哈希函数失去作用。”
Grover 算法可以为暴力搜索提供平方级加速。对于 SHA-256,这意味着将 256 位安全强度降低到约 128 位。这仍远超任何现实的攻击范围,尤其是考虑到构建一台能够大规模运行 Grover 算法的量子机器本身就极其困难。
对于对称密码学、Merkle 树和基于哈希的结构(包括 Solana 上的 PDA),扩展经典计算能力比依赖量子攻击更便宜,也更现实。
误解 5:“量子计算机可以从你的公钥中提取助记词。”
没有任何量子算法能够神奇地从公钥推导出助记词。助记词并未以数学形式嵌入公钥,也不存在任何可逆映射,能通过公开信息暴露钱包助记词。量子计算机可以从公钥推导出私钥,但无法进一步向“上游”追溯并重建最初生成该密钥对的助记词。
助记词通过单向密钥派生函数生成私钥,而 Shor 算法无法逆转这些函数。量子攻击者一旦获得你的私钥,就已经会造成灾难性后果——他们可以签署交易——但仍无法克隆或恢复你的助记词。你可以使用不同的派生路径,通过该助记词保护新的 PQC 密钥。
结论
Solana 短期内无须迁移到后量子密码学。要完成迁移,需要更改交易格式以容纳更大的 PQ 公钥,增加逻辑以确保派生的地址哈希位于曲线之外(可能使用 bump/salt 避免碰撞),并支持在运行时中验证多种 PQ 方案。最大的成本将是交易大小增加和验证计算量上升,因为 PQ 签名的处理成本高于 Ed25519。实用量子计算机的出现时间预测从“几年后”到“永远不会”不等,而当今的 PQ 签名方案对于围绕极高吞吐量优化的系统来说,体积很大且速度较慢。
但如果最终确实需要迁移,其路径在概念上十分清晰。这些改变没有一项是不可能实现的,但它们会重塑 Solana 中一些对性能最敏感的子系统。好消息是,当可信的量子威胁真正出现时,密码学格局很可能已经大不相同,届时也可能会有高效得多的 PQ 密码原语。
参考资料
相关文章
订阅 Helius
及时了解 Solana 开发的最新动态,并在我们发布新内容时收到更新


