一文读懂 Runes 与 BRC20 等同质化代币协议的对比lg...

作者：Jasmine

X/推：@Jasmine9m88

众所周知，Casey 推出 Runes 的原因是他认为 BRC20 在技术上存在不足，希望通过新的FT协议来减轻对比特币网络的压力。Runes 协议基于 UTXO，不仅可以有效减少垃圾UTXO的膨胀，而且具有良好的兼容性和可扩展性。它的核心协议简化到仅 500 行代码，目的是为开发者和用户提供一个简单易用的同质化代币协议。

Casey：“我不确定为比特币创建一个新的可替代代币协议是否是个好主意。可替代的代币有 99.9% 都是骗局和 meme 。然而，它们似乎不会在短时间内消失，就像赌场似乎不会在短时间内消失一样。为比特币创建一个好的可替代代币协议可能会为比特币网络带来可观的交易费收入，吸引开发者的关注，带来更多用户。此外，如果这个协议的链上足迹较小，同时促进负责任的 UTXO 管理，那么它可能相比现有协议更能减轻损害。”

自从去年9月宣布开发 Runes 协议以来，经过几个月的精心打磨，相比 BRC20 等 FT 协议，Runes 具有哪些特色和优势呢？

本文基于 Casey 近期的演讲、访谈、博客以及 GitHub 上的内容，对上述问题进行了梳理，以供大家参考，不代表本人观点。由于本人非技术背景，如有错误，欢迎指出。

Runes VS BRC20

1、操作更简洁、更高效

交易次数减少：BRC20 代币的部署和铸造分别需要两次交易完成，代币认领则需要三次。而 Runes 仅需一次交易即可完成所有操作，且不会生成多余的无用 UTXO 。

转账效率提升：BRC20 的一笔转账交易仅支持一个接收者和一种代币。而 Runes 支持同时向多个接收者转账，且可转账多种 Runes 代币。

2、对开发者更友好

数据存储与索引：BRC20 的数据以 JSON 格式存储在隔离见证中，基于账户模型，余额与地址绑定。而 Runes 的数据存储在交易的 OP_RETURN 字段中，采用 UTXO 模型，代币余额直接与 UTXO 绑定。因此，确认 Runes 余额时，只需验证所拥有的 UTXO ，无需像 BRC20 那样扫描整个网络状态，对索引更加友好。

提供参考实现 (reference implementation)：BRC20推出时仅有规范而无索引、浏览器、钱包等配套设施。而Runes在推出时便自带参考实现（即ord），包括索引、浏览器和钱包等功能。BRC20依赖序数理论进行代币转移，实现复杂。而Runes独立且不依赖于序数或铭文，编写替代实现应更为容易。

3、兼容性和扩展性更强

与UTXO二层协议兼容：Runes基于UTXO的设计使其能够与闪电网络、CKB 等基于 UTXO 的比特币二层协议更好地兼容。通过“ UTXO 同构绑定”， CKB 甚至可以直接为 Runes 提供智能合约功能。

支持 SPV（简单支付验证）：SPV 钱包是一种轻量级的比特币钱包，仅下载和验证与用户交易相关的区块头数据。用户可以使用 SPV 钱包来管理和使用 Runes 代币，享受轻便、简洁且快速的交易体验。这是 BRC20 所无法实现的。

支持软分叉升级：与 BRC-20 协议相比，Runes具有更强的可扩展性，可以通过软分叉进行升级。

4、代币发行（etch）方式更灵活

名称长度支持 1-28 个字符：BRC20 的代币名称限于四个字符以内，而 Runes 代币名称长度可在 1 至 28 个字符之间调整。为了平衡 Runes 的发行节奏并防止热门短名称被迅速占用，Runes 协议在上线初期的四个月内要求名称长度至少为 13 个字母。此后每隔约四个月，名称的最小长度将减少一个字母，直至下一次减半事件发生时，可创建仅含单一字符的 Runes（总计 26 个）。

名称更加明确：与 BRC20 代币名称可能包含任意 Unicode 字符不同，Runes 名称仅支持 A 到 Z 的字母和 • 字符，因此名称更加明确且难以伪造。

解决名称抢跑问题：采用 Commit-Reveal 机制来防止矿工提前得知 Runes ++

名称并进行抢跑。

引入多样化代币发行方式：除了 open etch（项目方无法预分配代币）和固定总量发行（项目方可以预分配代币）两种发行方式外，还在考虑添加更多玩法以放宽 open etch 的不可预留的要求。此外，Runes 还可以是 “ expressive ” 的——也许可以通过创建父子铭文的方式，把 Runes 放到子铭文下面。

5、安全性更高

抵御投毒交易攻击：BRC20 可能会遭受到投毒交易（攻击者通过向受害者地址发送大量小额 BRC20 转账铭文，可能导致接收者的余额被“锁定”）攻击，  Runes 则不会存在这个风险。

此外，Casey 还对其他几个较古老的 FT 协议与 Runes 进行了粗略的对比，Runes 的优势除了其更简单之外，还体现在以下几个方面：

Runes VS RGB

用户体验更优：接收 RGB 代币的前提是地址上必须已存在 UTXO，而 Runes 则不需要。

安全性更强：Runes 采用比特币的 UTXO 模型，因此不受竞态条件 (race condition) 的影响。

在链上的：在进行 RGB 交易时，不仅需要从比特币区块链下载数据，同时也需要向服务器下载和上传数据。Runes是在链上的，因此交易可以在不需要上传或下载服务器数据的情况下进行，甚至可以在不与接收者通信的情况下进行交易。

名称唯一：Runes代币的名称具有唯一性，而RGB代币名称可以重复。

Runes VS Taproot Assets

在链上的：与RGB相似，#Taproot Assets 的交易不仅需要从比特币区块链下载数据，还需要向服务器下载和上传数据。Runes的交易在链上完成，无需依赖额外的服务器数据交互。

Runes VS Counterparty

无需原生代币：Counterparty 需要利用原生资产来创建代币，而 Runes 则不需要。

基于 UTXO 的模型：与 Counterparty 的基于账户模型不同，Runes 采用基于 UTXO 的模型。这有助于避免地址重用问题、提升脚本功能，并更自然地与比特币生态系统相融合。

脚本兼容性：Runes 自动兼容所有当前和未来的脚本操作码及地址类型，而Counterparty则需要额外开发这些功能，这增加了 Runes 的灵活性和可扩展性。

Runes VS ERC20

一致性：所有Runes代币的行为都是统一的，而ERC20代币的发行则依赖于各自的智能合约，这可能导致复杂性和需要额外的审计。

名称唯一：Runes代币的名称具有唯一性，而ERC20代币名称可以重复。

“总有一天我们都会逝去，也许重要的是我们留下了什么。你是想在比特币这条坚固的链上留下永恒的印记，还是在其他可能消逝的链上建设呢？” 

—Casey

免责声明：本文仅供参考，不得被用作法律、税务、投资、理财或任何其他建议，不代表 RunesCC 立场。

来源：金色财经