CKB & RGB++

CKB 简介

CKB（Common Knowledge Base） 是 Nervos Network 的 Layer 1 公链，采用 PoW 共识机制，专注于去中心化应用和资产存储。CKB 使用创新的 Cell 模型，类似比特币的 UTXO 模型，但支持灵活的智能合约执行。每个 Cell 可存储状态数据和代码，合约逻辑通过 RISC-V 虚拟机执行。CKB 提供原生多资产支持与链上存储，确保高安全性与去中心化。其经济模型设计为“存储即挖矿”，鼓励长期数据存储与网络安全维护，适合开发 DeFi、NFT 和区块链基础设施。

CKB交易

CKB 的交易数据结构与比特币（BTC）类似，其中的 UTXO 被称为 Cell。每个 Cell 都绑定一个 Lock Script，花费该 Cell 需要解锁对应脚本，设计与比特币基本一致。然而，CKB 的 Lock Script 更加灵活多样，支持复杂的合约逻辑。

在 CKB 中，基础货币 CKB 同时用作手续费。与以太坊（ETH）不同，CKB 的手续费在生成 Cell 时按其容量收取，而不是在执行时收取。为防止死循环等问题，CKB 对每次合约执行设置了 Max Cycle 限制，确保计算资源的使用在安全范围内，避免潜在的 DoS 攻击。

CKB 交易数据结构

参考：https://docs.ckb.dev/docs/rfcs/0022-transaction-structure/0022-transaction-structure.zh

字段	解释
version	交易版本
cell_deps	在这个交易中需要依赖的cell，比如某个cell存储的数据或者代码，并不作为输入
header_deps	在这个交易中需要依赖的区块头
inputs	类似于UTXO中的vins，即消耗的cells
outputs	类似于UTXO中的vouts，即生成的cells
outputs_data	每一个outputcell存储的数据
witness	用于解锁lock脚本，在解锁inputs时会从该字段读取数据

在没有合约调用或数据存储的场景下，即简单转账时，CKB 的交易结构与比特币（BTC）的 UTXO 模型非常相似。以下通过一个示例来解释 CKB 交易中的核心字段：

示例：Alice 向 Bob 转账 100 CKB

1. 收集 UTXO (Cell)** **Alice 首先需要收集自己可以解锁的 Cells，作为交易的输入。每个 Cell 都有两个脚本字段：
   • Lock Script：用于控制该 Cell 的所有权，必须正确解锁才能消费该 Cell。
   • Type Script：用于执行合约逻辑。在简单转账场景中不涉及，后续介绍。
2. Lock Script 解锁机制** **CKB 的 Lock Script 比 BTC 的更灵活，支持多种形式：
   • 类似 BTC 的 P2PKH 签名验证
   • 简单的 Puzzle 解锁
   • 永久锁定（用于存储不可变数据或代码）
3. 在创建 Cell 时，创建者需要指定解锁代码的 Code Hash（指向脚本代码的位置）以及解锁参数（例如，签名算法和公钥）。消费该 Cell 时，交易必须在 Witness 字段中提供对应的解锁证明。
4. 构造交易
   • Inputs 字段：Alice 找到可用的 Cells，将其以 Out Point（即交易 ID 和输出索引）的形式填入 Inputs 字段。
   • Witness 字段：按照 Inputs 中的顺序依次填入解锁证明。
   • Cell Deps 字段：由于 CKB 支持多种类型的 Lock Script，代码存储在链上，为了正确执行解锁逻辑，Alice 需要在 Cell Deps 中指定包含该脚本代码的 Cell。若缺少该 Cell，交易将失败。
   • Outputs 字段：Alice 创建一个 Bob 能解锁的 Cell，并填入交易的 Outputs 字段。

通过上述步骤，Alice 完成了一笔简单的 CKB 转账交易，其结构与 BTC 基本一致，同时保留了更强的扩展能力。

