极客Web3

2024-07-27 19:32

来源链接

订阅此专栏

收藏此文章

作者：Faust & 雾月，BTCEden

2024 年 7 月，CKB 官宣了 RGB++ Layer 的正式启动，标志着此前发布的 RGB++ 协议彻底从理论落地为工程化产物，并将引入更具体、更实际的应用场景。凭借着在 BTC 与 CKB、Cardano 等泛 UTXO 公链之间构建 BTCFi 生态的愿景，RGB++ Layer 很快成为了人们关注的焦点。

概括来说，RGB++ Layer 以 RGB++ 协议为基础，利用同构绑定和 Leap 技术，为 RGB++ 原生资产或铭文 / 符文在 BTC、CKB、Cardano 等 UTXO 型公链之间提供“无需跨链桥”的全链交互体验；利用 CKB 图灵完备的智能合约环境，为比特币构建从资产发行到实现复杂 DeFi 功能的必要条件。

且由于 RGB++ Layer 背靠 CKB 完备的账户抽象生态，兼容比特币账户和钱包，可以为比特币用户创造良好的体验，为 BTCFi 的大规模采用铺平道路。

下文中，让我们深入理解 RGB++ Layer 的大致工作原理和特性，展望其为 BTCFi 生态带来的改变。由于其理论基础建立在 RGB++ 协议之上，我们将先从协议本身开始讲起。

RGB++ 协议：RGB++ Layer 的理论基石

RGB++ 协议发布于今年 1 月，其核心理念是用 CKB 链上验证的形式，替代 RGB 协议的“客户端验证”，本质是把 CKB 当做去中心化的索引器，将数据存储、资产来源验证等任务交由 CKB 完成，由后者作为 RGB 协议的验证层和 DA 层，以解决 RGB 协议在 UX 上的弊病、不利于支持 Defi 的缺陷。

与“一次性封装”的概念相呼应，RGB++ 引入了同构绑定的概念，以 CKB 链上的拓展型 UTXO——Cell 作为铭文 / 符文类资产的数据载体，再令 Cell 与比特币 /Cardano/Liquid 链上的 UTXO 建立绑定关系，最终让 RGB++ 资产继承比特币等 UTXO 公链的安全性，以防止发生双重支付。

这种“绑定 XXX 以继承 XXX 安全性”的思路，类似于现实中银行账户要绑定手机号和身份证。

举个例子，假设 Alice 要给 BOB 转去一些 TEST 代币，她可以生成一个声明，将存储 TEST 资产信息的 Cell 与 Bob 的比特币 UTXO 绑定起来。如果 Bob 打算再把 TEST 代币转给别人，绑定的比特币 UTXO 也要发生转移。

这样一来，承载 RGB++ 资产数据的 Cell，和比特币 UTXO 之间有 1 对 1 绑定的关系，只要比特币 UTXO 没有被双重消费，绑定的 RGB++ 资产就不会被双花。

说到 RGB++ Layer，它实际是对 RGB++ 协议进行工程化落地的产物，其主打的两大特性，包括同构绑定和 Leap 无桥跨链，下面让我们深入了解下同构绑定和 Leap 的技术实现原理。

同构绑定与 Leap：BTCFi 的资产发行与无桥跨链层

为了真正理解同构绑定和 Leap 的思路，我们先简单说下 CKB 的 Cell 模型。

Cell 实质是拓展型 UTXO，有 LockScript、TypeScript、Data 等多个字段，LockScript 的作用和比特币的锁定脚本类似，用于权限验证；TypeScript 类似于智能合约代码，Data 则用于存放资产数据。

如果你要在 CKB 链上发行 RGB++ 资产，首先要创建一个 Cell，并在相关字段里写好代币符号和合约代码，比如代币符号为 TEST。之后你可以把这些 Cell 拆解，并分发给很多人，就和比特币 UTXO 的拆分和转移方式一样。

由于 Cell 与比特币 UTXO 在结构上相似，且 CKB 可以兼容比特币签名算法，用户可以用比特币钱包操纵 CKB 链上资产。假如你拥有某个 Cell，你可以对锁定脚本进行设置，使解锁条件与比特币 UTXO 的解锁条件一致，这样就可以用比特币账户私钥操纵 CKB 链上的 Cell。

