一文搞懂RGB协议与RGB++协议

比特币铭文、符文的爆火，引发了新一轮人们对于比特币生态的期待，紧接着基于比特币实现智能合约技术迭代在快速发展，例如基于比特币的Layer2（如B² Network等）、侧链（如 Liquid，merlin等）。而发展多年的RGB协议热度也被重新拎了起来，CKB团队则另辟蹊径，基于RGB协议及自己的CKB公链，推出了RGB++协议，下面将详细介绍下这两个协议的实现原理。

内容隐藏

1 RGB协议

RGB协议

协议的愿景

我们知道比特币的虚拟机不是图灵完备的，无法支持复杂的智能合约实现，RGB协议的愿景就是实现一个可用于比特币区块链上的智能合约和资产发行的协议，增强比特币的功能以及其上智能合约的隐私性、可扩展性。RGB 协议是基于 Peter Todd 在 2016 年提出的客户端验证（client-side validation）和一次性密封（single-use-seals）的概念，但发展较为缓慢，社区至今也没有推出具体的稳定版本。

协议的实现原理

符文、铭文的实现是将具体的数据存储于比特币witness字段、OP_RETURN交易当中。其建立的基础是oridinals协议，即对比特币具体聪编号的协议。当符文、铭文被mint之后，其就与具体的聪进行绑定，之后的交易只需要转移具体的聪即可，而排序器会对这些聪的转移进行跟踪。

RGB存储数据存储及转移并不是基于聪，而是基于UTXO+OP_RETURN交易。与铭文、符文的一个区别也在于此，一个是基于聪，一个是基于UTXO的。（具体聪与UTXO相关可查看文章：比特币铭文与符文具体的技术实现）。

除此之外，铭文、符文发生转移的具体内容与RGB协议也不相同，例如A向B用户传递一个BRC20的资产，那么“转移”产生的具体内容如下图所示：

OP_RETURN里面是一个JSON字段，描述了对应的代币要转移的数量及对应到输出中的哪个UTXO（也就是哪个聪）。转移发生的所有内容都是在链上，而RGB协议则只将交易发生的“承诺”放到链上，而不是所有的交易内容，这样就可以减少调用智能合约产生的数据占用，提升其可扩展性。

除此之外符文与铭文的合约内容目前只针对一些简单的例如BRC20、BRC721协议的实现，但是对于复杂的合约铭文符文很难处理，例如要通过铭文符文实现一个类似于加密猫逻辑相对复杂的合约是十分困难的。但RGB协议有自己对应的VM（目前社区是AluVm），可以实现复杂合约。

协议流程说明

这里通过使用RGB协议完成一个BRC20智能合约发布、交易的流程，来说明RGB协议的实现原理。

合约发布

用户只需要发起一个比特币交易，交易的内容如下图所示：

输出的UTXO中有一个是OP_RETURN，里面包含了铸造合约的承诺，为理解方便，我们可以简单将其理解为合约的哈希值，铸造者可以提供哈希的原像也就是合约内容来揭示该承诺。

同时你本地的客户端拥有该合约的具体内容，该合约内容哈希的结果就是你在链上交易的承诺。发布了该合约之后，用户就可以在链下（一般指RGB的客户端）进行合约的调用。

合约调用（交易）

用户对BRC20合约的调用其实就是交易，我们以一个BRC20的转账为例。用户发起一笔转账交易需要：

在比特币链上同样发起一笔交易，交易输出的UTXO中包含了本次交易的承诺，这个承诺可以理解为该合约对应的所有状态，这些状态指在该和约下A用户有多少余额，B用户有多少余额等等，这些余额可以组成一个Merkle Root，当一笔交易发生，用户的余额变更，那么对应的merkle root也会发生变更，因为哈希算法的不可逆性，一个merkle root就可以代表一个合约的当前状态的结合。

如上图所以，A给C转账5，那么就会产生一个新的merkle root。同时A用户也会在比特币链上发起一笔交易，该交易输出的OP_RETURN里面就包含了这个merkle root承诺。在链下B用户收到该笔交易之后，会通过链上的承诺及A给出的具体交易信息，验证该笔交易的合法性。这个也就是上文提到的客户端验证（client-side validation）。

有两点需要注意，一个是前文的承诺不仅可以通过merkle root来完成，也可以通过零知识证明或者其他方式来完成，只要这个承诺符合上链数据少、可以被验证、不会被篡改的特性，都可以用来做为“承诺”使用。其次因为A与C在交易的时候需要通过客户端进行验证，所以A与C需要自己保留整个交易过程信息，以进行下一次的交易，不过这个可以由开发者通过客户端来实现。

上图所示转账的流程就构成了一个有向无环图，用户需要自己保留整个的交易信息，以备下次使用。

还有一个问题：如何保证用户对应的某个代币不会产生双花。反正都是客户端验证，A用户不就可以给B转账，同时也给C转账，将一笔钱花费两次。这里就涉及到了一次性密封（single-use-seals）的概念，前文提到资产（或者说交易）是同UTXO绑定的，用户转移资产的时候需要在比特币链上交易该UTXO，我们知道UTXO被花费之后就不能再花费第二次，即一次性密封后，解封之后就不能再使用了。以此来防止双花攻击。

一次性密封并不是特指UTXO，而是指所有拥有这种只能花费一次性质技术的总称，例如CKB的cell概念也具备一次性密封的性质。

做个总结：RGB智能合约通过将智能合约的状态与UTXO绑定的方式，实现一种基于UTXO的智能合约形式，同时将交易、验证放在链下（也就是RGB客户端），而只上链交易的承诺，并通过UTXO一次性密封的性质避免双花的问题。

RGB++协议

介绍RGB++协议前，先介绍下CKB链，CKB 是 Nervos Network 的 Layer1 层的原生 Token 的名称，比特币和 Nervos CKB 都是类似的存储和验证系统。比特币的是 UTXO 集，透过其脚本进行验证。NervosCKB 泛化了比特币的数据结构和脚本功能，将其全局状态存储为一组可编程的单元（我们称之为 Cell），并通过虚拟机来运行用户自定义的图灵完备脚本来验证他的状态转换。

CKB与RGB关联起来比较重要的性质就是CKB的底层存储模型与比特币是类似的，一个是UTXO一个是cell，相对于UTXO，cell模型可存储的内容更加丰富，同时上层支持使用CKB-VM实现的智能合约。正是这个性质为CKB实现RGB协议提供了便利。

RGB需要有客户端进行验证，RGB++直接将对应的交易锚定到CKB链上，即在比特币上面进行一次UTXO的转移，在CKB上同样进行一次交易（不过交易的内容不同，一个是将承诺上链，一个是具体的合约调用信息），同时因为CKB本身是基于UTXO模型的区块链，所以其智能合约的设计完美适配RGB协议提出的“构造基于比特币链的图灵完备的智能合约”设想。CKB链会附带一个比特币的轻客户端，在锚定的时候通过该轻客户端验证比特币链上UTXO的转移是否合法、完成。

简而言之，CKB通过自己与比特币类似的存储模型，使用CKB链代替RGB协议中客户端的角色，并完美接入自己已有的智能合约体系。