速来报名!AICon北京站鸿蒙专场~ 了解详情
写点什么

欧科云链团队最新发现:BRC-20 交易并不适用于 BTC-UTXO 标签模型

作者:Jason Jiang

  • 2023-07-07
    北京
  • 本文字数:4344 字

    阅读完需:约 14 分钟

欧科云链团队最新发现:BRC-20交易并不适用于BTC-UTXO标签模型

在 Web3 世界,链上活动所产生的数据直接对应着价值流动,掌握链上数据就能发现更多 Alpha。加上近年加密市场频繁遭遇风险事件,个人和机构用户对链上数据也愈加敏感。链上数据已成为洞悉加密世界必不可少的“利器”。但面对近来风头正盛的 BRC20 交易,我们对其进行地址标签分析时,却发现此前的 BTC-UTXO 模型却似乎并不完全适用。那问题究竟出在哪儿?又该如何解决?

BRC20 交易与 PSBT


分析问题前,首先要了解 BRC20 基本情况。2023 年 1 月,比特币核心贡献者 Casey Rodarmor 提出“序数理论”(Ordinals Theory),允许用户在比特币最小单位“聪”上写入任意文件(不超过 4MB 的图像、文本、视频等)。随后,匿名分析师 @domodata 基于 Ordinals 协议创建 BRC20 代币标准。这是一种实验性代币标准,允许任何人在比特币网络发行代币。


Ordinals 协议和 BRC20 标准给比特币生态创造了价值转移之外的全新用例,使其在减半之后有了另一种极具吸引力的叙事逻辑。作为最古老的区块链生态,比特币因此焕发无限活力,BRC20 代币也在 2023 年上半年成为广受关注的赛道:截至 2023 年 6 月 29 日,BRC20 相关代币已超过 6000 种,市值超过 6 亿美元。


但与以太坊 ERC20 部署智能合约后可立即发行和传输代币不同,BRC20 并不是实际意义上的代币,而是记录特定文本的“聪”,因此需要单独索引器来了解 BRC20 代币的状态或余额。同时,BRC20 是以公钥脚本中的 JSON 数据包为承载体,相关代币合约部署以及代币铸造、转移都需要利用 Ordinals 协议将铭文设置为 JSON 数据格式来实现。


由于比特币公钥脚本只存储数据,并不支持智能合约指令执行程序,所以 BRC20 代币也无法构建相关协议实现自动交割,理论上只能通过集中托管或 OTC 完成交易。这些方式不论交易效率和信任程度都不尽如人意,于是 PSBT(Partially Signed Bitcoin Transactions,部分签名比特币交易)开始被用于 BRC20 相关交易中。


所谓 PSBT,是由 BTC 核心开发者 Andrew Chow 提出的一项提高未签名交易便捷性的标准。它可以创建一个未完全签名的交易以及一些其他数据来协助未签名交易的传输,促进未签名交易的可移植性,让多方能在不同时间、不同场合(软件或硬件钱包)更便捷地对同一笔交易进行签名。在一笔多签交易中,Creator 只需先创建一个 PSBT 标识要花费的 UTXO 和接收 UTXO 的 output,再将这个 PSBT 复制到可签名的程序中,通过 Combiner 将多个 PSBT 集成到一个 PSBT 中并发给每个参与者,各方完成签名后即可完成完整交易。


简言之,PSBT 允许用户仅对部分 input 进行签名,以帮助 BRC20 代币在没有智能合约的情况下实现交易的去信任化。包括 UniSat 和其他 Ordinals 市场都在利用 PSBT 技术使买卖双方能以无需信任和非托管方式进行交易。

 

为何 BRC20 交易具有特殊性?


这是因为,如今我们在对比特币地址标签进行解析时,主要基于 UTXO 特性的 Common Spending 和 One-Time-Change 等原则进行追溯。其中,Common Spending 原则是指,如果一笔 BTC 交易同时有多个输入地址,那么可认定这些 input 地址属于同一个实体,因为只有他/它有所有的私钥才能将这些地址放在同一交易中


