RGB++与同构绑定：CKB、Cardano与Fuel如何赋能比特币生态

作者：Shew，极客web3

摘要：

· CKB团队提出的RGB++资产协议，提出了“同构绑定”的思想，本质是将CKB和Cardano、Fuel等基于UTXO编程模型的区块链，作为承载RGB资产“容器”的功能拓展层。这种同构绑定还适用于Atomical、Runes等具有UTXO特性的比特币生态资产协议，便于为比特币搭建链下的智能合约层。

· RGB++协议中，用户不必运行客户端亲自验证交易数据，可以把验证资产有效性、数据存储等工作移交给CKB和Cardanao等UTXO链。只要你“乐观”的认为，上述公链的安全性比较可靠，就无需自己去做验证；

· RGB++协议支持用户切换回客户端验证模式，此时你依然可以将CKB作为数据存储/DA层，不必自己保管数据。RGB++协议无需资产跨链，可通过比特币账户对CKB链上资产进行操作，并且可以减少往比特币链上发布Commitment的频率，也利于支持Defi场景；

· 如果是在EVM合约体系下，RGB++的许多特性并不好支持。综合来看，适合实现同构绑定的公链/功能拓展层，应该具有以下特性:

1. 使用UTXO模型或类似的状态存储方案；

2. 具有相当的UTXO可编程性，允许开发者编写解锁脚本；

3. 存在UTXO相关的状态空间，可以存储资产状态；

4. 可以通过智能合约或其他手段，支持运行比特币轻节点；

· 除了CKB以外，Cardano、Fuel也可以支持同构绑定，但后两者在智能合约语言及合约设计细节上，可能存在一些包袱，目前看来，CKB比后两者更适合作为同构绑定的比特币资产协议功能拓展层。

在RGB++Protocol LightPaper内，Nervos CKB联合创始人Cipher第一次提出了同构绑定的产品思路。相比于其他比特币Layer2方案，同构绑定可以更好的兼容RGB、Runes和Atomical等资产协议，并且可以避免资产跨链等带来额外安全累赘的因素。

简单来说，同构绑定是用CKB和Cardano链上的UTXO做“容器”，将RGB等UTXO型资产表达出来，进而为其添加可编程性及更多更复杂的场景。此前，极客web3曾在《从BTC到Sui、ADA与Nervos：UTXO模型及其相关拓展》总结过一系列支持可编程UTXO的区块链，本文将进一步探究这些区块链是否可以适配同构绑定方案。

RGB++和同构绑定

在分析不同UTXO链对同构绑定的兼容程度前，我们要先介绍一下同构绑定的原理。同构绑定是CKB团队在RGB++协议中提出的概念，所以此处我们以RGB++的工作流程，来介绍基于CKB的同构绑定是什么。

在介绍RGB++协议前，我们先简单了解一下RGB协议。RGB是一种运行在比特币链下的资产协议/P2P网络，有点像闪电网络一样。此外，RGB还是一种基于比特币UTXO的寄生资产协议，所谓寄生，是指RGB客户端会在比特币链下，声明某些RGB资产与比特币链上哪个UTXO相绑定，你拥有了这个UTXO，它绑定的RGB资产也归你差遣。

RGB协议和ERC-20等资产协议的运作方式截然不同。以太坊上的ERC-20合约中，记录了所有用户的资产状态，且以太坊的节点客户端会同步并验证所有的转账信息，把转账后的状态更新记录在资产合约中。这其实早已被人们所熟知，无非是靠以太坊的共识流程，来保证资产的状态变更没猫腻。由于以太坊节点们的共识很可靠，用户就算不运行客户端，也可以默认基于ERC-20合约的资产托管平台“没问题”。

但RGB协议却很奇葩，它为了增强隐私性，干脆把节点/客户端共识这个在区块链世界里约定俗成的东西删掉了。用户要自己运行RGB客户端，只接收和存储“与自己相关的资产数据”，看不到别人都干了啥，不像以太坊和ERC-20那样，有链上全部可见的转账记录。

这种情况下，如果有人给你转来一些RGB资产，你事先并不知道这些钱是怎么造出来的，转手自哪些人。如果对面那个人凭空声明一种资产，然后转给你一部分，这种造假币的作恶场景怎么处理？

RGB协议采用了这样一种思路：每一笔转账生效前，接收者先让发送者出示该资产的全部历史记录，比如从创世阶段到现在，这些资产是由谁发行的，中间途经哪些人，在这些人之间发生的每一次资产转移，是否都不违背会计记账准则（一人加，一人减）。

这样一来，你就能知道对面给你的是不是“有问题的钱”，所以说RGB本质是让交易当事人自己运行客户端做验证，基于客户端验证模式，对应着理性人博弈假设，只要当事人理智，客户端软件没问题，就能保证有问题的资产转移无法生效，或无法被其他人认可。