Bitget :便捷购买比特币和
Ordinals创始人亲述:为什么决定构想新协议「Rune」
注:原文来自Ordinals创始人Casey Rodarmor发布博文,MarsBit整理编译。
我不确定为比特币创建一个新的FT协议是否是个好主意。99.9%的FT是骗局和Meme。然而,它们似乎不会很快消失,就像赌场不会很快消失一样。为比特币创建一个良好的FT 协议可能会带来可观的交易费收入、开发者关注度和用户。此外,如果该协议具有较轻的链上足迹,并鼓励可信的UTXO管理,那么与现有协议相比,它可能会减少危害。至少,受欢迎的BRC-20已经创造大量的“垃圾”UTXO。
在比较现有的FT协议时,它们在一些重要方面存在差异:
复杂性:协议有多复杂? 易于实现吗? 易于采用吗?
用户体验:是否有任何对用户体验有负面影响的实现细节?特别是,依赖链外数据的协议具有更轻的链上足迹,但引入了大量的复杂性,并要求用户要么运行自己的服务器,要么发现并与现有服务器进行交互。
状态模型:基于UTXO的协议更自然地适合比特币,并通过避免创建“垃圾”UTXO来促进UTXO集最小化。
原生代币: 协议操作需要使用本地代币,这类协议操作繁琐、需要提取代币,自然不会被广泛采用。
比较现有的比特币FT协议:
BRC-20:不是基于UTXO的,且相当复杂,因为它需要 使用Ordinals 协议进行某些操作。
RGB:非常复杂,依赖于链外数据,已经开发了很长时间,但没有被采用。
Counterparty:某些操作需要原生代币,且不是基于UTXO。
Omni Layer:某些操作需要原生代币,且不是基于UTXO。
Taproot Assets:有点复杂,依赖于链外数据。
一个简单的、基于UTXO的FT协议会是什么样子? 这里有一个叫做“符文”(Rune)协议,它听起来很酷。
概述
“符文”余额包含在UTXO。一个UTXO可以包含任意数量的“符文”。
如果一个交易包含一个输出,其脚本 pubkey 包含一个 OP_RETURN ,后跟随一个 ASCII 大写字母 “R” 的数据输出,则该交易包含一个协议消息。协议消息是第一个数据输出之后的所有。
输入到带有无效协议消息的交易中的符文将被烧毁。这将使“符文”协议能够在未来进行升级,以避免旧客户端错误地分配符文余额的情况。
整数被编码为前缀变量,该变量开始的部分决定了“符文”字节长度。
转账
协议消息中的第一个数据输出被解码为一个整数序列。
这些整数序列包括元组 (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输出来烧毁。
构建交易
如果协议消息有第二个数据输出,该交易则为“符文”创建交易。第二个数据输出被解码为两个整数:SYMBOL 、DECIMALS。如果还有剩余的整数,协议消息无效。
创建交易可以使用分配元组中的ID 0 创建任意数量的符文,最多为2^128 - 1。
SYMBOL 是一个基 26 编码的人类可读符号,类似于序号坐标名称中使用的符号。唯一有效的字符是 A 到 Z。
DECIMALS决定小数点后位数,当显示创建符文时使用。
如果有任何错误,请检查输出符文的大小写。
如果尚未分配 SYMBOL,则将其分配给已发布符文,已发布符文接收下一个可用的数字符文 ID,从 1 开始。
如果 SYMBOL 已分配或为 BITCOIN、BTC 或 XBT,则不会创建新符文。 使用 0 符文 ID 的发行交易分配会被忽略,但其他分配仍会被处理。
注意事项
当显示UTXO余额时,UTXO的原生比特币余额可以用符文 ID 0和符号bitcoin, BTC或XBT显示。
没有试图避免符号占用,以保持协议的简单。避免符号占用的一种可能但仍然简单的技术是,只允许分配超过一定长度的符号,该长度随着时间的推移而减少,直到最终达到零并允许所有符号。这将避免在协议的早期分配短而理想的符号,并鼓励后来对理想符号的竞争,当这种竞争可能是有意义的。
在显示UTXO 余额时,UTXO 的本机比特币余额可以用符文 “ID 0 ”和符号“BITCOIN”、“BTC” 或 “XBT ”显示。