一枚 Cardano 原生资产的名字后面，永远跟着一串 40 个十六进制字符的资产政策 ID。它不是登记处发的编号，而是铸币规则那段脚本本身的哈希：谁掌握了脚本认可的密钥，谁就有权继续铸造。规则能读、ID 能算，铸币权限才算真看懂了。CIP-29「Phase-1 Monetary Scripts Serialization Formats」就是把这段脚本的两种书面写法统一起来的规范——2020 年 8 月由 IOHK 的 Matthias Benkort 起草，状态 Active。
脚本是积木，规则可以读出来
第一阶段货币脚本（原生脚本）由六种积木拼成：sig 要求某个密钥哈希签名；all 要求全部子脚本通过；any 只要一个子脚本通过即可；atLeast 设一个最低通过数；before 与 after 按槽号划时间窗。多签可以表达成 all 套多个 sig，带时限的授权可以用 before 圈死窗口，「三个董事里两人点头、或董事长在任意时刻单独放行」这类规则，则用 any 套 atLeast 加一个独立 sig。铸币政策是这些积木最常见的用户：把项目方密钥与时间窗拼进脚本，《发币那把钥匙放哪一层？CIP-1855 给铸造策略密钥排的派生号》签上见证，铸造才成立。
链上只认 CBOR，政策 ID 的算法藏得很直白
CIP-29 规定的第一个格式是 CBOR，它逐字节等于链上表示，内容直接取自 cardano-ledger 规格。需要脚本哈希时，规范写明：取 CBOR 序列化字节串、在前面拼一个空字节，再做 Blake2b-192 摘要。资产政策 ID 正是这条哈希的十六进制写法（24 字节、40 个字符）。前缀空字节的用意提案解释过：与其他类型的哈希划清界限，防止拿错材料碰出同一个数。
JSON 是给人和接口看的
第二种格式是 JSON 模式，type 字段写明积木种类、参数各归各位，形如一条 sig 记录：
{"type": "sig", "keyHash": "00000000000000000000000000000000000000000000000000000000"}提案建议命令行、API 这类需要人眼检查的界面用 JSON，而把 CBOR 留给链上与见证。官方测试向量给出了两组格式一一对应的例子——嵌套的 all 包 sig 加 any 包 after，对应一长串 820182… 开头的 CBOR 字节；简单脚本也有短例，一条 before 槽 42 的脚本 CBOR 只有 8205182a 四个字节。
大整数：解析器要有心理准备
规范专门提醒：脚本里允许出现无界整数，至少 64 位以上的数必须能处理。这与多签场景直接相关——atLeast 的计数、时间窗的槽号都可能落在普通整型边界之外，工具若悄悄截断，拼出的脚本和算出的哈希就全变了。
对读者意味着什么
把这层机制装进脑子，核验一枚资产的铸币权限就有了三步：在浏览器或工具里取回资产政策 ID；拿到对应的原生脚本（JSON 形态最好读），确认它写的是密钥签名、时间窗还是组合条件；对照脚本里的密钥哈希，判断铸造权实际在谁手里、有没有到期日。同一份脚本在任何工具里都应转成同一段 CBOR、同一个政策 ID——两份结果对不上，说明至少有一边的实现不守 CIP-29 的约定，该结果先别信。
为什么只有 CBOR 有资格被哈希
CIP-29 的标题里写着 Phase-1，指的是第一阶段货币脚本：sig、时间窗、计数条件这类声明式组合，不执行任意代码，资源消耗在构建时可以精确算出，所以第一阶段验证就能处理完毕。Plutus 脚本是另一类东西——真正被执行的程序，有自己的一套序列化与哈希纪律，不在本规范射程内。而即便同一段原生脚本，JSON 写法对键序、空格的容忍度也比字节串高：同一份规则完全可以排出两种都合法的 JSON。政策 ID 若跟着 JSON 走，工具一换、哈希就变，铸币授权会当场失去确定性。所以规范的分工很清晰：JSON 负责让人读明白规则，CBOR 负责被哈希、被上链、被当作政策的身份。顺带一提，原生脚本能表达的规则有限，遇到「必须同时满足复杂条件」的政策，项目方通常直接上 Plutus 脚本，此时链上挂的是脚本哈希加 Datum 的组合，读法又换一套。弄懂 CIP-29 的价值正在于此：先分得清你面对的是哪一类脚本，再谈读规则、算哈希、判断铸造权的归属。铸币规则只回答「谁还能发」，不回答「值多少钱」，本文不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。