# RGB++ 协议使用过程中的体验问题

By [Portal_Kay](https://paragraph.com/@portalkay) · 2024-06-19

---

随着 [@HueHubOfficial](https://x.com/HueHubOfficial) 官宣上线 Fair Launch 功能，相信很快 RGB++ 协议上的资产会像雨后春笋一样快速增加。然而，由于 RGB++ 在底层逻辑上跟大家熟知的 BRC-20 等完全不同，并且由于“同构绑定”的创新性，导致 RGB++ 资产在使用过程中也存在一些差异点。

为了减少大家后续使用 RGB++ 协议时的困惑，我把之前在参与协议测试时遇到的两个问题进行了整理。这里得感谢 @DaPangDunCrypto 胖墩老师给予的耐心解答，也感谢他在 RGB++ 协议落地过程中付出的巨大努力！

[https://x.com/portal\_kay](https://x.com/portal_kay)

> 更多 BTC 生态相关内容，欢迎关注推特 [@portal\_kay](https://x.com/portal_kay)

* * *

以下是我在体验 RGB++ 协议时遇到的两个困惑：

1\. BTC 一层转移 RGB++ 资产需要额外付出 0.00007 BTC
---------------------------------------

### 1.1 问题说明

*   当我们在 BTC 一层网络转移发送 RGB++ 资产时，需要额外支付一笔 0.00007 BTC 的费用到一个陌生钱包；
    
*   以下面这笔交易为例。这笔交易包含了4笔 Outputs，其中标为绿色的3笔都比较容易理解，分别是：① 这次转给接收钱包的 RGB++ 资产（比如：100 $Seal），② 转移一部分之后支付方剩余的 RGB++（比如：原有 1000 $Seal，转出 100，剩余 900），④ 是支付完这笔一层交易 BTC 费用之后得到的找零。其中第 ③ 笔输出，当时就让我产生了很大疑惑，因为这是一个陌生钱包地址，那么这笔 0.00007 BTC 的支出到底是怎么产生的呢？
    

![BTC 一层 RGB++ 资产转移订单](https://storage.googleapis.com/papyrus_images/e5a1484d8bcc5ba43cf9025bdbb9a123d27e7a867815c56c2d5a4b02bc115c55.png)

BTC 一层 RGB++ 资产转移订单

### 1.2 原因分析

*   我们都听过 RGB++ 的“同构绑定”设计，就是每一笔 BTC 一层上的 RGB++ 资产，其实会同构映射到 CKB 网络内，与 CKB 网络内一笔“一模一样”的资产进行绑定。
    
*   既然如此，那么我们上方示例里的这笔接收方新收到的 $Seal， 是不是也能在 CKB 网络里找到它的同构映射的“影子”呢？我们打开 [https://explorer.nervos.org/](https://explorer.nervos.org/)，输入接收方的 BTC 钱包地址，果然发现了刚才收到的那 100 $Seal。
    

![CKB Explorer 可显示同构隐射的 RGB++ 资产](https://storage.googleapis.com/papyrus_images/4ab635b18ed2ba8338ff48a5e5c02135e419aea1a6a6d833bdd835e7c65d96c4.png)

CKB Explorer 可显示同构隐射的 RGB++ 资产

*   同时，我们还可以进一步发现：其实这 100 $Seal 是一笔独立的 UTXO，并且这笔 UTXO 占据了 254 $CKB 的资产，就好像每一个 Ordinals 资产也同样需要占据一定额度的 BTC 聪一样（一般为546聪）。
    
*   分析到这里，刚才那笔 0.00007 BTC的意外支出就基本破案了：它其实是为了让你转出的这笔 RGB++ 资产能够映射到 CKB 网络内，代付的那 254 个用来作资产占用的 $CKB。可以简单换算一下两者的价值：0.00007 BTC ≈ 4.76 U，254 $CKB ≈ 6.3 U，两者的价值比较接近。当然，这个 0.00007 BTC的费率目前是固定的（测试网上也是这个额度），所以随着 $BTC 和 $CKB 汇率的变化，两者的价值会有所差异。可能 CKB 官方后期会引入类似浮动利率的机制来动态收取这笔代付费用。
    

2\. 一层资产 Leap 到 CKB 二层需要等 1个小时？
-------------------------------

### 2.1 问题说明

*   RGB++ 作为 BTC 一层资产，是可以转移到 CKB 二层网络的，这个过程叫做 Leap。然而，当我们希望把手头 $Seal 转移到 CKB 网络时，这个过程可能需要等待 1个小时以上。
    

### 2.2 原因分析

*   要了解 $Seal 从 BTC 一层 Leap 到 CKB 二层为什么要耗费1个小时以上，我们需要先理解 RGB++ 资产 Leap 的过程，它会涉及到 3 个步骤：① 在 BTC 一层创建一笔交易；② 在 CKB 二层创建一笔 同构交易；③ Unlock 操作，锁定 CKB 上该笔资产等待 6 个 BTC 区块再解锁。
    

![JoyID 钱包内的 RGB++ 资产 Leap 步骤](https://storage.googleapis.com/papyrus_images/1f799a29b25cda1ff7b461093f3b4bf2e0dcaf7392d8fc74009a069102210536.png)

JoyID 钱包内的 RGB++ 资产 Leap 步骤

*   在上面 3 个步骤中，其实步骤 ① 和 步骤 ② 并不会花费额外的时间，跟我们在 BTC 主网完成一笔交易的时间区别不大，关键就在于第 ③ 步。为了保证资产从一层 Leap 到二层的安全性，即资产确确实实已经在一层产生了 Leap 行为，而没有作假。因此才有了步骤 ③ 的Unlock 操作，即先在 CKB 二层锁定这笔 Leap 过来的资产，这时候我们在 CKB 二层暂时无法再操作这笔资产，需要等待主网确认 6个区块之后，才能解锁。正因为这6个区块，按照 BTC 网络每 10 分钟出一个块的节奏来计算，那么一次 Leap 操作平均就需要等待 60分钟。并且这是在主网不卡顿的情况下，如果遇到某些区块堵住，单个区块可能就需要等待一个小时，这种情况下 Leap 需要等待的时间就会更长。
    
*   其实这 6 个区块的锁定操作，并不是必须的，只是 CKB 团队为了确保资产的安全性足够高（防止双花），所以做了这个设定。实际运作当中有没有优化的必要，可能需要更多用户的体验之后才能有结论。当然，一层资产 Leap 到二层，本身不属于一项高频操作，这段时间的等待影响相对较小。
    

好了，以上是我在实际使用 RGB++ 协议时遇到的两个问题。其实本身这也不算是“问题”，只是 RGB++ 自身的创新，导致使用上会与其他我们熟知的 BTC 一层资产协议有所差别，因此产生一些疑问，希望文章能够让大家对 RGB++ 协议有更多的理解。

---

*Originally published on [Portal_Kay](https://paragraph.com/@portalkay/rgb)*