深入解读Runes协议的底层设计机制与局限性

1. Runes(符文)概述

过去一年，web3领域最受关注的热点无疑是铭文生态的爆发。其起源可追溯至Ordinals协议，该技术为比特币上的每个聪赋予唯一序号。Ordinals的核心开发者casey早在去年9月就提交了Runes协议的基础代码，但一直未正式上线。这导致一些项目提前分叉该代码，发行了如RunesAlpha等协议。尽管存在争议，但短短数月内数亿美元的市值增长也展现了Runes协议的巨大潜力。

官方版本的Runes协议预计将于2024年4月20日左右在比特币主网正式上线。这意味着项目方、钱包提供商以及NFT/FT交易平台将面临一个重大挑战：如何在没有测试网的情况下直接适配主网。

本文将系统梳理Runes项目的底层字段演变，帮助读者从根本上理解Runes与Brc20、Arc20等FT协议的区别，以便理性评估和参与。

2. 比特币链上数据记录方式

比特币上主要有两种将链下数据附加到链上的方案：铭刻和蚀刻。

2.1 蚀刻基础原理

Runes采用的是蚀刻技术，这是一种直接将信息记录到链上的方法。具体来说，是将数据写入比特币UTXO（未花费交易输出）的op-return字段中。这一功能始于2014年Bitcoin Core客户端0.9版本。OP_RETURN创建了一种可验证但不可消费的输出，允许数据存储在区块链上。

在比特币区块浏览器中，可以轻松看到交易中附加的op-return信息。例如，一个交易的输出#3可能是一个封闭的圆形矩形，表示它不能被再次转移或消费。这就像交易的备注区，永久保存在比特币的存储空间中，可通过交易哈希索引找到。

2.2 铭刻基础原理

Ordinals/brc20等协议将元数据嵌入到交易的见证数据中。这一过程通过隔离见证和"向Taproot支付"（P2TR）方式实现，包括提交和揭露两个阶段，需要两笔交易完成。

P2TR是比特币2021年Taproot升级引入的交易输出类型，允许更私密地存储不同交易条件。具体来说，P2TR地址使用脚本哈希生成，在花费时提供真实脚本（包含铭文数据）。因此，上传铭文数据需要先生成一个支付到此脚本生成的P2TR地址的UTXO（提交交易），然后在花费这个UTXO时，在见证脚本中提供真实脚本，从而将铭文数据上传到链上（揭露交易）。

Ordinals协议规定，铭文在完成这两笔交易后，绑定到第一个输入的第一个聪上。

2.3 两种数据上链方案对比

蚀刻：

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

铭刻：

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

3. Runes底层设计解析

3.1 Runes 0.11版本

早期Runes协议字段分为三部分：edicts（资产转移信息）、etching（资产部署信息）和burn（销毁）。

当op_Return中的信息解码后呈现正确格式的edicts信息时，链下解析器会计算用户资产的转移情况，output字段指定转移目标。

etching内容定义了资产部署的主要信息。与ERC721相比，主要区别在于limit和term字段限制了铸造数量和可铸造区间。这反映了铭文、符文项目与以太坊智能合约发行资产的根本差异。由于缺乏链上智能合约验证，铭文协议统一定义了资产发行和用户参与铸造的方式，以实现公平发射。

3.2 Runes 0.18版本

最新版Runes协议字段分为四个方面：

1. edicts：定义资产转移方向，新增pointer参数用于修改默认转移方向，以适应多种Runes资产同时转出的情况，降低编码量和交易成本。

2. Mint：新增字段，限制一笔交易只能铸造一个资产，平衡了技术型和普通用户的起跑线。

3. etching：资产部署方式发生重大变化。主要改动包括：

   • 资产ID改为字符串形式，节省编码空间。
   • terms字段引入height和offset参数，允许发行方指定铸造起止点。
   • cap参数控制总铸造次数。
   • 引入名字长度释放规则，控制稀缺资源。
   • 采用铭刻技术（commit和reveal）进行部署，提供隐私保护。

4. turbo：新增字段，为未来协议层变更预留。

4. Runes新版协议评价

优点：

• 贴合市场需求，解决了铭文生态中劣质资产横行的问题。
• 嵌入Ordinals协议，具备现成用户基础。
• 作为FT协议，弥补了Ordinals在市场运作方面的不足。
• 采用op_Return记录链上数据，提供灵活的账本能力和较高安全性。

缺点：

• 市场时机存在挑战，紧张的开发时间可能影响生态初期发展。
• 规则复杂，资产名称长度问题可能增加用户被钓鱼的风险。
• 未来兼容性存在疑虑，相比其他协议在L2或BVM方面的布局略显滞后。