前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >什么是BTC上最好的资产代打模型?

什么是BTC上最好的资产代打模型?

作者头像
十四君
发布2024-05-27 16:20:41
1560
发布2024-05-27 16:20:41
举报
文章被收录于专栏:UrlteamUrlteam

前言

交易是web3的灵魂,注意力是web3的最核心资源,价格是簇拥的起点,价值是时间的终点。

BTC减半已经过去一个月,而众望所归的Runes协议也过去一个月,这期间涌现出十余家代打平台,交易市场,在减半当天,甚至一笔代打一张Runes资产都需要超过100美金的成本。

本文以Runes资产为例,分析哪家才是比特币上资产代打(蚀刻)模型的最佳机制?

1、Runes代打平台GAS排名

下图是十四君梳理的一览图。

从方案角度排名,核心结论是:

  1. gas成本上“拆分+链式方案” < “链式” < ”拆分” < ”单打“
  2. 中心化程度:链式(无中间地址)< 拆分(无中间地址) < 链式 (有中间地址) < 拆分(有中间地址)
  3. 资产归集:链式 > 拆分+链式 > 拆分
  4. 批量上链速度:拆分 = 拆分+链式 > 链式

乍一看可能有些迷糊,什么是链式,什么是拆分呢?

这就要回归到Runes协议本身了,建议拓展阅读:《BTC减半在即,解读Runes协议的底层设计机制与局限

1.1、Runes蚀刻机制简述

Runes使用的是蚀刻技术,是一种简单直观记录信息到链上的方式:即写入bitc中UTXO(未花费交易)的op-return字段内,从功能在 Bitcoin Core 客户端 0.9 版中开始启用的(14年),OP-RETURN 会创造了一种明确的可验证不可消费型输出,让数据存在区块链上,类似于utxo的输出,但并不可被消费。

在btc的区块链浏览器中可以轻松看到,该笔交易就附着了一个op-return的信息,比如下图:

可以看到,这里的输出#3,其实是游离的,虽然他占据的一个该笔utxo的output的输出位置,但是他是一个闭环的圆矩形,这就说明他是不能被再次转移消费的,所以他就像是一个交易的备注区一样,就留在了比特币的存储空间上,通过交易哈希区索引找到他。

细心的你可能会发现, 为什么OP_RETURN的后面有一个RUNE_TEST 这就是将具体内容解码后的结果,点开明细按钮后,就可以找到52554e455f54455354 这样的编码串,其实一串十六进制编码数据,解码后就可以得到RUNE_TEST,同理,明细里还有其他的编码,最终解码后会成为一串字符串,大概是json的格式,从而体现出Runes资产的部署、铸造、发行等等寓意。

因此

所谓代打,具体机制总结起来就是:Runes一笔交易只能代打一个资产

那么所谓交易成本,在BTC中就是交易链上数据量的大小来体现,那么代打平台的设计,就等同于谁可以最小程度的控制交易中出现的utxo数量,就是最优模型。

下面让我们展开讲解拆分模型和链式模型

1.2、拆分模型

所谓拆分模型,是在代打过程中先进行一笔交易拆分出多个子交易,每个子交易再进行资产铸造过程。

例如tools.mempool的代打方案,执行时如下图所示,

第一笔交易会预估算出每个子交易的手续费消耗,然后预留出546(比特币常见粉尘值)+手续费金额,进行拆分出多个UTXO,这里会发现他转入到某个新的地址。

第二笔交易则是再从新的地址转回到用户地址,并且完成代打,用户也收拢到Runes资产。

这种模型显著的问题就是:

需要先一笔交易拆分,并且用户得到的是分散的UTXO。

那么当用户想要挂单卖出的时候,要么逐个挂单,要么先合并再挂单,对于大客户而言,会增加交易的成本。

并且tools.mempool平台在拆分交易中并不会为用户也执行一次代打,所以综合损耗是拆分模型中较高的。

1.3、链式模式

所谓链式就类似下列结构,用户最初的有2W个聪,每一个交易都是消费上一个还在内存池的交易,这样也是多笔交易。

这里会发现,这而尾号为s2t4所收取的6144个聪就是平台的代打手续费,对比执行代打所需要本身的手续费3892而言,可以说代打平台的收益是很高的,

该平台,就是之前号称5天开发完Runes代打+交易市场的Runestone,其实从交易上看该平台早就无人问津,但是在最初的那几天,还是产生了几乎3个BTC(150W以上)的手续费收入,对于个人开发者而言不可无不高啊。

然而这是其实是毫无意义的费用,已经有多个平台都有开源代打代码,比如OKX也开源了Runes代码:完美解决Runes编解码和代打问题,开发者可以直接引用构建自己的代打工具 https://github.com/okx/js-wallet-sdk 。

回到链式,由于他几乎是首笔进行了手续费收取,后续的每一笔交易都是如下图一般循环处理,所以他其实本身数据量是比较少的。

2、Runes最佳代打模型:拆分+链式

luminex 是目前相对较佳的方案模型,即可做大批量mint,平台带有utxo拆分工具便于使用,采用拆分+链式方案。