但在使用 PSBT 进行 BRC-20 交易时,整个 PSBT 广播前都会在链下协调好买卖方在 Input 与 Output 确认后再完成签名,因此在输入中可能会有买方、卖方、平台等多个角色,并存在一个具体参与方(物理上)同时担任多个角色的可能性,因此采用 Common Spending 原则的标签模型并不能兼容此类交易。


以具体的 BRC20 Token 交易为例。目前常见的 BRC20 交易涉及 Token 合约部署(Deploy)、铸造(Mint)和转移(Transfer)三种主要类型。


(1)在 Deploy 和 Mint 过程中,代币转账没有发送方地址而只有接收方地址,其 BTC 转账交易的 Input 和 output 地址最多只有一个,所以无法用基于 Common Spending 原则的模型进行标签拓展。



(ordi 的 deploy 交易-代币转账)



(ordi 的 deploy 交易-BTC 转账)


(2)在 BRC20 代币的 Transfer 过程中,Input 地址通常会有多个,我们可以通过查看交易的代币转账来辨别本次交易的买方和卖方地址。例如,在下面这笔 ordi 的 Transfer 交易


https://www.oklink.com/cn/btc/tx/bc2ac0be40b33cfaf0dedf7bafc97de113ce56e2e6dc7caf67c116f00d1dc849)中,代币发送方(bc1p...hdjn)为交易的卖方,代币接收方(bc1p...wftk)为交易的买方。



但在 BTC 转账交易的 Input 里会存在多个地址,其中有卖方地址,也可能会有买方地址和疑似第三方平台的地址:



经分析,我们发现在 BRC20 的 Transfer 过程中,尽管输入脚本类型大部分是单签(也存在少数多签情况),但由于可能应用 PSBT 技术,将卖方和第三方平台地址等共同添加到 input 中来实现多签,所以会导致 input 中多个地址虽然看起来是单签,但实际上却并不属于同一个实体/个人,因此也无法采用 Common Spending 原则进行判断。


综上,BRC20 交易的特殊性主要体现在:在 Deploy 和 Mint 过程中最多只会出现一个 input 地址,无法满足“Common Spending”原则的前提条件。在 Transfer 过程中,由于 input 地址中有可能包含多种角色,如果用基于“Common Spending”原则的 UTXO 模型对交易地址进行标签拓展,可能会将买方、卖方和第三方平台打上相同标签,导致标签错误,从而会误导其他主体对 BRC20 市场的判断,甚至会影响比特币地址标签的整体准确性和可信性

 

如何消除 BRC20 对 UTXO 标签模型的影响?


为了消除 BRC-20 交易带来的负面影响,在拓展 BTC-UTXO 标签模型的过程中,我们可以选择通过特定筛选机制识别和剔除相关交易,以保证整个 BTC- UTXO 标签库的准确性。同时考虑到,多重签名对基于“Common Spending”原则的 BTC-UTXO 标签拓展模型的影响,我们也需要对相关交易的 input 和 output 脚本进行解析,以过滤多签地址,从而在理论上支持 UTXO 标签拓展不受影响。


其中,识别多签主要是通过查看其锁定脚本中是否包含多个公钥和对应的签名条件。多签锁定脚本通常包含类似于"OP_CHECKMULTISIG" 或 "OP_CHECKMULTISIGVERIFY" 的操作码,并且需要满足多个签名条件才能解锁资金。如果在输出脚本中发现包含多个公钥和对应签名条件,那么这个输出就是一个多重签名输出。同样地,如果输入脚本包含了多个签名,那么这个输入就是一个多重签名输入。


需要注意的是,在进行脚本类型解析时,我们首先要判断交易是否为隔离见证交易。如果是隔离见证交易则需要对 Witness 信息进行解析。以下为常见的非隔离见证交易脚本和隔离见证交易脚本列表:


非隔离见证交易脚本类型

隔离见证交易脚本类型

NONSTANDARD

P2WPKH_V0

P2PK

P2WSH_V0

P2PKH

P2SH_P2WPKH

MULTISIG

P2SH_P2WSH

P2SH

P2SH_P2WSH MULTISIG

P2SH MULTISIG

P2SH_P2WSH_P2PKH

P2SH_P2PKH

 

