2024 年 3 月 2 日， Runes 生态基础设施项目 Rune alpha 的创始人，在 Github 的公开议题中，与 Runes 协议创始人 Casey 展开了讨论，双方对如何拓展 Runes 协议的「公开铭刻」机制进行了探讨。话题包括： 1、要不要放宽「公开铭刻」不可预留的要求？ 2、指出了采用「公开铭刻」发行方式的 Runes 符文不存在管理权的观点 3、提出了一套基于铭文 NFT 和符文 FT 互相配合的发行机制设想 出于对比特币衍生资产协议的浓厚兴趣，本文作者结合上述 Runes 的一些最新话题，写作了此篇文章，就 Runes 与 Ordinals 协议的过往，以及类似的资产发行方式进行开发性的探索，相信能够对大家了解比特币生态带来帮助。 所谓的 Runes 协议，是在比特币网络上发行同质化代币的协议，由 Ordinals 创始人 Casey 在发布 Ordinals 方案后，又重新构建的同质化代币方案，基于比特币 UTXO 的特性而构建，整体的设计思路非常简洁。 值得一提的是，Runes 协议计划在比特币 2024 年减半时（区块高度 840000 ），也即是今年四月下旬上线主网。现在 Runes 协议仍然处于优化和版本迭代的过程中。 在简要科普 Runes 的原理前，让我们先快速了解下来龙去脉，以及所谓的「公开铭刻」到底代表什么。 Runes 的提出者 Casey 在一开始并没有要做同质化代币协议的 idea ，早在 2022 年 12 月时， Casey 就发布了 Ordinals 协议，意图是将 NFT 数据永久上链 Bitcoin，简单说就是将 NFT 元数据像铭文一样，记录在比特币交易的见证数据 witness 中（witness 主要包含数字签名信息），这样就能够将任意形式的内容（如文本、图像等）铭刻在指定的聪上。 随后，历史的齿轮开始转动，2023 年 3 月 8 日，匿名开发者 Casey 基于 Ordinals 这个典型的 NFT 发行协议，迂回的搞出一套发行同质化代币的 BRC-20 标准，就是以铭文的方式，对那些需要上传到比特币链上的衍生资产数据，规定出统一的格式和属性（ Token 名称、总供应量、单次最大铸造量等），再通过索引器去解析并追踪这些信息，展示出 BRC-20 代币相关的钱包账户和资产数额。 关键来了，BRC-20 的发行，要依赖于 Ordinals 这种比特币铭文 NFT 协议，所以在初始的发行机制上变得和 NFT 铸造过程类似，天然具备「先到先得」的特性，谁先 Mint 谁就拥有，完全不同于以太坊 ERC-20 资产发行时“项目方先部署资产合约，定义资产分配机制，官方想怎么控盘都可以”。 这种 Fair Launch 的特性，使得大多数人有了公平参与同质化代币初始发行的机会，项目方无预留无锁仓，每个人都可以在资产最初发行的第一时间参与。很快，BRC 20 就带来了比特币链上衍生资产的发行热潮，甚至直接启动了这轮牛市。由此可知，我们今天重点讨论的「公开铭刻」的发行方式，对于 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 生态中。 2、是否预留、如何预留，是将自证的手段交给发行方 事实上， Casey 曾多次在 Youtube 视频里直言，同质化通证 99.9% 都是骗局，大家也别冠冕堂皇的说自己要改变世界，坦率地承认这是一个充满赌博和投机的行业，以诚相待，对所有人都好。IT’S JUST FOR FUN! 是从 issue#124 到 #165 ，可以看到 Casey 对同质化通证的使用场景有了更多认可。「公开铭刻」的方式勿需质疑，在此基础上进行拓展，比如增加预留机制，是将选择的权利、自证的手段交给发行方，也是防止劣币驱逐良币的好方法。 3、铭文 NFT 和符文 FT 将会有更多的创新空间 Casey 提出的铭文 NFT 和符文 FT 互相配合进行多轮次的发行机制设想，相当有趣。背景知识里我们说到， Ordinals 和 Runes 都是 Casey 设计的协议，应该算是两个平行关系协议，但是在 Github 上都做到 Ord 这个项目里，技术上不少交叉和配合，比如共用了同步区块这类底层逻辑。 当下热点 Runes tone 和 Runecoin 等项目，也是铭文和符文互相组合创新。Runecoin 的玩儿法是最主流的铭文预挖矿，持有 Runecoin 发行的 RSIC 铭文，就会持续不断的挖出项目的符文，然后 4 月底 Runes 协议上线再分配 FT 。期待未来有更多项目可以推陈出新，带来更新颖的玩儿法。 4、采用「公开铭刻」发行方式的 Runes 符文不存在所有权 Casey 原文中只表达了「 Rune 不存在所有权」，但是笔者认为这应该是特指采用「公开铭刻」发行方式的 Runes 符文不存在所有权。SonPin 提出的两轮「公开铭刻」方案，就一定会有一个拥有极高权限的地址的地址来操作，这并不是 Crypto 加密领域希望看到的。 就像项目 Runecoin 在发完 21000 张 RSIC 铭文 NFT 后，很快就将父铭文打到了中本聪地址，相当于没有人能够再次使用，也就是通过技术手段承诺不做增发。这波操作本身就为其带来一大波好评，非常涨路人缘。 因为在 BTC 做交互速度慢且 gas 高昂，所以当操作数量比较大的时候，为提高效率，一般会先设置一个父铭文，在父铭文的那一次交易里，直接批量处理多个子铭文，这样可以在交互的时候，节约区块链的存储空间和处理时间。 最后说一下 Casey 提到的 CTV，即「Check Template Verify」。 CTV 是一个比特币提议的协议升级，旨在通过允许用户在创建交易时，指定未来交易的模板，从而增强比特币网络的智能合约和锁定功能。CTV 的激活将使得用户能够创建更复杂的交易类型，例如可信赖的空投和开放式蚀刻，而无需协议的显式支持。 这个 CTV 提案增加了比特币网络的可编程性和灵活性，在这次讨论中提到，简单来说就是可以创建一个使用 UTXO 的解锁条件模板，有机会给 Runes 创造更多玩法。举个例子，通过「 Runes 协议+ CTV」，可以让 10 个用户联合使用 CTV 技术，共同 Mint 符文，然后预设未来的一些比特币支付交易的承诺之类。 免责声明：本文仅供参考，不得被用作法律、税务、投资、理财或任何其他建议，不代表 RunesCC 立场。什么是 Runes 协议
PS：什么是父铭文？