Cardano 允许普通交易附带一段链下备注（元数据），它不是自由文本，而是一份以整数标签分区的结构化对象。你看到的每条藏品说明、每个登记信息，第一层都是某个整数——这个整数从哪来、归谁用，由一份叫 CIP-10 的登记规范管着。本栏目讲过 CIP-25 怎么用元数据描述一枚藏品（见 不用智能合约的 NFT：Cardano 上 CIP-25 怎么描述一枚藏品），也讲过 CIP-26 的链下注册表（见 CIP-26 链下元数据注册表：Cardano 怎么给一串哈希配上名字与小数位），这两条标准能在同一笔交易里各行其是，靠的就是下面这套分区规矩。
元数据的结构：整数标签的映射表
CIP-10 原文给出的 CDDL 定义里，交易元数据是一张从 transaction_metadatum_label 到元数据本体的映射，标签是无符号整数；元数据本体可以是嵌套映射、数组、整数，或者带 (0..64) 大小约束的字节串与文本。这样设计带来两个官方明说的便利：节点可以按标签快速检索使用某标准的交易；同一笔交易可以并列多个互不相干的元数据条目。代价显而易见——如果两个项目用同一个数字装不同内容，检索和解析都会撞车。
编号区与登记流程
规范本体很短：0 到 15 整体保留；65536 到 131071 保留给私人用途，项目在自己的封闭系统里自便，不与其他标准相争；其余区间靠 registry.json 登记。想占一个新标签，向这份文件提 PR，写清项目背景、文档或预期用途。截至本文核验（2026 年 10 月抓取仓库当前版），登记簿已收录五十余条，例如 721 对应 CIP-25 的 NFT 元数据标准，94 对应 CIP-0094 的链上治理投票，标签数字与用途一一对应。CIP-10 还给了自助查重的办法：通过 Koios 公共 API 的 tx_by_metalabel 查询（形如 curl -s "https://api.koios.rest/api/v1/tx_by_metalabel?_label=8414"）看某个标签在链上是否已有人使用。
长度上限与拆字段
规范里 (0..64) 的约束按 CDDL 原样读，是单个文本与字节串条目的长度上限，而不是整段元数据的总量：要装下更长的内容，标准做法是拆成数组或多个字段再拼回去，CIP-25 藏品元数据的分块写法就与此有关。用户从工具里看到的”一句完整说明”，在链上很可能被切成数段存放——核对原文或哈希时，拼接顺序错了会得到不同结果，这是复制元数据做链下比对时最容易翻车的地方。另一处常见误读是把标签当分类树：65536 到 131071 是留给私人使用的连续区间，并非某个项目独占；登记簿里的单个标签也可能只有描述而不绑定正式标准文档，拿到陌生标签，先查登记说明，再决定用什么解析器读它。
登记不等于审核
需要把边界讲清楚：登记簿管的是编号不撞车，不是元数据写得对不对，更不是内容可信。任何账户都能在已登记的标签下写数据，钱包按标签挑选解析器，解析得出就展示、解析不出就忽略；同名标签下的恶意仿冒内容，CIP-10 本身不负责拦。这与地址格式、签名校验那类协议强制规则不同，属于行业协作约定，约束力来自工具开发者集体遵循。
用户侧怎么用
对普通用户，这套机制落到三个具体动作。其一，核对一笔交易的链上备注时先看标签号：标签决定了该按哪份标准读内容；其二，拿到藏品元数据时，确认工具解析用的标签与项目文档声明一致，两边对不上就要求项目方解释，而不是二选一盲信；其三，怀疑某编号被抢注或混淆时，把标签号和交易哈希一起放进区块浏览器或 Koios 查询，用交易时间线说话。登记簿只增不改的惯例也意味着历史标签会一直挂在链上，早年的项目名与今天的归属可能分家，涉及资产的判断仍要回到合约与发行方本身。以上是机制与核对路径，不构成投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。