以非隔离见证交易脚本 Pay-to-Public-Key-Hash (P2PKH)为例。这是最常见的比特币交易类型之一。在 P2PKH 交易中,发送方需要提供接收方的公钥哈希作为交易输出脚本。接收方需要提供与该公钥相对应的私钥来解锁输出。在对 P2PKH 进行解析时,主要规则为:


  • 输入脚本:包含签名信息以及公钥;script.getChunks().size() == 2;



  • 输出脚本:OP_DUP + OP_HASH160 + pubkeyHash + OP_EQUALVERIFY + OP_CHECKSIG;判断是否以 OP_DUP 开头并且以 OP_CHECKSIG 结尾。



在隔离见证交易中,以 P2WPKH 为例。这是一种使用隔离见证技术的交易类型,它可以提高交易的效率和安全性。在 P2WPKH 交易中,发送方需要提供接收方的公钥哈希作为输出脚本。在对这类交易进行解析时,其规则为:


  • 输入脚本:EMPTY

  • witness:签名 + pubkey;判断时首先获取 input script 是否为 EMPTY,然后判断 witness.getPushCount() == 2



  • 输出脚本:0 + 20byte witness program;判断时首先判断是否以 0 开头,之后判断 witness program 长度是否为 20byte。(注:P2WPKH 的 output script 中 witness program 长度规定为 20byte。)



除了依据不同交易的输入输出脚本特征对多签地址进行识别,我们也可以根据相关特征对 BRC20 交易进行筛选。根据调研,BRC20 交易采用 PSBT 技术通过线下签名的形式完成,其隔离见证类型为 Witness 里以 83 为结尾的半签名。


就如同下面这笔交易:

https://www.oklink.com/cn/btc/tx/cbb6bbd6a828b15afe01ec77eab3e96a83be3d5ff56d99caf8185af79c3d1b53


Address:bc1pd6pd4pdzx2an8w8pg8dlst8329ck8t8a6ehqqatglfstqmf3f9yss9yz7y


Winess:

["1b003b4099402cde95be79ab7f4b488c74058c0f620cf4cbeb37a90ca871c4a499334a1262f24fdbe484d7511a54a04aa0d693b02159b603021942cb74f55e9d83"]


Witness 里有以 83 结尾的半签名,所以理应将其视为 BRC20 相关交易。

 

在识别各类多签地址及 BRC20 之后,我们就可以根据一定的规则对多签地址和 BRC20 交易进行剔除,从而保证 BTC- UTXO 标签拓展模式的可行性和可信性。其基本思路如下图所示:



值得注意的是,当前全球主要链上数据服务商在拓展 UTXO 标签时,大都会考虑多重签名所带来的影响,但还未有其他机构关注或提出 BRC20 交易可能导致 UTXO 标签错误的问题。

弥合信息差,在海量链上数据寻找价值增量


Web3 世界对大多数人来说是陌生且神秘的,洞察 Web3 世界最重要的工具就是链上标签。标签解析能力也因此成为评估链上数据分析商竞争力的核心指标。但当我们真的选择链上数据服务商时,除了要关注链上标签的数量,还要关注标签的质量:标签是否准确?更新是否及时?......一个错误的标签带来的负面影响有时候远比没有标签的影响更大。基于此前积累的标签技术能力和对 BRC20 市场的深入理解,欧科云链团队此次发现并提出 BRC20 交易对 UTXO 标签模型的影响,其目的就是希望引起市场重视,提升比特币地址标签的可信性和可用性,让链上标签的质量更过硬。


除了标签解析,全球链上数据服务市场在拥有至少百亿美元级别的巨大发展潜力的同时,也需要持续创新以提升产品与服务质量。链上数据服务商不可能再像 Reuters 和 Bloomberg 等传统金融数据服务商那样,通过直接贩卖即时数据和信息获利,只能转向在海量链上信息中探寻更多增量价值,以更好的技术创新与服务创新吸引用户。只有根植于链上数据并有效结合链下信息,实现与虚拟与现实的有机结合,同时具有敏锐市场分析与数据洞察能力,链上数据分析服务才能适应加密创新与 Web3 市场发展。


