RGB++ 与同构绑定：CKB、Cardano 与 Fuel 如何赋能比特币生态

撰文：Shew，极客 web3

编辑：Faust，极客 web3

 

摘要：

 

• CKB 团队提出的 RGB++ 资产协议，提出了「同构绑定」的思想，本质是将 CKB 和 Cardano、Fuel 等基于 UTXO 编程模型的区块链，作为承载 RGB 资产「容器」的功能拓展层。这种同构绑定还适用于 Atomical、Runes 等具有 UTXO 特性的比特币生态资产协议，便于为比特币搭建链下的智能合约层。
• RGB++ 协议中，用户不必运行客户端亲自验证交易数据，可以把验证资产有效性、数据存储等工作移交给 CKB 和 Cardanao 等 UTXO 链。只要你「乐观」的认为，上述公链的安全性比较可靠，就无需自己去做验证；
• RGB++ 协议支持用户切换回客户端验证模式，此时你依然可以将 CKB 作为数据存储 /DA 层，不必自己保管数据。RGB++ 协议无需资产跨链，可通过比特币账户对 CKB 链上资产进行操作，并且可以减少往比特币链上发布 Commitment 的频率，也利于支持 Defi 场景；
• 如果是在 EVM 合约体系下，RGB++ 的许多特性并不好支持。综合来看，适合实现同构绑定的公链 / 功能拓展层，应该具有以下特性:

1. 使用 UTXO 模型或类似的状态存储方案；
2. 具有相当的 UTXO 可编程性，允许开发者编写解锁脚本；
3. 存在 UTXO 相关的状态空间，可以存储资产状态；
4. 可以通过智能合约或其他手段，支持运行比特币轻节点；

• 除了 CKB 以外，Cardano、Fuel 也可以支持同构绑定，但后两者在智能合约语言及合约设计细节上，可能存在一些包袱，目前看来，CKB 比后两者更适合作为同构绑定的比特币资产协议功能拓展层。

 

 

正文：在 RGB++Protocol LightPaper 内，Nervos CKB 联合创始人 Cipher 第一次提出了同构绑定的产品思路。相比于其他比特币 Layer2 方案，同构绑定可以更好的兼容 RGB、Runes 和 Atomical 等资产协议，并且可以避免资产跨链等带来额外安全累赘的因素。

 

简单来说，同构绑定是用 CKB 和 Cardano 链上的 UTXO 做「容器」，将 RGB 等 UTXO 型资产表达出来，进而为其添加可编程性及更多更复杂的场景。此前，极客 web3 曾在《从 BTC 到 Sui、ADA 与 Nervos：UTXO 模型及其相关拓展》总结过一系列支持可编程 UTXO 的区块链，本文将进一步探究这些区块链是否可以适配同构绑定方案。

 

RGB++ 和同构绑定

 

在分析不同 UTXO 链对同构绑定的兼容程度前，我们要先介绍一下同构绑定的原理。同构绑定是 CKB 团队在 RGB++ 协议中提出的概念，所以此处我们以 RGB++ 的工作流程，来介绍基于 CKB 的同构绑定是什么。

 

在介绍 RGB++ 协议前，我们先简单了解一下 RGB 协议。RGB 是一种运行在比特币链下的资产协议 /P2P 网络，有点像闪电网络一样。此外，RGB 还是一种基于比特币 UTXO 的寄生资产协议，所谓寄生，是指 RGB 客户端会在比特币链下，声明某些 RGB 资产与比特币链上哪个 UTXO 相绑定，你拥有了这个 UTXO，它绑定的 RGB 资产也归你差遣。

 

RGB 协议和 ERC-20 等资产协议的运作方式截然不同。以太坊上的 ERC-20 合约中，记录了所有用户的资产状态，且以太坊的节点客户端会同步并验证所有的转账信息，把转账后的状态更新记录在资产合约中。这其实早已被人们所熟知，无非是靠以太坊的共识流程，来保证资产的状态变更没猫腻。由于以太坊节点们的共识很可靠，用户就算不运行客户端，也可以默认基于 ERC-20 合约的资产托管平台「没问题」。

 

 

