写点什么

欧科云链团队最新发现: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:453983

评论

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

ModStartCMS模块化建站系统 v3.4.0 富文本粘贴上传,自定义分页

ModStart开源

php laravel modstart

网易数帆云原生日志平台架构实践

网易数帆

云原生 网易

如何选择最优路径完成云原生上云?听这场阿里云特别分享【云原生技术与最佳实践】

阿里巴巴云原生

网络协议之:socket协议详解之Datagram Socket

程序那些事

socket 网络协议 udp 程序那些事 3月月更

什么是FAQ?如何编写FAQ文档?

小炮

小程序插件提升APP使用体验

Speedoooo

敏捷开发 APP开发 app性能 容器平台 小程序插件

大咖说|阿里巴巴闻佳:数字技术将引领我们走向节能型社会

大咖说

阿里巴巴 数字化 环保 双碳

云图说|DRS数据对比——带您随时观测数据一致性

华为云开发者联盟

数据一致性 DRS 数据复制 数据迁移

使用Rust的几点理由,加入我们,一起学习!

非凸科技

无缝融入 Kubernetes 生态 | 云原生网关支持 Ingress 资源

阿里巴巴云原生

【web安全】Spring boot heapdump获取敏感信息

H

Java 网络安全 WEB安全

【CAD】系列Ⅰ

謓泽

3月月更

网络安全 kali web安全【渗透测试】目录遍历漏洞

学神来啦

网络安全 渗透测试 WEB安全 kali kali Linux

从旁观者到贡献者:经历 OpenYurt 的“开源之夏”,我们想让更多人体验社区的魅力

阿里巴巴云原生

详解图像处理的算术运算与逻辑运算

华为云开发者联盟

OpenCV 计算机视觉 图像处理 图像算术 逻辑运算

国产虚拟化软件H3C CAS体验之环境搭建(虚拟机搭建)

WangNing

虚拟化 环境搭建 H3C CAS

二维码的应用技术

源字节1号

开源 前端开发 二维码 后端、

C++后台开发学习路线

Linux服务器开发

后台开发 C/C++ 后端开发 Linux服务器开发 C++后台开发

销售CRM系统解决方案

低代码小观

销售管理 CRM 企业管理系统 CRM系统 客户关系管理系统

Intel CET缓解机制实战解读

腾讯安全云鼎实验室

安全攻防 网络安全 安全研究

设计秒杀系统架构,这4个关键点要注意

华为云开发者联盟

秒杀系统 订单 秒杀系统架构 RabbitMQ延时队列 Rabbit MQ

“==”和“===”,难道不是多一个的区别吗?

华为云开发者联盟

JavaScript typescript string 变量 操作符

NextRPC : RPC多段返回的创新和探索

阿里巴巴终端技术

RPC 客户端

数字化时代,银行如何建设管理小程序平台促进线上金融业务发展?

FinClip

小程序 银行

揭秘字节跳动云原生Spark History 服务 UIService

字节跳动数据平台

大数据 spark 字节跳动 湖仓一体

vivo鲁班RocketMQ平台的消息灰度方案

vivo互联网技术

RocketMQ 消息中间件

释放「数据价值」,请别忽视基础软件本身的提升

ToB行业头条

2021年券商APP盘点:用户规模大幅度增长,智能炒股成为行业标配

易观分析

券商

消息复杂计算的抽象和简化

阿里巴巴终端技术

数据处理 客户端 消息

业务驱动的全景监控体系在阿里的应用 | 阿里巴巴DevOps实践指南

阿里云云效

云计算 阿里云 DevOps 云原生 云端开发

Tech Talk 活动预告 | 送走 CentOS Linux 8,开发者们该如何保持 Linux 的采用途径?

亚马逊云科技 (Amazon Web Services)

开发者

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