查看原文
其他

关于Runes协议及“公开铭刻"发行机制的拓展讨论

MiX 极客 Web3 2024-03-12

作者: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生态中。

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这个项目里,技术上不少交叉和配合,比如共用了同步区块这类底层逻辑。


当下热点Runestone和Runecoin等项目,也是铭文和符文互相组合创新。Runecoin的玩儿法是最主流的铭文预挖矿,持有Runecoin发行的RSIC铭文,就会持续不断的挖出项目的符文,然后4月底Runes协议上线再分配FT。期待未来有更多项目可以推陈出新,带来更新颖的玩儿法。


4.采用「公开铭刻」发行方式的Runes符文不存在所有权


Casey原文中只表达了「Rune不存在所有权」,但是笔者认为这应该是特指采用「公开铭刻」发行方式的Runes符文不存在所有权。SonPin提出的两轮「公开铭刻」方案,就一定会有一个拥有极高权限的地址的地址来操作,这并不是Crypto加密领域希望看到的。


就像项目Runecoin在发完21000张RSIC铭文NFT后,很快就将父铭文打到了中本聪地址,相当于没有人能够再次使用,也就是通过技术手段承诺不做增发。这波操作本身就为其带来一大波好评,非常涨路人缘。


PS:什么是父铭文?因为在BTC做交互速度慢且gas高昂,所以当操作数量比较大的时候,为提高效率,一般会先设置一个父铭文,在父铭文的那一次交易里,直接批量处理多个子铭文,这样可以在交互的时候,节约区块链的存储空间和处理时间。


最后说一下Casey提到的CTV,即「Check Template Verify」。


CTV是一个比特币提议的协议升级,旨在通过允许用户在创建交易时,指定未来交易的模板,从而增强比特币网络的智能合约和锁定功能。CTV的激活将使得用户能够创建更复杂的交易类型,例如可信赖的空投和开放式蚀刻,而无需协议的显式支持。


这个CTV提案增加了比特币网络的可编程性和灵活性,在这次讨论中提到,简单来说就是可以创建一个使用UTXO的解锁条件模板,有机会给Runes创造更多玩法。举个例子,通过「Runes协议+CTV」,可以让10个用户联合使用CTV技术,共同Mint符文,然后预设未来的一些比特币支付交易的承诺之类。

继续滑动看下一个

关于Runes协议及“公开铭刻"发行机制的拓展讨论

MiX 极客 Web3
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存