撰文:@Weiqing
编排:@createpjf
作者说📖
比特币生态、铭文与 BRC-20 贯穿了 2023 年的大部分时间。就在币价回落,所有人都以为铭文的热度将会告一段落时,关于 BRC-20 是否应该升级的争论,又将各方重新拉回到聚光灯下。争端的核心可以概括为【是否要将 BRC-20 索引所运行的 0.9 版本升级并和 Ordinals 的迭代保持同步】。目前此次争议以 BRC-20 标准跟随 Ordinals 升级到 0.14( 截止本文完成时,Ordinals 已经发布 0.15 版本 ) 初步告一段落。本文将尝试从技术背景,各方观点及动机,投资者及用户观察等角度对整个升级的过程进行梳理,我们可以从中一窥比特币社区达成共识的过程。
1. 争端回顾
1.1 技术背景
BRC-20 是什么
BRC-20 是比特币链上的可替代代币 (Fungible Token,对比于 NFT,Non-Fungible Token) 协议,开发者可以基于这个协议进行发币、记账等操作。
比特币链,Ordinals 与 BRC-20 三者的关系
- BRC-20 是元协议,基于 Ordinals 构建;使用 Ordinals 协议作为完整的数据可用性层,并带有链下索引器来确定元协议状态;
- Ordinals 也是元协议,基于比特链构建;使用比特链协议作为完整的数据可用性层,并带有链下索引器来确定元协议状态;
所以,BRC-20 实际上是元元协议,通过名为「索引 (Index)」( 详见 1.1.3) 的机制来实现 1.1.1 中所提到的金融行为。
索引(Index)
索引是基于比特链的机制而产生的机制。
因为比特链上的代币区别于以太链,并不是由合约地址区分的、「真实存在的」代币,而是在各个区块中,以文本形式存储「备注」字段中的「账本」所记录的交易信息。由于比特链的去中心化特性,任何人都可以打包上传区块内容,并且「备注」字段信息不影响区块有效性,所以账本有有效的 / 正常运转的,也有无效的 / 恶意的,那么为了维持信息秩序,就要遵循一定的规则去收集这些账本信息并进行验证。验证的过程,就是索引。执行验证过程的程序 ( 以太链上叫做智能合约 ) 就是索引器。
索引器是一个数据库,可读取和注册所有 BRC-20 交易数据,如检查哪个铭文是第一个部署新代币的名称、跟踪铸造代币的钱包余额变动及相关交易地址数据等。索引器应用的规则,就是由各相关方达成的共识。
Jubilee 升级
Ordinals 协议一次升级的名称,发生在#824,544 区块上,升级时间为 2024 年 1 月 5 日,具体内容是将 Ordinals 协议更新至 0.13 版本。0.13 版本是 Ordinals 的例行但非定期更新,主要内容是协议功能的进一步丰富。

图 1-1 Ordinals 0.13 版本更新的内容 (1) ( 来源:Ordinals 的 Github 页面 )

图 1-2 Ordinals 0.13 版本更新的内容 (2) ( 来源:Ordinals 的 Github 页面 )
需要注意的是,Ordinals 本次更新的内容和索引问题并不直接相关。引发本次争端的源头是【BRC-20 根据 Ordinals 0.8 和 0.9 版本所生成的不同索引标准导致的索引结果不一致,并可能在未来版本产生更大的差异】以及【BRC-20 的协议标准已经冻结在 0.9】这两项内容 ( 详见 1.2.1)。
1.2 问题与争端
技术问题
如上文所述,虽然比特链自身的技术已经不再发展,但是 Ordinals 作为元协议,自身存在技术迭代和更新的情况。这种迭代自然也会影响其上的协议以及生态发展,自然也包括 BRC-20。
11 月,由 BRC-20 协议创始人 Domo 提出的提案已经在链上生效。该提案的内容是【将 BRC-20 的索引以 Ordinals 0.9 为基准进行标准化并冻结】( 意译 ),旨在维持协议的稳定运转,避免盲目迭代导致对技术标准和协议运行产生预料外冲击。
而在此前的 10 月,有人发现铭文 #35321413 和 #35329860 可以被 0.9 版本的 Ordinals 协议索引,但不被 0.7 和 0.8 版本索引。由于不同的市场采用不同版本的 Ordinals 协议,有的铭文在一些市场上无法被正确索引,并且造成了事实上的铭文编号偏移。
而对于 BRC-20 协议整体而言,这个问题更大。0.8 版本 Ordinals 协议的 BUG 可能会导致:1)超出最大供应量铸造;2)不同市场 Ordinals 协议版本差异间的双花。这类风险是不容忽视的。
生态问题
BRC-20 是「寄生」在 Ordinals 协议之上的协议,其索引是否要跟随 Ordinals 协议进行升级,在现阶段是一个两难的问题。一方面,Ordinals 协议依然在快速地更新迭代,越来越多的新特性被增添到协议中,尤其是「禧年 (Jubilee)」升级即将在区块高度 824544 激活,原有的生成诅咒铭文的方式将被修复,也就意味着,在 0.9 版本 Ordinals 协议中将被赋予负数编号的诅咒铭文,在 0.13 版本中将被赋予正数编号,Ordinals 协议的版本差异将使后续新铭文的编号情况出现极大差异。
此外,像 CBRC-20 这种使用了 Ordinals 协议新版本的新特性带来了性能优化的魔改版 BRC-20 协议也对 BRC-20 的发展形成了一定的挑战。
而另一方面,作为一个已经诞生了数量繁多、市值庞大的资产协议,BRC-20 在发展过程中保持稳定自然也成为了第一要务。如果为了追求新特性对 BRC-20 带来的优化与拓展而造成了用户的资产损失,毫无疑问会对 BRC-20 生态造成巨大的伤害。
所以,在技术问题和生态问题的双重加持之下,BRC-20 协议有话语权的各家出现了分歧,争端的核心可以概括为【是否要将 BRC-20 索引所运行的 0.9 版本升级并和 Ordinals 的迭代保持同步】。
1.3 各方声音
UniSat 钱包:严格跟随升级
UniSat 决定跟随 Ordinals 进行 Jubilee 升级,这可能会导致在比特币链上对 BRC-20 有两套不一样的索引标准并导致不同的记账规则。记账规则差异意味着用户在不同的地方可能会出现不同的余额、或者账户余额对不上的情况,这将会使 BRC-20 市场因 Ordinals 版本索引标准的不同而碎片化。
除此之外,UniSat 还推出了黑白模块系统。开发者可以在黑模块中引入新功能,代币可以放在黑模块中,但是直至被批准 (「变白」) 之后才可以被取出。UniSat 也寄希望于借助该模块来为使用者提供便利并且进一步规范市场。
对于其他未升级的协议,UniSat 的态度是「Split」。虽然是「分离」,但并不等同于 BTC 与 BCH 一样的「Fork( 分叉 )」。按 UniSat 官方的解释,这种 Split 可以允许两套不同的标准在两个不同的生态之下同时运行,但代币 / 账本信息等内容还可以自由进行交互。但相比于对技术迭代的反复提及,UniSat 并未过多解释如何应对市场混乱以及双花攻击等风险。
BRC-20 创始人 Domo:暂时冻结,聚焦测试
虽然 Domo 在此前提出了将 BRC-20 冻结在 Ordinals 0.9 的提案并且该提案也已经正式生效,但他同样认识到了技术上的问题及风险,并且对升级持开放态度。但是处于稳定性和防范风险的考虑,Domo 反对直接跟随 Ordinals 进行 Jubilee 升级,而是希望当前各索引者继续冻结在 0.9,同时在后台对未来版本的 Ordinals ( 不局限于 0.13) 进行充分测试。待测试收到满意的结果时,再决定 BRC-20 具体升级使用 Orindals 的哪个未来版本以及是否继续冻结。
少数激进派:直接分叉
除 UniSat 和 Domo 这对阵的两方以外,市场上还存在一些少数激进派,他们提出来的看法就是直接分叉 (Fork),即如同 BTC 与 BCH 一样,干脆执行不同的标准,代币信息不互通,「各玩各的」。但是一方面,该方案会对刚刚起步的 BRC-20 造成冲击并且进一步制造混乱,另一方面该声音的持有者在数量上为极少数并且并不会像 Domo 或者 UniSat 一样对生态产生重要且直接的想法,该种看法并没有得到过多的关注。
1.4 走势预测
注:本文行文时,各方已达成共识,即共同升级至 0.14.为保证行文完整性,保留此部分分析。
1 月 3 日,推主 @lilyanna_btc 发表长推,分析了几种潜在的可能性,在 TA 看来,大概有以下几种可能:
- 冻结派和升级派共存
- 升级派妥协,和冻结派一起停留在 0.9
- 冻结派妥协,跟随 Ordinals 进行升级
除此之外,笔者另有一个观点:各退一步,以商后事
Domo 在 L1F 的论坛上曾经说过,考虑用维护模式慢慢接纳 Ordinals 的升级。也就是说先冻结,后续再升级。这个方案实际上是不可行的。先冻结再升级,会重来一次铭文编号改不改的争论。在升级前的这部分铭文如果回溯,会重排铭文编号,这中间的铭文和交易,会出现比 BRC-20 直接升级更大的混乱。如果不回溯,BRC-20 的编号和 Ordinals 的编号会永远不一致。
1.5 最终结果
经过了各方 5 天的讨论与协调,各方最后达成了以下共识并实施推广:

图 1-3 各方同意的最终方案 ( 来源:推特 )
- BRC-20 随 Orindals 升级至 0.14 版本,即比 Jubilee 还要更进一步。该版本解决了索引过程中出现的 Bug,但是和 0.9 又不至于有明显的差异;
- 短期内不讨论 BRC-20 是否冻结于 Ordinals 0.14 版本,当前主要着眼于安全性、稳定性以及相关测试工作,后续根据结果再进一步决定。
- 对于 1.2.2 中提到的,可能造成铭文编号重复的问题,Ordinals 的编写者 Casey 曾提议如下:在编号有可能重复的铭文特定部分中添加标记,以表明该铭文在未来将会借助 Ordinals 上的微量修改而被正确索引。在更新到届时版本的 Ordinals 之前,索引商可以暂时跳过,并且在更新之后对铭文进行合并。在当前各方达成的中,这个名叫「Vindication」的提案被搁置,不过未来可能会被启用;
- 「Vindication」中提到的极端情况,各方正在一同尝试解决;
- 忽略代理和代码 (Delegation and Encoding) 问题。不过共识中并未详细说明代理和代码指代的是什么。

图 1-4 Casey 提出的 Vidication 提案 ( 来源:Casey 的 Github 页面 )