BTC减半在即：解读Runes协议的底层设计机制与局限

作者：十四君

前言

断更许久，终于复耕，我十四君又回来了。

在过去半年里笔者从ETH生态完全转入BTC生态，从应用层转入链底层，看btc、merlin、babylon、xion等L2公链底层，研究Ordinals、brc20、atomical、Runealpha、Runes等铭文符文协议源码。

有些许沉淀，那就继续始终输出吧，笔者将从技术视角给你带来独特见解与市场价值。

1、Runes(符文)是什么？

过去一年，web3最大的叙事莫过于铭文生态的爆发，最初的起点便是Ordinals，是一种为btc上每个聪给予唯一性序号的技术，可拓展阅读：解读比特币Oridinals协议与BRC20标准 原理创新与局限

其核心创始人casey，在去年9月就提交了基础版的Runes代码，但是一直迟迟没有发布主网上线，因此在9月的铭文热潮中，runeAlpha等项目便提前fork了该代码，单独发行了RunesAlpha等协议，虽然有一定抄袭的说法，但是短短数月数亿的总市值增长也让人看到Runes协议的无穷潜力。

那么由Ordinals协议的创始人casey所设计的，官方正版的Runes协议也将在2024.4.20号左右正式官宣上线。且直接上线btc主网，因此各路项目方想要发行Runes资产，各路钱包、NFT/FT交易市场想要支持Runes都将面临区块链行业最难的挑战之一，如何在没有测试网的情况直接冲刺主网！

而官方的Twitter发言更是高度自信~顺带学个新单词：Seppuku

本文，将会系统的梳理符文项目的底层字段变迁，让大家从根本上理解Runes与Brc20、Arc20等FT协议的差异点，对比优缺理性决策参与。

2、比特币上是如何记录额外信息的？

比特币上有两种主流的链下数据附着在链上的方案，铭刻与蚀刻

2.1、蚀刻基础原理

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资产的部署、铸造、发行等等寓意。

2.2、铭刻基础原理

其实Ordinals/brc20等协议中，要嵌入元数据到链上，都是写到交易的见证数据(witness data, witness field)中，这一铭刻铭文过程通过隔离见证(Segregated Witness, SegWit)和“向Taproot支付”(Pay-to-Taproot, P2TR)的方式实现，其中包含了提交（commit）和揭露（reveal）两个阶段也就是最终2笔交易来完成。

其实P2TR是比特币的一种交易输出类型，它是在2021年进行的Taproot升级中引入的，它使得不同的交易条件可以更加“隐私”地存储在区块链中，之所以提升隐私是因为只有在揭示的时候，才能看到具体完整内容。具体来说生成p2tr地址使用的是脚本hash，在花费时提供真正脚本（包含铭文数据），所以为了上传铭文数据，需要先生成一个支付到此脚本生成的p2tr地址的utxo（commit交易），然后花费这个utxo时，需要在见证脚本中提供真正脚本，也就把铭文数据上传到了链上（reveal交易）。

其实Ordinals协议非常好理解，就是在完成这个铭刻过程（commit、reveal）两笔交易都上链后，ordinals协议则定义规定此铭文绑定到了第一个输入的第一个sat上。所以，绑定的过程就是铭刻，绑定到结果就是铭文。

2.3、对比两者数据上链方案

蚀刻： 

• 优点：逻辑简单直观明确，交易成本低，可以不占用全节点内存池。

• 缺点：限制于80字节长度，需要高度压缩数据编码。

铭刻： 

• 优点：几乎不限制大小，有一定隐私保护能力，有多种玩法（时间锁、工作量证明）等 

• 缺点：交易需要2次上链，导致最终成本较高，commit存续时间长，对全节点内存池压力较大。

3、Runes底层设计解读

Runes协议最初的代码是casey发布在Ordinals 0.11.版本上，而最新的Ordinals 已经演进到0.18版本，巨大的版本变化，也让我们有机会步入一个顶级协议的设计过程中，就像十四君曾经解读的ERC721/ERC3525/ERC3475等标准，拓展阅读：

我们不妨也步入Runes的起点和终点两个版本的字段变化，来解读Runes的价值依规。

3.1、Runes 0.11版本解读

最初的Runes整体的字段分成3个部分，edicts( 资产转移信息)，etching( 资产部署信息)，burn(销毁)。

