从RGB到RGB++：CKB如何赋能比特币生态资产协议

作者：Shew & Faust，极客web3

顾问：CyberOrange，Unipass

摘要（较长）： · RGB 协议是比较有潜力的BTC拓展协议，本质是一种链下计算系统，它采用了和闪电网络类似的思想：用户亲自验证并授权和自身相关的资产变动事宜（Verify by yourself），把交易发起者认可的结果/承诺提交到比特币链上。

· RGB协议利用了与染色币及Mastercoin部分类似的思想，在比特币UTXO上关联着“寄生资产”。它把链下交易数据的Commitment“承诺”，存放到比特币链上，而不是像Ordinals协议那样发布完整的DA数据。根据比特币链上记录的承诺值，RGB客户端可以验证，其他客户端提供的RGB历史数据是否有效。

· 同时，单凭hash/Commitment无法还原背后的原像，外界不能直接观测到链上承诺值对应的链下数据，这样可以保护隐私，且相比于铭文，只把承诺上链能节省空间。从第三者的视角看，他其实不知道RGB客户端到底干了什么。

· RGB还利用了比特币UTXO一次性花费的特性，通过名为“一次性密封”的思路，把RGB资产所有权，和比特币UTXO关联起来。这样可以借助比特币强大的安全性，避免RGB资产被“双花/双重支付”（只要比特币UTXO不被双花，RGB资产就不会被双花）。

· 但 RGB 作为一个在比特币链下实现的智能合约系统，依赖于不同的客户端在本地存放历史数据，且不同客户端（用户）只存放与自己相关的数据，看不到别人的资产状况。这种“数据孤岛”虽然保护了隐私，但也使得RGB在大规模采用上面临麻烦，更像一个由OTC交易者组成的P2P网络。

· RGB++的思路是，用CKB链上的Cell，表达RGB资产的所有权关系。它把原本存放在RGB客户端本地的资产数据，挪到CKB链上用Cell的形式表达出来，与比特币UTXO之间建立映射关系，让CKB充当RGB资产的公开数据库与链下预结算层，替代RGB客户端，实现更可靠的数据托管与RGB合约交互。对于其他基于UTXO的Layer2而言，这种”同构绑定” 是一种趋势。

·RGB协议本身只支持交互式的转账流程，交易双方要频繁通信，这种模式难以支持Defi场景，也不利于RGB资产发行。CKB替代了独立客户端之后，可以实现非交互的RGB交易，利于Defi落地和空投等功能，且支持BTC资产无需跨链的与CKB链上资产交互。

·RGB++本质是用隐私换易用性，同时带来RGB协议无法实现的场景。如果用户看重产品的简单好用和功能完备性，就会青睐RGB++，如果追求隐私和Verify by yourself的安全，就会青睐传统的RGB协议，一切看用户自己的取舍。（理论上RGB++也可以通过ZK等方法解决隐私问题）

RGB协议的原理及其优缺点

RGB协议本身是一种比较复杂的方案，我们以一笔具体的RGB资产转账为例，为大家解释RGB协议是如何工作的。

假设有一种符合RGB协议要求的代币，叫TEST。Alice 希望 Bob 将 100 个TEST代币转给自己，换句话说，希望生成一笔 Bob—>Alice 的代币转账。

这里先解释下，RGB协议采用了称为“一次性封装”的思路，表面上说是Bob给Alice转账，实际是指，Bob控制着比特币链上的UTXO A，而UTXO A通过某些方法，关联了一些RGB资产。

如果Bob声明，要把UTXO A关联的部分RGB资产转让给Alice，它可以如此声明：把UTXO A关联的30枚TEST代币，转让给UTXO B来关联。由于Alice是UTXO B的所有者，所以她就拥有了关联的30枚TEST代币。

（图源：Discoco Labs）

实际上比特币链上的所有权记录方式，都是通过UTXO来实现的，声明UTXO B有资格控制xx数额RGB资产，就等价于说UTXO B的主人可以控制xx数额RGB资产，这与我们所习惯的账户地址模型并不一致，是比特币等UTXO公链的独特属性。

理解了这里后，我们再考察RGB协议的工作流程，可以感受到他与染色币及Mastercoin等比特币UTXO寄生资产的差异：

1. 按照RGB协议的原理，Alice 要先为转账交易开具发票(issues an invoice)，指明自己的意图。发票中包含以下信息:

合约 id： Alice声明要与哪个RGB资产合约交互

接口： 让 Bob 了解合约的所有交互接口

操作： Alice让Bob去调用的合约接口名

状态： Bob 需要修改的合约状态，此例中就是 Bob 转给 Alice 的代币数量