接下来，我们通过一个简单的合约调用场景，阐述 CKB 的可编程属性（对于上述常规逻辑，这里不再赘述）：

示例：类似 ERC20 的合约 UDT（User Defined Token）发行与转账

1. 发行 UDT

在 CKB 中，由于 Cell 模型的约束，合约本身不存储状态，所有数据和代码都以 Cell 的形式存在。为了确保代码和数据的完整性，通常会将存储代码（如 UDT 合约逻辑）和不可变数据（如 UDT 的 symbol、decimal 等配置信息）的 Cells 设为 死锁，避免被随意消耗，确保其持久性。

发行交易的构造：

• Inputs：任意能支付手续费的 Cell。
• Outputs：通常包括以下三个 Cells：
  • 发行 Cell：存储发行的 Token 数量。其 Lock Script 设置为 Issue Lock，Type Script 为 xUDT Type，Data 字段保存发行的 Token 总量。
  • 配置信息 Cell：存储合约的配置信息，如 Symbol 和 Decimal。其 Lock Script 设置为 Issue Lock，Type Script 为 Unique Type，Data 字段存储配置信息。
  • 找零 Cell：返还未使用的 CKB。

由于 UDT 标准已在 CKB 上实现，引用该标准的代码仅需将 Type Script 设置为 xUDT Type。 参考示例：xUDT 发行示例

2. 转账 UDT

• Inputs：保存账户余额的 Cells（如发行步骤中的第一个 Cell）。
• Outputs：一个新的 Cell，表示转账后的账户余额，Lock Script 为接收方的地址，Type Script 为 xUDT Type，Data 字段为转账金额。

RGB++

RGB++ 是基于 RGB 协议，在 Nervos 网络上实现的一种将 BTC 与 CKB 绑定的机制。其核心思想是结合 BTC 的 UTXO 和 OP_RETURN，与 CKB 的 Cell 模型和可编程能力，扩展 BTC 的智能合约功能，构建一种全新的 Layer 2（L2）方案。

在介绍 RGB++ 之前，我们先了解一下 BTC L2 解决方案的背景。

BTC 是一种功能有限但市值庞大的网络，其设计的局限性让智能合约功能显得遥不可及。然而，由于 BTC 的 TVL（锁定总价值）巨大，越来越多的开发者尝试在 BTC 上引入智能合约功能，争取在这片古老的代码中分得一杯羹。

目前主流的 BTC L2 解决方案都存在一定缺陷：

• 闪电网络：扩展BTC 的 功能，但无法发行资产，局限于支付网络。
• 侧链和其他 L2 项目：受限于 BTC 功能，无法去中心化实现跨链桥，只能通过 L2 中发行的代币间接绑定 BTC，如通过 PoX 等机制。

此外，诸如铭文（Ordinals）等资产发行方案多利用 BTC 的 OP_RETURN 和 satoshi 编号。这些方案技术上并不复杂，但由于 BTC 生态的广泛接受和市场认可，使其备受关注。然而，这些资产大多只能在 CEX 中交易，无法真正参与去中心化金融（DeFi）生态。

RGB++ 在此背景下应运而生，其设计灵感来源于 BTC 的 Color Coin 和 RGB 协议。

RGB++做了什么呢，他实现了一套可以在BTC上发行货币的标准，利用BTC的UTXO作为某个货币的所有权，发行货币的具体信息则存储在CKB上，可以在CKB上使得该种货币参与Defi，与此同时可以“无缝”的让货币在BTC和CKB上流通。

• 在 BTC 上原生发行资产：通过 BTC 的 UTXO 表示代币所有权，资产信息存储在 CKB 上。
• 跨链流通与 DeFi 集成：通过 Nervos 网络的可编程性，实现资产在 BTC 和 CKB 之间的无缝转移，支持 DeFi 场景。
• 安全性与互操作性：BTC 提供资产安全性，CKB 提供智能合约支持。

