几分钟速通RGB与RGB++协议设计：白话说明书

作者：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没问题，这就好比，当你收到来路不明的纸币后，你要求对方说明这些纸币的历史来源，是否是指定的发行方制造的，以此来规避假币。

With the hot issue of related assets, the discussion on the principle of agreement with geeks has gradually become a topic of concern to more people, but everyone realizes that to understand the agreement, the original agreement must be understood first. The technical structure is a little obscure, and the reference materials are scattered. So far, there are not many systematic and easy-to-understand reference materials. Geeks have published two articles on systematic interpretation of agreement before, but according to feedback from community members, the above articles are long and In order to make more people understand the agreement more quickly, the author of this article improvised a short vernacular interpretation of the agreement during the activities in Hong Kong, which can be read in a few minutes, hoping to help more community enthusiasts better and more intuitively understand the agreement. Users should do the data verification agreement in person, which is a special asset agreement and a computing system under the bitcoin chain. In some respects, it is similar to the payment channel. Users should personally run the client to verify their own transfer behavior, even if you. It's just that an asset receiver must first make sure that there is no error in the transfer statement of the asset sender before the transfer statement can take effect. Obviously, this is completely different from the traditional form of sending and receiving assets. We call it interactive transfer. Why is this because the agreement does not adopt the consensus agreement in traditional blockchain such as Bitcoin and Ethereum to protect privacy? Once the consensus agreement is adopted, almost all nodes in the network will observe that privacy is not guaranteed. If there are not a large number of sections, How to ensure the safety of asset changes in the consensus process in which all points participate? Here, the idea called client verification is used. You should run the client to verify the asset changes related to you in person. Suppose a user asks him to know the transfer information generated for the transferred token, and then he should send the transfer information and the asset data involved to him for personal inspection before entering the subsequent process and finally becoming an effective transfer. Therefore, the agreement is to let the user personally verify the validity of the data. Instead of the traditional consensus algorithm, but without consensus, the data received and stored by different clients are inconsistent. Everyone only stores their own asset data locally and doesn't know other people's asset status. This also constitutes a data island while protecting privacy. If someone claims that there are 10,000 tokens to be transferred to you, how do you believe him in the network? If someone wants to transfer money to you, he must first show his asset certificate and trace back to the historical source of assets from initial issuance to multiple changes of hands to determine whether to transfer them to you. The problem is that when you receive banknotes from unknown sources, you ask the other party to explain whether the historical source of these banknotes is made by a designated issuer in order to avoid counterfeit money. 比特币今日价格行情网_okx交易所app_永续合约_比特币怎么买卖交易_虚拟币交易所平台

（图片来源：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）

2. Alice构造一笔 “Alice to Bob” 的RGB资产转账数据，附带这些资产的历史来源交给Bob去验证。

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

4. Alice把这笔“Alice to Bob”的RGB转账数据构建成一棵Merkle Tree，把Merkle Root发布到比特币链上作为Commitment，我们可以把Commitment简单理解为转账数据的hash。

5. 如果未来有人想确定，上述“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如何赋能比特币生态》；

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

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

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

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

4. 存在比特币相关桥或者轻节点；