上述特性在 CKB、BTC 和其他 UTXO 公链之间也可以实现，比如你也可以用 Cardano 账户改写 CKB 链上的资产数据，RGB++ 资产的控制权也可以从 BTC 账户转移到 Cardano 账户，而无需跨链桥。下面我们将对这个话题展开解释。

前面我们曾提到，RGB++ 资产需要绑定比特币、Cardano、Liquid 等公链上的 UTXO，类似于现实中银行账户要绑定手机号和身份证；其次，RGB++ 资产本身只是一堆数据，这些数据需要有数据库之类的存储媒介，CKB 链上的 Cell 可以充当其数据库。

然后我们可以在权限验证这块做设置，允许人们用 BTC、Cardano 等不同公链的账户，去改写 CKB 链上的 RGB++ 资产数据。这便是同构绑定的核心宗旨。

RGB++ Layer 提出的“Leap”和无桥跨链，其实是基于同构绑定技术，对 RGB++ 资产绑定的 UTXO 进行“换绑”，比如你的资产之前绑定了比特币 UTXO，现在可以换绑到 Cardano、Liquid、Fuel 等链上的 UTXO，这样就可以把资产控制权限从 BTC 账户转移到 Cardano 账户上。

从用户感知的角度看，这其实等价于资产跨链，CKB 充当了类似于索引器和数据库的角色。但不同于传统的跨链方式，“Leap”只改变资产数据的使用权限，数据本身还是存储在 CKB 链上的，这种方式比 Lock-Mint 模式更简洁，也免去了对映射资产合约的依赖。

以上只是同构绑定和 Leap 的产品效果说明。下面让我们通过具体案例，来理解它们的技术实现思路。

同构绑定的实现方式

让我们来理解下同构绑定的技术实现方式。假设 Alice 有 100 枚 TEST 代币，数据存放在 Cell#0 中，与比特币链上的 UTXO#0 有绑定关系。

现在，Alice 要把 40 枚 TEST 代币转给 Bob。首先，她要把 Cell#0 拆分为两个新的 Cell，其中 Cell#1 包含 40 枚 TEST 代币，转让给 Bob；Cell#2 包含 60 枚 TEST，还是由 Alice 自己控制。

在这个过程中，Cell#0 绑定的 BTC UTXO#0，也要拆分为 UTXO#1 和 UTXO#2，分别与 Cell#1 和 Cell#2 绑定。当 Alice 把 Cell#1 转让给 Bob 时，可以一键操作把 BTC UTXO#1 也转让给 Bob，在 CKB 和 BTC 链上实现同步交易。

我们可以在此深度理解下同构绑定。其实这个概念的核心意义在于，CKB 的 Cell、Cardano 的 eUTXO 和 BTC UTXO 都是 UTXO 模型，且 CKB 兼容比特币 /Cardano 签名算法，后两条链上发生的 UTXO 的分解和转移，也可以 1:1 同步给 CKB 链上的 Cell。

这样一来，当我们对绑定着 RGB++ 资产的 BTC UTXO 进行操作时，可以把操作结果同步给 CKB 链上的 Cell，就好像实体和影子的关系一样。另外我们也要注意，RGB++ 资产关联了 BTC UTXO 和 CKB Cell 这两个实体，两者都是 RGB++ 资产的组成部分，缺一不可。

如果我们考察上面提到的 Alice 给 Bob 转账的案例，其大致流程为：

1. Alice 在本地构造一笔 CKB 交易数据（先不上链），这笔交易指明将记录资产数据的 Cell#0 销毁，生成 Cell#1 送给 Bob，Cell#2 留给自己；

2. Alice 在本地生成一个声明，把 Cell#1 绑定到 BTC UTXO#1，把 Cell#2 绑定到 BTC UTXO#2，并把 Cell#1 和 BTC UTXO#1 都送给 Bob；

3. 之后，Alice 在本地生成一个 Commitment（类似于 hash），对应的原始内容包含第 2 步中的声明 + 第 1 步中生成 CKB 交易数据。Commitment 的数据之后要被记录到比特币链上；

