# 从 CKB 视角看 RGB ## Metadata **Status**:: #x **Zettel**:: #zettel/fleeting **Created**:: [[2024-02-20]] **Topic**:: [[♯ CKB]] ## Synopsis 最近 [RGB++](https://talk.nervos.org/t/rgb-protocol-light-paper/7733) 是 CKB 社区一个很火的话题。为了弄清楚什么是 RGB++，先要了解一下 RGB。 在读了一些背景介绍和相关的描述文档之后，个人觉得讲得最清楚的是这一篇：[RGB Design](https://docs.rgb.info/design)。 在 RGB 中很重要的一个概念就是一次性封条 (Single-use seals)，而最流行的实现是使用 UTXO 作为一次性封条。这种作法可以理解为是加了一层代理，用户不是直接持有资产，而是持有 UTXOs，而这个 UTXO 代表了对资产进行处置的各种权力。这样转称资产实际上就只需要把处置权从当前所有者的 UTXO 转移到新的所有者的 UTXO 上即可。因为 UTXO 用后即焚的特性保证了处理权不能被多次转移，这也是为什么叫一次性封条。 如果经常参加一些 CKB 合约设计模式的讨论，通过 UTXO 代理所有权不是一个新概率。最近的比如说像 Spore 这种应用如果在 Cell 中存储了二进制大的数据时，支持转让 Cell 本身因为需要在新的 Cell 中重复 data，导致 tx 体积会很大，那通过加一层所有权的代理就可以解决这个问题。 如果资产和 UTXO 都使用 CKB 的话，所有权代理有一种很简单的实际方法。 - 实现一个 lock script，它的 args 是一个 hash，解锁条件是当前 tx 中存在一个 input，它的 type script hash 等于 args 中指定的 hash。不防称该 lock script 为 delegate lock。 - 创建一个 ownership cell，使用 type id 作为 type script，这样保证 type script hash 的唯一性，并只能在销毁时将 type script hash 转移给最多一个新的 cell 上。 - 使用 delegate lock 作为资产的 lock script，使用上一步创建的 ownership cell 的 type script hash 作为 args。 这样要处置资产，必须在同一个交易中同时加入 ownership cell。所以持有 ownership cell 就相当于拥有了处理资产的权力。转移资产只需要将 ownership cell 唯一的 type script hash 转给新所有者即可。 到这里，其实已经完成了 RGB 中的一次性封条的核心功能。基于这个例子再来看 RGB 还做了什么不一样的地方就比较容易理解了。 - RGB 资产不限不 CKB，实际上它的资产是 Off-chain 的，所以它加入了自己的虚拟机和合约平台。这个因为没有细看，所以不做过多展开。不过就我理解，其实是非常像基于 Sparse Markle Tree 的 Rollup。只不过每一次 Root Hash 提交时，所有状态有更新的资产，必须在交易中同时转移代表它们处置权的 UTXOs 完成所有权的验证。 - 因为交易带上了处置权 UTXOs，验证状态也只要通过 UTXOs 找到对应的 Root Hash 提交的交易，方便通过 light client 进行同步。这也就是 RGB 提到的客户端验证状态更新，并且只需要验证自己关心的部分。 - 为了隐私性，处置权不是像 type id 生成的 type script hash 在一个 tx 的某个 input 转移到同一个 tx 的某个 output 上，因为这样会很容易被溯源。RGB 的做法是在销毁代表处置权的 UTXO 时，把 hash(tx hash, output index, secret) 写到了交易里。其中 tx hash, output index 维一指定了新的 UTXO，而 secret 是只有新的所有者才知道的一段随机数据，因为 hash 的不可逆性，只有新的所有者才知道新的 UTXO 是哪一个。 - 也是为了隐私性，引入了 ZK 隐藏和数额相关的信息。  <!-- vim: set spelllang=en,cjk: -->