当前位置：首页 → 资讯 → 软件资讯 → Cardano拟增抗量子验签：两类算法进入合约，钱包签名为何仍未改变

Cardano拟增抗量子验签：两类算法进入合约，钱包签名为何仍未改变

发布时间：2026/11/3 4:56:47来源：游吧乐编辑

Cardano在11月1日的提案周报中讨论了抗量子签名，但持有ADA的用户今天还不能据此认定自己的钱包已经完成升级。Quantova提交的CIP-0206候选草案，目标是在Plutus智能合约中增加两种验签函数。本次查询官方仓库时，1300号拉取请求仍为开放状态，尚未合并。它值得关注的地方，是把算法选择推进到具体编码、拒绝规则与测试向量；真正决定应用能否使用的原生实现、费用模型和硬分叉安排，则仍在后面。

先确定一笔签名究竟保护哪层授权

据Crypto.news对11月1日周报的报道，这份提案由Quantova提出，选择了ML-DSA与SLH-DSA。对应的美国国家标准与技术研究院标准是FIPS 204与FIPS 205，均于2024年8月13日发布。NIST对这类方案使用的是能够抵抗大型量子计算机攻击的安全判断，而不是对所有实现和所有使用方式作无条件保证。算法标准、软件实现与链上应用，需要分开核验。

草案提出的接口接收公钥、消息和签名，返回验签结果。这个能力可以让合约检查一段符合相应格式的授权消息。合约能够验证抗量子签名，不等于现有账户的交易签名会自动更换。用户怎样登记新公钥、旧权限能否继续控制资金、紧急恢复由谁发起，都属于应用或后续账户迁移设计。只增加一个验证入口，无法回答所有资产授权路径是否都得到保护。

因此，评估一款未来声称采用该方案的钱包时，应该沿资金支出路径核对：新的签名检查是否是转账的必要条件，还是仅用来验证一份附加证明。如果原有密钥仍可单独完成资金转移，那么额外的证明功能与最终支出授权之间，就还没有形成同样强度的约束。这是权限结构的区别，不能用一个“抗量子”标签省略。

Binance全球顶级交易所 v3.22.4

类型：金融理财大小：306.2M语言：多国语言[中文]时间：11-2评分：10.0

两种算法提供选择，不代表每次都要求双签

ML-DSA以格问题为安全基础，SLH-DSA依赖哈希技术。草案选择两个不同技术家族，是希望在一种假设出现弱点时，仍保留另一种路径。这种设计的价值在于可迁移性：开发者不必把所有应用长期绑定到单一算法，未来也可以通过新的算法标识扩展格式。

不过，提供两种验签函数，与同一笔交易必须同时通过两种签名，是两个不同的规则。草案列出的是独立接口，并没有把所有应用改成默认双重授权。若应用只调用其中一个函数，它获得的是该方案对应的验证能力；若开发者希望建立组合条件，还须明确两种验证是同时必需，还是任一通过即可。后者在故障恢复上更灵活，却也可能把授权强度降到较弱的一条路径。

下面是两类验证路径的概念插图，表示合约可以选择不同验证方式，不表示主网已经部署，也不表示每笔交易都执行两种算法。

两类签名进入合约验证路径的概念插图

这种取舍也影响密钥管理。更复杂的组合可以分散算法风险，同时增加备份、恢复和签名设备适配的工作。应用应说明恢复流程是否绕开新条件，否则日常路径使用新算法，恢复入口却仍由单一旧密钥控制，实际安全边界就与宣传不同。这里没有一个适用于所有账户的固定答案，关键是把每个能够支出资产的入口列全。

先识别算法，再判断签名是否有效

草案把公钥和签名封装为带版本的对象，依次包含版本、算法标识、对象种类与内容。算法标识采用两个字节，避免仅凭字段长度推断算法。这样做并非包装上的细节：长度相近的数据不一定属于同一方案，而未来新增参数组时，显式标识能够让旧实现明确拒绝不支持的对象。

提案还区分了两种失败。格式正确但签名验证不通过，返回假；版本、类型或长度不符合规范，则令求值失败。对合约开发者而言，这会影响错误处理与资源消耗。把输入当作普通字节串传入之前，需要检查自己是否正在把签名放到公钥位置、混用不同算法，或者接受了少一个字节的对象。不能只测试一份正常签名通过，就推断输入边界全部正确。

官方草案附带的测试说明覆盖消息被改动、签名内容被改动、公钥不匹配、算法家族不匹配及错误长度等情况。这些材料提供了实现之间对照的目标。作者报告的参考测试与交叉验证有其价值，但本次没有独立运行全部密码学实现，也不能把作者的测试声明当作正式链上版本已经通过审计。

编码一致只是上线条件中的一部分

下面的英文内容为已核实草案的原文摘录排版，非网页截图。它明确把原生基准测试和硬分叉安排列为后续事项，不能据此给出主网上线时间。

CIP-0206原文关于原生费用模型的摘录排版

即使两个库对同一测试向量返回相同结果，也仍要确认节点所用版本、编译环境与异常处理一致。验签进入共识关键的求值器后，不同节点对同一输入必须得到同样的结果。对应用来说，这比单台设备上的演示更重要；某个库能够运行，只证明一段实现具有可测试性，不能代替网络升级与节点采用。

签名体积会进入交易预算，演示速度还不是链上费用

草案给出的ML-DSA-44公钥为1312字节、签名为2420字节；ML-DSA-65对应1952字节与3309字节。SLH-DSA-SHA2-128s的公钥仅32字节，签名却达到7856字节。这里比较的是草案列出的算法本体长度，版本封装及交易其他部分还需要额外空间。公钥更短，不能直接推出整笔交易更小。

这会把应用设计拉回实际约束。如果一个合约要同时携带多份签名，还要放入业务数据和其他见证，单次操作的空间需求就会上升。是否能够拆分授权、提前登记公钥或减少重复数据，要由具体实现验证；简单把新签名替换进原有多签流程，可能改变一笔交易可容纳的参与人数。这是需要测量的容量问题，而不是算法名称能够回答的问题。

草案列出的参考验签时间来自单核JavaScript实现，并明确说明它们只用于提示相对成本。这些毫秒数不能当作Cardano链上手续费，也不能当作主网吞吐量承诺。原生实现需要重新做基准测试，再校准Plutus费用模型。消息长度、算法参数和多次调用共同决定实际资源需求，不能只拿其中最快的一项作为产品性能。