如下图所示:

  1. 该平台在拆分就会先给用户打上一笔资产,一点不浪费。
  2. 并且如果铸造在25次以内,拆分出足够链式铸造的gas,然后执行铸造。
  3. 最后如果铸造在25次以上,就会拆分出多个链式的所需的gas,然后执行铸造。

虽然这样基本手续费并不优于链式,但是他可以做到至关重要的大批量铸造,以及他的上链效率可以卡在极限2个区块内完成铸造。

2.1、为什么会有上链效率的指标呢?

这是因为BTC节点有个防止Dos攻击的机制,

在单 utxo的vout 被消费以及其被消费的链路里,会限制最多25个交易在内存池中。

这是为什么大多数大批量Mint多数采用中间地址的原因,目的是解除这样的限制。对于链式而言,资产会叠加起来最终转给用户。

因此链式模型只有25个交易可以同时在内存池中,但是拆分模型则是在拆分的交易上链后,可以无限值放到内存池中(因为父交易已经不在内存池,每个utxo的vout都独立计算25限制)

所以luminex作为最优模型,并不只是gas最低,而是即保持gas很低,也还有大批铸造的能力。

不过,其实也还有比luminex更好的模型。

因为luminex的拆分交易也会单独代打给用户,但是这个资产其实是不用转给用户的,而是可以转给第二个链式交易的utxo里,因为Runes有资产默认流动机制,这样可以再luminex的情况下在减少一个utxo的成本。

2.2、BTC手续费优化率对比

讲述了半天成本,那成本究竟如何衡量?其实很简单,用户平时设置的是单价,即类似于gasPrice,但是BTC上其实是完全依赖于存储数据作为数量单位即vsize。

所以咱们以taproot地址为例(不同地址手续费不同,taproot地址属于较低的手续费),此种地址的结构中:

  1. 每增加一个input,vsize增加58。
  2. 每增加一个output,vsize增加43。
  3. 而写入每个OP_RETURN ,vsize需要30左右。

因此我们可以算出来以下优化率

链式 批量Mint 10笔,成本:i * 10 + o10 +p10 = 1310

拆分 批量Mint 10笔,成本:i * 10 + o10 +o9 +p*10= 1697

gas优化率:(1697-1310)/1697 = 22.8%

链式 批量Mint 20笔,成本:i * 20 + o20 +p20= 2620

拆分 批量Mint 20笔,成本:i * 20 + o20 +o19 +p*20= 3437

gas优化率:(3437-2620)/3437 = 23.8%

看似20%不多,但是在单笔铸造就要消耗100U的巅峰期,10次批量就可以降低200U的成本,细微的成本价差最终映射到成交的心理阈值上。

面对高昂的代打手续费,未来期望在web3圈子里分到最早一杯羹的人,还是需要学会基础的node js,从而直接运行各家开源代码(如上文提及的OKX开源的签名组件)从而直接越过平台收费问题,甚至在下篇交易市场篇中,也可以直接越过多家平台阻拦直接构建跨平台交易,甚至直接监听内存池,直接抢跑谋取收益。

3、总结

Runes资产协议发行1个月,可惜最终并没有突破10亿美金的阈值,也传出Ordinals与runes创始人casey要seppuku的直播趣谈。

但归根究底,还是生态中,代打和市场两个核心基建不完善,让散户参与成本过高,让机构参与缺乏生态运营。

首先目前出现的平台要么收取高额手续费,要么功能不齐全。比如Runestone虽然链式成本低,但是其gas估算不准确,容易导致最后一笔交易的磨损,伴随上链的不确定性,逐步使其退出市场。

还有,目前的代打模型,还是忽略了用户真实诉求,交易本身。

各个打到的资产,往往需要更快速的转手出去,但是在市场早期价格波动巨大的情况,并且btc极度拥挤,其实除了项目方自己市场行为之外,并不会有太多的大批量打资产的需求,换言之,有这么大资金量去打1000笔资产的,也自己有能力去做到,平台的核心用户是散户。

因此链式虽然成本低,但他并不适合最最早期,在高速波动的定价中,在市场缺乏拆分工具的情况下,链式产生的20多张复合在1笔交易中,会让交易的扫货的阈值变高。

最后本文是BTC上资产的代打机制篇,后续还有一份交易市场模型篇,可以适配到(BRC20、Ordinals、Atomical、Runes)等等新资产的交易模式,敬请关注,切勿错过。

参考资料:

  • runes拆分代打开源代码:https://github.com/okx/js-wallet-sdk
  • ruens协议官方源码:https://github.com/ordinals/ord
本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2024-05-26,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 十四君 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 1、Runes代打平台GAS排名
  • 2、Runes最佳代打模型:拆分+链式
  • 2.1、为什么会有上链效率的指标呢?
  • 2.2、BTC手续费优化率对比
    • 3、总结
    相关产品与服务
    云直播
    云直播(Cloud Streaming Services,CSS)为您提供极速、稳定、专业的云端直播处理服务,根据业务的不同直播场景需求,云直播提供了标准直播、快直播、云导播台三种服务,分别针对大规模实时观看、超低延时直播、便捷云端导播的场景,配合腾讯云视立方·直播 SDK,为您提供一站式的音视频直播解决方案。
    领券
    问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档