作为全球领先的 Web3 数据科技企业,欧科云链目前已具备行业领先的标签解析能力:不仅拥有全球最多的地址标签数量(30 亿+)和最全面的黑灰地址标签(2700 万+),还根据市场发展情况及时更新和拓展地址标签库,以满足用户最新需求。但无论是地址标签解析还是其他链上数据分析,都离不开与市场的交互与连接。欧科云链团队也始终秉持开放态度,期待与更多行业伙伴在地址标签解析和其他链上数据议题方面展开深入交流与合作,共同推动 Web3 生态繁荣。

 

作者简介


笔者系欧科云链研究院研究员 Jason Jiang。Jason 拥有丰富的区块链及数字科技研究经验,曾为多地政府及企业提供咨询服务,著有《Libra:一种金融创新实验》、《数字货币蓝皮书》等书籍。

 

关于欧科云链研究院


欧科云链研究院是欧科云链集团旗下的战略研究机构,以帮助全球商业、公共和社会部门更深入地了解金融科技和区块链经济的演变为使命,输出深度分析和专业内容,涵盖技术应用与创新、科技与社会演变和金融科技挑战等主题,致力于推动区块链技术等前沿科技的应用与可持续发展。

2023-07-07 11:454016

评论

发布
暂无评论
发现更多内容

Java 实现 捕鱼达人 小游戏【附源码】

JavaPub

【技术干货】代码示例:使用 Apache Spark 连接 TDengine

TDengine

数据库 tdengine 开源 时序数据库

【等保测评】2022年北京正规等保测评机构新名单公布

行云管家

等保测评 北京

基于阿里云 ASK 的 Istio 微服务应用部署初探

阿里巴巴云原生

阿里云 容器 微服务 云原生 服务网格

大数据培训数仓实践 Kimball 维度建模

@零度

数仓 大数据开发

亚信安慧AntDB数据库斩获“最佳数据库品牌”大奖

亚信AntDB数据库

编程,不止有代码,还有艺术

华为云开发者联盟

数据库 倒排索引 GaussDB(for Influx) hint

java培训动态上传jar包热部署实战分享

@零度

JAVA开发

如何快速解决集群异常和机器性能波动

NebulaGraph

可视化 图数据库 知识图谱

高危!Fastjson反序列化漏洞风险

源字节1号

软件开发

Java实现一个坦克大战的小游戏【附源码】

JavaPub

常用的 Lambda 表达式案例解析,工作中都会用到!

CRMEB

中科大脑知识图谱平台建设及业务实践

NebulaGraph

图数据库 知识图谱

【LeetCode】最多单词数的发件人Java题解

Albert

LeetCode 5月月更

深入解析 TiFlash丨多并发下线程创建、释放的阻塞问题

PingCAP

小鸟飞行游戏【附源码】

JavaPub

畅聊安全生产,对话B站、唯品会一线专家!|TakinTalks大咖对谈

TakinTalks稳定性社区

吃豆人游戏【附源码】

JavaPub

上新了 亚麻云 | 远程办公有点上头?解锁云上应用现代化的奥秘

亚马逊云科技 (Amazon Web Services)

远程办公 应用

什么是哈希?趣投哈希幸运哈希竞猜游戏开发方案策划

开发微hkkf5566

用户体验至上时代,银行的“主动出击”

博睿数据

金融 博睿数据 数据链DNA IT运维

俄罗斯方块【附源码】

JavaPub

Java 实现 1024 小游戏【附源码】

JavaPub

Java 实现 贪吃蛇 小游戏【附源码】

JavaPub

3D赛车【附源码】设计实现

JavaPub

关于敏捷测试象限的“秘密”

BY林子

敏捷开发 敏捷测试 测试策略

【等保测评】等保测评师怎么考,前景怎么样?

行云管家

网络安全 IT运维 等保测评 等保测评师

Java 实现 植物大战僵尸 小游戏【附源码】

JavaPub

Java

超级马里奥【附源码】

JavaPub

Java实现一个打飞机的小游戏【附源码】

JavaPub

A New ETL Language -- Easy SQL

Bright

数据开发 ETL 大数据开发 EasySQL

欧科云链团队最新发现:BRC-20交易并不适用于BTC-UTXO标签模型_区块链_InfoQ精选文章