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

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