（图片来源：Coinex）
上述流程是发生在比特币链下的，仅凭这些过程还无法让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资产。
（图片来源：极客web3/ GeekWeb3）
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网络具有极强的抗审查性，这种组织形式要比以太坊等大型公链更抗审查。
（图片来源：BTCEden.org ）
当然，极高的安全性与抗审查性、隐私保护，带来的代价也是明显的：用户要自己运行客户端验证数据，如果对面发过来一些转手几万次、历史记录很长的资产，你也要顶着压力全部验证完；
此外，每笔交易都要求双方进行多次通讯，接收方要先验证发送方的资产来源，然后发送回执，批准发送方的转账请求。这个过程中，双方之间至少要产生三次消息传递。这种“交互式转账”和大多数人所习惯的“非交互式转账”严重不符合，你能想象，别人要给你转钱，还要把交易数据发给你来检查，得到你的回执消息后，才能完成转账流程吗？
此外，我们曾提到，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资产交易发生时，对应的资产容器也可以呈现出相似特征，就像是实体和影子的关系一样，这便是“同构绑定”的精髓。
（图片来源：RGB++ LightPaper）
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++ LightPaper）
所有人的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如何赋能比特币生态》；
综合来看，适合实现同构绑定的公链/功能拓展层，应该具有以下特性:
使用UTXO模型或类似的状态存储方案；
具有相当的UTXO可编程性，允许开发者编写解锁脚本；
存在UTXO相关的状态空间，可以存储资产状态；
存在比特币相关桥或者轻节点；
APP 
