以太坊上的 NFT 合约常把 tokenURI 指向一个外部 JSON 文件；tezos 生态在 2020 年年中给出了另一种更系统的答案：TZIP-016 合约元数据。这份标准 2020 年 6 月 30 日创建、状态 Final，解决的是”合约有一堆不参与运行逻辑的信息——代码接口版本也好、一枚 NFT 对应的线下画作含义也好——该标准化地放在哪、怎么取”。它的定位不是代币接口本身，而是给所有合约（包括 FA2 藏品合约）装一块统一的铭牌。
入口定义在合约存储里。合规合约必须在 storage 里放一个标注 %metadata 的字段，类型是大写的 big_map：字符串到字节的映射，可以嵌在顶层嵌套对结构的任意位置，但不能藏在或类型、选项类型或映射内部。这个映射至少要有一个键为空字符串的条目，值必须是一条按规范书写的 URI，指向一份 JSON 文档。字节编码有条容易忽略的细节：值就是数据的原始字节流——URI 以 http 开头就直接存 0x68747470 打头的五个字节，没有 PACK 隐式打包、也没有引号转义层。
URI 的寻址方案是标准的第二层。它允许三类主流写法：普通的 http 与 https 外链；ipfs 方案，按 IPFS 的 URI 规范定位内容寻址文件；以及 tezos-storage 方案——把元数据直接存在链上合约的存储里。tezos-storage 有两种形态：tezos-storage:键名 表示”从当前合约的 metadata 大映射里取这个键”；tezos-storage://合约地址/路径 表示去另一个合约取。注意路径编码的严格规则：以斜杠开头、路径里的斜杠必须百分号转义，tezos-storage:hello/world 非法而 tezos-storage:hello%2Fworld 合法。还有一层防篡改设计：任何 URI 都可以再包一层 sha256://哈希/原URI——取回数据后先核对哈希再使用，把”内容可能被换”的链外信任变成一次本地哈希计算。
标准文本把自己的动机说得很务实：tezos 合约当时缺一把统一取元数据的钥匙，钱包、浏览器、集成方各写各的适配，生态碎片化。于是 TZIP-016 规定 JSON 文档的基础字段——名称、描述、版本，以及一个 interfaces 数组用来声明这份合约遵循的其他 TZIP 标准。这最后一条是整份标准的杠杆：FA2 代币接口（TZIP-012）、资产级元数据（TZIP-021）、钱包交互（TZIP-010）、名字解析（TZIP-022）等新能力，全靠合约在自己的元数据里登记接口标识，集成方读一眼就知道该用哪套方法对话。一份元数据 JSON 成了合约的能力注册表。
对 NFT 收藏者，这套结构的实际意义落在三处。第一处是”说明书在哪”：同一合约的 collections 与 tokens 级元数据可以用 tezos-storage 全部放链上，也可以 JSON 在外链——链上部分只要合约在就永远在，外链部分取决于托管方活得多久。第二处是”内容换没换”：tezos 市场页面显示的属性来自合约元数据入口，若作者更新元数据是走合约的更新入口改链上指针，任何工具都能验证构建标识与哈希；发现同一合约的图片在几天内变了，先查元数据 URI 与哈希层，而不是先怀疑渲染端。第三处是”能不能自动化核对”：big_map 加 URI 的组合让脚本可以批量拉取一个市场里所有合约的 JSON，做属性普查、外链存活检测——这些在纯外链 tokenURI 的世界里成本高得多。
最后一个常见误区值得点名：TZIP-016 是合约级标准，一枚一枚资产的字段清单归 TZIP-021 管，两层是分工不是替代——资产 JSON 往往正是通过合约元数据里的路径或视图被找到的。评估一个 tezos 藏品项目的耐久性时，正确的问题顺序是：元数据 URI 用的哪种方案、有没有哈希包装、更新入口归谁控制；这三个答案基本决定了”十年后这幅图还在不在、还是不是这幅图”。
本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。