写点什么

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

评论

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

个人信息保护法生效,企业数据安全合规正当时

行云管家

信息安全 数据安全 企业安全 网络保护

墨天轮国产数据库沙龙 | 黄新著:金仓数据库全生命周期管控

墨天轮

国产数据库 KingBase 人大金仓

百度人脸活体检测系统通过信通院“护脸计划”首批优秀级安全防护能力评估

百度开发者中心

安全 人脸识别 百度安全

springboot集成阿里云短信

小鲍侃java

11月日更

行云管家荣登36kr企服点评云计算软件排行榜NO.1

行云管家

云计算 软件 排行榜 IT运维

极光笔记丨Spark SQL 在极光的建设实践

极光GPTBots-极光推送

大数据 spark 计算引擎

11.11上云嘉年华,华为云数据库助力客户备战业务高峰

华为云数据库小助手

GaussDB GaussDB(for openGauss) GaussDB ( for Redis ) 华为云数据库

初识Java反射概念和使用

CRMEB

技术干货|开源项目-FlyFish使用攻略

云智慧AIOps社区

开源 大前端 低代码 数据可视化 大屏

Apache APISIX 扩展指南

API7.ai 技术团队

Apache 插件 API网关 Apache APISIX

OceanBase 源码解读(六):存储引擎详解

OceanBase 数据库

数据库 开发者 高性能 资源隔离 租户

白码低代码/无代码开发平台功能及作用

低代码小观

低代码 开发工具 开发平台 无代码 企业服务

一文,动态规划入门

bigsai

算法 动态规划

真香!180页100+题15W+字解析的《Java高级面试指南》,果断收下

Java 程序员 架构 分布式 算法

腾讯安全李滨:腾讯云数据安全与隐私保护探索与实践

腾讯安全云鼎实验室

数据安全 云安全

恒源云(GPUSHARE)_Child Tuning: 反向传播版的Dropout

恒源云

深度学习

什么是DISA STIG?概述+STIG安全

旋极智能

原来我才是内卷王,闭关3个月肝完Java 7大核心知识,成功斩获字节58万Offer。

Java高级开发

字节跳动 java; 字节跳动面经

你以为委派模式很神秘,其实你每天都在用

Tom弹架构

Java 架构 设计模式

为什么那么多人在用WGCLOUD

王逅逅

zabbix 监控系统 linux运维 运维系统

如何获取所有安装的应用程序信息

Changing Lin

11月日更

业务数据清洗,落地实现方案

数据 数据清洗 数据管理 数据服务 业务数据

《Linux一学就会》:第二章:Linux基本命令操作和文件管理

侠盗安全

Linux 运维 linux运维 云计算架构师

入职字节跳动那一天,我哭了(蘑菇街被裁,奋战7个月拿下offer)

Java MySQL redis 程序员 算法

推动产业创新,腾讯的底层逻辑是什么?

ToB行业头条

IOS技术分享| WebRTC iOS源码下载&编译

anyRTC开发者

ios 音视频 WebRTC 实时通信 视频直播

JavaIO流核心模块与基本原理

Java nio IO流 字符流 字节流

“神算子”上线!EasyDL时序预测模型零门槛轻松上手

百度开发者中心

百度飞桨

低代码是什么意思?

低代码小观

程序员 低代码 开发工具 开发平台 企业开发系统

内在可解释模型之RuleFit

索信达控股

机器学习 算法 模型

让脂肪起内讧?从内部全面瓦解脂肪

脑极体

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