Cardano 上的 NFT 元数据方案分了好几代，CIP-25 往交易里的登记项塞 JSON，CIP-68 把数据挪进账户的 Datum 里另存。而 CIP-67 想补的是另一块拼图：给资产名字本身加一个类型标签。按仓库信息，这份 CIP 的标题是 Asset Name Label Registry，状态 Proposed，仍在征求意见。
它要解决的问题藏在 Cardano 的一条底层规则里：资产以”策略脚本加资产名”标识，同一条发行脚本可以发出成千上万种不同名字的资产。NFT、同质化代币、同一作品的不同版次，全挤在这个命名空间里，光看名字分不出谁是谁。CIP-67 的提案因此非常朴素：在资产名前固定放七位十六进制字符，不同的七位码代表不同类型，比如一种码代表 NFT、一种代表版次标签、一种代表 NFT 的同物副本；具体哪个码对应哪种类型，登记进公共的标签注册表，避免各家用法打架。
这套前缀机制的巧妙之处在于只动名字、不动合约：钱包和交易所不需要逐合约适配，解析名字前缀就能预判”这是个 1 of 1、那是个版次”，列表排序、版次聚合、防误操作提示都有的做。对发行方则是纪律：铸造脚本生成的名字必须带正确前缀，否则会被工具识别成”未标注资产”。
但 Proposed 三个字必须放大读。它意味着这份标准还在讨论与修订中：前缀的精确长度、与 CIP-68 的版本嵌套如何配合、注册表由谁维护、已发行资产怎么标注，都可能有变。仓库讨论区里针对编辑与修改的澄清讨论仍在推进，任何”Cardano 已经强制标签制”的说法都与当前状态不符。读 Cardano 生态的工具时，把它按三层理解最稳：CIP-25 是交易内元数据的老路线，CIP-68 是 Datum 内嵌的当前主流，CIP-67 是想叠在命名层上的类型标签——三者不是替代关系，是叠放关系。
给使用者的核对建议同样具体：如果你在 Cardano 上发 NFT，按所选标准的文档决定名字要不要带前缀，别只抄示例脚本；如果你在评估某个项目的元数据规范，把它引用的 CIP 编号与状态逐个点开看，Proposed 的条款只能当参考不能当依据；如果你在钱包里见到名字带长串十六进制前缀的资产，先查该项目是否遵循标签注册表，再决定怎么展示。标准演进的节奏很慢，但方向清楚：把约定从口头挪进可解析的结构里。本文不构成任何投资建议。
把三层放在一起举个具体例子：一枚按主流路线发行的 Cardano NFT，发行脚本的名字前缀遵循标签注册表，元数据按 CIP-68 的格式写进 Datum，钱包解析时先看前缀知道它是 NFT、再去 Datum 里取名称、图像与版次字段；若某天检索到一枚没有前缀的资产，钱包就回退到保守展示，不给它做版次聚合。这个例子也说明 Proposed 阶段的现实影响：注册表未定稿前，不同脚本作者可能选用不同前缀约定，工具之间的识别差异因此存在，同一枚 NFT 在两个钱包里显示不同不是幻觉，是标准间隙。想要确定性体验的用户，最稳妥的仍是选择明确声明遵循已定稿标准的发行方；发行方等到条款定稿再迁移前缀、并在公告里写清映射，是对社区负责的姿势。
再把 Proposed 这个词放回 CIP 流程里校准：卡达诺改进提案通常经历草稿、评审、待定等阶段，名字与流程细节以仓库当前约定为准，Proposed 一般意味着文本仍在征求实现反馈。它既不等于被否决，也不等于被采纳，唯一确定的确定是还不确定。写教程的人常在这一步失手，把某钱包已支持的解析实践当成标准定稿；引用时的安全句式是某钱包目前按某草案解析，而不是卡达诺规定如此。一词之差，决定读者是把这张地图当真还是当沙盘。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。