注：本文来自@Yang1127LI 推特，火星财经整理如下：

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网络保证

----- （以下来自CKB自己的描述）

"但由于开篇提出的 PoW 安全的非线性特性，24个区块的 ckb 确认即可等价于 6 确认的 BTC 确认，因此我们也可以说 L2 交易安全性与 L1 交易安全性等价(需要更多区块确认，但事实上更短确认时间)

能做到这一点的前提是 RGB++ 的同构映射链必须是 PoW 的，如果它是 PoS 的链, 无论等待多少个区块, 它安全性上限都是 PoS 的 stake 量, 无法与 Bitcoin 安全性等价"

--------

个人理解: 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上存在于代码和状态中 通过同构映射绑定)