在铭文的数据结构里，tag 1 装内容类型，tag 5 装任意元数据，而 tag 17 装的是一套全新的东西：Properties（属性）。按照 ord 官方手册的定义，它是”与 metadata 相对的、有协议定义含义的结构化数据”。两者的区别值得掰开讲清楚，因为这直接决定钱包和索引器”敢不敢用”这份数据。
metadata 是一段任意 CBOR，协议不规定字段含义，/inscription 页面把它当作自由格式内容展示；你可以往里塞任何键值，但别的实现无权假设里面有什么。Properties 则必须服从一份严格的 CDDL 模式：最外层是一个映射，键 0 是一个 Item 数组（展册条目，下一篇再展开），键 1 是 Attributes（属性块），键 2 是一段拼接后的字节（打包存放的条目交易 ID），此外允许任意额外的键值对——但手册明确要求：匹配通配 any => any 的字段必须被接受并忽略，为将来扩展留门。Attributes 里目前定义了两样：键 0 是标题（text），键 1 是 Traits（特征表）。Traits 是一张”名字到值”的映射，名字必须唯一，值只能是布尔、整数、null 或字符串四种之一。Item 则携带条目铭文 ID（32 至 36 字节）、可选的属性块和可选的序号键。
结构之外是体积规则，这也是铭文刻写的老约束在起作用：封套里单个数据推送不能超过 520 字节，所以超过 520 字节的 CBOR 必须拆进多个 tag 17 字段，解码前先拼接。同时 Properties 明确不支持 CBOR 的不定长类型——映射、数组、字节串、文本串都必须 definite 编码，解析器因此可以不用回溯地流式读取。
再往下是压缩与两道防线的组合。当 tag 19（property_encoding）写成字符串 “br” 时，属性内容按 Brotli 压缩存储，刻写时在 ord wallet inscribe 或 ord wallet batch 上加 --compress 即可。为防”解压缩炸弹”，手册规定解压后的属性最大 4,000,000 字节；为防拒绝服务攻击，又规定解压倍率不得超过 30 比 1——例如压缩体 100 字节，解压后最多允许 3,000 字节。任何一条不满足——编码字段写了 “br” 以外的值、解压超限、倍率超标——ord 的处理方式都是把这条铭文当作没有属性，而不是报错拒收。
对普通收藏者，理解 Properties 的实用价值有两点。一是核验”属性从哪来”：标题、特征这类以前只能写在网站数据库里的字段，现在有协议定义的结构化载体，多个索引器理论上应当读出一致结果；读不一致时，可以先用支持 ord 新版本的本地节点对照。二是理解它不是作品本体：Properties 只是属性卡，图像、视频内容仍由内容与内容类型字段承载，“属性很全”与”内容是原始文件”是两回事。
协议为什么要把 Properties 做成强结构，而不是继续往 metadata 里塞约定俗成的字段？答案藏在多实现环境里。metadata 没有协议定义，同一个键在不同项目里含义各写各的，索引器只能按启发式猜；猜错了，属性墙、特征筛选、稀有度计算全部失真，而且没有任何一方”违约”，因为根本没有共同的格式承诺。Properties 反其道而行：先规定字段只能有哪几种类型（Traits 的值只允许布尔、整数、null、字符串，名字不许重复），再规定不认识的键必须接收并忽略，实现之间第一次有了”同一份字节读出同一份语义”的地基。对创作者，代价是自由：想放一段自由长文，仍然要回到 metadata 或内容本身；对使用者，收益是可移植：今天按这份模式建的筛选器，明年换一个索引器还能跑出同样的名单。
落到收藏场景，属性卡改变的是”稀有度争议”的举证方式。过去判断一枚 NFT 有没有”金背景”，靠的是某张排行榜网站数据库里的布尔字段，网站改版口径就跟着变；Properties 让特征以协议结构存进铭文自身，任何索引器都按同一份 CDDL 解码，理论上不再需要信任中间表。但也要清醒：写进属性卡的特征只代表铸造者当时的声明，官方口径、社区共识与链上字段的三方不一致依旧存在，尤其要警惕后加特征——铭文内容不可变，一个人却可以用新的 Properties 重新铸造一枚”同名不同史”的作品。 本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。