取代BRC-20激活BTC生态？Ordinals创始人带来新协议Runes

原文 | Casey Rodarmor

编译 | Odaily星球日报

昨天， Ordinals 创建者 Casey Rodarmor 发布 博客 ，介绍了一个新的可替代代币（fungible token，简称 FT）协议 Runes。

关于比特币究竟是否需要 FT，Casey Rodarmor 在 其推文 中表示 FT 具有两面性。一方面， 99.99% 的 FT 都是「狗屎」和骗局，削弱了比特币的纯净度；另一方面，它们为比特币生态带来大量的费用收入、开发者和用户。“人们喜欢代币，它们就像赛博朋克赌场，所以费用收入可能是可观的和持续的，直到人们对（网络）安全预算的担忧完全缓解。”

他补充说，目前已经出现了 BRC-20、RGB 和 Taproot 等 FT 协议。与简单的链上协议相比，RGB 和 Taproot 这样的协议很复杂，可能会给用户体验带来挑战。BRC-20 非常简单，并且与需要链下数据存储和检索基础设施的 RGB/Taproot 相比，可以提供不错的用户体验；但 BRC 20 代币的问题在于，它们会产生“垃圾 UTXO”而占据比特币的空间。

Rodarmor 表示，Runes 是以 UTXO 为基础的协议，更自然地适应比特币，并通过避免创建“垃圾 UTXO”来促进 UTXO 集合的最小化。

以下内容来自 Casey Rodarmor 博文，由Odaily星球日报编译

我不确定，为比特币创建一个新的可替代代币（FT）协议是否是一个好主意。99.9% 的 FT 都是骗局和表情包。然而，它们似乎不会很快消失，就像赌场似乎不会很快消失一样。

为比特币创建一个良好的 FT 协议，可能会为比特币带来可观的交易费收入、开发者关注度以及用户。此外，如果该协议的链上足迹较小并激励负责任的 UTXO 管理，那么与现有协议相比，它可能会减少危害。比如现在流行的 BRC-20 ，就导致了大量垃圾 UTXO 的产生。

如果我们比较现有的 FT 协议，会发现它们有几个重要的区别：

• 复杂性：协议有多复杂？实施起来容易吗？容易被采纳吗？

• 用户体验：是否存在对用户体验有负面影响的实现细节？特别是，依赖于链下数据的协议具有较轻的链上足迹，但引入了很大的复杂性，并且要求用户要么运行自己的服务器，要么发现现有服务器并与现有服务器交互。

• 状态模型：基于 UTXO 的协议更自然地适合比特币，并通过避免创建“垃圾”UTXO 来促进 UTXO 集最小化。

• 原生代币：具有协议操作所需的原生代币的协议是繁琐的、可提取的，并且自然不太被广泛采用。

根据上面的维度，对比特币生态现有的 FT 协议比较结果如下：

• BRC-20 ：不是基于 UTXO 的，而且相当复杂，因为它需要在一些操作中使用序数理论；

• RGB：非常复杂，依赖于链下数据，已经开发了很长时间没有被采用；

• Counterparty ：具有某些操作所需的原生代币，而不是基于 UTXO 的；

• Omni Layer：具有某些操作所需的原生代币，而不是基于 UTXO 的；

• Taproot Assets：有点复杂，依赖链下数据。

对于比特币来说，一个简单的、基于 UTXO 的、具有良好用户体验的 FT 协议会是什么样子？下面，我想大家介绍一个非常酷的方案，它叫「Runes」（符文）。

（1）概述

Rune （符文）余额由 UTXO  持有；UTXO 可以包含任意数量的 runes。

如果交易包含一个输出，其脚本 pubkey 包含 OP_RETURN 后跟 ASCII 大写字母 R 的数据推送，则该事务包含一个协议消息。该协议消息是第一个之后推送的所有数据。

输入（input）到具有无效协议消息的交易的符文将被销毁，这允许未来的升级改变符文的分配或创建方式，避免旧客户端错误地分配符文余额。

整数被编码为前缀 varint，其中 varint 中的前导数决定了其长度（以字节为单位）。

（2）转账

协议消息中的第一个数据推送被解码为序列整数。

这些整数被解释为（ID、OUTPUT、AMOUNT）元组序列。如果被解码的整数个数不是 3 的倍数，则该协议消息消息无效。

• ID 是要分配的运行的数字 ID

• OUTPUT 是要赋值的输出的索引

• AMOUNT 是要分配的运行量

ID 被编码为 delta。这允许多次分配相同的符文，以避免重复完整的符文 ID。例如，元组： [( 100, 1, 20), ( 0, 2 10), ( 20, 1, 5)]

进行以下分配：

• ID 100 ，输出 1, 20 符文

• ID 100 ，输出 2, 10 符文

• id 120 ，输出 1, 5 符文

AMOUNT 0 是“所有剩余符文”的简写。

处理完所有元组分配后，任何未赋值的符文都被赋值给第一个非 OP_RETURN 输出(如果有的话)。 多余的赋值将被忽略。

可以通过将符文分配给包含协议消息的 OP_RETURN 输出，来刻录符文。

（3）发行

如果协议消息有第二次数据推送，则它是一个发行交易。第二次数据推送被解码为两个整数，SYMBOL、DECIMALS。如果剩下额外的整数，则协议消息无效。

发行交易可以使用赋值元组中的 ID 0 创建任意数量的发行符文，最多可达 2 ^ 128 - 1 。

SYMBOL 是一个人类可读的 26 位基本编码符号，类似于序数 sat 名称中使用的符号。唯一有效的字符是 A 到 Z 。

DECIMALS 是显示发行的符文时应使用的小数点后的位数。

如果 SYMBOL 尚未分配，则将其分配给已发布的符文，并且已发布的符文接收下一个可用的数字符文 ID（从 1 开始）。

如果 SYMBOL 已被分配，或者是 BITCOIN、 BTC 或 XBT ，则不会创建新的符文。使用 0 符文 ID 的发行交易分配将被忽略，但其他分配仍会被处理。

（4）注意

当显示 UTXO 余额时，UTXO 的本地比特币余额可以用符文 ID 0 和符号  BITCOIN、 BTC 或 XBT 来显示。

为了保持协议简单，（Runes）并没有采取避免符号抢注的机制。实际上，避免符号占用的一种有效且简单的方式是，仅允许分配超过一定长度的符号，该长度随着时间的推移而减少，然后最终达到零并允许所有符号。这将避免在协议的早期分配简短的、理想的符号，并鼓励后来者对理想符号进行竞争——如果这种竞争有意义。

写在最后

这个方案真的对市场有用吗？我不知道。

它只是尽可能简单，不依赖于链下数据，没有原生代币，并且非常适合比特币的原生 UTXO 模型。这样的方案，可能会从其他链上足迹更差的方案中吸引用户，并将开发者和用户的注意力转向比特币，鼓励他们采用比特币本身。

另一方面，FT 的世界是一个完全无法挽回的欺骗和贪婪的深渊，所以它可能会被洗掉。