3000字大白话讲清RGB与RGB++协议设计

作者：Faust，极客 web3 & BTCEden.org 联创

来源：极客 web3

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

上述流程是发生在比特币链下的，仅凭这些过程还无法让 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 资产。

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），就可以了。