但RGB 协议却很奇葩，它为了增强隐私性，干脆把节点 / 客户端共识这个在区块链世界里约定俗成的东西删掉了。用户要自己运行 RGB 客户端，只接收和存储「与自己相关的资产数据」，看不到别人都干了啥，不像以太坊和 ERC-20 那样，有链上全部可见的转账记录。

 

这种情况下，如果有人给你转来一些 RGB 资产，你事先并不知道这些钱是怎么造出来的，转手自哪些人。如果对面那个人凭空声明一种资产，然后转给你一部分，这种造假币的作恶场景怎么处理？

 

RGB 协议采用了这样一种思路：每一笔转账生效前，接收者先让发送者出示该资产的全部历史记录，比如从创世阶段到现在，这些资产是由谁发行的，中间途经哪些人，在这些人之间发生的每一次资产转移，是否都不违背会计记账准则（一人加，一人减）。

 

这样一来，你就能知道对面给你的是不是「有问题的钱」，所以说 RGB 本质是让交易当事人自己运行客户端做验证，基于客户端验证模式，对应着理性人博弈假设，只要当事人理智，客户端软件没问题，就能保证有问题的资产转移无法生效，或无法被其他人认可。

 

值得注意的是，RGB 协议会把这些比特币链下的交易数据，压缩为 Commitment（本质是个 merkle root），上传到比特币链上，这就让链下的转账记录，与比特币主网直接产生关联。

 

（RGB 协议交互流程图）

 

由于 RGB 客户端之间没有共识，RGB 资产合约的发布无法「极其可靠」的传播给所有节点，合约发布者和用户干脆就通过电子邮件或是推特等任意形式，自发的获知 RGB 资产合约的细节，形式非常随意。

 

下图中展示了恶意的 RGB 资产转移场景，作为 RGB 用户，我们要在自己的客户端本地，存储 RGB 资产对应的智能合约。当其他人向我们转账时，我们根据本地存储的资产合约内容，可以知道当前这笔转账是否违反合约中定义好的规则。根据对面提供的资产来源信息（历史记录），可以确认对方的资产来源有没有问题（是不是凭空声明出来的）。

 

 

复盘上述流程，不难看出，不同的 RGB 客户端接收并存储的数据往往是独立的，你往往不知道别人有哪些资产，有多少数额。反过来，别人基本也不知道你的资产状况。

 

这就是典型的数据孤岛，也就是大家存储的数据都不一致。理论上虽然可以提高隐私程度，但相应的也带来了很多麻烦。你必须在自己的客户端本地维护好 RGB 资产的数据，这些数据一旦丢失，就会造成严重后果（资产不可用）。但事实上，只要你维护好本地数据，RGB 协议就可以为你带来和比特币主网基本等价的安全性。

 

 

此外，RGB 客户端之间通讯用的 Bifrost 协议，会协助用户和其他客户端进行 p2p 通讯，可以把他的资产数据加密后传播给其他节点，叫对方帮忙存储（注意是加密后的数据，对面不知道明文）。只要你不把密钥也弄丢了，在本地数据丢失时，可以通过网络中其他节点，还原出自己原本拥有的资产数据。

 

但原始 RGB 协议的缺点还是很明显，首先每笔交易都要求双方进行多次通讯，接收方要先验证发送方的资产来源，然后发送回执，批准发送方的转账请求。这个过程中，双方之间至少要产生三次消息传递。这种「交互式转账」和大多数人所习惯的「非交互式转账」严重不符合，你能想象，别人要给你转钱，还要把交易数据发给你来检查，得到你的回执消息后，才能完成转账流程吗？（流程图在前文可见）

 

其次，绝大多数的 Defi 场景都需要数据透明、状态可验证的智能合约，但 RGB 协议天生不支持此类场景，所以是对 Defi 非常不友好的；此外，RGB 协议里用户必须去运行客户端做自验证，如果你偶然间接收到一笔转手自几万人的资产，你甚至还要验证这笔资产的几万次转手记录。很显然，所有的事情都让用户去自行解决，并不利于产品本身的推广和采用。

 

