铭文 Properties 字段：用 CBOR 把属性结构化刻上链，Brotli 压缩还带两道闸门

先给直观含义

铭文的 metadata 字段大家熟：刻一堆自由格式的 CBOR，索引器尽量渲染成人能读的样子。Properties 是它有条理的另一面：协议为属性头像这类场景定义了一套严格 schema 的 CBOR，装进标签 17 的字段。同样是刻属性，properties 承诺“所有按规范解析的程序看到的是同一组含义明确的键”，metadata 只承诺“尽量展示”。项目文档的原话很直接：metadata 没有协议定义的含义，properties 有协议定义的含义并且必须符合严格 schema。

结构里装了什么

按文档给出的 CDDL 描述（文档同时强调：参考实现 ord 才是规范性说明），properties 顶层最多三类内容：

• 键 0：Item 数组——这件作品包含的子件列表。每个 Item 可以带一段 32 到 36 字节的铭文 ID、一份属性（Attributes）或一个铭文 ID 索引，具体用哪种方式标识另一件铭文由集合约定。
• 键 1：Attributes——这件作品自己的展示信息，含标题与 traits（trait 名必须唯一，取值可以是布尔、整数、文本或空）。
• 键 2：一段字节串，存放画廊子项的交易 ID，用于把分散在多笔交易里的子铭文拼成一组。

通配位（* any => any）意味着解析器必须接受但不理解未知键，给未来扩展留门。协议同时不支持不定长 CBOR 类型：所有映射、数组、字节串和文本串都必须是定长编码，这是解析确定性的要求。

标签 19 管编码方式，值为文本 br 时，properties 要先做 Brotli 解压。文档给了两道防炸弹护栏：解压后最大 4,000,000 字节；压缩比最大 30 比 1——压缩后 100 字节的输入，解压结果超过 3,000 字节就判违规。刻写时用 ord wallet inscribe 或 ord wallet batch 加压缩标志即可生成。带问题 properties 的铭文（非法 CBOR、超限、压缩炸弹）会被 ord 当作没有 properties 处理。

单块数据推送 520 字节的限制依然适用：超过就拆成多个 tag 17 推送，索引时拼接回来。

它解决什么问题、不解决什么

解决的是“属性只活在市场数据库里”的尴尬：traits 直接刻进揭示交易，任何按规范实现的索引器都能重建属性表，不再完全依赖集合方的接口。对跨平台核验、对集合方更换服务商，这是一次实打实的去依赖。

不解决的是：它不规定 trait 的命名标准，一套集合一套叫法依旧常态；它也不阻止有人往展示属性里塞恶意名称；解压实现若不做防护会有资源消耗风险——30 比 1 与 4,000,000 字节这两道限制正是为此而写。

读一枚铭文的 properties

普通用户可以通过 ord 命令行或支持该字段的服务页面查看解析结果。开发者的路径是：取揭示交易里的 envelope，找 tag 17 的推送，按块拼接后做 CBOR 解码，若 tag 19 为 br 则先解压。建议的校验顺序是：先看 tag 19 取值是否合法，再校验压缩比与解压体积，最后按 CDDL 结构逐项走键 0、1、2。

顺带区分两件事：properties 与 metadata 可以并存，前者结构化、后者自由格式；市场页面展示的“属性”可能来自 properties，也可能来自项目自己维护的链下表格，看数据来源是核验的第一步。

解析器的行为边界

三条对写解析器的人特别重要的规则。第一，兼容姿态是强制的：properties 结构里带通配位，未来新增的键必须“接受但忽略”，这样旧解析器不会在新数据面前罢工。第二，不定长 CBOR 类型全部不支持，映射、数组、字节串、文本串都必须定长编码——这条不是风格偏好，是索引确定性的地基。第三，坏数据处理姿态是“降级而非报错”：非法 CBOR、超过解压上限、压缩比违规的 properties，ord 一律当作这枚铭文没有 properties，铭文本身照常可索引、可展示。另外提醒一次 520 字节的推送块限制：长属性要拆成多个 tag 17 推送再拼接，拼接顺序就是解码顺序。

风险提示：本文为铭文协议字段科普，不构成任何投资建议；字段语义以 ord 参考实现为准。