在 Cardano 上发一个自有资产，看的不只是「谁点了铸造」，而是「谁握着那把策略密钥」。一段铸造脚本（policy）里写明哪些密钥的签名被认可，铸币交易必须带上符合脚本约定的见证。随机生成这类密钥当然可以，但备份、移交、多人协作都麻烦。CIP-1855 给出的答案是：把策略密钥也纳入助记词的确定性派生体系。截至撰稿时，这份由 IOHK 工程师（Samuel Leathers 等四人）起草的文档在 CIPs 仓库中仍是 Proposed 状态，且 Implementors 一栏为空。
三层路径与两个编号
HD 钱包按 BIP-32 的层级派生密钥，路径用 m / purpose' / … 表达用途。日常钱包用 发一笔交易要来回问三次回执？EIP-7966 想把发送和回执合并成一个请求的思路，Cardano 专门定义了 purpose 1852。CIP-1855 则另开一个 purpose：1855'，币种沿用 1815'（SLIP-44 注册给 Ada 的编号），第三层是策略索引 policy_ix'，取值范围 2^31 到 2^32-1。示例路径形如 m/1855'/1815'/0'、m/1855'/1815'/1'——每个策略密钥都走硬化派生，索引直接表达在第三层上。
为什么不再拆 role 和 index
与 CIP-1852 不同，这里不使用 role 与 index 两层。提案的理由很直接：策略签名密钥目前不存在多种角色的区分需求，索引在第三层就表达完了，再多套两层只是徒增扫描成本。对照 用硬件钱包登录网站是什么原理？SLIP-0013 服务身份与签名登录拆解可以看出取舍：面向海量日常账户的路径需要「账户-角色-地址索引」的树形结构，而一把发币授权的钥匙不需要被成千上万次派生，扁平的三层结构反而更省扫描、更少歧义。
bech32 前缀：让钥匙的用途写在脸上
为了让人和工具一眼分清密钥类型，CIP-1855 向 CIP-5 的前缀注册表提议了新的 bech32 前缀：私钥 policy_sk、公钥 policy_vk、验证密钥哈希 policy_vkh（即对策略验证密钥做 blake2b-224 摘要）。注意它没有为扩展密钥定义前缀——提案的理由是当前看不到把策略扩展公钥交出去的场景，需要时再补。前缀的意义在于防呆：一串 policy_sk 开头的材料被误当支付私钥导入，工具可以当场拦下。
为什么值得挂到助记词上
提案的 Rationale 讲得很坦白：IOHK 的 ERC20 转换项目需要管理策略密钥，与其随机生成再单独备份，不如把密钥绑定到一句助记词上——备份只有一件事，交接也只需交接助记词；第三方若要用同一句助记词挂多个代币，就用不同的 policy_ix 区分。
硬币的另一面：助记词即发币权
把策略密钥收进助记词体系，意味着知道这句助记词的人能派生出全部策略密钥。托管助记词，就等于托管了发币权；审计一个项目的铸造权限时，除了看脚本里写的密钥哈希，还要看这把哈希对应的密钥究竟派生自谁的助记词、那句助记词现在在谁手里。多签与冷热分离的做法可以参考 《多签钱包连不上 dApp？CIP-106 给网页补上的四个接口》。
边界与核验建议
CIP-1855 仍是提案，不是强制规则：钱包可以不支持，导入导出时若无 policy_sk 前缀识别能力，就要退回按原样处理十六进制或 JSON 材料。核验一枚资产的铸造政策，最终以区块浏览器上的资产政策 ID 和链上脚本为准，本文不构成投资建议，也不涉及任何收益判断。
实操层面：钥匙进不了钱包怎么办
三层路径全部硬化，带来两个可以提前预判的后果。其一，hardened 派生下，光看账户扩展公钥算不出这些子公钥，想「只看不签」地盯住铸造权，得靠能同时访问私钥的命令行工具或全权限钱包，不能指望把一个扩展公钥交给观察员就万事大吉。其二，只实现了 1852 那条线的钱包根本不会去扫 m/1855'/1815' 分支，你把助记词导入十个钱包，可能没有一处在界面上显示这把策略密钥——这不是币丢了，是路径没被扫描。稳妥做法是：策略密钥的日常使用交给明确支持 CIP-1855 的工具或命令行，导入导出认准 policy_sk、policy_vk 前缀，交接时顺手用前缀做防呆校验。反方向的教训同样成立：拿到一串来历不明的密钥材料，先看前缀再决定导入哪个应用，把发币钥匙当支付私钥用出去，轻则签名失败，重则把铸造权暴露给不该看的人。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。