对于上述问题，RGB++ 的解决思路是：让用户在客户端自验证模式，与第三方托管模式之间自由切换，用户可以把数据验证与存储、智能合约托管等包袱，甩给 CKB 去承担，当然用户要乐观的信任，CKB 这条 POW 公链是可靠的；如果某些对安全和隐私有更高追求的人，比如手握大量资产的大户，也可以回退到原始的 RGB 模式。这里要强调的是，RGB++ 和原始的 RGB 协议，理论上是可以彼此兼容的，并不是有他无我。

 

（RGB++ 协议交互流程图【简略版】）

 

在此前的文章《从 RGB 到 RGB++：CKB 如何赋能比特币生态资产协议》中，我们曾简单科普过 RGB++ 的「同构绑定」，这里我们再快速的复盘下：

 

CKB 有自己的拓展型 UTXO，叫 Cell，它比 BTC 链上的 UTXO 多出了可编程性。而「同构绑定」，就是将 CKB 链上的 Cell 作为 RGB 资产数据的「容器」，把 RGB 资产的关键参数写入到 Cell 中。

 

 

由于 RGB 资产和比特币 UTXO 存在绑定关系，所以在资产的逻辑形式上具备 UTXO 的特性。而同样具备 UTXO 特性的 Cell，自然适合作为 RGB 资产的「容器」。每当 RGB 资产交易发生时，对应的 Cell 容器，也可以呈现出相似的特征，就像是实体和影子的关系一样，这便是「同构绑定」的精髓。

 

For example，假如 Alice 拥有 100 枚 RGB 代币，以及比特币链上的 UTXO A，同时在 CKB 链上有一个 Cell，这个 Cell 上标记着「RGB Token Balance：100」，解锁条件与 UTXO A 有关联。

 

如果 Alice 想把 30 枚代币送给 Bob，可以先生成一个 Commitment，对应的声明是：把 UTXO A 关联的 RGB 代币，转移 30 枚给 Bob，70 枚转给自己控制的其他 UTXO。

 

之后，Alice 在比特币链上花费 UTXO A，发布上述声明，然后在 CKB 链上发起交易，把承载 100 枚 RGB 代币的 Cell 容器消费掉，生成两个新容器，一个容纳 30 枚代币（给 Bob），一个容纳 70 枚代币（Alice 控制）。在此过程中，验证 Alice 的资产有效性与交易声明有效性的任务，是由 CKB 网络节点走共识来完成的，不需要 Bob 介入。CKB 此时充当了一个比特币链下的验证层与 DA 层。

 

 

这就类似于以太坊 ERC-20 合约每次状态变更，不需要用户去运行客户端验证，道理差不多，由共识协议和节点网络，来替代客户端验证。而且，所有人的 RGB 资产数据都存放在 CKB 链上，具有全局可验证的特性，这利于 Defi 场景的实现，比如流动性池和资产质押协议等。

 

这里面其实引入了一个重要的信任假设：用户往往要乐观的认为，CKB 这条链，或者说由大量节点靠共识协议组成的网络平台，是可靠无误的。如果你不信任 CKB，也可以遵循原始 RGB 协议中的交互式通讯与验证流程，自己运行客户端。

 

当然，如果有人偏要自己运行 RGB++ 客户端，验证别人的资产历史来源，他可以直接验证 CKB 链上与 RGB 资产容器 Cell 相关的历史。只要运行一个 CKB 轻节点，通过接收 Merkle Proof 和 CKB 区块头，就可以确信自己收到的历史数据，没被网络中的恶意攻击者篡改。可以说，CKB 在这里又充当了历史数据存储层。

 

简单来说，同构绑定不但适用于 RGB，还适用于 Runes、Atomical 等各种有 UTXO 特性的资产协议，它把存储在用户客户端本地的资产状态、历史数据，以及对应的智能合约，全部挪给 CKB 或 Cardano 等 UTXO 型公链来存储和托管。上述 UTXO 型资产协议，可以把 CKB 或 Cardano 的 UTXO 模型作为「容器」，借着容器来展现出资产的形态与状况，便于配合智能合约等场景。

 

而且在同构绑定协议下，用户无需跨链即可直接用比特币账户，操作自己在 CKB 等 UTXO 链上的 RGB 资产容器，只需要借助 Cell 的 UTXO 特性，把 Cell 容器的解锁条件设定为与某个比特币地址 / 比特币 UTXO 相关联即可。由于在极客 web3 之前的 RGB++ 科普文中，我们已经对 Cell 的特性进行过解读，所以不在此赘述。

 

 

