待解问题

Label 309 v1 已经冻结。元数据标签 309 下的线格式、规范 CBOR 编码、算法注册表、密封 PoE 信封以及签名构造均已敲定：一个符合规范的 v1 验证器能读取每一条 v1 记录，一个符合规范的 v1 生产者所产出的记录也能被每一个 v1 验证器接受。本页要谈的不是改动这些内容，而是登记标准在今天已确认的部分，以及仍属于前瞻性的部分：那些为可能的未来修订版预留的候选密码学构造，以及当其中某项落地时，更改一个密码学常量所遵循的有纪律的流程。

这里没有任何内容属于产品路线图。每一条都是协议层面的技术决定：一个算法标识符、一项派生、一条验证器策略，或一条版本控制规则。实现本标准的读者，需要已敲定的那一半来在今天构建出一个 v1 实现，也需要前瞻性的那一半，好让这套实现在面对未来某个后量子或纯 RFC 的后继版本时，只需新增一条注册表条目即可，而绝不必推倒重写。

已敲定的构造

这些都已经决定。之所以在此明确陈述，是因为它们正是实现者最常希望在同一处得到确认的承重选择；相关链接页面则承载着完整的构造细节。

后量子 KEM 已随 v1 一同交付

混合 KEM X-Wing（ML-KEM-768 与 X25519 组合而成）从首个版本起就以标识符 mlkem768x25519 注册在 enc.kem 注册表中。它并非未来的候选项：它存在于 enc.scheme: 1 之中，与经典的 x25519 KEM 并列，而线上的 enc.kem 字段会按记录逐一选定每个槽位的 KEM、槽位形态以及密钥加密密钥的派生方式。

X-Wing 是被当作一个黑盒来使用的：整个构造只用到它的公开接口（封装、解封装，以及那个 32 字节共享密钥），对组合器内部哈希不作任何假设。经典路径从其 HKDF salt 里的 pub_R 所获得的那条接收方绑定，在混合路径上改由一个外部 salt 提供，该 salt 就着槽位自身的线上字节算出：SHA-256("cardano-poe-xwing-kek-salt-v1" || kem_ct || pub_R)。把这串拼接哈希到固定的 32 字节，既把密文和接收方公钥绑定进了逐槽位的 KEK，又消解了变长后量子密文在裸拼接 salt 布局下会引发的解析歧义。对外只暴露混合变体：纯 ML-KEM 被刻意搁置，这样一来，万一 ML-KEM-768 哪天被攻破，X25519 这一支仍能保住经典安全性。参见 密封 PoE 和 算法注册表。

密封密钥承诺绑定头部与哈希主张

两条密封路径都把内容加密密钥承诺到一份封闭的转录上，并用信封其余部分所用的同一个规范 CBOR 函数加以序列化，该转录钉死了头部字段以及该项的明文哈希主张（hashes_hash）。在面向接收方（enc.slots）的路径上，承诺在链上：slots_mac 是一个由 CEK 加键的 HMAC，作用于一份承载着 scheme、path、AEAD 和 KEM 标识符、nonce、打乱后的槽集以及 hashes_hash 的转录之上——因此中继无法在不让链上 MAC 检查失败（且在任何密文拉取之前就失败）的前提下，把某段密文嫁接到一组不同的槽位或一份不同的哈希主张上。口令（enc.passphrase）路径则在一段 密文数据块之内 的 32 字节头部里携带一份等价的承诺，其转录额外加上 Argon2id 的 salt 和参数——于是篡改 KDF 输入就会让承诺检查失败。随后内容本身在一个由 CEK 派生出的内容密钥之下、被封装进一个分段 STREAM；逐块 AAD 为空，因为每个头部字段都已经传递性地绑定到了那把密钥上。完整构造见 密封 PoE。

确认深度属于验证器策略

一条记录在其交易被打包的那一刻起就已锚定，但验证器在给出裁定之前要求多大程度的最终结算，则取决于它所采用的确认深度阈值。Label 309 把这一点定为验证器策略，而非一项规范性的 MUST。标准只定义那块机器可读的接口：确认较浅时返回 pending 裁定，以及在突破某个已配置阈值时返回一个带类型的失败；而阈值本身（RECOMMENDED ≥ 15 个区块）则是一项由部署方配置的输入，并非烧录进线格式里的常量。一个对高价值主张要求更深结算的验证器，同样完全符合规范。参见 验证。

Ed25519 验证采用严格模式

记录级签名 MUST 按照 RFC 8032 §5.1.7 的严格规则验证，而不能采用更宽松的 ZIP-215 批量验证容忍度。严格验证会拒绝那些宽松验证器会接受的非规范编码和小阶点，因此两个符合规范的验证器面对同一个签名时，总会得出相同的裁定。实现者必须确认自己的 Ed25519 后端处于严格模式；有些库默认使用的是宽松变体。参见 签名。

规范 CBOR 是确定性约定

每一条记录都按 RFC 8949 §4.2.1 编码为规范 CBOR：整数取首选形式、数组与映射采用定长、映射键按字节序排序、无重复键、无标签。正是这种确定性，让一个实现对记录体计算出的签名能在另一个实现下通过验证，也让两个产出同一逻辑记录的生产者能输出逐字节一致的字节。这一点在每一个符合规范的实现中都没有商量余地，也是跨语言一致性约定的根基。

前瞻性候选项

