3000字大白话讲清RGB与RGB++协议设计

文章转载来源： 极客 Web3

作者：Faust，极客 web3 & BTCEden.org 联创

随着 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 资产。

1. Alice 构造一笔 「Alice to Bob」 的 RGB 资产转账数据，附带这些资产的历史来源交给 Bob 去验证。
2. Bob 在本地确认这些数据没问题后，给 Alice 发送一个回执，告诉她：这笔交易可以通过了。
3. Alice 把这笔「Alice to Bob」的 RGB 转账数据构建成一棵 Merkle Tree，把 Merkle Root 发布到比特币链上作为 Commitment，我们可以把 Commitment 简单理解为转账数据的 hash。
4. 如果未来有人想确定，上述「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 协议与 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 链不太适合，会遇到很多坑。（此话题可以单独成文，涉及的内容较多，有兴趣的读者可以参考极客 web3 此前文章 《RGB++ 与同构绑定：CKB、Cardano 与 Fuel 如何赋能比特币生态》；

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

1. 使用 UTXO 模型或类似的状态存储方案；
2. 具有相当的 UTXO 可编程性，允许开发者编写解锁脚本；
3. 存在 UTXO 相关的状态空间，可以存储资产状态；
4. 存在比特币相关桥或者轻节点；