如果 RGB 资产交易双方信得过 CKB 的安全性，甚至不必频繁的在比特币链上发布 Commitment，可以在许多笔 RGB 转账进行后，再汇总发送一个 Commitment 到比特币链上，这被称为「交易折叠」功能，可以降低使用成本。

 

但需要注意的是，同构绑定采用的「容器」，往往需要支持 UTXO 模型的公链，或是在状态存储上有类似特征的 infra，而 EVM 链显然不太适合，在技术实现上会遇到很多坑。首先，前文提到 RGB++「无需跨链即可操作 CKB 链上资产容器」，基本就无法在 EVM 链身上实现；就算强行实现，成本也可能很高；

 

再者，在 RGB++ 协议中，很多人没有必要运行客户端或是把资产数据存放在本地。如果用 ERC-20 的方式，把所有人的资产余额都记录在这个合约中，假如有人要回退到客户端自验证的模式，他提出要检查某个人的资产来源，此时他就可能要把所有和资产合约产生交互的交易记录，全都扫描一遍，这会带来巨大压力。

 

直白的说，ERC-20 等资产合约，把所有人的资产状态耦合在一起存储，如果你要单独检验其中某个人的资产变更历史记录，将会变得很难，就好像在一个公用的聊天室中，你想知道有哪些人给王刚发过消息，就不得不把整个聊天室里的消息记录顶朝天翻一遍。而 UTXO 就像是一对一的私聊频道，你要查历史记录会很容易。

 

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

 

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

 

当然，我们也希望用于同构绑定的公链具有较强的安全性，另一方面，我们也希望该公链上的 UTXO 解锁条件，应当是可编程的，如此一来，用户就可以直接用 BTC 的签名方案，解锁自己在其他公链上同构绑定的 UTXO，而不需要再更换签名算法。

 

目前，CKB 上 UTXO 的锁定脚本是可编程的，官方对此还兼容了不同公链的签名方案，对于同构绑定而言，CKB 网络基本符合以上几个特性，那其他基于 UTXO 的公链呢？我们对 Fuel 和 Cardano 进行了初步考察，认为他们在理论上都可以支持同构绑定。

 

Fuel：基于 UTXO 的以太坊 OP Rollup

 

Fuel 是一个基于 UTXO 的以太坊 OP Rollup，还是把欺诈证明概念引入以太坊 Layer2 生态的先驱。对于正常的 UTXO 功能支持，Fuel 与 BTC 是基本一致的。

 

 

在 Fuel 将其内部的 UTXO 分为了以下三类:

 

• Input Coin：标准的 UTXO，用于表示用户的资产，具有原生的时间锁，同时允许用户编写解锁脚本 predicate；
• Input Contract：用于合约调用的 UTXO，内部包含合约的状态根和合约资产等数据；
• Input Message：用于传递信息的 UTXO，主要包含信息接受人等字段；

 

当用户花费 UTXO 后会产生以下输出:

 

• Output Coin：用于标准的资产转账；
• Output Contract : 合约交互产生的输出，内部包含合约交互后的状态根；
• Output Contract Created : 一种特殊的 UTXO，是创建合约时产生的输出，内部包含合约的 ID 与状态根；

 

与 CKB 的 Cell 内部包含所有的合约状态不同，Fuel 的 UTXO 实际上并不会携带所有的与交易有关的合约状态。Fuel 仅在 UTXO 内，携带有合约的状态根 Stateroot，也就是状态树的 root。合约的完整状态存储在 Fuel 的状态库内部，由智能合约所拥有。

 

值得一提的是，对于智能合约的状态处理，Fuel 合约与 solidity 合约在思想上一致，甚至在编程的形式上也比较接近。下图展示了一个用 Fuel 的 Sway 语言编写的计数器合约，该合约包含一个计数器，当用户调用 increment_counter 函数时，合约内存储的计数器就自增 1。

 

我们可以看到，Sway 合约的编写逻辑与一般的 Solidity 合约相似，我们首先给出合约的 ABI，然后给出合约的状态变量，然后给出合约的具体实现。所有的代码编写流程并没有涉及到 Fuel 的 UTXO 系统。

 

 

