比特币 Ordinals 铭文与 BRC-20:潘多拉的魔盒

Ordinal 铭文的本质是:在比特币网络上借助一个永远不会被执行的 Taproot 脚本,搭建了一个简易的记账层 ,进行资产和数据的统计和记录。Ordinal 铭文已经引发了比特币社区对比特币基本作用和精神的讨论,这种讨论可能会诞生比特币关于安全性和可编程性的分叉,潘多拉的魔盒正在打开。

什么是 Ordinals 铭文

b5137589-d6e5-4250-88b3-026a4f865c6d.jpg

Ordinals 由开发者 Casey Rodarmor 于 2023年1月20日 在比特币主网上推出针对「聪(Satoshis)」的排序协议,其中「聪」是比特币的最小单位,每一枚比特币都是由一亿个「聪」构成 (1 btc = 10^8 sat),Ordinals 协议赋予每一个「聪」唯一标识。

Ordinals 铭文(Inscriptions)是构建在 Ordinals 协议之上的非同质化代币(NFT),包含了图像、文本、视频等数据。

对比以太坊 NFT,我们可以简单认为 Ordinals 协议实现了 tokenID,铭文实现了 metadata。

如何实现 tokenID

tokenID 为每个 NFT 提供了一个独特的编号,使用户能够将代币彼此区分开来,tokenID 是使 NFT 具有独一无二的原因。

以太坊由于其可编程性很好实现 tokenID,但比特币要使用类似的实现通常要借助第二层网络,如 Counterparty 和 Stacks 已经实现了基于比特币的NFT,但 Ordinals 铭文与其他比特币 NFT 的架构有根本的不同。

Ordinals 协议利用了比特币的 UTXO 交易模型。UTXO 类似于现金的交易模型(cash system),这与传统的基于账户余额的模型有所不同。

在比特币区块链中,所有的余额都是存储在一个名为“未花费交易输出”(Unspent Transaction Output, UTXO)的列表中。每个 UTXO 都包含一定数量的比特币,以及这些比特币的所有者信息,并标明是否可用。可以将其想象成一张署有持有人姓名的现金支票,只要持有人在上面签名,就可以将使用权转让给他人。对于特定的地址,其所有的 UTXO 金额加起来即为该地址钱包的余额。通过遍历所有的 UTXO,我们可以获取每个地址的当前余额。将所有的 UTXO 金额加总,则为当前全部流通的比特币。

为了更好地理解比特币网络的支付模型,我们通过一个例子介绍由A支付给B金额为n的比特币的支付流程。下图展示了用户A发送3个比特币给用户B的过程。

image.png

  1. 对于用户A,首先需要确定其拥有的所有UTXO集合,即用户A可以支配的所有比特币;
  2. A从这个集合中选取一个或者多个UTXO作为交易的输入,这些输入的金额之和为m(2+0.8+0.5=3.3 BTC)要大于需要支付的金额n(3 BTC);
  3. 用户A为交易设置两个输出,一个输出支付给B的地址,金额是n(3 BTC),另一个输出支付给A自己的一个找零地址,金额为m-n-fee(3.3-3-0.001=0.299 BTC)。用户的钱包通常由多个地址组成,一般情况下每个地址只使用一次,找零默认返回给一个新的地址;
  4. 等矿工将这笔交易打包上链进行确认后,B就可以收到这笔交易信息。因为区块的大小有上限(约1 MB),所以矿工会优先确认交易费率(fee_rate=fee/size)高的交易,以获取最高的手续费回报。

根据 Ordinals 协议,「聪」的编号是根据它们被开采的顺序而定,并且由于每一「聪」 BTC 都是通过挖矿奖励产生的,所以可以通过溯源确定它的序号。

假设用户A通过挖矿获得了第100-110个「聪」(10个「聪」是一个整体存放在同一个 id 为 adc123 的 UTXO 中)。当用户A 要支付给用户B 5个「聪」时,他选择使用 id 为 abc123 作为交易的输入,其中5个「聪」给到用户B,5个「聪」作为找零返回给用户A。这两份5个「聪」都是一个整体,分别存放在两个 id 为 abc456 和 abc789 的 UTXO 中。上述 UTXO id和「聪」的数量仅作为例子展示,在实际情况下发送的「聪」的数量最小限制为546个以及 UTXO id 也并非以此形式表达。

image.png

