POS 与 MEV-Boost 的转变，从根本上重塑了交易生命周期的模式，更精细的环节让各参与者们产生极致博弈。

撰文：十四君

Runes（符文）是什么？

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

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

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

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

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

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

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

蚀刻基础原理

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 上。所以，绑定的过程就是铭刻，绑定到结果就是铭文。

对比两者数据上链方案

蚀刻： 

• 优点：逻辑简单直观明确，交易成本低，可以不占用全节点内存池。
• 缺点：限制于 80 字节长度，需要高度压缩数据编码。

铭刻： 

• 优点：几乎不限制大小，有一定隐私保护能力，有多种玩法（时间锁、工作量证明）等 
• 缺点：交易需要 2 次上链，导致最终成本较高，commit 存续时间长，对全节点内存池压力较大。

Runes 底层设计解读

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

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 中实现了什么，又是怎样的考虑从而要有这样的字段呢？

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 字段，这暂时还没有明确的公开作用，寓意为参与后面的其他协议层变更。

如何评价 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 稍有落后，也局限了符文项目只作为发行层面的玩法。

本文内容参考资料：

runes 协议编解码分析：https://github.com/okx/js-wallet-sdk

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