RGB++ 的 “同构绑定”,如何赋能 RGB、Atomical 和 Runes 等比特币生态资产协议
编辑:Faust,极客 Web3
![](https://web3caff.com/wp-content/uploads/2024/03/image-497.png)
摘要:· 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 比后两者更适合作为同构绑定的比特币资产协议功能拓展层。
![](https://web3caff.com/wp-content/uploads/2024/03/image-496.png)
正文:在 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 合约的资产托管平台 “没问题”。
![](https://web3caff.com/wp-content/uploads/2024/03/image-495.png)
但 RGB 协议却很奇葩,它为了增强隐私性,干脆把节点/客户端共识这个在区块链世界里约定俗成的东西删掉了。用户要自己运行 RGB 客户端,只接收和存储 “与自己相关的资产数据”,看不到别人都干了啥,不像以太坊和 ERC-20 那样,有链上全部可见的转账记录。
这种情况下,如果有人给你转来一些 RGB 资产,你事先并不知道这些钱是怎么造出来的,转手自哪些人。如果对面那个人凭空声明一种资产,然后转给你一部分,这种造假币的作恶场景怎么处理?
RGB 协议采用了这样一种思路:每一笔转账生效前,接收者先让发送者出示该资产的全部历史记录,比如从创世阶段到现在,这些资产是由谁发行的,中间途经哪些人,在这些人之间发生的每一次资产转移,是否都不违背会计记账准则(一人加,一人减)。
这样一来,你就能知道对面给你的是不是 “有问题的钱”,所以说 RGB 本质是让交易当事人自己运行客户端做验证,基于客户端验证模式,对应着理性人博弈假设,只要当事人理智,客户端软件没问题,就能保证有问题的资产转移无法生效,或无法被其他人认可。
值得注意的是,RGB 协议会把这些比特币链下的交易数据,压缩为 Commitment(本质是个 merkle root),上传到比特币链上,这就让链下的转账记录,与比特币主网直接产生关联。
![](https://web3caff.com/wp-content/uploads/2024/03/image-494.png)
由于 RGB 客户端之间没有共识,RGB 资产合约的发布无法 “极其可靠” 的传播给所有节点,合约发布者和用户干脆就通过电子邮件或是推特等任意形式,自发的获知 RGB 资产合约的细节,形式非常随意。
下图中展示了恶意的 RGB 资产转移场景,作为 RGB 用户,我们要在自己的客户端本地,存储 RGB 资产对应的智能合约。当其他人向我们转账时,我们根据本地存储的资产合约内容,可以知道当前这笔转账是否违反合约中定义好的规则。根据对面提供的资产来源信息(历史记录),可以确认对方的资产来源有没有问题(是不是凭空声明出来的)。
![](https://web3caff.com/wp-content/uploads/2024/03/image-493.png)
复盘上述流程,不难看出,不同的 RGB 客户端接收并存储的数据往往是独立的,你往往不知道别人有哪些资产,有多少数额。反过来,别人基本也不知道你的资产状况。
这就是典型的数据孤岛,也就是大家存储的数据都不一致。理论上虽然可以提高隐私程度,但相应的也带来了很多麻烦。你必须在自己的客户端本地维护好 RGB 资产的数据,这些数据一旦丢失,就会造成严重后果(资产不可用)。但事实上,只要你维护好本地数据,RGB 协议就可以为你带来和比特币主网基本等价的安全性。
![](https://web3caff.com/wp-content/uploads/2024/03/image-492.png)
此外,RGB 客户端之间通讯用的 Bifrost 协议,会协助用户和其他客户端进行 p2p 通讯,可以把他的资产数据加密后传播给其他节点,叫对方帮忙存储(注意是加密后的数据,对面不知道明文)。只要你不把密钥也弄丢了,在本地数据丢失时,可以通过网络中其他节点,还原出自己原本拥有的资产数据。
但原始 RGB 协议的缺点还是很明显,首先每笔交易都要求双方进行多次通讯,接收方要先验证发送方的资产来源,然后发送回执,批准发送方的转账请求。这个过程中,双方之间至少要产生三次消息传递。这种 “交互式转账” 和大多数人所习惯的 “非交互式转账” 严重不符合,你能想象,别人要给你转钱,还要把交易数据发给你来检查,得到你的回执消息后,才能完成转账流程吗?(流程图在前文可见)
其次,绝大多数的 Defi 场景都需要数据透明、状态可验证的智能合约,但 RGB 协议天生不支持此类场景,所以是对 Defi 非常不友好的;此外,RGB 协议里用户必须去运行客户端做自验证,如果你偶然间接收到一笔转手自几万人的资产,你甚至还要验证这笔资产的几万次转手记录。很显然,所有的事情都让用户去自行解决,并不利于产品本身的推广和采用。
对于上述问题,RGB++的解决思路是:让用户在客户端自验证模式,与第三方托管模式之间自由切换,用户可以把数据验证与存储、智能合约托管等包袱,甩给 CKB 去承担,当然用户要乐观的信任,CKB 这条 POW 公链是可靠的;如果某些对安全和隐私有更高追求的人,比如手握大量资产的大户,也可以回退到原始的 RGB 模式。这里要强调的是,RGB++和原始的 RGB 协议,理论上是可以彼此兼容的,并不是有他无我。
![](https://web3caff.com/wp-content/uploads/2024/03/image-491.png)
在此前的文章 《从 RGB 到 RGB++:CKB 如何赋能比特币生态资产协议》中,我们曾简单科普过 RGB++的 “同构绑定”,这里我们再快速的复盘下:
CKB 有自己的拓展型 UTXO,叫 Cell,它比 BTC 链上的 UTXO 多出了可编程性。而 “同构绑定”,就是将 CKB 链上的 Cell 作为 RGB 资产数据的 “容器”,把 RGB 资产的关键参数写入到 Cell 中。
![](https://web3caff.com/wp-content/uploads/2024/03/image-490.png)
由于 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 层。
![](https://web3caff.com/wp-content/uploads/2024/03/image-489.png)
这就类似于以太坊 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 的特性进行过解读,所以不在此赘述。
![](https://web3caff.com/wp-content/uploads/2024/03/image-488.png)
如果 RGB 资产交易双方信得过 CKB 的安全性,甚至不必频繁的在比特币链上发布 Commitment,可以在许多笔 RGB 转账进行后,再汇总发送一个 Commitment 到比特币链上,这被称为 “交易折叠” 功能,可以降低使用成本。
但需要注意的是,同构绑定采用的 “容器”,往往需要支持 UTXO 模型的公链,或是在状态存储上有类似特征的 infra,而 EVM 链显然不太适合,在技术实现上会遇到很多坑。首先,前文提到 RGB++“无需跨链即可操作 CKB 链上资产容器”,基本就无法在 EVM 链身上实现;就算强行实现,成本也可能很高;
再者,在 RGB++协议中,很多人没有必要运行客户端或是把资产数据存放在本地。如果用 ERC-20 的方式,把所有人的资产余额都记录在这个合约中,假如有人要回退到客户端自验证的模式,他提出要检查某个人的资产来源,此时他就可能要把所有和资产合约产生交互的交易记录,全都扫描一遍,这会带来巨大压力。
直白的说,ERC-20 等资产合约,把所有人的资产状态耦合在一起存储,如果你要单独检验其中某个人的资产变更历史记录,将会变得很难,就好像在一个公用的聊天室中,你想知道有哪些人给王刚发过消息,就不得不把整个聊天室里的消息记录顶朝天翻一遍。而 UTXO 就像是一对一的私聊频道,你要查历史记录会很容易。
综合来看,适合实现同构绑定的公链/功能拓展层,应该具有以下特性:
- 使用 UTXO 模型或类似的状态存储方案;
- 具有相当的 UTXO 可编程性,允许开发者编写解锁脚本;
- 存在 UTXO 相关的状态空间,可以存储资产状态;
- 存在比特币相关桥或者轻节点;
当然,我们也希望用于同构绑定的公链具有较强的安全性,另一方面,我们也希望该公链上的 UTXO 解锁条件,应当是可编程的,如此一来,用户就可以直接用 BTC 的签名方案,解锁自己在其他公链上同构绑定的 UTXO,而不需要再更换签名算法。
目前,CKB 上 UTXO 的锁定脚本是可编程的,官方对此还兼容了不同公链的签名方案,对于同构绑定而言,CKB 网络基本符合以上几个特性,那其他基于 UTXO 的公链呢?我们对 Fuel 和 Cardano 进行了初步考察,认为他们在理论上都可以支持同构绑定。
Fuel:基于 UTXO 的以太坊 OP Rollup
Fuel 是一个基于 UTXO 的以太坊 OP Rollup,还是把欺诈证明概念引入以太坊 Layer2 生态的先驱。对于正常的 UTXO 功能支持,Fuel 与 BTC 是基本一致的。
![](https://web3caff.com/wp-content/uploads/2024/03/image-487.png)
在 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 系统。
![](https://web3caff.com/wp-content/uploads/2024/03/image-486.png)
所以,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 链的交易计算过程在链下直接进行,把计算结果提交到链上去验证。若通过验证,则交易结果上链)
![](https://web3caff.com/wp-content/uploads/2024/03/image-485.png)
开发者可以使用 PlutusCore 语言在 Cardano 链上进行 UTXO 的编程,与 CKB 类似,开发者可以编写解锁脚本和一些用于状态更新的函数。
我们以基于 UTXO 的拍卖流程介绍 Cardano 的 UTXO 编程模式。假设我们需要实现一个资产拍卖 DAPP,要求用户可以在拍卖结束前给出报价,具体来说,就是用户消费自己的 UTXO,与此拍卖合约 UTXO,然后生成一个新的拍卖 UTXO。当有人给出更高报价时,除了生成新的拍卖合约 UTXO,也会生成对上一个人的退款 UTXO。具体流程如下图:
![](https://web3caff.com/wp-content/uploads/2024/03/image-484.png)
实现上述拍卖流程,需要在拍卖智能合约 UTXO 内存储一些状态,比如当前拍卖的最高价与给出报价的人。下图展示了 PlutusCore 内部的状态声明,我们可以看到,bBidder 和 bAmount 展示了拍卖的报价和给出报价的钱包地址。而 Auction Params 内则包含拍卖的基本信息。
![](https://web3caff.com/wp-content/uploads/2024/03/image-483.png)
当用户花费此 UTXO 时,我们可以更新合约内的状态。下图展示了拍卖合约内一些具体的状态更新和业务逻辑。比如校验用户报价和校验当前拍卖是否仍在进行的逻辑。当然,由于 PlutusCore 是 Haskell 编程语言,这是一种纯函数式编程语言,大部分开发者可能无法直接看懂其含义。
![](https://web3caff.com/wp-content/uploads/2024/03/image-482.png)
在 Cardano 上构造同构绑定具有可行性,我们可以使用 Datum 存储资产状态,并编写特定的脚本来兼容比特币相关签名算法。但严重的问题是,大部分程序员可能无法适应使用 PlutusCore 进行合约编程,而且其编程环境是较难搭建的,对开发者而言并不友好。
总结
同构绑定要求链具有以下属性:
- 使用 UTXO 模型
- 具有相当的 UTXO 可编程性,允许开发者编写解锁脚本
- 存在 UTXO 相关的状态空间,可以存储资产状态
- 可以通过智能合约或其他手段,支持运行比特币轻节点
Fuel 由于其智能合约编程思想的特殊性,虽然可以兼容同构绑定,但还是会带来一些包袱;而 Cardaon 使用 Haskell 编程语言进行合约编程,大部分开发者很难快速上手。基于上述理由,采用 RISC-V 指令集并在 UTXO 编程的特性上更平衡的 CKB,可能是更适配同构绑定的功能拓展层。
免责声明:作为区块链信息平台,本站所发布文章仅代表作者及嘉宾个人观点,与 Web3Caff 立场无关。文章内的信息仅供参考,均不构成任何投资建议及要约,并请您遵守所在国家或地区的相关法律法规。