详解RGB ：被忽视的BTC扩容方案

文章来源：ViaBTC Capital

原文标题：A Brief Analysis of RGB: A Scalable, Confidential Smart Contract Protocol Built on Bitcoin，作者 ViaBTC Capital

一、背景

 RGB 响应比特币可扩展性与隐私性痛点的诞生

比特币自 2009 年上线以来，其网络性能一直备受关注。但比特币每秒只能处理约 7 笔交易，无法支持智能合约的扩展。在隔离见证升级后，虽然比特币区块大小限制改为了交易数据区块上限 1M 和见证数据区块上限 3M，总大小 4M。但这一上限至今未改变，随着比特币的影响力不断增大，扩容问题凸显。扩容仍是比特币生态面临的核心问题之一，各种技术路线正在积极探索解决方案，目前比特币的主要扩容方向有：

• - 侧链技术，如 Liquid、Stacks 和 Rootstock；

• - 状态通道，如闪电网络，可以使部分高频交易转移至链下；

• - 非升级式扩容，如 RGB 和比特币脚本，不需要修改比特币代码；

• - 升级式扩容，如 Drivechain(BIP300/301）需要高比例的矿工支持，通过硬分叉比特币实现扩容。

这些技术里有一些较早的扩容方案正在重获关注，如去年末流行的 Nostr 推动了闪电网络的采用，Ordinals 也于年初迎来爆发。而 RGB 作为是一个基于比特币、闪电网络的图灵完备、可扩展和隐私性强的智能合约方案，也在今年 4 月发布了新版本 v0.10。

 RGB 历史

• 早在 2016 年，Peter Todd 还提出了这个一次性密封条（Single-use-seal）和客户端验证（Client-Side Validation）的想法。受到这些重要概念的启发，RGB 在 2018 年被提出。

• 2019 年，核心开发 Orlovsky 开始推进 RGB，并真正开发了许多最终成为 RGB 协议的部分。 在瑞士成立了 LNP BP 协会，以帮助提供与所有这些相关的标准。

• 2023 年 4 月份，在进行大量地开发之后，RGB 发布 v0.10。

 二、设计概述

RGB 如何实现可扩展性和隐私性：

 客户端验证（Client-Side Validation）

目前大部分公链使用全局共识模型（Global Consensus），所有节点验证所有交易，节点之间传输所有交易信息，全网共享统一的全局状态。

全局共识模型所带来的问题：

• - 可扩展性限制，使得验证所有合约互动变得昂贵；

• - 高成本阻止了更多用户参与运行节点，节点集中化；

• - 缺乏隐私，交易信息公开。

CSV，即 “客户端验证”，只需要让共识层保持对账本事件的加密承诺就足够了，将实际的事件信息（账本）存储在区块链之外。这种方法源自 Peter Todd 的工作，他称之为 “客户端验证”。客户端验证这种方式把交易数据转移到链下，链下存储并验证详细信息，只在链上提交最少的信息。而且交易数据在链下也仅在交易的发送者和接收者之间传输，例如在只有钱包、互动方需要知道合约数据的情况下进行验证。

CSV 的特性：

• - 详细的交易信息在链下，并且只在客户端进行验证；

• - 仅在链上存储这些交易信息的承诺；

• - 只验证用户必须知道的交易。

所以，RGB 中对于资产转入的验证方式与比特币支付中的验证有很大不同。在比特币中，节点持续下载来验证区块和内存池中的交易，以此实时掌握 UTXO 集合的最新状态。在看到新交易时，只需要验证其所有输入是否在 UTXO 集合的最新状态中就可以校验其历史的有效性。

而在 RGB 中，没有一个全局网络广播所有的交易来创建比特币 UTXO 集合的等价物。这意味着在接收到资产转入时，RGB 客户端不仅要验证最近的状态转换是否有效，还需要对所有上溯到发行合约创世状态的前序状态转换进行相同的验证。所以 RGB 需要自底向上逐步验证交易历史，以防止双花攻击。

RGB 通过仅验证相关交易来提高可扩展性，同时也可能会出现类似数据可用性的问题（可能需要通过数据共享来优化支付验证）。

基于比特币的一次性密封条（Single-use-seal）

物理的一次性密封条是带有独特编号的塑料扣，通常用于在存储和运输过程中检测篡改，确保货物箱子在运输过程中没有被打开。而数字的一次性密封条可以对消息进行密封，确保消息只能使用一次，它可以避免多次出售同一资产。

Bitcoin 采用的是 UTXO（Unspent Transaction Output）模型，即还没有被用来支付的交易输出，为了避免依赖可信实体来证明数字密封条的打开和关闭，可以使用比特币的未花费交易输出 (UTXO) 作为密封。UTXO 在创建时可以看作关闭的密封，在花费时打开。由于比特币共识规则, 一个输出只能花费一次，因此可以保证密封条只能打开一次。所以 Single-use-seal 用于将比特币 UTXO 与链下合约状态关联，最终以承诺执行下一状态转换的链下 RGB 交易方式花费（关闭）。类似于现实世界中用于保护运输容器的一次性物理封条，一次性密封条是一个独特的对象，它可以精确地封闭一条信息，防止重复消费。

我们用支票来做一个简单的类比。我们可以简单把 UTXO 看作是一连串支票的集合，每张支票上的金额不一样。当你汇款给别人时，其实就是使用了一张尚未兑现的支票，换成了新的支票给别人，如果有余额剩下也会同时生成新的支票给自己。而 Single-use-seal 则类似把一些资产流转记录印在了这张支票的附加信息位置，利用支票只能兑换一次的限制，保证了资产不能重复流转：

1. 首先，Alice 发行了某种资产（例如资产名字 USD Tether，代号 USDT，总量 1 亿枚），然后把这些信息的承诺印在了在某张有效的支票 A 附加信息位置（支票机不需要管附加信息写了什么，支票正面写个 1 元也可以，只要属于 Alice 而且还没兑现即可）。

2. 当 Alice 要转移资产给 Bob（例如给 Bob 1000 万枚，剩下 9000 万枚还属于 Alice），那 Alice 需要兑现支票 A，而且需要在支票 A 附加信息位置写上转给支票 B 的 1000 万枚（拥有者 Bob）、转给支票 C 拥有者 9000 万枚（拥有者 Alice，即剩下 9000 万枚还属于 Alice）

3. Bob 转移资产给 Dave 的时候，同样也是需要花掉支票 B，在附加信息位置注明支票 D 1000 万枚（拥有者 Dave）

4. 之后每次转移，都重复这个过程，原持有人将部分金额背书给新的接收者，接受者需要对照整个资产流转的历史进行验证。所以整个资产转移就像流通中的支票一样，每次转手都会开新支票，每张支票只能兑现一次，旧的支票 (UTXO) 则作废，这确保了状态只能向前转换，不会回退，而且也不能兑现两次。这样通过链上的记录，就可以可靠地反映数字资产的状态变化。

RGB 使用了上述基于比特币的一次性密封条模型，这意味着当 RGB 交易发生时，发送方实际创建的是定义权利转移的合约的状态转换（State transitions）。以 Token 为例，首先，合约的发行方设置了创世状态，定义合约细节如资产名称、总发行量和拥有发行权的 UTXO。然后，随着资产首次转移，第一个 UTXO 的所有者可以创建状态转换，定义哪个新的 UTXO 将拥有该资产。这样，RGB 通过比特币 UTXO 只能花费一次的属性来实现状态转换，从而可靠地定义和跟踪数字资产及相关权利的转移和变更。

它将所有交易内容保留在比特币之外，仅在交易的发送者和接收者之间传输，同时将这些数据的承诺锚定到比特币的 UTXO。当 UTXO 被消费后，它就无法再以同样的方式再次被消费，这表明合约已经发生了改变。

RGB 利用比特币区块链来防止双花，具体做法是在花费拥有被转移权利的 UTXO 的比特币交易中提交每个 RGB 状态转换。一个比特币交易中可以提交多个状态转换，同时每个状态转换只能在比特币交易中提交一次 (否则会造成双花)。

为实现在一个提交中有多个状态转换，进行了多级聚合，再通过 Taproot 或 OP_RETURN 将其提交到比特币交易。如果比特币交易中有多个提交，只有第一个相关联的 RGB 验证规则，其他会被忽略，防止双花。

 RGB 的特点

可拓展性

• - 相比于其它将所有的逻辑都放在链上的竞争对手协议，CSV 把数据放在链下，降低成本和计算压力；

• - 直接在比特币上可用，无需改动比特币，无需复杂的链上交易；

• - 支持闪电网络。

隐私性

• - 第三方无法看到 RGB 交易及其关联的一次性密封条；

• - blinded UTXOs，UTXO 拼接一个随机盲化秘密值之后的哈希值组成，支付方不知道资产发到哪里。只有当接受方在花费这资产的时候，新的接受方才可以验证到；

• - 同时，还用了一种零知识证明机制 Bulletproof，所有权人可以看到从创始状态到自己的状态这一路上用到的所有 UTXO，但他们看不到每一次状态转换中被转移的资产数量。

 三、RGB 的功能与丰富应用场景

 支持合约（Schemas）

开发者可以使用 RGB 的 Schemas，它们是可作为特定用例模板的合约。

一些 RGB Schemas 的例子:

• - RGB20 发行可互换资产

• - RGB21 发行不可互换资产

• - RGB22 去中心化数字身份

• - RGB23 可审计数据的可验证唯一历史日志

• - RGB24 去中心化全球域名系统

• - RGB25 发行收藏品资产

任何人都可以自由开发不同的应用模式，而无需征求 RGB 开发者的许可。但是，预计大多数用例都可以通过几个主要模式覆盖

 AluVM

RGB 使用了特殊设计的基于 register 的 RISC 虚拟机，它是图灵完备的，能够以与现有基于区块链的系统相同的可用性保证来操作全局状态。类似以太坊的 EVM，架构是在闪电网络上面嵌套一个 RGB 节点，然后 RGB 节点上嵌套一个 RGB 客户端。

 RGB 如何与比特币闪电网络深度融合

RGB 可以通过 Bifrost 扩展与闪电网络接口，实现近乎即时结算，无需等待新的比特币区块被挖掘。

将特定代币的支付通道连接到闪电网络，RGB 资产可以实现与常规闪电网络付款一样的用户体验和安全假设，确保低价、快速和稳定的支付，这将可能会给整个用户、开发者和闪电节点运营商生态系统带来好处。

 四、和其他方案对比

 RGB和 TARO 对比

TARO（现在改名为 Taproot Assets），2022 年 4 月，闪电网络开发商 Lightning Labs 完成 7000 万美元 B 轮融资，推出由 Taproot 支持的 Taro 协议。

RGB 和 TAR 两者都是基于 CSV，设计思路类似，甚至有争议称 Taro 参考了 RGB 设计。不过目前看，Taro 专注在代币层面，而 RGB 则要实现智能合约功能。

 RGB和其他比特币方案对比

不同于基于 BIP300、BIP301 的 Drivechain 需要进行硬分叉，RGB 兼容所有现有的比特币技术以及未来可能出现的比特币软分叉，并且不需要对基础比特币层进行任何更改。

不同于 Ordinals 把所有数据都放到链上，RGB 只需要把数据承诺放到链上，通过 UTXO 保障资金安全的情况，消耗的链上空间并不多，同时也可以直接接入闪电网络。

 RGB和 Rollup 对比

Rollup 是以太坊的扩展解决方案，用户在以太坊的智能合约中存款并转入二层之后，之后这些资产可以在同一 Rollup 的用户之间进行转账，这些交易会定期聚合并提交到链上。

此外，RGB 也不是一条区块链。

 挑战

- 生态系统仍处于初期阶段，虽然底层已经搭建好，但上面的基础应用还不多，开发者工具和用户发展可能需要一些时间；

- 客户端需要存储更多数据，如果丢失用于验证交易的链下数据，用户也就无法再去花费，需要保存不仅仅是密钥。与此同时，与比特币和其他全局共识系统不同，RGB 客户端不需要看到和验证全局发生的所有交易，只需关注与其钱包相关的交易。因此，每个客户端需要验证的数据量大大减少，从而提高了整体系统的可扩展性。在收到支付时需要验证大量数据可能看起来是一个问题，因为验证时间会拖慢支付体验。但是只有当资产交易历史很长时才会成为问题，到时需要构建新的数据可用层，并允许客户端自发地分享特定合约的状态转换数据，这样未来的接收方可以提前开始验证部分交易历史；

• - 对于流行 CSV 代币，大量使用最终会增加其所需要的验证成本；

• - 社区驱动，依赖于团队默默钻研技术，进度比较慢，而且运营推广也比较少；

• - 开发者学习曲线，除了需要了解比特币知识，也需要学习 RGB 的状态变更和合约。

 生态项目

• DIBA

• 网站：https://diba.io/

• DIBA 是利用 RGB 智能合约的比特币 NFT 市场。

• Cosminmart

• 网站：https://www.cosminmart.com/

• Cosminmart 是一个基于 RGB 协议的生态系统，提供钱包、市场、Launchpad 和浏览器等功能。

• Mycitadel

• 网站：https://mycitadel.io/

• Mycitadel 钱包支持多签、时间锁、Taproot 等功能。

• Bitmask

• 网站：https://bitmask.app/

• Bitmask 是一款插件钱包。

参考资料

https://hackernoon.com/top-4-directions-of-bitcoin-ecosystem-scalability

https://docs.rgb.info/

https://github.com/RGB-WG/blackpaper/blob/master/README.md

https://docs.lightning.engineering/the-lightning-network/taproot-assets

https://docsend.com/view/he8x9erkjmphphvn