4. Alice 在比特币链上发起交易，把 UTXO#0 销毁，生成 UTXO#1 送给 Bob，UTXO#2 留给自己，并把 Commitment 以 OP_Return 操作码的形式写到比特币链上；

5. 第 4 步完成后，再将第 1 步生成的 CKB 交易发送至 CKB 链上。

上面省略了一些比较复杂的细节。事实上，当 Alice 把自己的 RGB++ 资产转移给 Bob 时，要先进行复杂的身份证明，证明自己的确是 Cell#0 的主人。这里面涉及的事情，包括：

1.证明 Cell#0 和 BTC UTXO#0 的确有绑定关系；

2.Alice 证明自己是 Cell#0 和 BTC UTXO#0 的实际控制者。

要注意，写有 RGB++ 资产数据的 Cell 和比特币 UTXO 可以被比特币账户同步改写，整个交互流程中，通过比特币账户即可完成一键式操作。上述场景不仅限于比特币和 CKB 之间的同构绑定，可以拓展到 Cardano、Liquid、莱特币等广阔的范畴，想象空间还是很大的。

Leap 的实现原理与支持场景

前面我们曾提到，Leap 功能实际就是切换 RGB++ 资产绑定的 UTXO，比如将其从比特币换绑到 Cardano，之后就可以用 Cardano 账户控制 RGB++ 资产。此后你还可以在 Cardano 链上转账，把控制 RGB++ 资产的 UTXO 拆分转移给更多人。

通过这种方式，RGB++ 资产可以在多条 UTXO 公链上转移和分发，但却可以绕开传统跨链桥 Lock-Mint 的模式。在这个过程中，需要由 CKB 公链充当类似于索引器的角色，见证并处理 Leap 请求。

假设你要把 BTC 绑定的 RGB++ 资产转移给 Cardano 账户，最核心的几步无外乎：

1. 在比特币链上发布 Commitment，声明将 BTC UTXO 绑定的 Cell 解绑；

2. 在 Cardano 链上发布 Commitment，声明将 Cell 绑定至 Cardano UTXO；

3. 变更 Cell 的锁定脚本，将解锁条件关联的比特币 UTXO，变为 Cardano 上的 eUTXO。

我们可以注意到，在这整个流程中，RGB++ 资产数据仍然存放在 CKB 链上，只是把解锁条件关联的比特币 UTXO，变更为 Cardano 链上的 eUTXO。当然具体的执行流程比上面说的复杂不少，在此不赘述。

此外在leap 方案中有一个隐性前提，即 CKB 公链作为一种第三方的见证人、索引以及 DA 设施。作为公链其可信度要远超传统跨链桥的 MPC 和多签等方式。

其实基于 Leap 功能还可以实现很有意思的场景，比如我们可以实现“全链交易”。假设我们横跨比特币、Cardano 和 CKB 搭建起索引器，构建一个交易平台，允许买家和卖家交易 RGB++ 资产，买家可以把自己的比特币转给卖家，然后用自己的 Cardano 账户接收 RGB++ 资产。

这个过程中，RGB++ 资产的数据还是记录在 Cell 中，但这个 Cell 会被转移到买家手中，然后其解锁权限从卖家的比特币 UTXO 变更为买家的 Cardano eUTXO。

Wrapper

虽然 Leap 功能对于 RGB++ 资产是完美的，但还是有一些瓶颈：

对于比特币和 Cardano 而言，RGB++ 资产本质是基于 OP_RETURN 操作码的铭文 / 符文 / 染色币。这些公链节点无法感知到 RGB++ 资产的存在，而 CKB 实际上是以索引器的身份从中参与协调。也就是说，对于比特币和 Cardano 而言，RGB++ Layer 主要支持的是铭文 / 符文 / 染色币的 Leap，而不是 BTC、ADA 等原生资产的跨链。

对此，RGB++ Layer 官方引入了 Wrapper，可以简单理解为一种基于欺诈证明和超额质押的桥。以 rBTC wrapper 为例，它将 BTC 桥接到 RGB++ Layer，在 RGB++ Layer 上运行的一组智能合约会监控桥的守护者。如果守护者有恶意行为，他们的抵押物将被 slash。如果守护者串通盗窃锁定的 BTC，rBTC 持有者可以获得全额赔偿。

