BRC-20 与 Runes：同是比特币代币，账本写法差在哪

在比特币上发可互换代币的路线里，BRC-20 和 Runes 名气最大。两者都不发新链、不加侧链，却让同一笔比特币账本记出了可交易的代币余额。区别集中在账本怎么写、在哪记，本文按官方文档从四个维度对比。

数据载体：JSON 铭文与紧凑编码

BRC-20 的每条操作——部署、铸造、转账——都是一段可读的 JSON 文本，走 Ordinals 的信封机制刻进交易见证数据。好处是任何会用铭文工具的人都能肉眼看懂；代价是文本冗余大，每个数字、每对引号都要占链上空间。Runes 走另一条路：官方手册描述协议消息以 Runestone 形式存在于交易输出，脚本以 OP_RETURN 开头、后接 OP_13 和数据推送，字节流解码成一串整数再解析成指令。同样是转账，Runes 用编码整数表达代币与数量，体积比 JSON 小得多，人却没法直接读，必须依赖解析器。

余额记在哪：聪与 UTXO

BRC-20 的余额锚在聪上：mint 铭文落在哪个聪，索引器就把数量记在聪所在地址名下，转账还得分两步——先刻 transfer 铭文锁定数量，再把那条聪发出去，由此产生可转余额与可用余额的双簿记。Runes 的余额直接跟着 UTXO 走：官方手册说一个交易输出可以同时持有任何数量符文的余额，交易输入携带的符文自动转给输出，除非 Runestone 里的 edict 条款另行指定分配。转账即普通比特币转账，没有先锁定再发送的中间状态，也就不需要双簿记。

交易结构：一交易一指令与一交易多事

BRC-20 一笔交易通常承载一个 JSON 操作，操作多则交易多。Runestone 一笔可以依次完成雕刻新符文、mint 已有符文、按多条 edict 给多个输出分配余额，交易效率的差距来自数据模型。销毁语义也对照分明：BRC-20 靠把聪转到无主地址之类的约定做法，语义由社区与索引器解释；Runes 把代币指向 OP_RETURN 输出即协议定义的销毁，指向错误输出会销毁这点另文详述。

对索引器的依赖程度

两条路线都运行在比特币共识之外，账本状态全靠索引器推演，这一点本质相同。差异在依赖的面：BRC-20 的每一步（包括每笔转账）都要重放铭文序列，同名冲突与铭文堆积都压给索引器；Runes 把结构放进编码字段，格式错误的 Runestone 被整体判为 Cenotaph 并按规则处理，规则边界在文档中更收敛。对普通用户的实际影响：BRC-20 资产跨工具核对时口径差异更常见，Runes 则对客户端版本与解析实现是否支持最新字段更敏感。

小结

选择视角可以简化为：要人能直接读、工具链门槛低，看 BRC-20 的铭文路线；要单位数据效率高、交易结构紧凑，看 Runes 的编码路线。两者都不改变一个共同前提——比特币节点不校验代币账本，一切余额展示都是索引器推论，核验务必走到 deploy 或 etching 交易这一层。

选择策略之外的共同底线

无论倾向哪条路线，有几件事完全相同：余额都是索引器推论，都要求钱包地址类型与协议兼容，都有同名与仿冒问题，都不因“上链”而自动获得价值或版权。技术路线的比较只在成本与工程层面成立，任何把“某某协议更先进”直接翻译成“更值得持有”的说法，都超出了协议文档能支持的范围，应当原样退回给说这话的人。 最后一个容易被忽略的维度是历史数据的可追溯性：BRC-20 的全部操作都以可读铭文形式留痕，任何人都能逐笔复核账本叙事；Runes 的操作编码更紧凑，复核时需要相应解码工具。两者都没有更透明或不透明之分，只是审计入口的形态不同，选哪个入口取决于你手上有什么工具。

风险提示：本文仅为协议机制对比科普，不构成任何投资建议，也不构成对任何代币的评价。