Seal（密封条） ：用于一次性密封的UTXO，可以简单理解为，Alice 用来接受Bob的RGB资产授权的UTXO。

最后，Alice 会获得一个如下的发票内容:

上述发票遵循如下格式：

2. Alice 需要将上述发票发送给 Bob。Bob 会检查发票信息，按照Alice的意图来生成新的RGB交易，把RGB资产转让给Alice。

但这里要格外注意，Bob必须设法证明，自己的确有部分TEST资产所有权。至于为何要这么做，是因为RGB协议默认“没有全局可见的资产状态记录”，不会像以太坊那样用一个公共托管合约来记录并处理所有人的资产。

RGB协议下，不同的客户端只记录和自身相关的资产数据，包括这些资产的当前余额、历史来源等，每个客户端记录的数据基本都不一致。这样一来，每个人都无法确认其他人的资产状况，所以在P2P交易时要出示资产证明。

用一句生动的比喻就是，你和对面在用纸钞进行交易，但你不知道对方的纸钞是不是自己印的假币，你便要求他说清楚，这些纸钞是从哪里弄来的，经过多少人转手，以此来判断对方是否在用假币糊弄你。

双方互相认可后，就可以放心大胆的交易，每一笔RGB交易也只需要参与方彼此认可就行，是完全P2P的（类似于OTC）。

显然，这种模式可以保护隐私，因为每个人的资产状况、交易记录，都不会被外界轻易获知，你和交易对手方做了什么，外人很难知道。道理就好比，纸币可以比银行转账更好匿踪。但显然，这也会在用户体验上造成不便。

在前面谈到的Alice和Bob案例中，Bob收到Alice的发票并获知其意图后，要从本地客户端的历史数据中，选出和TEST资产相关的历史转账记录，连同新生成的 Bob -> Alice 转账，一起交给Alice去校验，证明新的RGB交易/所有权变更，背后对应的资产所有权来源是有效无误的。

一般而言，客户端本地存放的数据称为Stash“藏品”，包含了RGB资产的过往数据。我们可以把Stash当做RGB资产合约的日志记录。

3. 当Alice从Bob那里收到数据，以及新声明的 Bob—>Alice 交易后，会验证其有效性， 如果验证通过，Alice 便会生成一个“确认签名”，返回给 Bob。

4. Bob 收到 Alice 的确认签名后，便 把Bob —> Alice交易对应的 Commitment（承诺）广播到 BTC 网络内，最终写入BTC链上， 使其具备“最终性”。

（Commitment的结构图，其实本质是个merkle root）

如果Bob—>Alice转账中，声明 UTXO B 的主人将拥有30枚TEST代币，则Alice只要证明自己是UTXO B的主人，就可以使用这些TEST代币。

5. 如果未来Alice要把TEST代币转给别人，当出示这些TEST的历史来源时，对方可以根据比特币链上的commitment承诺值进行核验，看Alice提供的数据能否和链上的承诺值对应。 这样可以防止伪造数据。

RGB协议的好处在于，可以在链下支持复杂的智能合约计算。 它本质上把计算步骤挪到了BTC链下，仅在链上记录Commitment，在 保护隐私 的同时，在链下声明比特币UTXO和RGB资产所有权之间的关联，借助比特币来刻录并实现RGB资产的所有权变更。

由于所有的交易声明都需要由当事人验证并授权，所以其安全模型基于“理性人假设”， 只要当事人是理智的，只要比特币是安全的，RGB资产所有权就“基本安全”。

但 RGB协议的缺陷也很明显 （前文有提及数据孤岛与碎片化存储问题）。首先， 要给其他人转账，甚至要先得到对方的同意和确认，双方基本要同时在线；

其次，因为 缺乏全局可见的数据记录方式， RGB的 合约发布甚至都采用了非常奇葩的形式， 合约使用者要事先从合约发布者处，获知合约包含的接口功能，具体的获知方式可以是通过电子邮件或是扫二维码。（看官方目前的说辞，估计把合约代码挂官网首页、推特置顶也可以）

我们再来探讨一下 RGB 协议的合约状态。在 RGB 协议内，合约的初始状态(Genesis)由创建者在合约创建时就设置好，比如 RBG-20 合约中的代币名称、总量等。而后， 合约的状态伴随着RGB交易的持续递进而变化，但这种合约状态演进是非线性的，构成了一个有向无环图DAG。

（图中owner1的视野范围是蓝色和绿色部分，Owner2视野范围是蓝色和黄色部分）

