作者:Faust,极客 web3 & BTCEden.org 联创

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

原始的 RGB 协议在技术构造上略为晦涩,参考资料较为零散,至今没有多少系统性且较通俗易懂的参考资料,极客 web3 此前虽曾发表过两篇关于 RGB 与 RGB++ 的系统性解读文章(可以看我们公号的历史记录),但据社区成员反馈,前述文章篇幅较亢长且太烧脑。

为了让更多人能更快理解 RGB 与 RGB++ 协议,本文作者在香港活动期间,临时赶工完成了一篇关于 RGB 与 RGB++ 的简短白话解读,可以在几分钟内读完,希望帮助更多社区爱好者更好、更直观的理解 RGB 与 RGB++。

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

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

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

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

  1. Alice 构造一笔 「Alice to Bob」 的 RGB 资产转账数据,附带这些资产的历史来源交给 Bob 去验证。
  2. Bob 在本地确认这些数据没问题后,给 Alice 发送一个回执,告诉她:这笔交易可以通过了。
  3. Alice 把这笔「Alice to Bob」的 RGB 转账数据构建成一棵 Merkle Tree,把 Merkle Root 发布到比特币链上作为 Commitment,我们可以把 Commitment 简单理解为转账数据的 hash。
  4. 如果未来有人想确定,上述「Alice to Bob」的转账真实发生过,他需要做两件事:在比特币链下获取「Alice to Bob」的完整转账信息,然后查验比特币链上是否存在对应的 Commitment(转账数据的 hash),就可以了。

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

比特币在此充当了 RGB 网络的历史日志,但日志上只记录交易数据的 hash/Merkle root,而非交易数据本身。由于采用了客户端验证和一次性密封,RGB 协议具有极高的安全性;由于 RGB 网络是由动态的用户客户端以 P2P、无共识的形态组成的,你可以随时更换交易对手方,不需要把交易请求发送给某些个数量有限的节点,所以RGB 网络具有极强的抗审查性,这种组织形式要比以太坊等大型公链更抗审查。

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

当然,极高的安全性与抗审查性、隐私保护,带来的代价也是明显的:用户要自己运行客户端验证数据,如果对面发过来一些转手几万次、历史记录很长的资产,你也要顶着压力全部验证完;

此外,每笔交易都要求双方进行多次通讯,接收方要先验证发送方的资产来源,然后发送回执,批准发送方的转账请求。这个过程中,双方之间至少要产生三次消息传递。这种「交互式转账」和大多数人所习惯的「非交互式转账」严重不符合,你能想象,别人要给你转钱,还要把交易数据发给你来检查,得到你的回执消息后,才能完成转账流程吗?

此外,我们曾提到,RGB 网络没有共识,每个客户端都是孤岛,不利于把传统公链上的复杂智能合约场景迁移到 RGB 网络中,因为以太坊或 Solana 上的 Defi 协议都依赖于全局可见、数据透明的账本。如何优化 RGB 协议,提高用户体验并解决上述问题?这成为了 RGB 协议绕不开的一个问题。

RGB++:客户端验证变为乐观的托管

名为 RGB++ 的协议提出了新思路,它把 RGB 协议与 CKB、Cardano、Fuel 等支持 UTXO 的公链结合起来,由后者作为 RGB 资产的验证层与数据存储层,把原本由用户进行的数据验证工作,移交给 CKB 等第三方平台 / 公链,这相当于把客户端验证替换为「第三方去中心化平台做验证」,只要你信任 CKB、Cardano、Fuel 等公链即可,如果你不信任他们,也可以切换回传统的 RGB 模式。

RGB++ 和原始的 RGB 协议,理论上是可以彼此兼容的,并不是有他无我。

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

要实现上面提到的效果,需要借助一种名为「同构绑定」的思想。CKB 和 Cardano 等公链有自己的拓展型 UTXO,它比 BTC 链上的 UTXO 多出了可编程性。而「同构绑定」,就是将 CKB、Cardano、Fuel 链上的拓展型 UTXO 作为 RGB 资产数据的「容器」,把 RGB 资产的参数写入到这些容器中,在区块链上直接展示出来。每当 RGB 资产交易发生时,对应的资产容器也可以呈现出相似特征,就像是实体和影子的关系一样,这便是「同构绑定」的精髓。

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

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 层。

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

所有人的 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 到比特币链上,这被称为「交易折叠」功能,可以降低使用成本。

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

但要注意,同构绑定采用的「容器」,需要支持 UTXO 模型的公链,或是在状态存储上有类似特征的基础设施,EVM 链不太适合,会遇到很多坑。(此话题可以单独成文,涉及的内容较多,有兴趣的读者可以参考极客 web3 此前文章 《RGB++ 与同构绑定:CKB、Cardano 与 Fuel 如何赋能比特币生态》;

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

  1. 使用 UTXO 模型或类似的状态存储方案;
  2. 具有相当的 UTXO 可编程性,允许开发者编写解锁脚本;
  3. 存在 UTXO 相关的状态空间,可以存储资产状态;
  4. 存在比特币相关桥或者轻节点;