所以，Fuel 的合约编程体验不同于 CKB 和 Cardanao 等 UTXO 型编程语言，Fuel 提供了一种更接近 EVM 智能合约编程开发的体验。开发者也可以使用 Sway 语言构造解锁脚本，以实现特殊的签名算法验证逻辑，或者复杂的多签等解锁逻辑。

 

在 Fuel 内实现同构绑定是基本可行的，但还是存在以下问题:

 

Fuel 使用的 sway 语言，在智能合约设计方面，思想更接近 EVM 链，而不是契合 BTC 或 CKB 和 Cardano，RGB、Atomicals 等 UTXO 型资产的发行者，要在 Fuel 上专门构造一种智能合约，在 CKB 等链上用另一种，这是相当复杂的。

 

Cardano：基于 POS 的 eUTXO 公链

 

Cardaon 是另一个使用 UTXO 模型的区块链，但不同于 Fuel，它是一个 Layer1 公链。Cardano 用 eUTXO（拓展型 UTXO）来称呼其系统内的 UTXO 编程模型。相比于 CKB，Cardano 内的 eUTXO 包含以下几部分结构:

 

• Script:  智能合约，用于验证 UTXO 是否可以被解锁与执行状态转换；
• Redeemers:  用户提供的用于解锁 UTXO 的数据，一般为签名数据，类似于比特币的 Witness；
• Datum:  智能合约的状态空间，可以存储资产状态等数据；
• Transaction Context:  UTXO 交易的上下文数据，如交易的输入参数和结果（UTXO 链的交易计算过程在链下直接进行，把计算结果提交到链上去验证。若通过验证，则交易结果上链）

 

 

开发者可以使用 PlutusCore 语言在 Cardano 链上进行 UTXO 的编程，与 CKB 类似，开发者可以编写解锁脚本和一些用于状态更新的函数。

 

我们以基于 UTXO 的拍卖流程介绍 Cardano 的 UTXO 编程模式。假设我们需要实现一个资产拍卖 DAPP，要求用户可以在拍卖结束前给出报价，具体来说，就是用户消费自己的 UTXO，与此拍卖合约 UTXO，然后生成一个新的拍卖 UTXO。当有人给出更高报价时，除了生成新的拍卖合约 UTXO，也会生成对上一个人的退款 UTXO。具体流程如下图:

 

 

实现上述拍卖流程，需要在拍卖智能合约 UTXO 内存储一些状态，比如当前拍卖的最高价与给出报价的人。下图展示了 PlutusCore 内部的状态声明，我们可以看到，bBidder 和 bAmount 展示了拍卖的报价和给出报价的钱包地址。而 Auction Params 内则包含拍卖的基本信息。

 

 

当用户花费此 UTXO 时，我们可以更新合约内的状态。下图展示了拍卖合约内一些具体的状态更新和业务逻辑。比如校验用户报价和校验当前拍卖是否仍在进行的逻辑。当然，由于 PlutusCore 是 Haskell 编程语言，这是一种纯函数式编程语言，大部分开发者可能无法直接看懂其含义。

 

 

在 Cardano 上构造同构绑定具有可行性，我们可以使用 Datum 存储资产状态，并编写特定的脚本来兼容比特币相关签名算法。但严重的问题是，大部分程序员可能无法适应使用 PlutusCore 进行合约编程，而且其编程环境是较难搭建的，对开发者而言并不友好。

 

总结

 

同构绑定要求链具有以下属性:

 

1. 使用 UTXO 模型
2. 具有相当的 UTXO 可编程性，允许开发者编写解锁脚本
3. 存在 UTXO 相关的状态空间，可以存储资产状态
4. 可以通过智能合约或其他手段，支持运行比特币轻节点

 

Fuel 由于其智能合约编程思想的特殊性，虽然可以兼容同构绑定，但还是会带来一些包袱；而 Cardaon 使用 Haskell 编程语言进行合约编程，大部分开发者很难快速上手。基于上述理由，采用 RISC-V 指令集并在 UTXO 编程的特性上更平衡的 CKB，可能是更适配同构绑定的功能拓展层。