本文作者通过简单明了的方式解释了RGB协议及RGB++协议，介绍了如何通过客户端验证和第三方验证在比特币及其他公链上实现资产转移。RGB协议强调用户验证数据，以保证安全性和隐私；而RGB++协议将验证工作转移到第三方平台，牺牲了一定的隐私性。文章还讨论了同构绑定的概念，以及在CKB、Cardano等具有UTXO模型的公链上实现RGB资产交易的方法。要注意选择适合实现同构绑定的公链，具备UTXO模型和解锁脚本编写能力等特性。
作者：Faust，极客 web3 & BTCEden.org 联创
随着RGB++及相关资产的火热，关于RGB与RGB++协议原理的讨论逐渐成为更多人关注的话题。但大家认识到，要理解RGB++，必须先理解RGB协议。
原始的RGB协议在技术上构造上略为晦涩，参考资料较差零散，迄今为止没有多少系统性且较通俗易懂的参考资料，极客web3事实上曾发表过两篇关于RGB与RGB++的系统性解读文章（可以看看我们公号的历史记录大脑），但根据社区成员反馈，第四篇文章篇幅较兴奋长且太烧。
为了让更多人能够更快地理解RGB与RGB++协议，本文作者在香港活动期间，临时赶工完成了一篇关于RGB与RGB++的简短白话解读，可以在几内读完，希望对更多社区爱好有帮助更好、更敏锐的理解 RGB 和 RGB++。
RGB协议：用户要优先做数据验证
RGB协议是一种特殊的P2P资产协议，是比特币链下的计算系统，它在某些方面与支付通道类似：用户要顶层运行客户端，手机验证与自己有关的交易行为（自行验证） 。即使你只是一个资产接收者，也要先确定资产发送者的转账声明没有错误，然后我们近期的转账声明才能生效。显然这与传统的资产发送者与接收形式不同，将其称为「跋涉」。
原因在于，RGB协议为了隐私，不采用比特币和以太坊等传统区块链中的「共识协议」（数据为什么一旦走共识协议，被网络内几乎所有节点都落地到，隐私不好保障）。如果没有大量节点都参与的投票流程，又保证资产变更是安全的？这里用到名为「客户端验证」的思想（自己验证），你要自己运行客户端，优先验证和您相关的资产波动。
假设有一个 RGB 用户叫 Bob，他认识 Alice，Alice 要给 Bob 转来 100 张 TEST 代币。Alice 生成了「Alice to Bob」的转动信息后，要先把转动信息和涉及的资产数据发送给 Bob ，让他先检查一遍，确定无误才会进入后续流程，最终成为一笔有效的 RGB 路线。所以说，RGB 协议是让用户赠送验证数据效果，取代传统的人工智能算法。
但没有认识到，不同的 RGB 客户端接收和存储的数据都不一致，大家只在本地存储与自己有关的资产数据，不知道别人的资产状况，这在保护隐私的同时，也构成了「数据孤岛」 。如果有人宣称有100万枚TEST代币，要转给你10万枚，你如何相信他？
在 RGB 网络中，如果有人要给你转账，必须让他先出示资产证明，回溯资产从初始发行到多重转手的历史来源，确定要转给你的代币 没问题，这就比，当你收的时候在即将到来的纸币不明朗之后，你要求对方说明这些纸币的历史来源，是否是指定的发行方制造的，以此来规避假币。
以下流程是发生在比特币链下的，仅凭这些过程还无法让 RGB 与比特币网络产生直接关联。对此，RGB 协议采用了一种名为「一次性印章」的思想，把 RGB 资产与比特币联系起来链上的UTXO绑定起来，只要比特币UTXO没有被双重消费，绑定的RGB资产就不会发生双重支付，这样就可以借助比特币网络来阻止RGB资产发生「重组」。当然，这需要在比特币链上发布承诺，并使用 OP_Return 操作码。
这里整理一下RGB协议的工作流程：
1. RGB资产与比特币UTXO存在绑定关系，而Bob拥有某些比特币UTXO。Alice要给Bob转账100枚代币，在接收资产前，Bob事先告诉Alice，应该用Bob的哪个比特币UTXO 绑定这些 RGB 资产。
比特币在这里充当了 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资产交易发生时，资产容器也可以呈现出相似图案，就像是实体和影子的关系一样，这就是「同构绑定」的对应精髓。
例如，假设 Alice 拥有 100 张 RGB 代币，以及比特币链上的 UTXO A，同时在 CKB 链上有一个 UTXO，这个 UTXO 上标记着「RGB代币 Balance：100」，解锁条件与 UTXO A 有关联。
如果Alice想把30枚代币送给Bob，可以先生做出一个承诺，对应的声明是：把UTXO关联的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 的安全性，甚至不必频繁刷新的在比特币链上发布承诺，可以在多笔 RGB 转账进行后，再将一个承诺汇总发送到比特币链上，这被称为「交易折叠」功能，可以降低使用成本。
但要注意，同构绑定采用的「容器」，需要支持 UTXO 模型的公链，或者在状态存储上有类似特征的基础设施，EVM 链不太适合，会遇到很多坑。（此话题可以单独成文，涉及的内容参考基准，有兴趣的读者可以客 web3 彼此文章《RGB++ 与同构绑定：CKB、Cardano 与 Fuel 如何赋能比特币生态》；
综合来看，适合实现同构绑定的公链/功能拓展层，应具有以下特性：