通过这种方式，RGB++ 实现了比传统 L2 更灵活的资产发行与流通方案。

RGB++原理

每一项技术的诞生都旨在解决特定的问题，RGB++ 也不例外。

在 BTC 上发行资产时，常见方案是使用 OP_RETURN 作为验证和存储字段。然而，这种方式存在显著限制，尤其是在双花攻击防范方面。由于 BTC 本身缺乏智能合约支持，很难确保一笔存款不会被同时花费给两个不同的接收方。

RGB 的核心思想：一次性密封

为了解决这个问题，RGB 协议被提出，其核心概念是“一次性密封”。这一思想将资产比作密封在文件夹中的文件，文件只能被打开一次，使用后需要重新密封。通过这种机制，可以有效防止双花问题。

实际上，这一机制与 BTC 的 UTXO 模型极为相似：每个 UTXO 只能被消费一次，消费后会被视为“已花费”，类似于“密封已打开”的状态。（这一思想在 2016 年提出，但具体含义可能因背景不同而略有差异。）

尽管 RGB 协议构想精妙，但在实践中遇到了一些难以克服的挑战：

1. 数据可用性（DA）：BTC 本身无法提供充足的数据可用性。
2. 智能合约支持：BTC 没有内置合约功能，难以实现复杂逻辑。
3. 点对点（P2P）网络支持：BTC 网络缺乏灵活的数据分发机制。

RGB++ 的解决方案

为弥补这些不足，RGB++ 应运而生，通过引入 Nervos CKB 提供的功能，解决了上述难题：

1. 数据可用性（DA）：在 CKB 上部署了一个 BTC 轻节点，确保数据可用性。
2. 智能合约支持：CKB 的灵活智能合约模型满足复杂逻辑需求。
3. P2P 网络支持：CKB 提供了原生的 P2P 网络功能，便于数据共享与传播。

通过这些设计，RGB++ 成为了一种能够在 BTC 上安全发行资产的创新方案，既继承了 BTC 网络的安全性，又借助 CKB 的可扩展性和编程能力，成功构建了一个强大的跨链资产发行与管理系统。

RGB++实现

RGB++ 的实现主要依赖于“同构绑定”思想，其核心目标是将 BTC 的 UTXO 与 CKB 的 UTXO 进行绑定。

以发行新的 Token 为例：

在 CKB 上发行的 Token 在 Cell 模型框架下管理，只有能够解锁该 Token 对应 Cell 的 lock script 才能花费该 Token。通常情况下，Token 的转账与所有权管理都发生在 CKB 上。

RGB++ 引入了 RGB++ Lock 和 BTC Time Lock 两种新的 lock script，使 CKB 上的某个 Cell 可以与 BTC 的某个 UTXO 绑定。

用户可以将某一包含 Token 的 Cell 的解锁条件设定为拥有指定 BTC UTXO 所有权的用户，只有成功证明花费了该 BTC UTXO，才能在 CKB 上花费该 Cell 中的 Token。该锁定脚本类型即为 RGB++ Lock。

当用户希望将 RGB++ 类型的 Cell 解锁，并将所有权转移到 CKB 链内（即后续验证不再依赖 BTC 侧，转变为普通的 Token 形式），需要在 inputs 中包含对应的 RGB++ Cell，在 outputs 中提供一个 BTC Time Lock 类型的 Cell，证明该交易已在 BTC 被花费并确认（通常等待 6 个区块）。

为实现同构绑定，RGB++ 协议规定，在解锁 RGB++ Lock 类型的 Cell 时，需要同时在 CKB 和 BTC 上提交两笔交易：

• btc_tx：在 BTC 链上的交易，花费指定的 BTC UTXO。
• ckb_tx：在 CKB 链上的交易，解锁对应的 RGB++ Token Cell。

如上图所示，在 btc_tx 中：

• vin：需要包含解锁 CKB 对应 UTXO 的输入。
• vout：其 index = 0 的位置需包含一个 opreturn 类型的输出，该输出中存储一个 32 字节的 commitment。

