关于Runes协议及“公开铭刻"发行机制的拓展讨论
作者：MiX
编辑：Faust，极客web3
2024年3月2日，Runes生态基础设施项目Rune alpha的创始人，在Github的公开议题中，与Runes协议创始人Casey展开了讨论，双方对如何拓展Runes协议的「公开铭刻」机制进行了探讨。话题包括：
·要不要放宽「公开铭刻」不可预留的要求？
·指出了采用「公开铭刻」发行方式的Runes符文不存在管理权的观点
·提出了一套基于铭文NFT和符文FT互相配合的发行机制设想
出于对比特币衍生资产协议的浓厚兴趣，本文作者结合上述Runes的一些最新话题，写作了此篇文章，就Runes与Ordinals协议的过往，以及类似的资产发行方式进行开发性的探索，相信能够对大家了解比特币生态带来帮助。
什么是Runes协议
所谓的Runes协议，是在比特币网络上发行同质化代币的协议，由Ordinals创始人Casey在发布Ordinals方案后，又重新构建的同质化代币方案，基于比特币UTXO的特性而构建，整体的设计思路非常简洁。
值得一提的是，Runes协议计划在比特币2024年减半时（区块高度840000），也即是今年四月下旬上线主网。现在Runes协议仍然处于优化和版本迭代的过程中。
在简要科普Runes的原理前，让我们先快速了解下来龙去脉，以及所谓的【公开铭刻】到底代表什么。
Runes的提出者Casey在一开始并没有要做同质化代币协议的idea，早在2022年12月时，Casey就发布了Ordinals协议，意图是将NFT数据永久上链Bitcoin，简单说就是将NFT元数据像铭文一样，记录在比特币交易的见证数据witness中（witness主要包含数字签名信息），这样就能够将任意形式的内容（如文本、图像等）铭刻在指定的聪上。
（图片来源：https://yishi.io/a-beginner-guide-to-the-ordinals-protocol/）
随后，历史的齿轮开始转动，2023年3月8日，匿名开发者@domodata基于Ordinals这个典型的NFT发行协议，迂回的搞出一套发行同质化代币的BRC-20标准，就是以铭文的方式，对那些需要上传到比特币链上的衍生资产数据，规定出统一的格式和属性（Token名称、总供应量、单次最大铸造量等），再通过索引器去解析并追踪这些信息，展示出BRC-20代币相关的钱包账户和资产数额。
关键来了，BRC-20的发行，要依赖于Ordinals这种比特币铭文NFT协议，所以在初始的发行机制上变得和NFT铸造过程类似，天然具备「先到先得」的特性，谁先Mint谁就拥有，完全不同于以太坊ERC-20资产发行时“项目方先部署资产合约，定义资产分配机制，官方想怎么控盘都可以”。
这种Fair Launch的特性，使得大多数人有了公平参与同质化代币初始发行的机会，项目方无预留无锁仓，每个人都可以在资产最初发行的第一时间参与。很快，BRC20就带来了比特币链上衍生资产的发行热潮，甚至直接启动了这轮牛市。由此可知，我们今天重点讨论的「公开铭刻」的发行方式，对于Runes协议而言非常重要。
但BRC-20也带来了很多问题：BRC-20资产的每一次操作，都要在比特币链上发起特定的交易，随着BRC-20资产的火爆，比特币UTXO数据集也快速膨胀，这使得BTC核心开发者对BRC-20产生公开质疑。
Ordinals创始人Casey不仅反对BRC-20，更是对基于Ordinals之上发行的FT资产不予认可，但是BRC-20的火爆，让他觉得虽然99%的代币都是骗局和噱头，但这些东西仍会像赌场一样无法消失。
同时，BRC-20在比特币链上留下了“过多的痕迹”，为比特币节点带来了数据承载上的负担，但如果有人提出一套，能够在上链数据方面“减负”的资产协议，或许能减缓BRC-20带来的问题。
所以Casey决定为比特币构建一种“更好的同质化代币协议”，随后在2023年9月25日，他发布了Runes协议的初步构想。
从技术角度看，Runes协议基于比特币UTXO和附加信息而构建，每一笔交易的触发，都要把链下生成的数字签名信息on chain，我们可以在签名信息中携带特定格式的消息。Runes协议通过OP_RETURN操作码来标记出“特定消息”，这些特定消息就是与Runes资产变更相关的信息。
相比于BRC-20协议，Runes 优势很多，其中最重要在于：
1.交易步骤简化，且不会生成多余的无用UTXO，能更好的为比特币节点“减轻负担”。此外，BRC-20的一笔转账交易仅支持一个接收者和一种代币，而Runes支持同时向多个接收者转账，且可转账多种Runes代币。
2.资产数据的存储与索引更简洁：BRC-20的数据以JSON格式存储在特定交易的witness数据中，且BRC-20基于账户模型，资产余额与指定的账户相关联。而Runes协议的数据存储在特定交易的OP_RETURN字段中，资产的记录方式采用UTXO模型，可以直接与比特币链上的UTXO“同构绑定”。
在确认一个人的Runes资产状况时，只需验证这个人拥有的、与Runes资产相绑定的特殊UTXO，虽然还是要追溯部分信息完成计算，但无需像BRC-20那样扫描比特币链上的完整UTXO集合，这种轻量化的方式对数据索引更友好。
3.与UTXO功能拓展层兼容：Runes基于UTXO的设计，使其能够与CKB、Cardano、Fuel等基于UTXO的功能拓展层更好地兼容。通过类似于RGB++的“UTXO同构绑定”，上述功能拓展层可以为Runes提供智能合约场景。
简要谈完了技术，我们回到本文最开始谈论的发行机制的事情。Casey为Runes符文设计了两套发行方式，即「固定总量」和「公开铭刻」：
1.固定总量就是发行方直接铭刻所有Runes符文，然后再进行分发，相对更中心化。
2.公开铭刻就是对Runes符文的发行方式设定参数，比如指明一个区块高度或时间戳，在符合规则的时间段内，用户Mint了多少资产，最后该符文的总量就是多少。
两种发行方式对应的场景与机制完全不同，下文中我们只聊「公开铭刻」。
事实上，Sondotpin从Runes的Issues#124议题中，就开始讨论此话题，并得到了Casey的认可。
而Issues#165具体内容如下：
Sondotpin：目前的公开发行，项目方/发行方不能提前预留Runes符文，这限制了项目方设计优秀通证经济模型的机会。
Casey：请查看之前的Issues#124。我正在考虑放宽这个要求，允许发行方在发行时以合理的方式安排符文，甚至超出参数的设定范围。如果这样设计，相关信息会在Runes符文的详情页做非常突出的展示。
Sondotpin：是不是可以设计一个多次发行的机制，比如能有两轮「公开铭刻」Runes符文，然后每一轮发行设定不同的参数？
Casey：我并不倾向于这样的做法，因为Runes符文本质上并没有「管理者」。发行的权限不应该掌握在有特别权限的单一实体手上。但是你可以在发行符文的时候添加一个铭文，然后在这个铭文的基础上再发行新的符文，这样就可以实现两次发行的符文都是同一个资产。当然，你也可以采用预挖的方式，然后用其他的分配方式进行发行。
如果未来 CTV 的功能能够顺利启动，就不需要协议支持了，CTV 直接可以预先设定条件模板，达到条件后就可以做符合条件设置的空投和公开发行。
围绕Casey和SonPin的讨论，个人看法：
1.在发起项目的早期，预留部分Token确有必要
在早期，项目方想要实现业务的自举，需要有一定的Token储备去激励核心团队、凝聚社区。如果可以按照本次讨论去实现协议，是对「公开铭刻」的公平和全民参与价值的补充，可以让更多有价值基础项目方通过「公开铭刻」的方式参与到Runes生态中。