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

来源：极客 web3

随着 RGB++ 及相关资产发行的火热，关于 RGB 与 RGB++ 协议原理的讨论逐渐成为更多人关注的话题。但大家意识到，要理解 RGB++，必须先理解 RGB 协议。

原始的 RGB 协议在技术构造上略为晦涩，参考资料较为零散，至今没有多少系统性且较通俗易懂的参考资料，极客 web3 此前虽曾发表过两篇关于 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 没问题，这就好比，当你收到来路不明的纸币后，你要求对方说明这些纸币的历史来源，是否是指定的发行方制造的，以此来规避假币。