在铭文社区里，几乎每个人都把”编号”挂在嘴边，但编号的确定规则其实很少被完整讲清楚。按照 Ordinal Theory Handbook（ord 官方手册）的定义，铭文编号从 0 开始，按两条顺序依次分配：先按揭示交易（reveal 交易）出现在区块中的先后，再按同一笔揭示交易内部铭文封套（envelope）出现的先后。也就是说，决定编号的不是你提交铸造的时间，而是你的揭示交易被打包的顺序，以及交易脚本里那段 OP_FALSE OP_IF … OP_ENDIF 数据被解析器逐输入遍历到的次序。
需要先区分两组数字。一组是铭文 ID 里的 i 序号，例如 …dai0、…dai1，它只表示同一笔揭示交易的输入里第几个封套；另一组是全局铭文编号，才是藏家口中”第几号铭文”。同一笔交易里铸出多个铭文时，它们共享同一个 txid，只靠 i 序号区分，而全局编号则继续按区块内顺序排队。
手册还明确记录了一个无法修复的历史行为：有一类铭文在揭示之后立刻被当作手续费花掉，由于早期 ord 实现的缺陷，它们在编号时被”挪到”了所在区块的最后。官方说明得很直白——除非愿意改动大量既有编号，这个行为已经不能修正。于是你会看到链上出现”后到的交易反而编号靠前”的观感，这不是索引器算错，而是被永久冻结的历史事实。
另一种特殊情况叫诅咒铭文（cursed inscription）。当一笔揭示交易里的铭文违反了 ord 的分配规则（例如同一输入上的排序要求）时，这些铭文会被从负一开始、向更小的负数方向编号。手册记录了后续的变化：在名为 jubilee 的协议调整之后（区块 824544 起及以后），被诅咒的铭文得到”平反”，重新获得正数编号。这意味着你在不同索引器上查到的历史编号口径，取决于它是否按这套规则回溯处理。
还有一个与编号相关的操作叫再刻铭文（reinscription）。手册说明：对已经刻过铭文的聪，可以在钱包仍持有该铭文的前提下，用 --reinscribe 选项再追加一枚新铭文；追加不会修改原铭文，只是让同一聪上挂了两个编号。指定目标可以用 --satpoint（输出坐标），也可以在开启聪索引后用 --sat 直接按聪号操作。新手常见误区是把”再刻”理解成”覆盖”——链上旧铭文原样存在，多出来的编号同样可以在浏览器里查到。
理解这套规则的现实意义在于核验：当你比较两枚铭文的先后、稀缺性或判断某个”编号靠前”的宣传时，应当先确认口径是 i 序号还是全局编号，再考虑历史缺陷区间与被诅咒后恢复的编号段。编号只是索引顺序的产物，并不自动等于官方认定的”更早”或”更稀有”，把它当作市场叙事里的唯一证据并不可靠。
编号与 i 序号的分工，再举一个实操例子会更清楚。假设一笔揭示交易有两个输入：第一个输入的封套里塞了两段铭文数据，第二个输入有一段，那么按手册的解析方式，会依次产生 i0、i1、i2 三个 ID；如果同区块里还有别人的揭示交易排在你前面，你们的全局编号就要先按交易进块的先后分高下，交易内部再按输入与封套的先后排 i 序号。核验时务必把两组数字分开抄：交易哈希加 i 序号是这枚铭文的身份证，全局编号只是 ord 给你的一行队列号。同一聪被再刻之后会出现两个编号挂在同一输出上，谁在前谁在后、谁被展示为当前有效，取决于索引器实现与你的查询方式——遇到”一枚聪两个号”的收藏，别只截图一个编号就下结论。
还有一个容易混淆的点：编号与区块高度不是一回事。两个编号相邻的铭文可能来自不同高度的区块，同一区块里的铭文编号也可能因为那笔”揭示后立刻进手续费”的历史缺陷而首尾倒置；跨索引器对账时，如果一方按区块时间展示、另一方按全局编号排序，屏幕顺序的不同并不代表任何一方算错了资产。把编号当作查询索引、把交易哈希当作事实凭证，这个分工在排序异常的边缘案例里最省心。 本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。