下面这些是候选项，并非已交付的构造。没有一项是 v1 的缺陷，也没有一项已被承诺采纳。把它们记录在此，是为了让今天构建的实现给它们留出作为新增注册表条目的余地，也是为了让未来的评审者能看清，算法可演进（algorithm-agile）的设计已经预先考虑到了哪些演进方向。

一个预留的备选内容 AEAD 配置档

v1 密封 PoE 的内容层是 chacha20-poly1305-stream64k——即采用分段 STREAM 布局的 RFC 8439 ChaCha20-Poly1305——它本身就有 RFC 背书，因此关于当前内容密码的正式地位并不存在悬而未决的问题。仍然预留的，是在某个部署场景将来确有需要时、通往一个不同的内容 AEAD 的一条路径。标识符 aes-256-gcm（NIST SP 800-38D）正是为此目的预留在 AEAD 注册表中的，且不属于 enc.scheme: 1：一条命名它的记录在今天遵循未知信封规则。

引入它将是一个未来的 enc.scheme: 2 构造，它保留现有的 slots[] + slots_mac 与口令承诺模型，只把内容层替换掉，并为那种密码钉死新的分块大小、内容密钥派生、每块 nonce 的构造方式、每块 AAD，以及末块认证。它是一个回退配置档，而不是替代品：现有的 enc.scheme: 1 记录仍然有效，并且在 enc.scheme: 2 的规范性定义及其测试向量出现之前，这个配置档绝不可被实现。

预留的后量子签名算法

后量子轨迹的 KEM 那一半已随 v1 一同交付（见上文）。签名那一半已被预留，但尚未实现。一旦 IETF COSE 稳定下后量子算法标识符，有两个族系作为候选项可以纳入现有的签名注册表：

由于签名算法在 COSE 受保护头中是一个具名标识符，注册一个后继算法纯属新增之举：现有的 Ed25519 记录照样能通过验证，而一个不认得某新签名算法的验证器，只会报出一个不支持该算法的信号，而不会因此拒绝那条内容主张。一个无法识别的签名，永远不会让其背后的存在性证明失效。参见 签名。

一条可能的 v: 2 发布路径

单项新增（一个新的 KEM、一种新的内容 AEAD、一种新的签名算法）都是注册表条目，并不会改动顶层记录模式。尤其是一项 KEM 新增，属于 enc.scheme: 1 之下的注册表条目，而非一次 scheme 提升；enc.scheme 提升只为跨 KEM 的构造变更而保留，也就是一种一次性作用于所有 KEM 的新 slots_mac 或内容 AEAD。

如果会改动记录模式的候选项积累到足够多，那么这些累积起来的变更可能值得发布一条与 v1 并存的顶层 v: 2 记录。两个版本都将作为标签 309 下有效的元数据模式继续存在；验证器依据记录内部的 v 判别符来选择。通向标准化的那些步骤会针对新修订版重新走一遍。这是范围最大的一种演进，且只由累积触发，这里没有任何内容排定了时间表。

可选的单跳取代关系解析

一条记录的可选 supersedes 字段，会以交易哈希指向一条更早的记录。解析这个指针对验证器而言是可选的。一个验证器若只确认 supersedes 在结构上是一个 32 字节的哈希、却不去拉取此前那笔交易，它仍然符合规范，只是错过了揭示取代关系链的机会。指导建议：验证器 MAY 解析一跳，就所引用的那个哈希重新查询交易解析器，并报告它的存在性和区块时间，但不再向下递归。一跳足矣；更深的遍历是调用方的责任，而且取代关系从不撤销那条更早的记录，链上始终把它保留为可永久独立验证的状态。

迁移一个密码学常量

上述每一项已敲定的构造都依赖于一些具名常量：算法标识符、HKDF info 字符串、KDF salt、AEAD nonce 长度、域分隔标签。更改其中任何一个的含义都是一次线格式破坏，而标准为此规定了唯一一条有纪律的路径。统领性的规则是：采用能解决问题的最小范围变更，并且绝不在同一命名空间下悄悄更改某个已有常量的含义。

这套流程是新增且向后兼容的——旧记录会继续在它们发布时所用的常量下通过验证——并按范围逐级推进：

1. 给命名空间标版本，而不是给取值标版本。 一项派生发生改动时，会把它所涉及的每一个域分隔字符串上的 -vN 后缀递增：HKDF info 字符串（…-v1 → …-v2）、HMAC 消息前缀、salt 以及各类标签。新常量归入新后缀之下；旧常量在旧后缀之下仍然有效。较旧的验证器会在判别符处干净利落地拒绝较新的记录，而不会对它们做出误解。

2. 提升与影响范围相匹配的判别符。 一项局限于某个槽位族系的变更，由 enc.kem 选定；一项作用于内容层或槽位集合承诺的跨 KEM 变更，是一次 enc.scheme 提升；一项作用于记录模式本身的变更，则是一次顶层 v 提升。每个判别符都把破坏局限在实际发生改动的那个最小层级上。

3. 让前序版本保持可验证。 较旧的记录版本会作为冻结的模式继续可读。验证器依据记录自身的版本判别符来选择构造，因此单个实现能够并排验证 v1 与某个未来的后继版本。绝不会有任何一条记录因为某个后继版本上线而停止验证。

相关页面

• 算法注册表——那些命名空间会随迁移而标版本的具名标识符。
• 密封 PoE——X-Wing 混合 KEM、密钥承诺转录绑定，以及 enc.scheme / enc.kem 判别符。
• 签名——严格的 Ed25519 验证，以及那些预留的后量子算法将要加入的签名注册表。