Runestone 解码管线：比特币交易里的字节怎么变成 Runes 指令

一句话理解

Runes 把造币、铸造、转账指令写成嵌在比特币交易输出里的“符文石”（Runestone）。协议文档给出的识别方式：找到第一个脚本公钥以 OP_RETURN 开头、紧随 OP_13 的输出，把它后面的数据推送全部拼接成一个载荷缓冲，再解码成一串 128 位整数，最后把这些整数解析成语义消息。协议自 2024 年的 840000 区块激活，更早区块里的 Runestone 被忽略。

抽象层面，一个 runestone 的字段是：一批 Edict（分配指令）、可选的一个 Etching（刻印）、可选的一个 Mint（铸造引用）、可选的一个 pointer（输出指针）。这四样正好对应 Runes 能做的事：把币分到输出、造新币、按条件铸币、决定余额落点。

三层解码

第一层是脚本层。载荷里只接受数据推送操作码；只要遇到任何非数据推送操作码，这条直接被判定为 Cenotaph（衣冠冢），不含任何刻印、铸造或分配语义。

第二层是整数层。拼接后的字节按 LEB128 varint 解码：每个字节的最高位是继续位，最后一字节继续位清零。单个 varint 超过 18 字节、会溢出 128 位、或在结尾前被截断，同样判为 Cenotaph。

第三层是消息层。整数序列被读成“标签到值”的映射，重复标签的值追加。出现值为 0 的标签时，其后整数切换成 Edict 模式，每四个一组：Rune ID 的区块高度、Rune ID 的交易序号、数量、输出编号。两个值得记住的工程细节：Edict 里的 Rune ID 用增量编码——区块高度增量为 0 时下一个数是交易序号增量，否则是绝对交易序号，因此编码前必须先按 Rune ID 排序；所有 Edict 处理完，未分配的余额默认落到第一个非 OP_RETURN 输出，除非 runestone 用 pointer 指定别处。

为什么设计成这样

OP_RETURN 输出不被比特币规则当作可花费支出，天然适合承载“只给索引器看”的数据；但为了让交易能正常中继，推送必须压得很小，所以协议用 varint 和增量编码而不是 JSON 文本。Rune ID 直接取“刻印所在区块加交易序号”（文本形式 BLOCK:TX），本身就自带历史顺序，不需要额外全局注册表。

Cenotaph 机制是它的升级轨道：将来语义扩展后，旧实现会把看不懂的结构判为衣冠冢，按“币已烧掉”显示，而不是错误地以为币还在某个输出里。规范把这写成明确的兼容性契约：让未升级的客户端不会把币的位置搞错。

能说明什么、不能说明什么

能说明：哪些交易被当作 Runes 消息、想执行什么指令，纯靠交易本身即可复现，不必读任何链下数据库；“格式出错的交易烧币”也不是惩罚，而是未升级客户端眼中的诚实显示。

不能说明：这套编码不定义哪个代币有价值，也不保证你的索引器与别人解码一致——尤其在各家实现追随规范修订的节奏差异期。协议文档是事实来源，任何市场展示都只是对它的再解释。

普通用户的两条核对

一是遇到 Runes 余额显示异常，先确认所用工具是否按最新协议版本解码，而不是先怀疑币丢了。二是看到批量操作被拆成多笔交易，多数是协议约束与钱包构造策略的结果，不等于额外收费。

刻名字时的名字承诺

刻印（etching）环节还有一个容易被忽略的校验：协议要求刻名交易里包含对名字的承诺——把要刻的名字按规定编码放进一个数据推送；找不到有效承诺时，这次刻印会被直接忽略。它的意义在防错配：索引器不必猜测字节序列对应的名字，名字与字节互相验证，减少了恶意构造字节序列冒充他人名字的空间。看到“名字被抢先”的争论时，可以回看双方交易里的承诺字段，确认索引器判定依据是否一致。

风险提示：本文为协议机制科普，不构成任何投资建议。Runes 的账本语义以官方协议文档与比特币链上数据为准。