超越BRC20？一文读懂比特币符文协议Runes的前世今生
Runes 的设计专注于易用性，有望在比特币代币生态系统中引入重要变革。
原文：https://www.panewslab.com/zh/articledetails/l8750iy9.html
作者：Rock
RUNE协议背景
用一句话对「符文」协议最大的特点进行概括：一个简单的、基于 UTXO 的、能使比特币用户具有使用良好体验的 同质化代币 协议。
Runes 的设计专注于易用性，有望在比特币代币生态系统中引入重要变革。采用比特币的 UTXO 模型，Runes 通过减少UTXO集的不必要膨胀，提供了一种“减少危害”的解决方案，这是现有协议如BRC-20和Stamps等面临的重要问题。其简化的设计有望吸引更多开发者的兴趣和参与，从而可能推动比特币开发社区的创新。用户体验的无缝性也有望吸引更多主流用户采用，因为他们无需处理原生代币或处理链下的复杂性,总体而言，符文提供了一种更加简单、直观的方式来处理比特币区块链上的可替代代币。
关键事件时间线梳理
2022 年 12月14日 Casey 发布铭文Ordinals协议，允许在比特币的最小单位（聪）上刻入数据，用户可以在聪上写入文本、图片、音频、视频等数据。
2023 年 3 月 8 日 Domo匿名开发者基于Ordinals协议，发布BRC20协议，并mint 首个代币资产 ORDI，当前ORDI市值14亿美金
2023年-05月-08日 BTC核心开发者发文，声称“BRC20协议 垃圾邮件过多、交易频繁，引起BTC网络阻塞，BTC社区应该采取行动阻止”
2023年-09月-01日 Casey 公开反对BRC20协议，并希望可以停止铸造 BRC-20
2023年-09月-28日 Casey 撰写博客，提出基于UTXO模型的 符文协议，并声称“这可能是一个糟糕的想法”
2023年-09月-28日 ordi社区 开始开发RUNE协议，并公布将在下一次比特币减半时间，预计4月份上线主网
2023年-11月-14日 RuneAlpha 成立，并且提前一步实践发布RUNE协议，同期开发出fair mint RUNE协议代币工具，并公开mint $COOK, 截止本文发布前$COOK市值2700万美金
2024年-01月-15 RuneAlpha 宣布致力于构建Rune协议 基础设施，并公布具体实施路线
2024年-01月-29日OKX公开在推特2月底会支持RuneAlpha 上线OKX钱包，并且与 RuneAlpha 创始人 @sondotpin 召开AMA会议
2024年-01月-20日 RUNECOIN 项目成立， 并且宣布空投RSIC 铭文的方式分发， 同时等主网上线后，按照对应比例兑换到RUNE 协议主网
2024年-02月-12 Casey 公开声称，将在主网上线时，通过硬编码形式发布 10个首发符文
2024年-02月-17 中文社区正式成立，并吸引一众推特大V参与讨论建设。
重要事件详解
一、什么是铭文（inscriptions)
比特币铭文（Bitcoin Inscription）是一段通过采用Ordinals（序数）铭刻（inscribe）在聪（Satoshis）上的元数据，也可称“比特币NFT”。
如果将比特币比作数字黄金，那么铭文便是黄金打造的饰品，他们共享相同的本质，铭文是指通过交易见证数据部分将任意数据嵌入比特币区块链的过程，
二、什么是BRC20
BRC-20是基于Ordinals协议的一组铭文。它以一定的数据规范格式，规定了代币名称、代币总量、每张铭文铸造的代币数量。下图示例中，Panda就是代币名字，最大代币数量为1亿，每个铭文mint的最大代币数量为1万。这个BRC-20就相当于支票一样，你可以在限额内填任何金额。BRC-20现在介于代币和NFT的之间的一种形态，或者说兼具两者的特征，非常有意思。
BRC-20 实际是比特币上的一个Token发布标准，它规定了比特币上发行Token的名称、发行量、转账等功能，由社区爱好者@domodata于2023年3月8日创建，BRC-20创始第二天也就是3 月9 日有超过30,000 个「铭文」被铸造，其中文本类型「铭文」数量接近27,000 个。BRC-20 创建者强调这只是一个实验，该实验旨在测试能否通过比特币NFT Ordinals 协议进行铸造和转移Token，是否能够促进比特币的「可替代性」。ordi 是第一个被部署的BRC-20 Token，每次铸造限制为1000个，总量为2100万个，ordi从发行到现在已经涨了超过100倍。
三、BRC20 引起的问题
2023年-05月-08日 BTC核心开发者 Luke Dashjr 在BTC社区中发文讨论，声称“BRC20协议 垃圾邮件过多、交易频繁，引起BTC网络阻塞，BTC社区应该采取行动阻止”
BRC-20允许通过比特币上的Ordinals协议铸造和转移可替代代币，Ordinals协议创始人 Casey Rodarmor认为，BRC-20代币的问题在于，它们用“垃圾”未使用的交易输出（UTXO）向比特币发送垃圾邮件。同时由于BRC-20 协议是基于Ordinals协议，相当于多套了一层多余的协议
Casey Rodarmor在9月26日的文章中解释说，BRC-20代币具有“UTXO扩散的不良后果”，并建议将 Runes 作为基于UTXO的替代方案。
四、RUNES 协议的出世背景
在 Ordinals 协议的官方手册里，我们可以看出 Casey 对 Ordinals 协议的设想就是一个通过比特币创造「数字文物」，或者说「 NFT 」的协议。但随着 Ordinals 协议的发展， BRC -20 相关的铭文数量已经占到了铭文总数的 85% 以上。
Casey 对 BRC -20 的不满已经很久了，尤其是他最近引起轩然大波的两条推文，更能感受到他对于 BRC -20 的消极态度：
五、RUNE协议的正式出世
2023年-09月-28日 Casey 撰写博客，提出基于UTXO模型的 RUNE符文协议
Casey Rodarmor 用一句话对「符文」协议最大的特点进行了概括——一个简单的、基于 UTXO 的、能使比特币用户具有使用良好体验的 FT 协议。
Casey 认为，如果该协议的链上「足迹」较小，并促进可信任的 UTXO 管理，那么与现有的比特币 FT 协议相比，它可能会减少「危害」。至少，目前 BRC -20 的流行已经创造了大量的「垃圾」 UTXO 。
Casey 在以下 4 方面将「符文」协议与其它现有的比特币 FT 协议进行了比较：
复杂性：协议有多复杂？实施起来容易吗？容易被大范围采用吗？
用户体验：是否有任何实施细节会对用户体验产生负面影响？特别是，依赖链下数据的协议具有较轻的链上「足迹」，但引入了很大的复杂性。并且，用户要么运行自己的服务器，要么发现现有服务器并与其交互。
状态模型：基于 UTXO 的协议更自然地适合比特币，并通过避免创建「垃圾」 UTXO 来促进 UTXO 集最小化。
原生 Token ：具有协议操作所需的原生 Token 的是繁琐的、抽取性的，自然不太会受到广泛采用。
##比较的结果是：
BRC -20：不是基于 UTXO 并且相当复杂，因为它需要使用 Ordinals 协议来进行某些操作。
RGB ：非常复杂，依赖链下数据，已经开发了很长时间而没有被广泛采用。
Counterparty ：某些操作需要使用原生 Token ，而不是基于 UTXO 。
Omni Layer ：某些操作需要使用原生 Token ，而不是基于 UTXO 。
Taproot Assets ( Taro )：有点复杂，依赖链下数据。
概述
「符文」 Token 的余额直接包含在 UTXO 内， UTXO 可以包含任意数量的「符文」 Token 。
如果一笔交易包含一个输出，而该输出的脚本 pubkey 包含一个 OP _ R ETU R N ，后跟一个表示 ASCII 大写字母「 R 」的数据输出，则该交易包含一个协议消息。协议消息是第一个数据输出之后的所有。
如果将无效的协议消息和「符文」 Token 插入到一笔交易中，「符文」 Token 将被烧毁。这将使「符文」协议能够在未来进行升级，避免已经被创建/分配的「符文」 Token 无法纠正在旧版本协议中的分配错误。
将整数编码为前缀变量，该变量开始的部分决定了「符文」 Token 的字节长度。
「符文」 Token 的转账
协议消息中的第一个数据输出被解码为一个整数序列，这个整数序列将包含「 ID 」、「 OUTPUT 」和「 AMOUNT 」3 种信息。如果解码后的整数数量不是 3 的倍数，协议消息将被视为无效。
ID ：指定了进行转账的是哪个「符文」Token。每个「符文」Token 在被创建时都会被分配一个 ID，ID 是从 1 开始的，越早创建的「符文」Token ID 值越小。
OUTPUT ：决定分配给第几个输出。
AMOUNT ：转账的「符文」Token 数量。如果 AMOUNT 数量为 0，则代表账户剩余的全部「符文」Token 数量。
处理完整数序列所包含的所有操作后，如果还有不需要操作的「符文」 Token ，都分配到第一个非 OP _ RETURN 输出。此外，如果把「符文」 Token 分配到包含协议消息的 OP _ RETURN 输出中，「符文」 Token 可能被烧毁。
「符文」 Token 的创建
如果协议消息后还有第二个数据输出，该交易则为一笔「符文」 Token 创建交易。这部分的数据输出将被解码为「 SYMBOL 」和「 DECIMALS 」两个整数，如果还有更多其它整数则无效。
SYMBOL ：相当于 BRC-20 的 Ticker（即 Token 名称），最多支持 26 位，可用字符只有 A-Z。
DECIMALS ：精度，决定「符文」Token 能支持小数点后多少位。
如果「 SYMBOL 」还未被使用，该「符文」 Token 将被分配一个 ID 值，第一个被创建的「符文」 Token ID 值为 1， BITCOIN 、 BTC 和 XBT 这 3 个名称被禁用。如果「 SYMBOL 」已被使用，那么创建将无效。也就是说，在「符文」协议依然不支持创建同名 Token 。
比特币余额在 UTXO 中的显示
在一个 UTXO 中，比特币的余额将显示为 BITCOIN 、 BTC 或 XBT ，又或是以 ID 值为 0 的方式显示。
六、Runes VS BRC-20
BRC-20 代币将比特币与不需要的 UTXO 混在一起，造成了效率问题，而Runes协议基于 UTXO解决了其引起的 UTXO 扩散问题。相对于BRC-20，Runes减少了一层服务器共识，变得更加简单，同时不依赖链下数据，没有原生代币，非常适合比特币的原生 UTXO 模型。
Runes 背后的核心思想是最大限度地减少其链上足迹，同时鼓励用户和开发人员采用优化 UTXO 使用的实践，旨在与比特币本身的基本架构更加无缝地结合。Runes的主要优势是它有潜力促进负责任的 UTXO 管理，遏制目前堵塞比特币网络的不良UTXO 的产生。通过这种方式，Runes 为比特币区块链的整体健康和效率做出了贡献。
这里重点强调Runes协议的一个明显优势：与闪电网络兼容，这是相对于 BRC-20 的明显优势。简而言之，用户可以将Runes添加到各种多重签名钱包中，并将其余额结算给不同的提供商。同时向闪电网络引入新的用例、开发人员和用户。
七、RuneAlpha 对RUNE协议的首次实践
RuneAlpha 是一个基于RUNE协议的早期实践性项目，提前发布了RUNE协议的实验网站(runealpha.xyz)，提供fari mint 公平铸造 和fixed cap 两种铸币方式，并且首次推出基于PSBTS技术的符文交易市场，为符文协议的落地做出了不可磨灭的贡献。
RuneAlpha 由Ordinals Chef 团队创始人 @sondotpin创办，作为最早期的RUNE协议实践项目之一，落地时引起了市场的广泛关注，其发布代币$COOK当前市值高达2700万美金，并且在市场多个币圈OG 的推广下，$COOK被誉为是下一个$ORDI
1$COOK =1 $ORDI
2024年01月29日 OKX发布推文，公开支持RuneAlpha，并且会集成RuneAlpha $COOK 等代币 到 OKX钱包，允许转账交易等操作。
同时RuneAlpha 宣布最新的空投计划，持有$COOK 的人 可以获取空投 NFT，并公布了24年的路线图，将研发符文钱包、符文去中心化交易所、符文RWA、符文NFT等一系列符文相关基础设施及生态设施。
七、RUNECOIN 空投RISC 铭文，并通过RISC 对符文挖矿的方式成功引起市场对符文的广泛关注
2024年-01月-20 日 RUNECOIN 项目成立， 并且宣布空投RSIC 铭文， 同时等主网上线后，按照对应比例兑换到RUNE 协议主网。
RUNECOIN 空投的RSIC 铭文 ，主要空投给了一些铭文长期持有者，吸引了一众币圈的推特大V，如巫师 @0xcryptowizard等人转推，成功的实现了一次大范围的符文营销，并且通过挖矿的形式锁定代币，为后续的符文营销打开了思路。
八、RUNE协议中文社区的正式成立
Runes 中文社区 推特@RunesCC成立于2024年1月4日，由 Mix 发起， 早期只是推特的两位作者@MixRestaking 及 @Rock_Lee_520 个人编写一些短文， 后续有了更多推广Runes的核心骨干和大咖的加入，如 ：
比特里里 @lilyanna_btc
艺术家 @yzr668
宝儿 @Alina19990420
RuneAlpha 创始人 @sondotpin
推特大佬的加入，使得“Runes 中文核心力量群”成为了当前 RUNES 协议的最强共识微信群，群成立当日， $COOK 价格上涨超过45%，此后中文社区将继续扩张社区，并从现有社区挑选骨干作为群管理员。
$COOK 涨幅数据来源：https://runealpha.xyz/market
本文内容参考网络上优秀文章整编汇总而成。感谢各位作者对符文协议的贡献：
https://www.chaincatcher.com/article/2102482
https://www.528btc.com/news/129132928.html
https://new.qq.com/rain/a/20231207A03JA700
https://rodarmor.com/blog/runes/
最后更新于