比如 Bob 给 Alice 转账时，仅出示从合约初始化，到Bob获得代币的部分转账记录，包含的数据路径比较狭隘。而 Alice 也仅能获知此路径分支包含的交易信息，难以获知其他人的转账信息。这虽然保护了RGB用户的隐私，但也带来了 不良后果：用户很难获知RGB 合约的全局状态，比如每个人有多少RGB资产。这会带来很多麻烦。

比如，当Bob —> Alice转账进行到最后步骤，其承诺值被写入BTC链上且不可逆转后，Bob 可以在本地删掉部分数据——假如Bob将自己全部的TEST代币都给了别人，可以直接把本地存放的TEST代币相关数据删掉，以减轻存储压力。

而作为代币接收方的 Alice，则要在本地记录此次交易所涉及的全部数据。（ 假如Bob删掉了本地的TEST代币数据，Alice的客户端节点又因为事故彻底损坏了，那么此时，Alice的资产是不是就永久冻结了？ 因为没有其他地方存放Alice的TEST资产数据，除非事先就备份好。）

这本质上可以 归结为DA和数据存储问题， 即RGB协议的新增数据无法以一种可靠、全局可见的方式传播出去，最终会使得不同的客户端成为“数据孤岛”。此前曾在以太坊生态如日中天，但后来遭到废弃的Plasma方案，也是因为无法解决DA问题，最终胎死腹中。

此外， RGB协议还需要交易双方进行大量通信， 很多通信步骤都要依赖中心化设施，在这块的细节描述还不成熟，官方甚至说可以通过邮件来通信。

比较显然的是， RGB协议的设计对于追求易用性的长尾用户不太友好， 虽然拥有较多资产且对隐私有较高追求的大户会乐于做数据备份和客户端维护，但对于长尾用户而言，这些包袱还是太重了，会对大规模采用造成严重阻碍。甚至于到目前，人们大多认为没有出现什么现象级的RGB资产。

下图中，我们给出了RGB资产转账的流程图，读者可以基于此图更加深刻理解转账的整体流程。

简而言之，RGB协议借助比特币UTXO，实现RGB资产的所有权变更，并通过在BTC链上发布承诺值（Commitment），确保链下数据无法被客户端私自篡改。实际上，RGB所谓的 “一次性密封”，就是通过链下的RGB交易声明，把比特币UTXO和RGB资产所有权关联起来，以此借助比特币强大的安全性，来保障RGB资产安全。 但由于DA和数据存储问题，原始RGB协议的可用性及UX比较差，且资产容易因为数据丢失而冻结（不可用）。

RGB++：基于CKB的加强版RGB协议

在上文中，我们总结了 RBG 系统的优点与缺点，其中，客户端数据孤岛、合约状态无法全局可见，构成了影响RGB协议易用性的最主要因素。

实际上， RGB协议的优点和缺点都很明显， 对隐私和安全有较高追求的人会倾向于自己运行客户端，并做好数据备份，但长尾用户显然没这个耐心（比如，大多数闪电网络用户会依赖于第三方节点，而不是自己去运行客户端）。

基于这个理由，Nervos联创Cipher提出了 名为RGB++的方案，尝试将RGB的资产状态、合约发布与交易验证，委托给CKB公链来进行。CKB充当了第三方的数据托管与计算平台， 不再需要用户自己运行RGB客户端。

由于CKB本身是拓展的UTXO模型（Cell），可以将RGB资产的链下信息写入到Cell中，并在Cell和比特币UTXO之间建立1对1的映射关系，实现基于CKB的RGB资产数据托管与验证方案，以此解决易用性问题，作为RGB原始方案的一种强化补充。

这段话读起来可能有点绕，对此我们再展开解释一下：

文章前面提到，RGB协议本质是通过发布链上承诺与链下声明，把比特币UTXO和RGB资产所有权关联起来。但RGB资产合约的数据是碎片化存放在不同客户端本地的，没有一个全局可见的视图。

RGB++通过CKB的拓展版UTXO——Cell，把比特币UTXO与对应的RGB资产之间的映射关系，直接在CKB链上展示出来，并且由CKB公链替代用户的P2P客户端，验证每一笔RGB转账的有效性。

有了这样一个全局可见的RGB数据记录后，很多难以在RGB协议中实现的场景都会更容易落地。

（RGB++的交易流程，把RGB资产信息写入Cell，再将Cell与比特币UTXO建立关联，最后把CKB上发生的RGB++交易，以及与RGB++资产关联的比特币UTXO，一并包含在承诺里，再把承诺值写到比特币链上）