该 commitment 包含部分 ckb_tx 信息（由于 btc_tx 尚未上链，未生成 tx_id，因此 ckb_tx 中缺少部分信息，需延后补充）。此 commitment 用于证明 btc_tx 与 ckb_tx 的关联关系，并以哈希形式存储在 opreturn 中。

此外，vout 中还需加入一个新的 UTXO，表示：

• 被花费的 BTC UTXO 的证明（即 BTC Time Lock）。
• 或表示 CKB 链上某个 Cell 锚定的 UTXO 转移。

关于 commitment 的具体计算方式，由于当前 RGB++ 文档尚不完善（Light Paper 与 Lock Script Design 存在描述冲突），因此无法提供更详细的内容。

完成 commitment 计算后，需要将 btc_tx 上链。待生成 tx_id 后，补全 ckb_tx 信息，并在 CKB 上发送该交易。

通过此设计，RGB++ 可实现 CKB 上资产与 BTC UTXO 的绑定，并在 CKB 与 BTC 之间灵活转换。

交易分析

在 RGB++ 框架下发行的资产支持四种主要操作：

1. Transfer on L2（在 CKB 上转账）： 在 CKB 上进行资产转账，与常规的 Token 转账流程无异。
2. Transfer on L1（在 BTC 上转账）： 本质上是将 CKB 资产的锚定 UTXO 从原持有者 A 转移到新持有者 B。此类交易的输入与输出资产均使用 RGB++ lock。
3. Leap from L1 to L2（从 L1 跳跃到 L2）： 将由 BTC UTXO 控制的 CKB 资产转变为由 CKB 自主控制的资产（退化为普通 Token）。该操作的输入资产为 RGB++ lock，输出资产为 BTC time lock。
4. Leap from L2 to L1（从 L2 跳跃到 L1）： 将 CKB 上的资产转变为由 BTC UTXO 锚定和控制的资产。输入资产不需要 RGB++ lock（可以是普通锁，或 BTC time lock），而输出资产必须使用 RGB++ lock。

我们以一系列实际发生的交易为例来阐述这些概念并分析其原理。

Transfer on L2

在 CKB 上进行资产转账，与常规的 Token 转账流程无异。这里不再赘述。

Transfer on L1

交易示例： CKB 交易链接

该交易展示了 CKB 上的 DOB 资产从原有控制 UTXO 转移到新的控制 UTXO 的过程：

• 原控制 UTXO（UTXO 0）: BTC 交易 0d0768bfe9d8… 此 UTXO 原本控制着 CKB 链上的 DOB 资产。
• 转移后控制 UTXO（UTXO 1）: BTC 交易 9b881cede655… 在该交易执行后，资产控制权从 UTXO 0 成功转移至 UTXO 1。

在这笔交易中，我们可以看到该交易有两个cell。

其中第一个cell为输入，是UTXO 0的解锁信息，点击cell info即可查看该cell的信息。

{

“code_hash”: “0xbc6c568a1a0d0a09f6844dc9d74ddb4343c32143ff25f727c59edf4fb72d6936”,

“args”: “0x02000000b92dc7d93a4f8d09130860bcb90cbad9c40faae0373ba2eb9b94d8e9bf68070d”,

“hash_type”: “type”

}

该 lock script 包含以下三个字段：

1. code_hash：指向 RGB++ lock script 的代码哈希值。
2. hash_type：表示 lock script 的类型，通常为 “type”。
3. args：解锁脚本所需的参数，其内容实际上对应 UTXO 0，采用小端形式表示。该参数的低位是 BTC 交易哈希 btc_tx_id，高位是 UTXO 0 在该交易中的 vout 下标。在本例中，BTC 交易哈希为 0d0768bfe9d8949beba23b37e0aa0fc4d9ba0cb9bc600813098d4f3ad9c72db9，而 vout 下标为 2。

