产品战略专家梁宁确认出席AICon北京站,分享AI时代下的商业逻辑与产品需求 了解详情
写点什么

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

评论

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

如何快速运用iPaas与协议进行接口对接

RestCloud

ipaas 接口对接 协议对接

助力客户效益增长近10倍!即构宝藏算法是如何做到的?

ZEGO即构

人工智能 AI 算法 直播技术 虚拟背景

Python如何接收键盘按键

霍格沃兹测试开发学社

Python教程:如何向Word中添加表格

霍格沃兹测试开发学社

Axios拦截器:优化前后端交互的利器还是纸老虎?

测吧(北京)科技有限公司

测试

万界星空科技MES系统在智能生产中的重要作用

万界星空科技

工业互联网 制造业 智能制造 mes 万界星空科技

CloudIDE就是未来编程的新风向

Tp_jh

产品 编程语言 研发效能 企业动态 云端开发

Covalent Network借助大规模的历史Web3数据集,推动人工智能发展

股市老人

从 Linux 内核角度探秘 JDK MappedByteBuffer

bin的技术小屋

jdk RocketMQ JVM Linux内核 java nio

低代码开发与数据可视化

不在线第一只蜗牛

低代码 数据可视化

Pandas:如何让你的代码性能飙升

快乐非自愿限量之名

pandas 代码 数据可视化

架构实战营 - 模块三作业

满心

架构实战营

使用Python爬取豆瓣电影影评:从数据收集到情感分析

霍格沃兹测试开发学社

低代码与前端开发架构:重塑软件开发的未来

快乐非自愿限量之名

前端开发 前端架构 低代码

直播预约丨《袋鼠云大数据实操指南》No.1:从理论到实践,离线开发全流程解析

袋鼠云数栈

大数据 离线开发 离线开发离线计算 数据实操

GTC 2024 开幕,英伟达发布新一代 GPU 架构;Apple ID 或将淘汰丨 RTE 开发者日报 Vol.168

声网

Flask蓝图与ORM技术:神奇的组合还是无用功?

测吧(北京)科技有限公司

测试

安全护卫联手:JWT鉴权与Vue路由守卫,确保敏感资源访问权限完全掌控

测吧(北京)科技有限公司

测试

1688API接口推荐:1688口令转换真实链接接口 审核中

tbapi

1688API接口 1688口令接口 1688淘口令接口

海外社交营销为什么用云手机?不用普通手机?

Ogcloud

云手机 海外云手机 云手机海外版 国外云手机 跨境云手机

订阅GPT4之前必须了解的十件事情-【新手向】ChatGPT入门指南

蓉蓉

openai ChatGPT GPT-4

Partisia区块链推出MOCCA方案,让资产管理更加可信化且可编程

石头财经

Axios拦截器:是前端优化的利器还是不可忽视的安全漏洞源?

测吧(北京)科技有限公司

测试

那些放弃Jira的企业都找了哪些替代工具?盘点15款

爱吃小舅的鱼

项目管理 Jira 项目管理工具

云手机在海外电商中的应用优势

Ogcloud

云手机 海外云手机 云手机海外版 电商云手机

云手机为企业出海提供多元化解决方案

Ogcloud

云手机 海外云手机 云手机海外版 国外云手机 跨境云手机

Vue路由守卫:是破解安全漏洞的关键还是新的安全风险?

测吧(北京)科技有限公司

测试

跨平台应用程序开发如何选择框架

雪奈椰子

看你能解锁哪些新身份?OpenHarmony大使、MVP、金码达人在线申报

OpenHarmony开发者

阿里云 SelectDB 联合 DTS ,一键实现 TP 数据实时入仓

SelectDB

大数据 阿里云 云数据库 数据迁移 #数据库

PHP 服务实现监控可观测性最佳实践

观测云

php

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