在结合了 Leap 和 Wrapper 后，BTCFi 生态中的各种资产如 RGB++ 原生资产、BRC20、ARC20、符文等都可以跨到其他层或公链上去。

下图是应用 LeapX 的使用流程的一部分，可以看到它几乎支持了所有 BTCFi 主流资产到不同生态体系的互操作性。并且对不同发行方式的资产都有相应的相应的处理流程，有一部分用的 wrapper，有一部分用的是 leap。

CKB-VM：BTCFi 的智能合约引擎

上面我们主要解释了 RGB++ Layer 的同构绑定与 Leap 概念。下面让我们考察其他的要点。

在传统的 BTCFi 中，由于缺乏智能合约的支持，只能实现一些比较简单的 Dapp，有些实现方法会有一定中心化风险，有些则比较笨拙不灵活。

为了实现在区块链上可用的智能合约层，CKB 为 RGB++ Layer 提供了 CKB-VM，任何能够支持 RISC-V 虚拟机的编程语言都可以用于在 RGB++ Layer 上进行合约开发。开发者可以使用他们偏好的工具和语言，在统一的智能合约框架和执行环境下，实现高效、安全的智能合约的开发与部署。

以下是一段用 C 语言实现的 CKB 中用户自定义代币 UDT 的 transfer 方法。可以看到除了语言不同，其基础逻辑和一般的代币都是相同的。而由于 RISC-V 有广泛的语言和编译器支持，对开发者的智能合约开发入门要求就比较低，我们可以很轻松的用 JavaScript、Rust、Go、Java 和 Ruby 把这段逻辑重写出来，而非必须学习某种 DSL 语言才可以编写合约。

当然，语言只是编程的一个方面，具体的智能合约框架的学习是不可避免的。

原生 AA 生态：无缝衔接 BTC 与 RGB++

最后让我们再简单了解下 RGB++ Layer 背后的原生 AA 与账户抽象生态。由于 BTCFi 本质是为原生的比特币资产提供多样性的 Defi 体验，能否兼容主流比特币钱包将会是 BTCFi 周边设施需要考虑的重要因素，而RGB++ Layer 直接复用了 CKB 的原生 AA 方案，可以在可开发者侧和用户侧都尽量与 BTC 和 Cardano 等重要的 UTXO 公链兼容。

在 RGB++ Layer 中，用户可以使用不同的签名算法进行鉴权。如，用户可以使用 BTC、Cardano 甚至 WebAuthn 等账户、钱包或鉴权方式，直接操纵 RGB++ Layer 上的资产。

我们以下面的钱包中间件 CCC 为例，它可以为钱包和 dApp 提供各种公链对 CKB 的可操作性。

下图是 CCC 的连接窗口。我们可以看到，它支持 Unisat 和 Metamask 等主流钱包入口。

另一个例子是 WebAuthn 的实现，CKB 生态钱包 JoyID 就是典型代表。通过 JoyID，用户可以直接通过生物识别（如指纹或面部识别）方式进行身份验证，实现无缝且高安全性的登录和身份管理。

可以说，同构绑定和 Leap 能够成立的基础就在于 RGB++ Layer 拥有完备的原生 AA 方案，可以很好的兼容其他公链的账户标准，这种特性不但便于支持一些关键场景，同时也可以为 UX 扫清障碍。

总结

在上文中，我们对 RGB++ Layer 的全貌进行了考察，它可以作为铭文 / 符文 / 染色币等各种 Memecoin 的重要基础设施，实现全链交互的场景。而 RGB++ Layer 基于 RiscV 构建的智能合约执行环境，可以为 BTCFi 所需要的复杂业务逻辑创造土壤。

碍于篇幅所限，本文只是对 RGB++ Layer 核心技术的简单科普，并没有对许多复杂的细节进行系统性的科普。未来我们将持续关注 RGB++ Layer 的进展，对该项目相关的一系列技术方案进行更为透彻和深度的解析，大家敬请期待！

【免责声明】市场有风险，投资需谨慎。本文不构成投资建议，用户应考虑本文中的任何意见、观点或结论是否符合其特定状况。据此投资，责任自负。