在上述的交易中,用户A的10个「聪」的流转路径为:

  1. 挖矿产生10个「聪」,编号是[100, 110)。表示编号为第100到第109个「聪」存放在id为abc123的UTXO中,其所有者为用户A。
  2. 在A进行转账时,10个「聪」分成两份,每份5个「聪」。这里采用「先到先得」的原则,即「聪」的编号排序是按照它们在交易输出中的索引决定的。假设输出的顺序先是用户A,然后是用户B,那么用户A剩余5个「聪」的序号是[100, 105),存放在id为 abc456 的 UTXO 中,而用户B的5个「聪」的序号是[105, 110),存放在id为 abc789 的 UTXO 中。

如何实现 metadata

Ordinals 铭文的元数据并没有存储在一个特定的位置上。相反,这些元数据被嵌入到交易的见证数据(witness data, witness field) 中,这就是为什么称之为 "铭文" 的原因,因为这些数据被像铭文一样“刻”在比特币交易的特定部分上,而这些数据正是附着在特定「聪」上的。这一铭文过程通过隔离见证(Segregated Witness, SegWit)和Taproot 的方式实现,其中包含了提交(commit)和揭露(reveal)两个阶段,能够将任何形式的内容(如文本、图像或视频)铭刻在指定的「聪」上。

隔离见证是2017年的一个更新,导致了比特币区块链的软分叉。该更新通过增加一个可以支持任意数据的 "见证数据(witness data)" 部分,有效地将比特币交易隔离成两个部分。

image.png

隔离见证将交易和见证(签名)数据分为不同的部分,并使任意的数据可以存储在见证部分。

在技术上,隔离见证的实施意味着交易不再需要包括见证数据(不会占用比特币原本为区块安排的 1MB 空间)。取而代之的是,在一个区块的末尾,为见证数据创建了一个额外独立的空间。它支持任意的数据转账,并有一个折扣的 "区块重量(block weight)",巧妙地将大量的数据保持在比特币的区块大小限制内,以避免硬分叉的需要。

Taproot 于2021年11月实施,是一个多方面的升级,旨在改善比特币的隐私、可扩展性和安全性。Taproot 创建了一个更容易存储任意见证数据的系统,并放宽了对一个比特币交易中可以放置多少任意数据的限制。这次升级的最初目标是进一步加强基于比特币的智能合约,如时间锁定合约,其通常是在见证数据中表述。

image.png

Ordinals 铭文将 metadata 数据存储在 Taproot 脚本路径的花费脚本(spent script)中。

首先,由于Taproot脚本的存储方式,我们可以在Taproot脚本路径支出脚本中存储铭文内容,这些脚本在内容方面几乎没有任何限制,同时还能获得见证数据的折扣,使得存储铭文内容相对经济。由于Taproot脚本的消费只能从已经存在的Taproot输出中进行,因此,铭文采用了两阶段的提交/揭示流程进行铸造。首先,在提交交易中,创建了一个承诺包含铭文内容的脚本的Taproot输出。然后,在揭示交易中,通过将那笔铭文对应的 UTXO 作为输入,发起交易。此时,其对应的铭文内容被公开至全网。

这种做法大大降低了对资源的消耗。如果不使用 Taproot 脚本,见证信息会存储在交易的输出中。这样,只要这笔输出未被消费,见证信息就会一直存储在UTXO集中。相反,如果使用了P2TR,见证信息不会出现在提交阶段生成的交易中,因此它不会被写入UTXO集。只有当这笔UTXO被消费时,见证信息才会在揭示阶段的交易输入中出现。P2TR让元数据能够写入比特币区块链,但却从未出现在UTXO集中。由于维护/修改UTXO集需要更多的资源,因此这种做法可以节省大量资源。

什么是 BRC-20

image.png

BRC-20的虽然名字很像以太坊的 ERC-20,但其实两者技术差别非常大,ERC-20代币的持有状态保存于链上 ,能在链上得到网络共识,而BRC-20只是一种特殊的 Ordinals协议铭文,由 Twitter 用户 @domodata 于 2023年3月8日创建,利用 JSON 数据的序数铭文来部署代币合约、铸币和转移代币。部署的json如下:

{ 

    *"p": "brc-20",//Protocol: 帮助线下的记账系统识别和处理brc-20事件  *

    *"op": "deploy",//op 操作: 事件类型 (Deploy, Mint, Transfer)  *

    *"tick": "ordi", //Ticker: brc-20代币的标识符,长度为4个字母(可以是emoji) *

    *"max": "21000000",//Max supply: brc-20代币的最大供应量  *

    *"lim": "1000"//Mint limit: 每次brc-20代币铸造量的限制*

}

