前言

交易是web3的灵魂，注意力是web3的最核心资源，价格是簇拥的起点，价值是时间的终点。BTC 减半已经过去一个月，而众望所归的 Runes 协议也过去一个月，这期间涌现出十余家代打平台，交易市场，在减半当天，甚至一笔代打一张 Runes 资产都需要超过 100 美金的成本。本文以 Runes 资产为例，分析哪家才是比特币上资产代打（蚀刻）模型的最佳机制？

1、Runes 代打平台 GAS 排名

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

从方案角度排名，核心结论是：

• gas 成本上“拆分+链式方案” < “链式” < ”拆分” < ”单打“

• 中心化程度：链式（无中间地址）< 拆分（无中间地址） < 链式 （有中间地址） < 拆分（有中间地址）

• 资产归集：链式 > 拆分+链式 > 拆分

• 批量上链速度：拆分 = 拆分+链式 > 链式

• 乍一看可能有些迷糊，什么是链式，什么是拆分呢？这就要回归到 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  这就是将具体内容解码后的结果，点开明细按钮后，就可以找到 52554 e 455 f 54455354 这样的编码串，其实一串十六进制编码数据，解码后就可以得到 RUNE_TEST，同理，明细里还有其他的编码，最终解码后会成为一串字符串，大概是 json 的格式，从而体现出 Runes 资产的部署、铸造、发行等等寓意。

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

那么所谓交易成本，在 BTC 中就是交易链上数据量的大小来体现，那么代打平台的设计，就等同于谁可以最小程度的控制交易中出现的 utxo 数量，就是最优模型。下面让我们展开讲解拆分模型和链式模型

1.2、拆分模型

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

例如 tools.mempool 的代打方案，执行时如下图所示，第一笔交易会预估算出每个子交易的手续费消耗，然后预留出 546 （比特币常见粉尘值）+手续费金额，进行拆分出多个 UTXO，这里会发现他转入到某个新的地址。

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

这种模型显著的问题就是：需要先一笔交易拆分，并且用户得到的是分散的 UTXO。那么当用户想要挂单卖出的时候，要么逐个挂单，要么先合并再挂单，对于大客户而言，会增加交易的成本。并且 tools.mempool 平台在拆分交易中并不会为用户也执行一次代打，所以综合损耗是拆分模型中较高的。

1.3、链式模式

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

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

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

然而这是其实是毫无意义的费用，已经有多个平台都有开源代打代码，比如 OKX 也开源了 Runes 代码：完美解决 Runes 编解码和代打问题，开发者可以直接引用构建自己的代打工具 

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

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

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

• 该平台在拆分就会先给用户打上一笔资产，一点不浪费。

• 并且如果铸造在 25 次以内，拆分出足够链式铸造的 gas，然后执行铸造。

• 最后如果铸造在 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 + o 10 +p 10 = 1310 

拆分 批量 Mint 10 笔，成本：i * 10 + o 10 +o 9  +p* 10 = 1697 

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

链式 批量 Mint 20 笔，成本：i * 20 + o 20 +p 20 = 2620 

拆分 批量 Mint 20 笔，成本：i * 20 + o 20 +o 19  +p* 20 =  3437 

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

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

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

3、总结

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

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

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

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

各个打到的资产，往往需要更快速的转手出去，但是在市场早期价格波动巨大的情况，并且 btc 极度拥挤，其实除了项目方自己市场行为之外，并不会有太多的大批量打资产的需求，换言之，有这么大资金量去打 1000 笔资产的，也自己有能力去做到，平台的核心用户是散户。因此链式虽然成本低，但他并不适合最最早期，在高速波动的定价中，在市场缺乏拆分工具的情况下，链式产生的 20 多张复合在 1 笔交易中，会让交易的扫货的阈值变高。最后本文是 BTC 上资产的代打机制篇，后续还有一份交易市场模型篇，可以适配到（BRC 20、Ordinals、Atomical、Runes）等等新资产的交易模式，敬请关注，切勿错过。

参考资料：

• runes 拆分代打开源代码：https://github.com/okx/js-wallet-sdk

• ruens协议官方源码：https://github.com/ordinals/ord