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
2、比特币上是如何记录额外信息的？
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资产的部署、铸造、发行等等寓意。
其实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中实现了什么，又是怎样的考虑从而要有这样的字段呢？
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新版协议
runes协议编解码分析：https://github.com/okx/js-wallet-sdk ruens协议官方源码：https://github.com/ordinals/ord
【十四君-原创回顾】
NFT即钱包的ERC-6551 真有那么神奇吗？ 深入EVM-合约分类这件小事背后的风险 用一个小时讲清楚账号抽象这件事 解读比特币Oridinals协议与BRC20标准 原理创新与局限 跨链赛道研报：LayerZero全链互操作协议凭什么估值30亿美金(上）