对应的 op 还 mint和 transfer,两个格式几乎一致。当 op 是 Transfer 时,铭文的转账接收方就是铭文对应的「聪」的接收方,因此 BRC-20 的转账必须伴随比特币所有权的转移 ,不是只是作为手续费被消耗。

BRC-20 实行的是「先到先得」的机制,重复的 deploy 和超限的 mint 都是无效的,由中心化机构依据链上登记的各个op来推导出用户当前应该有的余额,并对交易进行有效性裁定。

在这个过程中,铭文是 ‘附加’ 交易「聪」上的,比特币的矿工并不会处理这些铭文,从链上来看跟其它「聪」依然是没有分别的,他们都是当做普通的「聪」来转移的。

BRC-20 的中心化问题

对于 BRC-20 协议来说,它把铭文当作一个账本,用于记录 BRC-20 代币的部署、铸造和转移。由于比特币上无法运行智能合约,BRC-20 代币无法通过运行智能合约查询当前代币的相关信息。因此,BRC-20 通过链外查询,即使用中心化服务器检索比特币区块,记录所有 BRC-20 代币的部署、铸造和转移操作从而查询出各用户的 BRC-20 代币最终的余额。

简单来说,BRC-20 的账本是去中心化的,记录在比特币链上,但结算过程却是中心化的。目前有 brc-20.io 和 unisat.io 两个网站支持 BRC-20 代币的相关查询。

image.png

而结算过程的中心化可能会导致不同平台对于某一账户余额的查询会有不同的结果。尽管在链上记录了所有的操作,但验证这些操作却是由某一客户端负责的。如果这些中心化服务商不公开他们的验证规则,那么整个 BRC-20 生态实际上没有任何保障。

实际上在 4月23日晚,UniSat 上线了 BRC-20 交易平台,但因为代码库存在漏洞,遭受大量双花攻击。地址 bc1pwturekq4w455l64ttze8j7mnhgsuaupsn99ggd0ds23js924e6ms9fxyht 最开始铸造了转账的 Ordinals NFT 尝试凭空将 5000 枚 ORDI 和 35000 枚 ORDI 陆续转到自己的地址,并且试图将凭空铸造的 ordi 卖给其它用户。Unisat 后续暂停了网站访问并进行调查,最后发现有 70 笔交易受到影响。

如果 Unisat 当晚没有检索出错误,那么此次双花攻击造成的损失预计超过 100 万美元。如何确保中心化服务器检索验证不出错是 BRC-20 发展过程中最需要解决的问题。

写在最后

这一篇是我公众号(公众号名:小猪Web3)的一篇发表,探讨了 Ordinal 铭文和 BRC-20。Ordinal 铭文的本质是:在比特币网络上借助一个永远不会被执行的 Taproot 脚本,搭建了一个简易的记账层 ,进行资产和数据的统计和记录。由于只有记账,这就意味着不会有类似智能合约的脚本执行以及验证的过程,必然高度依赖链下的中心化管理和上报结果。因此,除了 BRC-20,所有 Ordinals 铭文只要涉及到状态转移(例如交易)就必须基于比特币网络之外的线下服务进行状态维护。如果底层的状态服务不可用或者有缺陷,可能导致资产损失,因为比特币网络没办法阻止失效铭文上链,中心化平台要裁定谁的铭文有效,在该平台上就是有效的。

这种完全中心化的交易方法和定价方法给了中心化平台巨大的作恶空间,加上铭文「先到先得」的 fomo 机制和矿工按矿工费优先打包的机制存在的逻辑悖论,矿工和抢跑机器人可以抢先 mint 大量热度高的铭文,这就决定了 mint 一定是不公平的。

不过新事物的发展难以预见和判断,毫无疑问,Ordinal 铭文已经引发了比特币社区对比特币基本作用和精神的讨论,这种讨论可能会诞生比特币关于安全性和可编程性的分叉,潘多拉的魔盒正在打开。

笔者来自蚂蚁链,也是一名以太坊/Solana/Sui上的开发者,熟悉主流公链技术和 Web3 项目,拉了一个学习交流群,欢迎对 Web3 有兴趣的同学加入(戳我微信号 go15810306120)。

点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ,好文好收益,欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
Web3朱大胆
Web3朱大胆
0xBD95...d478
从百度到灯火阑珊处,从传统互联网转型区块链的程序员,目前在蚂蚁链负责区块链研发,熟悉主流公链和Web3项目,擅长C++/Rust/Go/Solidity/(Sui)Move。同时也在做Web3自媒体,致力于分享前沿Web3技术。 行业交流欢迎加WX:go15810306120