RGB++ 中的 Cell 模型以及 L1 和 L2 交易是什么? RGB++ 是如何不依赖跨链桥实现"资产跨链"的?

TL DR:

CKB 的基础组成元素是 Cell 全部的 Cell 构成了全部的状态 在 RGB++ 中 交易分为两种: L1交易和L2交易 他们交易消耗的 UTXO 不同 也就是权限控制的来源不同 安全性等级也不同*(这个定义可能有争议)

RGB++ 通过同构映射让 BTC 的权限验证可以在 CKB上 进行 通过Jump 操作 完成无需多签钱包和跨链桥的"资产跨链" 用户可以自己选择在 L1 还是 L2 来操作 RGB++ 资产

1. Cell模型

我们之前提到过RGB++中对于BTC和CKB上的资产关联是通过"同构映射"(或者叫"同构绑定" \<isomorphic binding>)来完成的 顾名思义 同构 = 同为PoW+UTXO系统 但准确来说 CKB是一种基于Cell的模型(扩展版的UTXO) 一个Cell是CKB网络中的基本单元 结构体如下

BTC UTXO 的输出中包含数量 nValue 和解锁脚本 scriptPubkey 而 Cell 中把它们分别做了扩展

- nValue => capacity + data
- scriptPubkey => lock + type_ 

capacity 是一个整数，表示这块空间有多大(以字节数为单位) data 则是保存状态的地方, 可以写入任意的一段字节 lock表达的是这块共识空间的所有者是谁 - 只有能提供参数(例如签名)使得 lock脚本成功执行的人，才能“更新”这个Cell中的状态 type定义了data中保存的数据在状态迁移过程中必须要遵守的规则

CKB中存在着许许多多的Cells, 所有这些Cell的集合形成了CKB完整的当前状态 (类比以太坊就是所有账户的所有状态组成了世界状态) 每次交易都会"销毁"一些Cells 再创建一些新的Cells

类似于"销毁"BTC UTXO的流程 Cell中的lock部分会验证使用者的权限 然后根据type里定义的规则 以及capacity里限制的空间做一些检查 最后完成对data的更改

2. RGB++里面的L1交易和L2交易

RGB++ 中 L1 交易是指 RGB++ 交易的 UTXO 持有人是一个 BTC 的 UTXO 也就是 Cell 的权限检查是来自于 BTC UTXO aka. 只有BTC UTXO的所有者&消费了BTC的UTXO才能完成在CKB上的状态更新

这种情况下 每一笔RGB++交易依然在CKB上会同步发起一笔交易 但安全性保证完全来自于BTC L1 CKB此时只是作为数据可用性和状态公示层来使用 省去大家自己维护客户端数据的过程 安全等级: RGB++ L1 === RGB === BTC

而RGB++的L2交易是指100%发生在CKB上的交易 它的安全性100%由CKB网络保证 "但由于开篇提出的 PoW 安全的非线性特性，24个区块的 ckb 确认即可等价于 6 确认的 BTC 确认，因此我们也可以说 L2 交易安全性与 L1 交易安全性等价(需要更多区块确认，但事实上更短确认时间) 能做到这一点的前提是 RGB++ 的同构映射链必须是 PoW 的，如果它是 PoS 的链, 无论等待多少个区块, 它安全性上限都是 PoS 的 stake 量, 无法与 Bitcoin 安全性等价" ----- 来自CKB自己的描述

L2交易的安全性等价BTC 指的是CKB网络本身很安全 而不是它继承了同等级的BTC安全 -------- 个人理解

安全等级: RGB++ L2 == CKB ==? BTC

3. Jump操作

"RGB++ 协议中用户的资产既可以在 Bitcoin 上流转, 也可以随时到 CKB 上流转, 或者反向操作. 在切换的过程不需要跨链桥，更不需要信任任何多签方"

Jump 操作简单来讲 就是把 Cell中UTXO 的鉴权从 BTC L1 转移到 CKB 上

完成之后 对于这种资产的后续操作就从一笔 L1 交易变成了一笔 L2 交易 而这里的安全性核心是Jump过程本身怎么在不需要跨链桥的情况下保证安全

RGB++ 交易的信息在 L1 中表现为 Commitment 在L2中表现为data 安全就是 在 CKB 和 BTC 上的两笔互为同构映射的交易都正确地执行 并且获得了确认/交易确定性(finalized)

这之中唯一的风险就是 BTC 交易的 revert 可能性 会导致这个Jump 操作无法完成

如图中所示 如果 BTC 上的 TX A被 revert 并换成了包含不同的 utxo 收款的交易信息 那么在 CKB 上新的同构绑定交易(TX B') 便无法通过 CKB 上的验证 因为之前的同构绑定交易(TX B)已经尝试使用了 btc_utxo#1 无法再次使用 这样的话 交易中涉及到的 RGB++ 资产将被永久锁定 这时我们还要确保生成的 CKB Cell (也就是未来如果 Jump 成功 将被使用来构建 L2 交易的 Cell )也被正确的锁定 所以在 CKB Cell 中也加入了解锁条件: 在 BTC 中交易经过一定区块数量(6)的确认后才能解锁

在上面的例子中 BTC TX A已经被revert替换 所以这个CKB Cell的解锁条件无法满足 这个Cell也就永远被锁定了

所以一个正常的Jump操作需要 在 BTC 和 CKB 上分别等待对应数量的区块数 来确保最终性和安全性

4. 总结

结合 Cell 模型 L1 和 L2 交易的定义 以及Jump操作 总结以下几点

• L1交易就是由BTC账户发起控制的RGB++交易 这种交易中涉及到的CKB Cell的解锁条件是BTC网络中的UTXO 拥有等同于BTC的安全等级
• L2交易是纯粹的CKB交易 这种交易中涉及到的CKB Cell的解锁条件是CKB网络中的UTXO 拥有CKB网络的安全等级
• Jump操作就是转移了CKB Cell里的解锁条件/鉴权 Jump跨链之前 操作属于L1交易 Jump跨链之后 操作便开始属于L2交易 Jump并没有"转移资产" 而是转移了资产的控制方式 因为 资产始终同时存在于两条链上(BTC上存在Commitment中 CKB上存在于代码和状态中 通过同构映射绑定)

PS: 关于L2交易的部分 自己可能理解不准确 欢迎指正