读懂比特币资产发行协议：RGB 与 RGB++ 的设计原理

作者：極客Web3来源：加密信息网讯2024-04-09

本文将用简短的白话解读比特币资产发行协议 RGB 与 RGB++ 的设计原理，希望帮助更多社群爱好者更好、更直观的理解 RGB 与 RGB++。

随著 RGB++ 及相关资产发行的火热，关于 RGB 与 RGB++ 协议原理的讨论逐渐成为更多人关注的话题。但大家意识到，要理解 RGB++，必须先理解 RGB 协议。

原始的 RGB 协议在技术构造上略为晦涩，参考资料较为零散，至今没有多少系统性且较通俗易懂的参考资料，极客 web3 此前虽曾发表过两篇关于 RGB 与 RGB++ 的系统性解读文章，但据社群成员回馈，前述文章篇幅较亢长且太烧脑。

为了让更多人能更快理解 RGB 与 RGB++ 协议，本文作者在香港活动期间，临时赶工完成了一篇关于 RGB 与 RGB++ 的简短白话解读，可以在几分钟内读完，希望帮助更多社群爱好者更好、更直观的理解 RGB 与 RGB++。

RGB 协议：使用者要亲自做资料验证

RGB 协议是一种特殊的 P2P 资产协议，是比特币链下的计算系统，它在某些方面与支付通道类似：使用者要亲自执行客户端，自行验证与自己有关的转帐行为（Verify by yourself）。即便你只是一个资产接收者，也要先确定资产传送者的转帐宣告没有错误，然后这笔转帐宣告才能生效。显然这与传统的资产传送与接收形式截然不同，我们将其称之为「互动式转帐」。

为什么要这样？原因在于，RGB 协议为了保障隐私，没有采用比特币和以太坊等传统区块链中的「共识协议」（资料一旦走共识协议，就会被网路内几乎所有节点都观测到，隐私不好保障）。如果没有大量节点都参与的共识流程，该如何保证资产变更是安全的？这里用到名为「客户端验证」的思想（Verify by yourself），你要自己执行客户端，亲自验证和你相关的资产变动。

假设有个 RGB 使用者叫 Bob，他认识 Alice，Alice 要给 Bob 转来 100 枚 TEST 代币。Alice 生成了「Alice to Bob」的转帐资讯后，要先把转帐资讯和涉及的资产资料传送给 Bob，让他亲自检查一遍，确定无误才会进入后续流程，最终成为一笔有效的 RGB 转帐。所以说，RGB 协议是让使用者亲自验证资料有效性，取代传统的共识演算法。

但没有了共识，不同 RGB 客户端接收和储存的资料都不一致，大家只在本地储存与自己有关的资产资料，不知道别人的资产状况，这在保护隐私的同时，也构成了「资料孤岛」。如果有人声称有 100 万枚 TEST 代币，要转给你 10 万枚，你如何相信他？

在 RGB 网路中，如果有人要给你转帐，必须让他先出示资产证明，回溯资产从初始发行到多次转手的历史来源，确定要转给你的 Token 没问题，这就好比，当你收到来路不明的纸币后，你要求对方说明这些纸币的历史来源，是否是指定的发行方制造的，以此来规避假币。

上述流程是发生在比特币链下的，仅凭这些过程还无法让 RGB 与比特币网路产生直接关联。对此，RGB 协议采用了名为「single use seal」的思想，把 RGB 资产与比特币链上的 UTXO 系结起来，只要比特币 UTXO 没有被双重消费，系结的 RGB 资产就不会发生双重支付，这样就可以借助比特币网路来防止 RGB 资产发生「Re-organization」。当然，这需要在比特币链上释出 Commitment，并用到 OP_Return 操作码。

在此梳理一下 RGB 协议的 workflow：

1. RGB 资产与比特币 UTXO 有著系结关系，而 Bob 拥有某些个比特币 UTXO。Alice 要给 Bob 转帐 100 枚代币，在接收资产前，Bob 事先告诉 Alice，应该用 Bob 的哪个比特币 UTXO 系结这些 RGB 资产。

Alice 构造一笔「Alice to Bob」的 RGB 资产转帐资料，附带这些资产的历史来源交给 Bob 去验证。

Bob 在本地确认这些资料没问题后，给 Alice 传送一个回执，告诉她：这笔交易可以通过了。

Alice 把这笔「Alice to Bob」的 RGB 转帐资料构建成一棵 Merkle Tree，把 Merkle Root 释出到比特币链上作为 Commitment，我们可以把 Commitment 简单理解为转帐资料的 hash。

如果未来有人想确定，上述「Alice to Bob」的转帐真实发生过，他需要做两件事：在比特币链下获取「Alice to Bob」的完整转帐资讯，然后查验比特币链上是否存在对应的 Commitment（转帐资料的 hash），就可以了。

比特币在此充当了 RGB 网路的历史日志，但日志上只记录交易资料的 hash/Merkle root，而非交易资料本身。由于采用了客户端验证和一次性密封，RGB 协议具有极高的安全性；由于 RGB 网路是由动态的使用者客户端以 P2P、无共识的形态组成的，你可以随时更换交易对手方，不需要把交易请求传送给某些个数量有限的节点，所以 RGB 网路具有极强的抗审查性，这种组织形式要比以太坊等大型公链更抗审查。

