

- Chapter Ⅰ — 命运的齿轮开始转动
- 「1」Ordinal Numbers
- 「2」Ordinals 协议
- Chapter Ⅱ — BTC 生态资产发行的百花齐放
- 「1」BRC-20 协议
- 「2」TRAC Systems
- 「3」Atomicals 协议
- 「4」Bitmap 协议
- 「5」BRC-100 协议
- 「6」BRC-420 协议
- 「7」Runes 协议
- 总结
现有的很多文章都是从 Ordinals 协议说起,但在 Ordinals 的官方文档中,第一个提及的是 Ordinal Numbers 理论,从这也可推断出 Casey 应该也是从中获得一些启发从而创造出了 Ordinals 协议众所周知,在 Bitcoin 世界中最小的单位是聪 (sat),而 Ordinal Numbers 理论可以简单地理解为是人为地给这些 sat 进行编号。从 BIP 提案中的动机部分我们可以总结为该理论想要为 Bitcoin 提供一个可作为稳定标识符的方式来防止所有权转移或密钥轮换,且不需要对 Bitcoin 网络进行任何更改。当然,这个理论也存在着一些反对的意见,如会降低用户的隐私性、增加 UTXO 集的大小、粉尘攻击等,具体内容可参见 BIP 提案。 「2」Ordinals 协议 协议提出Ordinals 协议 由 Casey 提出并发布,他在其中提出了如下的想法:”我们能否按照一定顺序排列这些「聪」,给它们分配一个介于 0 和 2,100,000,000,000,000 之间的序数,然后,把它们连接到其他信息:图片、文字、视频甚至一串代码。从而每个聪都变得独一无二,不可替代。这就相当于让比特币拥有了原生的、创造 NFT 的能力。”Ordinals 协议在 2022 年年底就已部署,第一个主网上的铭文是在 2022.12.14 UTC 铭刻的(https://ordinalswallet.com/inscription/6fb976ab49dcec017f1e201e84395983204ae1a7c2abf7ced0a85d692e442799i0),在这期间协议一直都在更新迭代但未进行官宣,目前能从 Casey 的推特中找到的第一条官宣推文如下,所以 Ordinals 协议既可以认为是在 12 月提出,也可以是在 1 月提出。(这里也要感谢 shep 哥提供的线索) 协议特点1. sat 的编号以及稀有度的划分 人类是天生的收藏家,既然 Ordinal Numbers 是人为地给 sat 进行编号,那为何不来给这些 sat 来个高低之分,故有了稀有度之间的区分。目前稀有度共分为 6 种:







注意:1. domo 最早关于 BRC-20 的推文是 2023.3.9,但从 $meme 和 $ordi 的部署时间来看,应该是 2023.3.8 就已推出2. $meme 是第一个部署的 BRC-20,而 $ordi 是第一个正式发布的 BRC-20,可通过查看它们的部署时间推断出来而关于 $ordi 的发展大家应该都有所体会,这里不多提及,详情可参考下方这篇推文:https://twitter.com/Web3Loon/status/1731581279920123963 协议原理BRC-20 协议通过制定一系列标准来实现在 Ordinal 理论的基础上可以部署、铸造、转移 BRC-20 token。该协议的格式标准源于 Sats Name 项目(第一个基于 Ordinals 协议的 DID 项目)的格式:





- 第一笔交易在本地帐本中读取最新账本数据并计算余额
- 第二笔交易再进行转账。

- 具有独特代币标准的 OrdFi 协议
- 兼容 BRC-20 代币,便于市场集成,且突破了 BRC-20 的名称长度限制,BRC-20 代币长度固定为 4 位,而 Tap 的代币长度为 3 或者 5-32 位(不能是 4 位)
- 支持批量转账、质押资产、代币 swap 等功能。提高交易效率而不依赖 L2 链
- 首个支持诅咒铭文的协议
- 使用前面部署的 $TRAC 作为其协议的治理代币(不太能算是特点,但放在这进行说明)

- 专有 API 导致的各种问题:服务锁定、高交互成本、相同的链上数据会有不同的表现形式、开发者之间的竞争
- 不可靠的索引器:资产安全问题、频繁改动、Ordinals 的正负数
- 缺乏顶层设计:难以组合协议并开发出专有设施
- 链上元数据的局限性:
- 示例:集合必须手动上传到 Github 仓库中,并且它们必须在数十个市场上手动更新,对于链上响应没有达成共识
- 错误无法修复或修复成本高昂
- Ordinals 协议的数据结构非常依赖于单个文件的使用,这意味着不同市场存在链外约定和专有索引
- 缺少控制:如果无法访问强大的高性能去中心化索引器以及更多服务/索引器锁定,那么数据可移植性将会成为一个问题
- 缺乏收益:依赖这些特定的服务和市场及其索引器、API 等专有服务会导致利润减少

- 这样我们可以根据电力等能源消耗来对内容进行排名
- 当你有一个非常酷的参考或前缀时,可以通过共识来组织一个相关社区
- 在铸造过程中加入随机的运气成分
- 围绕虚荣的 TXIDs 和 REFs 来组织社区
- 基于昂贵信号理论的内容排名
- 节流和限制 token 的铸造 — 垃圾邮件过滤器
- 容器名称服务:
- 容器名称以主题标签 # 符号开头,且每个名称都是独一无二不可重复的,在铸造时采取先到先得的方式
- 名称的长度在 3-64 个字符范围之间,且使用了 Bitwork 来减慢容器名称的注册速度
- 容器名称示例:#bitcoin-funks,#gemini-warriors,……

- 在部署 ARC20 时,代币名称、总量、数量限制、难度设置、开始区块、图像等等信息。
- 用户在铸造 ARC20 时,将代币的名称写入 UTXO 的脚本中,数量直接由 UTXO 中 sats 的数量决定,1 sat = 1 token。
- 转账 ARC20,用户无需再向 BTC 存入任何数据,仅需将持续持有代币的 UXTO 作为交易输入,输出给其他地址。
- 极大地降低了索引服务器的成本,几乎任何人都能自己制作索引服务器,系统去中心化程度很高
- 转账完全依赖 BTC 网络,不会重复创造垃圾交易,ARC20 转账本身安全性由 BTC 保障
- ARC20 原子性和 BTC 的原子性保持一致,适合实现很多原生应用
- 在部署 ARC20 时,代币名称、总量、数量限制、难度设置、开始区块、图像等等信息。
- 用户在铸造 ARC20 时,将代币的名称写入 UTXO 的脚本中,数量直接由 UTXO 中 sats 的数量决定,1 sat = 1 token。
- 转账 ARC20,用户无需再向 BTC 存入任何数据,仅需将持续持有代币的 UXTO 作为交易输入,输出给其他地址。


- 首先我们注册了一个领域 +ATOM
- 当我们想要在这个领域下组建一个关于 Punk NFT 的社区时,我们就可以基于 +ATOM 领域创建一个子领域 +ATOM.PUNK
- 在之后我们想在 Punk 社区里组建一个 DAO,那么就可以再创建一个子领域 +ATOM.PUNK.DAO
- DAO 中每个人都分配一个 DID,则可以创建一个子域名 +ATOM.PUNK.DAO.JINGLE
- 任何一个领域或子领域都可以发布子领域
- 所有子领域都可以继承相同的特点并基于子领域发布其子领域
- 所有人都是他们拥有的领域的注册者,不存在中心化机构
- 使用聪作为基本单位代表代币
- 允许在比特币上创建、传输和更新数字对象
- 提供去中心化且符合比特币文化的代币化方法
- 利用工作量证明(POW)增加铸造过程的公平性和去中心化
- 旨在扩展比特币的功能,支持更广泛的应用


省流:就是基于 BRC-100 协议进行各种扩展如空投协议、治理协议、中继协议等等,我们可以为理解为 Mikael 想要将各种 DeFi 的玩法引入到 BTC 中
- 协议继承 BRC-100 协议引入了继承的概念。直接或间接继承自 BRC-100 的协议称为 BRC-100 扩展协议。BRC-100 扩展协议必须仅继承自一种协议。扩展协议将继承父协议的属性、操作和计算操作,并且只能扩展属性和计算操作。这就类似于我们在制作陶瓷时,在最初的时候只是一个泥胚,慢慢地,我们通过对其进行打磨和造型,就逐渐有了更多扩展的功能如装饰、盛放东西等。
- BRC-100 协议栈 BRC-100 协议及其所有扩展和改进协议统称为 BRC-100 协议栈,基于该协议栈,所有代币/应用程序都可以相互兼容,这意味着一个代币/应用程序可以在任何地方使用其他应用程序。
- 协议和应用 在 BRC-100 协议栈中,协议是描述应用程序的属性、操作和计算操作的标准。应用程序是协议通过铭文部署到比特币网络后创建的实例。应用本质上是一个具有计算能力和状态的代币。协议中详细描述了应用程序的计算能力。如果不添加子应用程序,应用程序就无法拥有协议中未描述的计算能力。添加的子应用程序也只能具有协议的计算能力,否则公共索引器无法验证应用程序的状态,导致用户和应用程序的状态不一致。
- 应用嵌套 基于 BRC-100 及其扩展协议部署的应用可以嵌套,即一个应用下可以创建另一个应用,称为子应用。子应用的 ticker 以 “parent application ticker:” 开头,一个应用下可以创建多个应用,完成多个独立的计算逻辑。例如,在经典的 AMM DEX 场景中,需要在一个 DEX 应用程序中创建多个 LP 子应用程序/代币,如“amm_dex:LP_BRC100_BTC”。
- 应用状态和地址 除了 UTXO 模型之外,BRC-100 协议还引入了状态机模型来扩展协议的计算能力。应用程序、子应用程序和地址都可以有状态。例如,应用程序可以持有代币,地址可以在应用程序中拥有余额。UTXO 和状态的转换是通过 burn2/burn3 和 mint2/mint3 指令完成的。计算操作(cop)用于表示具体的计算逻辑,即应用程序和地址状态的转换逻辑。例如,地址 A 通过 burn3 铭文向应用程序销毁 10 个 token1。此时应用程序拥有这个 UTXO 和 10 个 token1。应用程序可以通过其计算逻辑改变任何地址或应用程序的内部状态来分配这 10 个 token1。那么应用程序中拥有 token1 的地址或应用程序就可以通过 mint3 指令铸造它。
- 权限 BRC-100 协议引入了两种角色:所有者和管理员。带有应用程序部署铭文的地址称为所有者。所有者可以跟踪部署铭文的 UTXO 转账。所有子应用程序的所有者都是父应用程序的所有者。管理员由所有者管理,管理员不能管理其他管理员。所有者和管理员的权限受到严格限制。他们无法审查用户,只能做:治理未启动 DAO 的应用程序,完成 mint2/burn2 的计算操作。管理员可以是地址、应用程序或子应用程序。应用程序和子应用程序默认互为管理员,无需额外设置,但子应用程序之间不互为管理员。burn2/burn3 的铭文需要发送给应用程序的部署者才能正确处理。“mint2” 指令需要铸造的部分代币只能由应用程序/子应用程序逻辑分配,并且应用程序/子应用程序需要成为代币的管理员,“burn2” 指令也有类似的逻辑。burn2/burn3 的铭文需要发送给应用程序的部署者,以便根据计算操作的逻辑正确处理。
- 应用程序的去中心化治理 BRC-100 协议栈引入了治理协议:BRC-101,它可以治理实现 BRC-100 或其扩展协议标准的应用程序。而应用启动 DAO 后,需要通过去中心化投票来完成治理。应用程序的治理包括:更新应用程序和子应用程序的属性、部署子应用程序、停止应用程序。应用治理是链上治理。链上投票通过后,应通过计算操作:egov 通知应用程序,然后应用程序将在时间锁定后自动执行治理。
- 部署应用程序/Token 在 BRC-100 协议中,有两种部署应用程序的方式:一种是直接使用部署指令进行部署,另一种是通过治理协议:BRC-101 进行部署。第一个用于部署配置不需要治理的父应用程序和子应用程序,另一个用于部署需要治理的子应用程序。
- 铸造代币 BRC-100 协议提供了三种铸造指令:mint、mint2、mint3,用于在不同场景下铸造代币。部署应用程序时,需要设置用户可以铸造的代币数量(使用 “mint” 指令)。剩余的代币也将使用 “mint” 指令来铸造。“mint”:用户铸造,公平铸造,任何人都可以为用户铸造代币,但 “mint” 操作者铸造的总数不能超过应用程序的 “max” 和 “mma” 属性的设置。铸币后,代币的流通供应量将会增加。“mint2”:白名单铸造,应用程序记录可以铸造的用户或应用程序的数量,任何人都可以在应用程序规则下为用户或应用程序 mint2 代币。mint2 之后,代币的流通供应量也将增加。“mint3”:国库铸造,mint3 为其他应用中的用户或应用的余额,任何人都可以在应用规则下为用户或应用 mint3 代币。mint3 之后,代币的流通供应量不会增加。
- 销毁代币 销毁是 BRC-100 协议新引入的操作。用户可以对销毁操作进行铭刻,然后将铭文传输给应用程序的部署者,这与传输操作的语义类似。然后刻录的代币将被销毁或转移到应用程序的余额中。与 mint 操作的定义类似,burn 操作符也有 3 个:burn、burn2、burn3,逻辑上分别对应 mint、mint2、mint3。不需要额外的配置,所有应用程序/代币都支持这三个销毁指令。“burn”:公共销毁,每个人都可以使用指令销毁代币。代币销毁成功后,流通量将会减少,且被销毁的代币无法再次铸造。“burn2”:白名单销毁,根据应用程序预设的规则,burn2 代币到应用程序后,用户的余额会减少,应用程序的状态也会相应更新,流通量会减少。实际中, AMM DEX 中的移除流动性等逻辑可以通过 burn2 来实现。“burn3”:国库销毁,burn3 会减少用户的代币余额,增加 “to” 应用的余额。实际应用中,可以配合 mint3 完成 AMM DEX 中的兑换代币、增加流动性等逻辑。
- 交易税和通货紧缩 BRC-100 协议引入了一种新的代币交易机制:交易税和通货紧缩。应用程序可以设置交易税收百分比、税收接收者和交易黑洞百分比。这些设置仅在基于 AMM 的去中心化交易所进行交易时生效。正常的转账、铸币和销毁操作不会引发交易税和通货紧缩。
- 计算操作 计算操作是 BRC-100 协议的扩展计算行为。它用 cop 属性来表示,是协议计算能力的最小单位。与 op 操作符一起使用时:burn2/burn3/mint2/mint3,可以理解为状态转换函数,它定义了应用程序和用户的状态在相应的 op 操作符下如何更新。
- Oracle 预言机 Oracle 是区块链与链下各方交互的常见需求,并且在以太坊等区块链上得到了很好的实现和应用。如果没有预言机,区块链上的智能合约将完全局限于链上数据。但与区块链相比,BRC-100 协议有非常特殊的特点。它不仅具有区块链的计算能力,而且还依赖链下索引器来完成计算。同时,链下索引器能够直接与其他区块链或元协议进行通信,但区块链无法做到这一点,这意味着索引器可以通过足够的证明数据来验证链下或链上的任何数据满足 Oracle BRC-100 协议的要求。例如:验证 BTC 或 BRC-20 资产的转移、验证以太坊某个区块上的 ETH 价格等。换句话说,在 BRC-100 协议中,预言机有了新的范式:证明和验证,其中用户提交证明数据,索引器作为 Oracle Verifier 来验证用户提交的协议外证明数据,不需要独立的 Oracle 服务。BRC-100协议中,burn2/burn3/mint2/mint3 指令原生支持 proof 属性,用于提交协议外证明数据。索引器可以验证证明数据,保证状态的一致性和正确性,证明可以是转账证明、默克尔树证明、零知识证明、价格证明等,可用于桥接资产、空投等场景、比特币第 2 层、借贷清算等。
- 中继协议 比特币上的元协议是异构的,无法相互通信。不同的协议类似于不同的区块链,它们共享比特币区块链的安全性,并且具有不同的计算能力。此外,元协议不能直接与其他区块链通信:例如以太坊,也不能使用其他区块链上的资产。因此,BRC-100 协议栈需要中继协议来完成比特币、元协议、区块链与 BRC-100 协议之间的通信,将其他协议或区块链上的资产桥接到 BRC-100 上,参与 DeFi 等去中心化应用。同时,由于协议和区块链的多样性,BRC-100 将拥有多种中继协议。首先,我们将发布:BRC-103,负责桥接比特币、BRC-20 和 BRC-100 之间的资产。当将资产从元协议或区块链(来源)桥接到 BRC-100 协议(目标)时,为了索引器可以验证传输的正确性,需要使用 “mint2” 指令提交证明数据,这称为传输证明。转账证明是指在目标协议(BRC-100)上铸造锚定资产时,需要同时提交来源端(如比特币、BRC-20 或其他区块链)上的转账数据作为证明,可以是交易哈希或铭文 ID。以便所有 BRC-100 索引器都可以验证所锚定资产铸币的正确性。Transfer Proof 是 Oracle BRC-100 协议的一个非常重要的应用。
- BRC-101(已发布)
- BRC-100 协议栈的去中心化链上治理协议,定义了如何更新父/子应用程序/代币的属性、停止应用程序和添加子应用程序。另外,BRC-101 也可以通过去中心化投票来完成链下治理。
- BRC-102(开发中)自动化流动性协议,定义了如何通过自动做市商(AMM)算法交换 BRC-100 协议栈的代币。计算逻辑将类似于以太坊上的 Uniswap。
- BRC-103(开发中)BTC、BRC-20 和 BRC-100 之间的中继协议。比特币上的元协议是异构的并且无法相互通信。不同的协议类似于不同的链。它们共享比特币区块链的安全性,并具有不同的计算能力。因此 BRC-100 协议栈会发布多个中继协议来完成元协议、不同链和 BRC-100 之间的通信,并将其他协议和链上的资产桥接到 BRC-100 上,参与 DeFi 等 DApp。
- BRC-104流动性挖矿协议,定义了质押代币后如何获得代币奖励。质押代币可以是任何基于 BRC-100 的代币,例如 BRC-103 协议的流动性池代币,也可以是与奖励代币相同的代币。此外,BRC-104 将支持锁定期来锁定质押的代币。
- BRC-105空投协议,定义了如何高效地将代币空投到多个地址。该协议将使用 Merkle Tree 来完成空投,以节省交易费用,因为所有原始空投数据不需要在比特币上公开。用户在 “mint2” 时只需要提交 Merkle Proof 来证明自己拥有空投,那么所有索引器都可以验证正确性来完成空投。
- BRC-106去中心化稳定币池协议,定义了如何通过抵押品生成稳定币。计算逻辑将类似于以太坊上 MakerDAO3 的 DAI。
- BRC-107借贷池协议,定义了如何通过抵押品借入资产。计算逻辑将类似于以太坊上的Aave。
- BRC-108稳定币的自动化流动性协议。
- BRC-109永续期货的去中心化交易协议。
- BRC-110EVM 兼容区块链和 BRC-100 之间的中继协议,定义了如何将 EVM 兼容区块链上的资产桥接到 BRC-100。
- BRC-111比特币第 2 层验证协议,定义了如何像以太坊上的第 2 层智能合约一样验证比特币第 2 层的证明数据。


