在 Cardano 的工具链里复制一串密钥，最常见的挫败不是密钥错了，而是外皮不通用：同一把扩展签名密钥，在有的实现里是 128 字节，在另一些实现里是 96 字节，还有工具干脆用它自定的 JSON 文本封装。CIP-16 就是为了结束这种局面而写的，标题是 Cryptographic Key Serialisation Formats，状态 Active，起草日期 2020 年 12 月 21 日，类别归在工具类。
它先记录了一个尴尬事实
提案开篇举的例子就是问题本身：对 BIP32-Ed25519 扩展签名密钥，cardano-crypto 的实现支持 128 字节的二进制序列化，而 jcli 与 cardano-addresses 支持 96 字节；cardano-cli 又是另一套叫作 text envelope 的自定义 JSON 格式，别的项目读不了。后果落在两个人身上：用户没法在不同软件和工具之间自由使用自己的密钥，开发者要支持多种格式就得写容易出错的序列化与转换代码。
四种格式与它们的字节构成
规范一共定义四种。验证密钥（公钥）就是原样的 32 字节 Ed25519 公钥数据。扩展验证密钥是 64 字节，前 32 字节是 Ed25519 公钥、后 32 字节是链码。签名密钥（私钥）是原样的 32 字节 Ed25519 私钥数据。扩展签名密钥是 96 字节，前 64 字节是 Ed25519 扩展私钥、后 32 字节是链码。四种都再套一层 Bech32 编码，用哪个人类可读前缀由 CIP-5 决定，因此你在工具里看到的形态是 addr_vk、addr_xvk、addr_sk、addr_xsk 这一类前缀开头的一串小写字母数字，质押密钥一侧对应 stake_vk、stake_xvk、stake_sk、stake_xsk，CIP-1854 的多签形态另有 stake_shared_ 开头的一组。
为什么扩展签名密钥取 96 而不是 128
原来那套 128 字节格式把扩展私钥、公钥和链码三段都装了进去。规范指出，那 32 字节公钥是冗余的：它能从 64 字节扩展私钥的头 32 字节直接推导出来。加上 jcli 和 cardano-addresses 等工具早已在用更紧凑的 96 字节格式，CIP-16 于是把 96 字节定为标准。这个取舍很值得记住，因为它意味着拿到一串自称扩展签名密钥的东西时，长度本身就是一条判据。
读到一串密钥时该怎么判断
第一步看前缀：vk 结尾的是只能验签与派生地址的公钥，sk 结尾的是能签名这一把密钥的私钥，带 x 的两种各自多带一个链码，属于扩展密钥。第二步看解码后的裸字节长度，32、64、96 三个数字里对不对得上。第三步才轮到用途：需要交出去让人查账的，走公钥或查看类材料；能签名的私钥只在本地或签名器里待着；扩展签名密钥因为可以继续沿树派生，权限最大，一旦泄露就不是单把地址的事。这个“前缀告诉你它是什么角色”的思路，和比特币那套用首字符区分外皮的私钥格式是同一家族的做法，细节可以在同一把私钥的几种外皮：WIF、十六进制与导入导出的格式边界里对照着看。
别把带链码的公钥当无害字符串
扩展公钥多带的那 32 字节链码，用途是让公开信息能继续沿树推导；具体能推到多远、是否支持你心里想的那种派生，取决于实现所采用的 BIP32-Ed25519 变体，不能一概而论。安全边界的讨论方式与比特币的扩展公钥是一致的：它不是私钥，但也不是纯粹的“一个地址”，把它交给观察型工具前要先想清楚要它看多少，比特币 xpub 扩展公钥是什么？观察钱包的安全边界里把这类边界拆开讲过。至于把派生路径再叠一层的事，属于BIP-44 派生路径怎么读：为什么同一句助记词，导入后地址却不一样那条线的话题，本文不重复。
现状与兼容处理
规范的状态是 Active，作者列出的实现方包括 jcli、cardano-signer 与 cardano-serialization-lib，走向 Active 的验收清单里“确认由不同开发者的应用与工具支持”一项已勾选。这不等于所有 Cardano 软件都放弃了旧格式：128 字节序列化与 text envelope JSON 至今仍在一些工具里活着。所以遇到导不进去的情况，先比长度、比前缀，看清楚是不是同一族外皮，再决定要不要转换；不要手工把一串 128 字节截成 96 字节塞进另一把私钥的槽里，那属于用错觉代替验证。密钥、链码、派生路径的泄露后果只跟谁拿到什么有关，与资产价格无关，本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。