当然，极高的安全性与抗审查性、隐私保护，带来的代价也是明显的：使用者要自己执行客户端验证资料，如果对面发过来一些转手几万次、历史记录很长的资产，你也要顶著压力全部验证完。

此外，每笔交易都要求双方进行多次通讯，接收方要先验证传送方的资产来源，然后传送回执，批准传送方的转帐请求。这个过程中，双方之间至少要产生三次讯息传递。这种「互动式转帐」和大多数人所习惯的「非互动式转帐」严重不符合，你能想像，别人要给你转钱，还要把交易资料发给你来检查，得到你的回执讯息后，才能完成转帐流程吗？

此外，我们曾提到，RGB 网路没有共识，每个客户端都是孤岛，不利于把传统公链上的复杂智慧合约场景迁移到 RGB 网路中，因为以太坊或 Solana 上的 Defi 协议都依赖于全域性可见、资料透明的帐本。如何优化 RGB 协议，提高使用者体验并解决上述问题？这成为了 RGB 协议绕不开的一个问题。

延伸阅读：一文读懂比特币资产发行协议「RGB」的设计与特点、安全挑战

RGB++：客户端验证变为乐观的托管

名为 RGB++ 的协议提出了新思路，它把 RGB 协议与 CKB、Cardano、Fuel 等支援 UTXO 的公链结合起来，由后者作为 RGB 资产的验证层与资料储存层，把原本由使用者进行的资料验证工作，移交给 CKB 等第三方平台 / 公链，这相当于把客户端验证替换为「第三方去中心化平台做验证」，只要你信任 CKB、Cardano、Fuel 等公链即可，如果你不信任他们，也可以切换回传统的 RGB 模式。

RGB++ 和原始的 RGB 协议，理论上是可以彼此相容的，并不是有他无我。

要实现上面提到的效果，需要借助一种名为「同构系结」的思想。CKB 和 Cardano 等公链有自己的拓展型 UTXO，它比 BTC 链上的 UTXO 多出了可程式设计性。而「同构系结」，就是将 CKB、Cardano、Fuel 链上的拓展型 UTXO 作为 RGB 资产资料的「容器」，把 RGB 资产的引数写入到这些容器中，在区块链上直接展示出来。每当 RGB 资产交易发生时，对应的资产容器也可以呈现出相似特征，就像是实体和影子的关系一样，这便是「同构系结」的精髓。

For example，假如 Alice 拥有 100 枚 RGB 代币，以及比特币链上的 UTXO A，同时在 CKB 链上有一个 UTXO，这个 UTXO 上标记著「RGB Token Balance：100」，解锁条件与 UTXO A 有关联。

如果 Alice 想把 30 枚代币送给 Bob，可以先生成一个 Commitment，对应的宣告是：把 UTXO A 关联的 RGB 代币，转移 30 枚给 Bob，70 枚转给自己控制的其他 UTXO。

之后，Alice 在比特币链上花费 UTXO A，释出上述宣告，然后在 CKB 链上发起交易，把承载 100 枚 RGB 代币的 UTXO 容器消费掉，生成两个新容器，一个容纳 30 枚代币（给 Bob），一个容纳 70 枚代币（Alice 控制）。在此过程中，验证 Alice 的资产有效性与交易宣告有效性的任务，是由 CKB 或 Cardano 等网路节点走共识来完成的，不需要 Bob 介入。此时，CKB 和 Cardano 等充当了比特币链下的验证层与 DA 层。

所有人的 RGB 资产资料都存放在 CKB 或 Cardano 链上，具有全域性可验证的特性，利于 Defi 场景的实现，比如流动性池和资产质押协议等。当然上述做法也牺牲了隐私性，本质是在隐私和产品易用性之间做取舍，如果你追求极致的安全与隐私，可以切换回传统 RGB 模式；如果你不在意这些，就可以放心采用 RGB++ 的模式，完全看你个人的需求。（其实借助 CKB 和 Cardano 等公链强大的功能完备性，可以借助 ZK 来实现隐私交易）

这里要强调，RGB++ 引入了一个重要的信任假设：使用者要乐观的认为，CKB/Cardano 这条链，或者说由大量节点靠共识协议组成的网路平台，是可靠无误的。如果你不信任 CKB，也可以遵循原始 RGB 协议中的互动式通讯与验证流程，自己执行客户端。

在 RGB++ 协议下，使用者无需跨链即可直接用比特币帐户，操作自己在 CKB/Cardano 等 UTXO 链上的 RGB 资产容器，只需要借助上述公链中 UTXO 的特性，把 Cell 容器的解锁条件设定为与某个比特币地址 / 比特币 UTXO 相关联即可。如果 RGB 资产交易双方信得过 CKB 的安全性，甚至不必频繁的在比特币链上释出 Commitment，可以在许多笔 RGB 转帐进行后，再汇总传送一个 Commitment 到比特币链上，这被称为「交易折叠」功能，可以降低使用成本。

但要注意，同构系结采用的「容器」，需要支援 UTXO 模型的公链，或是在状态储存上有类似特征的基础设施，EVM 链不太适合，会遇到很多坑。

综合来看，适合实现同构系结的公链 / 功能拓展层，应该具有以下特性: