铭文协议在 tag 17 属性结构里留了一种特殊玩法：只要一枚铭文的 Properties 里带上 Item 数组，它本身就成了一个”画廊”（GALLERY）。ord 官方手册把它定义为：由若干条铭文 ID 组成的链上集合，任何人、对任意铭文都可以建，不需要被收录者的同意。这个”无许可”性质决定了画廊的全部用途与全部局限。
先看数据怎么存。每条 Item 的键 0 里放序列化后的铭文 ID：铭文 ID 文本形如”64 位十六进制 txid 加字母 i 加十进制序号”，而链上序列化规则是 32 字节交易 ID 后面拼 4 字节小端整数序号；序号末尾的零可以省略，所以最普通的 i0 铭文可以只占 32 字节，这也是手册里 Item 键 0 允许 32 到 36 字节的原因。当属性条目多到几十上百条时，协议还提供了第二种打包编码：把所有条目的 32 字节交易 ID 连续拼接进 Properties 外层键 2 的字节串里，Item 内部只留序号整数（省略时按 0 处理）。手册规定这两种编码可互换，任何实现都必须两种都接受并显示成相同结果。原因也不神秘：交易 ID 本质是哈希摘要，接近随机字节，混进可压缩的 CBOR 主体里会显著拉低 Brotli 压缩效果，把”不可压缩的部分”集中堆放，压缩率立刻回来——这是链上字节经济性对数据结构的直接塑形。
体验层面，带条目的铭文会在 /inscription 页面把成员展示出来；ord 服务器的 JSON 接口也配套提供了 /galleries、/galleries/<页码>、/gallery/<铭文ID>、/gallery/<铭文ID>/<页码> 等端点分页查询。用 ord wallet inscribe 加 --gallery 选项，或在 batch 文件的条目里写 gallery 数组（每项含 id、title、traits），就能把展册直接刻上链。
最需要讲清楚的是画廊”不能证明什么”。手册特意把画廊与 children（子铭文）对照：子铭文的父子关系靠”在铸造交易输入里花掉父铭文”来建立，不可伪造；而画廊任何人随手可建，任何人都可以被写进任何人的展册，因此被收录不代表出处（provenance）成立；也因为无许可，画廊条目页不会反向链接回收录它的展册——链上没有”这个展册是谁建的、展册可不可信”的默认约束。换句话说，画廊适合作为公开策展、主题清单、收藏展示的链上书签，不适合被当作”官方认证合集”的证据；核验归属仍然要回到父铭文、合约与发行方公告这些一手线索上。
实操上画廊还有几个容易踩的点。其一，条目 ID 写的是铭文 ID 原文，32 字节 txid 加小端序号的编码一旦手抄错位，展册会安静地收录一枚不存在的条目——老版本实现遇到解码失败的条目可能直接跳过，你页面上少了一枚却说不出原因。其二，ord wallet batch 的 gallery 数组支持给条目配 title 与 traits，这让”展签”也能上链，但要记住这些标签属于展册作者，不是被收录铭文自己的属性，两个来源的标签冲突时以你信任的一方为准。其三，展册本身是铭文，它就服从铭文的一切规则：跟着聪搬家、可被转赠、被烧掉父铭文也不影响它存在；删展册在链上从来不是抹除，只是你不再引用它。把 Gallery 理解成”公开的、可转手的、带时间戳的收藏书单”，用途和局限就都想得通了。
还有一个数据面值得注意：展册条目多时，Properties 的体积直接决定刻上链的成本，因为交易费按虚拟字节计价，几百条 32 字节哈希就是十几 KB 的见证数据。打包编码把不可压缩的哈希集中放置，让可压缩部分继续受益，本质上是把”文件排布影响压缩率”这件链下的事搬进了共识语境。理解这一层，你就会明白为什么手册特意规定两种编码必须等价处理：协议在替未来的工具箱保住兼容余地，也让今天的发行方不必在压缩器版本上押注。 本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。