为了证明该 UTXO 0 已被正确花费，需要在 CKB 交易的 witness 字段中提供相应的证明，格式同样采用小端表示。

由于 RGB++ lock script 尚未开源，witness 字段的解码方案也未公开，因此该部分的具体内容暂时无法深入解释。

第二个cell为输出，包含了两个内容：第一个内容为解锁脚本，其内容与第一个cell类似，区别在于将参数指定为了 UTXO 1；第二个参数为输出cell 类型，用于存储资产信息，这里不过多介绍。

此时，我们查看与该 CKB 交易对应的 BTC 交易。根据前述描述，可以推断出该 BTC 交易即为包含 UTXO 1 的 BTC 交易：

BTC 交易链接

该 BTC 交易包含两个输入和五个输出。值得注意的是，只有价值为 546 satoshi 的 UTXO 才与 RGB++ 相关。

• 第二个输入：对应 UTXO 0，是 BTC 交易中的输入。
• 第一个输出：为 op_return 类型的 commitment，包含 CKB 交易部分内容的哈希。
• 第三个输出（下标为 2）：即为 UTXO 1，表示资产的控制权转移。

Leap From L1

交易示例: CKB 交易链接

该交易由两个 cell 构成：

• 第一个 cell：作为 RGB++ lock 的资产输入，其验证与解锁过程与前述示例一致，不再赘述。
• 第二个 cell：为 BTC time lock 类型的输出 cell。

第二个 cell 的锁定脚本

{

“code_hash”: “0x70d64497a075bd651e98ac030455ea200637ee325a12ad08aff03f1a117e5a62”,

“args”: “0x7f000000100000005b0000005f0000004b000000100000003000000031000000d00c84f0ec8fd441c38bc3f87a371f547190f2fcff88e642bc5bf54b9e3183230116000000000142e95c1d92eb12950161b52b671ff0a9820f0b360600000045babaa47e4b8cc3310677057848128f8fb933d37bc789cb841d23cfdcd1675a”,

“hash_type”: “type”

}

其中：

• code_hash：指向 BTC time lock 解锁脚本。
• args：解码后的内容如下：

script: {

“codeHash”: “0xd00c84f0ec8fd441c38bc3f87a371f547190f2fcff88e642bc5bf54b9e318323”,

“hashType”: “type”,

“args”: “0x16000000000142e95c1d92eb12950161b52b671ff0a9820f0b36”

}

after: 6

txid: 5a67d1dccf231d84cb89c77bd333b98f8f12487805770631c38c4b7ea4baba45

• script：指向该 cell 资产的脚本与参数信息：脚本链接
• txid：对应的 BTC 交易：BTC 交易链接

查看txid对应的BTC交易信息，该 BTC 交易的输入包含了 RGB++ lock 所对应的 UTXO（价值 546 satoshi）。vout中第一个UTXO输出为 op_return 类型的 commitment，用以链接 CKB 交易。

该交易证明了原本锚定 CKB 上资产的 UTXO 已被花费。根据协议，需等待 6 个区块确认后，该资产才可被解锁。

与此BTC time lock 对应的 cell 的解锁交易链接：CKB 交易链接

用户在 witness 字段中提供了 BTC time lock 中 BTC 交易的确认证明，表明资产已成功被释放，完全受 CKB 控制。

Leap From L2

示例交易: CKB 交易链接

该交易的输入未包含 RGB++ lock 类型的 cell，而输出包含一个 RGB++ lock 类型的 cell。 由于该锁定脚本的生成过程已在前述章节详细描述，此处不再赘述。

参考资料

https://github.com/utxostack/RGBPlusPlus-design/blob/main/docs/lockscript-design-prd-cn.md

https://github.com/utxostack/RGBPlusPlus-design/blob/main/docs/light-paper-cn.md

https://docs.ckb.dev/

https://talk.nervos.org/t/rgb-protocol-light-paper/7733