第一次读 Runes 数据的工具开发者，常在代币编号上愣住：规范里每枚 Runes 代币的身份不是名字、不是连续序号，而是「871324:19」这样一串冒号分隔的两段数。名字当然也有——刻写时挑的 base-26 编码字符串——但在协议的内部账本里，真正的身份是这个两段数。理解它为什么长这样，能顺带看懂比特币资产与以太坊资产在“名字从哪来”这件事上的根本分歧。
按 Runestone 规范的定义：代币编号（规范中的结构体就叫 RuneId）由该代币被刻写（etch）时的区块高度，加上那笔交易在区块内的位置索引构成，文本表示为 BLOCK:TX。它本质是一枚坐标——告诉你的不是“你是第几号公民”，而是“你出生在哪栋楼的哪个房间”。
为什么不用全局流水号？因为在比特币上没有东西负责数这个数。以太坊上合约可以维护自增变量，铸造到第几枚一目了然，因为以太坊有执行引擎、有世界状态、有“调用按顺序执行”这层抽象。比特币只有按块排列的交易序列，索引器能依赖的唯一公共秩序就是区块顺序与块内位置。与其再造一个必须全链一致、任何分叉都会打乱的水位计数器，不如直接引用账本本来就存在的两个坐标：重放到哪一块，编号就在哪一块解析出来。这套身份与区块同生共死——分叉改变的是“哪个块有效”，编号随块一起作废或生效，不存在计数错位的残留状态。
坐标式编号立刻制造一个鸡生蛋问题：一笔交易常常要在刻写新代币的同时分配它的预挖部分——把币划给多个输出。可这笔交易自己的“块内位置”要到打包那一刻才知道，脚本没法预知未来。规范的解法简洁：保留 0:0 作占位符。规范明文写道——因为刻写交易的代币 ID 在被打包进区块前不可知，交易内部凡要指代“本笔正在诞生的这枚代币”，一律写 0:0，由索引器解析时替换成真实编号。占位符体系还内建了本笔内部的次序语言，多份刻写依次类推。
这套设计对使用者的影响比想象中具体。跨工具对账时，名字不可靠：base-26 名字受时间表解锁、圆点分隔符展示变体等规则影响，不同界面渲染出的“同一名字”可能经过不同加工；block:tx 编号才是稳定主键，且自带出生信息——第一段就是区块高度，想复核这枚代币的全部刻写参数（小数位、符号、mint 条款），按编号定位原始交易即可。比较两枚代币谁更早上线，编号的第一段就是答案，不需要信任任何登记处；这也解释了为什么抢注名字要靠承诺机制防前跑：名字的价值独立于编号存在，抢注是真金白银的竞争。
两个高频误读顺手拆掉。第一，把「871324:19」读成“第 87 万号”或某种价格——两段数只是坐标，与供应量、精度、符号毫无关系，那些住在刻写字段里，各管各的。第二，把钱包界面显示的代币名当索引器主键——不少解析报错正源于工具用名字当缓存键，撞名、改名就串数据；认编号的实现对这类事故天然免疫。
对做数据分析的人，这套编号还有一个实用推论：block:tx 是天然的排序键，跨版本、跨工具的数据集合并时用它做主键拼接几乎无冲突；用名字拼接则会遇到改名、圆点变体、大小写等一整列脏数据问题。反过来，凡是拿名字当主键的自建脚本，都值得回头查一次撞名记录。另一个小提醒：区块高度第一段本身也是信息源——把一枚代币的编号高度与你关注的协议事件高度并排，就能肉眼判断它上线在哪些规则变更之前、之后，评估“老规则铸造、新规则解读”的兼容风险时，这是零成本的第一眼筛子。
留一个对照收尾：以太坊 NFT 的身份是「合约地址+代币编号」，依赖对象模型；Solana 是铸造账户地址，依赖账户体系；比特币 Runes 的身份是账本坐标，依赖区块秩序。三种命名法没有优劣，只有与各自账本结构的匹配。看懂一枚资产的名字结构，你其实已经看懂了它所在链的记账骨架。本文为机制说明，不构成任何投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。