一枚铭文的身份证：交易哈希加 i 序号的两段坐标

在铭文交易记录里，一枚藏品的身份常常是一串六十四加几个字符的长码，末尾跟着 i0 这样的尾巴，比如 521f…79dai0。它不像以太坊那样有合约地址加编号的直观结构，第一次见很容易复制错、理解偏。这串坐标其实只有两段：i 字母之前是揭示交易的交易哈希，i 之后是这枚铭文在该笔交易内部的序号。

序号规则来自一个现实：一笔揭示交易可以同时揭示多枚铭文——多个输入各带一个内容封套，或一个输入里塞进多个封套。索引器解析时按输入顺序连续扫描每个数据封套，扫到第一个记为 i0，第二个记为 i1，依此类推，跨输入连续计数。也就是说，同一笔交易里的编号先后反映的是解析顺序，而不是”谁更重要”；想给某枚铭文排在前面的卖家，靠的是把它的封套排在交易输入的构造顺序里。因为编号只依赖交易自身的结构，只要交易被打包，每个索引器都会得到同一个答案，这正是去中心化环境里做引用的前提。

要注意它与另两个编号的分工。一个是全局铭文编号：按区块出现顺序把全链所有铭文从 0 开始通排，是”第几号铭文”这种历史叙事用的序号；另一个是合集内部的通证编号，比如一个项目一万枚图里各自的 1 到 10000，只在该合约或索引规则内有意义。三段体系各有用途：交易哈希加 i 序号是铭文的门牌号，全网唯一、可直接寻址；全局编号方便讲历史；合集编号方便运营。混淆它们的后果很具体——拿 i 序号去查全局库、或拿合集编号当唯一标识做委托，都会指错对象。

这串身份证不只是查询用的字符串。铭文规范里，内容指向自身标识的约定让一枚铭文可以引用”我自己”：自展示页面用它找回自己的内容，委托模式用它锁定被引用的目标——一枚铭文把内容权委托给另一枚铭文时，写在封套里的目标正是这串标识；递归式的 HTML 铭文加载其他素材时，引用的也是各素材的标识。换句话说，它是铭文之间互相认识的通用语言，谁生成的界面都不影响这串码的指向，这也解释了为什么交易平台、浏览器、钱包之间能互相核对”同一枚”。

实操提醒三条。第一，复制长码务必连同 i 尾巴一起，缺了后缀等于只报了楼栋没报房间；第二，验证一场比赛的归属，以揭示交易的确认数和所在区块为准，未确认交易里的编号可能被替换交易改写；第三，遇到声称”零号""同号”的稀缺叙事，先分清说的是全局编号还是交易内序号，两类数字的获得难度完全不是一回事。

把这套坐标放进真实工作流里再看一遍。假设一笔揭示交易的输入零藏两个封套、输入二藏一个、输入四藏一个，解析器从输入零开始顺序扫描，四枚铭文依次拿到 i0、i1、i2、i3，输入三没有封套就跳过——编号只反映结构位置，与内容、稀有度、铸造时间无关。跨平台核对藏品时，正确姿势是拿完整身份证去查：官方浏览器的详情页、钱包的铭文列表、交易场的挂单，三者应当指向同一笔揭示交易与同一序号；若某平台只展示“第几号”的短名，先确认它指全局编号还是合集编号，短名重号是客服扯皮的高发区。另一个易错点是把身份证当作内容指纹：这串坐标不包含素材的散列，同一枚铭文的内容是否被渲染层篡改，要靠内容本身与网关返回的字节比对，坐标只保证“找的是同一条记录”，不保证“看到的是同一张图”——这两层分开，排查问题时才不会被“编号没错啊”卡住。 本文为机制说明，不构成任何投资建议。