可能有人第一时间想到了 EVM。我们是否可以用 EVM 承载 RGB 的状态与验证？答案是：很麻烦，因为RGB 资产本质上寄生于比特币UTXO，与比特币UTXO存在1对1的映射关系。 如果要把比特币UTXO与EVM合约数据建立映射关系，在技术实现上并不顺畅，还不如直接选择一条UTXO公链。

而且，以太坊上的“资产”往往是点对池的公共物品，一个合约上记录无数人的资产数据，合约控制者拥有绝对权力， 这种资产处理方式与比特币UTXO以及RGB协议严重冲突， 后两者的设计思路，是彻底实现资产的私有化，每个人完全控制自己的资产（想想纸币和微信支付的区别），不必考虑以太坊和EVM链一贯存在的：资产合约owner滥用职权、合约出bug导致资金受损、资产合约的数据要迁移时很麻烦 等问题。

（出自极客web3过往文章：《技术圈名人响马：高性能公链难出新事，智能合约涉及权力分配》 ）

所以， 如果要将比特币UTXO与链下RGB资产之间的映射关系表达的较为顺畅，最好的选择还是通过UTXO链。 而CKB支持的是拓展型UTXO——Cell，且CKB VM的指令集基于 RISC-V，比起EVM更容易兼容不同的密码学算法，包括比特币的公私钥验证算法，所以更利于实现RGB++提出的技术方案。

RGB++的技术实现

RGB++用到了CKB的拓展型UTXO——Cell 。而一个Cell包含以下字段:

Capacity代表此 Cell拥有的链上空间大小，data指 Cell 内包含的数据集，可以被读取或修改。

Type是这个Cell 绑定的程序代码，限制了data数据的修改条件。比如，你的Cell里有100枚TEST代币的数据，但你声明将110枚TEST转给别人，这不符合Type里规定的限制条件，会被拒绝。

而Lock则代表Cell 的所有权验证逻辑，类似于比特币UTXO的解锁脚本。

我们可以把Cell理解为升级版的UTXO，多出了Type和Capacity这两个字段，且data可以自定义数据类型，至于Cell的所有权变更方式，和比特币UTXO差不多，都是通过解锁脚本来实现。

而RGB++的思路是，用CKB链上的Cell，表达RGB资产的所有权关系。 它把原本存放在RGB客户端本地的资产数据，挪到CKB链上用Cell的形式表达出来，让CKB充当RGB资产的公开数据库。而表示RGB资产的Cell，会和比特币链上的UTXO存在1对1的映射关系，这种映射关系会在Cell的Lock字段里直接展示出来。

比如说， 假设某个RGB资产关联着比特币UTXO A，则对应的映射版Cell，可以把自己的所有权验证条件，设置为和比特币UTXO A一致 （就是把Lock脚本设置为比特币UTXO A的解锁条件）。如果你是UTXO A的控制者，你就能直接操作CKB上的映射Cell，当然， CKB会验证你是不是UTXO A的主人。

CKB链上会实现比特币轻节点，同步比特币区块头。当你声明RGB交易，要对RGB资产对应的Cell进行操作时，要先证明自己是比特币UTXO A的控制者， 证明步骤分两步：

1.向CKB链上实现的比特币轻节点证明，UTXO A存在于比特币链上，需要出示Merkle Proof；

2.出示数字签名，证明自己是UTXO A的所有者。

在 RGB++方案中，用户在前端声明一笔RGB资产转账后，会在CKB链上触发一笔交易，对记录RGB资产数据的Cell进行改写，变更其所有权。 原本可能是比特币UTXO 1的控制者拥有这个Cell，所有权变更后，比特币UTXO 2的控制者成为了Cell的新主人。这一切都在CKB链上可见。

这里要注意的是，与BTC链上承诺相关的工作流程，依然在 BTC 主网进行，就是说 RGB++仍然要在比特币链上发布Commitment， 与CKB上发生的RGB资产交易记录关联起来。这一步与传统RGB协议并无不同。

但不同的是， 传统RGB协议中由客户端在链下自己负责的工作，都由CKB来负责， 比如交易对手方要验证资产来源、客户端要在本地存储资产来源数据、RGB合约发布要通过第三方渠道等，这些繁琐的包袱都可以由CKB负责解决，不需要用户自己运行客户端。

这样解决了RGB客户端数据孤岛问题，也解决了合约状态无法全局可见的缺陷。同时，RGB合约可以直接部署在 CKB 链上，全局可见，供RGB Cell来引用，这样就避免了RGB协议合约发布时的一系列奇葩操作。

概括来讲， CKB 利用Cell脚本的可编程性，先确定RGB转账发起者 的确拥有RGB资产关联的比特币UTXO，若验证通过，则允许用户通过转账，将记录RGB资产数据的Cell转让给别人。