{  "edicts": // 资产转移信息   [    {      "id": "1000c82970852",       "amount": 1000, //     转移数量      "output": 0    // 绑定到第几个输出    }  ],  "etching": {  // 资产部署信息    "divisibility": 1,  //最小分割单位    "limit": 1000, //每一次mint的量    "rune": "COOK", //全称    "symbol": "C", //缩写    "term": 150 //多少个块内可以mint  },  "burn": false // 销毁信息}

具体来说，当一笔交易的op_Return里，信息解码之后能够呈现edicts 的信息，且格式正确，那么链下的解析器，就会计算出该用户的资产发生了转移，其中的output就是转移的目标地。

同理etching 的内容也是直接呈现了部署资产的主要信息，我们可以和ERC721对比，最大的差别在于limit和term 限制了mint的数量和可mint的区间。而这点也就是铭文、符文项目与以太坊智能合约发行资产的根本性差别，由于链上缺乏智能合约的验证，这就少了实时验证的能力，如果某个项目方发行链上的资产还自己运行一套新的铭文协议来定制化自己的白名单Mint、代币经济学释放速率，版税缴纳等等功能，都将会缺乏共识，就没有人来参与这个项目了，所以铭文协议（brc20、atomical、Runes）等都是统一定义了资产发行的方式，也统一了用户参与mint的方式，以公平发射的理念，完全开放用户参与，进一步杜绝了项目方过度干预资产市场认知的情况。

即使是项目方才通过扫货累计资产来控制市场，也需要付出巨大的gas代价，这个过程里可被用户感知到并且自由选择。

那最初版本的Runes协议设计，其实已经挺完善了，因此演变出的runealpha，哪怕是山寨的也占据不少的市场规模，累计82W的交易笔数，仅手续费就消耗掉312个BTC。

用户可以轻易的使用rune字段本身的设计实现资产的复合、拆分，甚至一旦Runes资产与Ordinals、atomical等资产跨协议复合了，也可以借助op_Return多样的语言表达性，从而实现拆分。

那最新的Runes 协议在0.18中实现了什么，又是怎样的考虑从而要有这样的字段呢？

3.2、Runes 0.18版本解读

要看懂Runes 0.18十分艰难，因为缺乏测试网，基本都只能从casey的源代码里看逻辑，最终梳理出来字段分4个方面：

pub struct Runestone {  pub edicts: Vec<Edict>,  pub etching: Option<Etching>,  pub mint: Option<RuneId>,  pub pointer: Option<u32>,}pub struct Edict {  pub id: RuneId,  pub amount: u128,  pub output: u32,}

首先edicts还是定义资产转移方向方面的定义，与runeAlpha基本一致，差别的是多了一个pointer的参数，这是用来修改资产默认转移方向的，原本的默认转移是第0位，有了这个参数后，可以设置为1或者其他，设计理念是为了适配多种Runes资产同时转出的时候，降低op_Return编码量的作用，最终可以降低用户的交易成本。

其次，新增了Mint字段，由于他的mint放在了和edicts等同级别的对象里，这也就意味着一笔交易只能mint一个资产，这与之前RunesAlpha的时候不同，那时候刻意的设计可以实现一笔交易mint大量新资产，这样一来平衡了技术打资产和普通用户打资产的起跑线，大家都要靠争gas来获取了。

部署资产的方式巨变

最后比较重要的改变是 etching也就是部署资产的细节设计，完全字段内容如下：

pub struct Etching {  // 资产部署信息  pub divisibility: Option<u8>,  //最小分割单位  pub premine: Option<u128>,  // 提前挖掘区块数  pub rune: Option<Rune>,   // runes资产名字  pub spacers: Option<u32>, // runes资产名字的点符号分隔符  pub symbol: Option<char>, // 缩写  pub terms: Option<Terms>, // 铸造规则的系列字段  pub turbo: bool,          // 涡轮，该资产是否参与后续测试性版本变化}pub struct Terms { // 铸造规则的系列字段  pub amount: Option<u128>, // 单次mint的数量限制  pub cap: Option<u128>,    // 总共的mint次数限制  pub height: (Option<u64>, Option<u64>), // 可以被mint的块高  pub offset: (Option<u64>, Option<u64>), // 偏移量，结束mint的终点}

基本看晕了吧，确实是非常复杂的部署新资产方式，让我们详细道来~

首先较大的改动点是为了降低op_Return编码量的设计，毕竟op_Return限制80字节的长度每一个编码空间都要珍惜。因此casey做了资产id的变化，从单纯的区块高度+交易序号生成的唯一id值变化为字符串形式的区块高度+冒号+交易序号，由于比特币主网也才80多w的区块高度，所以最终的id编码节约了一半，可别小瞧，在批量Mint，批量转移场景就成倍的降低成本了。

其次是保障参与者公平性的terms字段，现在部署资产开始Mint不再是runealpha那样，依据部署资产协议的交易上链的区块高度开始，而是发行方指定的height和offset作为起终点。这样一来，用户即使不时时刻刻盯着内存池，从而挖掘最新可以被mint的机会，也不用太担心误入钓鱼山寨项目中。毕竟项目方就可以提前先部署好资产，然后在进行一系列的运营宣发活动，最终让用户参与，除了区间高度作为参与时间的衡量外还有cap，作为总mint次数，进一步控制了资产发行的规模，不再是无极限mint，而是限定发行，先到先得。

作为资产发行协议，那么如何控制发行方的规模和权益便是一大挑战，对于铭文而言，最重要的就是资产名字，那么Runes里名字就是稀缺资源，有一个伴随减半周期的Runes名字长度释放规则，一开始只能部署较长的名字，时间越久才越能部署少字符数的名字。

可以想象，每当一个名字长度释放周期，那么就会持续的掀起类似域名那样的抢注潮流，那如何避免项目方被抢注呢？

这便引入了Runes这次部署的最重大变化，部署的流程，不再只是一笔op_Return的交易，而是一次铭刻，前文有提及，铭刻技术通过commit和reveal可以进行一定的隐私保护，那么新版的premine就是承担了这个作用，要求commit和reveal两笔交易有一定的间隔，然后被揭示出来的时候市场才知道发行方要使用的名字，这时候，即使其他黑客要想制作钓鱼资产，即使是高手在内存池已经看到了该名字，要仿冒，也过不去这个提前量的限制，今儿保护发行方对名字的掌控力。

在18版本最后还新增了turbo字段，这暂时还没有明确的公开作用，寓意为参与后面的其他协议层变更。

4、如何评价Runes新版协议

通过上文对底层字段的解读，十四君也不禁感慨，casey对资产发行的玩法真是见解独到，短短2个月的时间，设计并实现如此贴合市场需求痛点的协议内容。

这是一个看价格来衡量价值的市场，铭文协议一开始作为完全差异化智能合约的模式，打开了很多的想象空间，真正的公平mint也让大量用户真正进入btc的圈子，又进一步引发btcL2d热潮。但是铭文协议一开始的粗放，导致劣质资产横飞，满大街的盗版和rug让铭文生态蒙尘。符文的出现，更高程度定制化的发行管理将会让市场变得有序。

并且Runes协议是嵌入在Ordinals协议本身当中，借助Ordinals本身的用户基础，让Runes协议的发行从一开始就站在巨人的肩膀上。作为FT协议的定位弥补了原先Ordinals只作为 NFT 缺乏市场运作玩法的窘境。

最后，采用op_Return的方式记录链上数据，几乎可以让Runes资产拥有任何机构和复现账本的能力，其中心化程度进一步降低也就可以让Runes资产具备了与btc相等的一定安全性能。

Runes协议有什么缺点呢？确实有

首先是市场时机问题，虽然casey选定在btc减半期同步上线，但是高度紧张的开发时间，甚至在昨天还在变更协议的内容， 这也让市场上能第一时间接入Runes协议的机构越来越少，这样一来协议生态也就需要更多的时间来发酵。

其次是规则复杂性，对于发行管理的规则已经很复杂，但是名字的变化让发行方一开始可选的是较长的名字选择，结合特殊的点符号，让Runes协议的名字最大长度甚至变成：

B•C•G•D•E•N•L•Q•R•Q•W•D•S•L•R•U•G•S•N•L•B•T•M•F•I•J•A•V

几乎55位的长度，这样变相放大了用户被钓鱼的风险，并且移动端插件端等界面也很难完整展示出来。

最后是未来兼容性问题，同样市场火热的atomical协议，现在布局已经走向AVM阶段，让铭文摆脱单纯的代币炒作阶段，进一步走向btc L2或者BVM的叙事中，这点不得不说casey稍有落后，也局限了符文项目只作为发行层面的玩法。