简而概之，CKB 充当了RGB资产的公开数据托管平台，提供了数据存储与全局可见的合约发布功能，也提供了所有权验证与计算功能。更加精简一点来说，就是 CKB 替代了 RGB 中的客户端，并且顺带解决了其他的问题。

当然，RGB++既然实现了全局可见的数据发布，隐私性相比于RGB协议必然是降低的，但好处是易用性得到了极大幅度提升。

所以 RGB++本质是用隐私换易用性，同时能带来RGB协议无法实现的场景。 如果用户看重产品的简单好用和功能完备性，就会青睐RGB++，如果追求隐私和Verify by yourself的安全，就会青睐传统的RGB协议， 一切看用户自己的取舍 （思路就和Vitalik评论以太坊Layer2时表达的差不多，追求安全就去用Rollup，追求低成本就去用Validium和Optimium等非Rollup方案）。当然， 按照RGB++白皮书中的说法，后续也可以在CKB链上实现隐私交易方案，隐藏用户的身份与转账金额。

RGB++的附加特性

交易的非交互性（非常重要）

原始RGB 协议的一个重要问题在于，收款方要先向付款方发送一条消息（就是前文说过的支票），指明把自己的一个UTXO与RGB资产绑定，RGB转账才能顺利实施。 这就要求收款方与付款方之间经过多道交互式通信，才能完成一笔普通交易， 显然增加了用户的理解难度和产品复杂度。而RGB++利用了CKB作为数据托管与计算平台的特性，允许对手方之间通过异步、非交互的方法来完成转账。

A 向B 转账时，只需要事先知道B的地址，声明向该地址转账，不需要收款人在线通信或提供数据。 之后，收款人可以自己去领取资产，CKB链上的脚本代码，会验证收款人是否是付款人指定的那个。显然，这种模式更贴近大多数人的习惯，诸如 空投、奖励分发等原本在RGB协议中不支持的模式也可以跑的通，这样也有利于RGB资产发行。

此外，RGB协议的工作模式天然不利于Defi场景的展开，比如Uniswap这种典型的多对多、非交互式的交易池，在原始RGB协议中几乎无法展开，而RGB++实现了非交互式交易、状态全局可见可验证，只要借用Cell来实现一个“所有满足条件的人都可以修改其状态的“无主合约”，就可以把很多Defi场景落地。

当然，所有人都可以修改其状态的无主合约，很容易出现状态争用/读写冲突，就是好几个人想同时修改合约状态，这样会导致混乱。为了解决这个问题，RGB++计划用一个链上实现的Intent Cell 作为“排序器”，对不同的请求进行排序。

交易折叠（聚合多笔交易的承诺发布）

交易折叠比较好理解，就是把CKB作为一个“链下预结算层”， 等多笔RGB转账发生后，把一批交易聚合起来，生成一个对应批量交易的Commitment，一次性发布到比特币链上。

具体表现为以下流程图：

BTC资产无需跨链直接与CKB链上资产交互

RGB++ 实现了比特币UTXO与CKB Cell之间的关联映射后，可以直接实现无需资产跨链的互操作。 你可以通过RGB++交易声明，把自己的比特币UTXO转移给别人，对方可以把自己的CKB资产所有权转让给你。这种模式拥有很大的想象空间，结合前面提到的交易折叠（批量交易），理论上可以实现无需BTC资产跨链的BTC——CKB链上资产互操作。

总结

RGB++把存放在不同RGB客户端本地的资产数据，直接用CKB链上的Cell表达出来，再把Cell与比特币链上的UTXO关联起来。用户可以通过比特币账户/资产，与自己在CKB链上的RGB++资产进行交互。这种方式比较简洁，且 解决了RGB协议中 转账需要双方事先通讯、难以支持全局可见的状态、数据存储碎片化、智能合约及Defi不友好等问题。

RGB++无需资产跨链，就可以实现BTC—CKB之间的互操作，且便于RGB资产与Defi场景结合，极大程度解决了RGB协议的易用性问题。但 对于追求高度隐私的RGB小众玩家而言，RGB++本质是以隐私换易用性，一切还要看用户的取舍。 但理论上来讲，隐私问题可以在CKB链上通过引入ZK等方法来解决。

整体而言，RGB++展示了CKB作为一个比特币链下结算层/计算层的潜力，而这种思路会在未来，被越来越多的比特币Layer2或资产协议所采纳， 可以预见的是，比特币链下的第三方结算层间的角逐，或许不久后就会展开。 而主打POW和UTXO、有着多年技术积淀的CKB，或许能够在这场模块化区块链的角逐中表现出自己的技术优势。