從 RGB 到 RGB++，重新認識 CKB 作為位元幣 Layer2 及鏈下結算層的潛力

RGB++本質是用隱私換易用性，同時帶來RGB協定無法實現的場景。

撰文：Shew、Faust，極客 web3

顧問：CyberOrange，Unipass

摘要（較長）：RGB 協定是比較有潛力的 BTC 拓展協定，本質是一種鏈下計算系統，它採用了和閃電網路類似的思想：用戶親自驗證並授權和自身相關的資產變動事宜（Verify by yourself），把交易發起者認可的結果 / 承諾提交到位元幣鏈上。

• RGB 協定利用了與染色幣及 Mastercoin 部分類似的思想，在位元幣 UTXO 上關聯著「寄生資產」。它把鏈下交易數據的 Commitment「承諾」，存放到位元幣鏈上，而不是像 Ordinals 協定那樣發佈完整的 DA 數據。根據位元幣鏈上記錄的承諾值，RGB 客戶端可以驗證，其他客戶端提供的 RGB 歷史數據是否有效。

• 同時，單憑 hash/Commitment 無法還原背後的原像，外界不能直接觀測到鏈上承諾值對應的鏈下數據，這樣可以保護隱私，且相比於銘文，只把承諾上鏈能節省空間。從第三者的視角看，他其實不知道 RGB 客戶端到底幹了什麼。

• RGB 還利用了位元幣 UTXO 一次性花費的特性，通過名為「一次性密封」的思路，把 RGB 資產所有權，和位元幣 UTXO 關聯起來。這樣可以藉助位元幣強大的安全性，避免 RGB 資產被「雙花 / 雙重支付」（只要位元幣 UTXO 不被雙花，RGB 資產就不會被雙花）。

• 但 RGB 作為一個在位元幣鏈下實現的智慧合約系統，依賴於不同的客戶端在本地存放歷史數據，且不同客戶端（用戶）只存放與自己相關的數據，看不到別人的資產狀況。這種「數據孤島」雖然保護了隱私，但也使得 RGB 在大規模採用上面臨麻煩，更像一個由 OTC 交易者組成的 P2P 網路。

• RGB++ 的思路是，用 CKB 鏈上的 Cell，表達 RGB 資產的所有權關係。它把原本存放在 RGB 客戶端本地的資產數據，挪到 CKB 鏈上用 Cell 的形式表達出來，與位元幣 UTXO 之間建立映射關係，讓 CKB 充當 RGB 資產的公開資料庫與鏈下預結算層，替代 RGB 客戶端，實現更可靠的數據託管與 RGB 合約交互。對於其他基於 UTXO 的 Layer2 而言，這種「同構綁定」 是一種趨勢。

• RGB 協定本身只支持互動式的轉賬流程，交易雙方要頻繁通信，這種模式難以支持 Defi 場景，也不利於 RGB 資產發行。CKB 替代了獨立客戶端之後，可以實現非交互的 RGB 交易，利於 Defi 落地和空投等功能，且支持 BTC 資產無需跨鏈的與 CKB 鏈上資產交互。

• RGB++ 本質是用隱私換易用性，同時帶來 RGB 協定無法實現的場景。如果用戶看重產品的簡單好用和功能完備性，就會青睞 RGB++，如果追求隱私和 Verify by yourself 的安全，就會青睞傳統的 RGB 協定，一切看用戶自己的取捨。（理論上 RGB++ 也可以通過 ZK 等方法解決隱私問題）

RGB 協定的原理及其優缺點

RGB 協定本身是一種比較複雜的方案，我們以一筆具體的 RGB 資產轉賬為例，為大家解釋 RGB 協定是如何工作的。

假設有一種符合 RGB 協定要求的代幣，叫 TEST。Alice 希望 Bob 將 100 個 TEST 代幣轉給自己，換句話說，希望生成一筆 Bob—>Alice 的代幣轉賬。

這裡先解釋下，RGB 協定採用了稱為「一次性封裝」的思路，表面上說是 Bob 給 Alice 轉賬，實際是指，Bob 控制著位元幣鏈上的 UTXO A，而 UTXO A 通過某些方法，關聯了一些 RGB 資產。

如果 Bob 聲明，要把 UTXO A 關聯的部分 RGB 資產轉讓給 Alice，它可以如此聲明：把 UTXO A 關聯的 30 枚 TEST 代幣，轉讓給 UTXO B 來關聯。由於 Alice 是 UTXO B 的所有者，所以她就擁有了關聯的 30 枚 TEST 代幣。

（圖源：Discoco Labs）

實際上位元幣鏈上的所有權記錄方式，都是通過 UTXO 來實現的，聲明 UTXO B 有資格控制 xx 數額 RGB 資產，就等價於說 UTXO B 的主人可以控制 xx 數額 RGB 資產，這與我們所習慣的賬戶地址模型並不一致，是位元幣等 UTXO 公鏈的獨特屬性。

理解了這裡後，我們再考察 RGB 協定的工作流程，可以感受到他與染色幣及 Mastercoin 等位元幣 UTXO 寄生資產的差異：

1.按照 RGB 協定的原理，Alice 要先為轉賬交易開具發票 (issues an invoice)，指明自己的意圖。發票中包含以下資訊:

• 合約 id：Alice 聲明要與哪個 RGB 資產合約交互

• 接口：讓 Bob 瞭解合約的所有交互接口

• 操作：Alice 讓 Bob 去調用的合約接口名

• 狀態：Bob 需要修改的合約狀態，此例中就是 Bob 轉給 Alice 的代幣數量

• Seal（密封條）：用於一次性密封的 UTXO，可以簡單理解為，Alice 用來接受 Bob 的 RGB 資產授權的 UTXO。

最後，Alice 會獲得一個如下的發票內容:

上述發票遵循如下格式：

2.Alice 需要將上述發票發送給 Bob。Bob 會檢查發票資訊，按照 Alice 的意圖來生成新的 RGB 交易，把 RGB 資產轉讓給 Alice。

但這裡要格外注意，Bob 必須設法證明，自己的確有部分 TEST 資產所有權。至於為何要這麼做，是因為 RGB 協定默認「沒有全局可見的資產狀態記錄」，不會像以太坊那樣用一個公共託管合約來記錄並處理所有人的資產。

RGB 協定下，不同的客戶端只記錄和自身相關的資產數據，包括這些資產的當前餘額、歷史來源等，每個客戶端記錄的數據基本都不一致。這樣一來，每個人都無法確認其他人的資產狀況，所以在 P2P 交易時要出示資產證明。

用一句生動的比喻就是，你和對面在用紙鈔進行交易，但你不知道對方的紙鈔是不是自己印的假幣，你便要求他說清楚，這些紙鈔是從哪裡弄來的，經過多少人轉手，以此來判斷對方是否在用假幣糊弄你。

雙方互相認可後，就可以放心大膽的交易，每一筆 RGB 交易也只需要參與方彼此認可就行，是完全 P2P 的（類似於 OTC）。

顯然，這種模式可以保護隱私，因為每個人的資產狀況、交易記錄，都不會被外界輕易獲知，你和交易對手方做了什麼，外人很難知道。道理就好比，紙幣可以比銀行轉賬更好匿蹤。但顯然，這也會在用戶體驗上造成不便。

在前面談到的 Alice 和 Bob 案例中，Bob 收到 Alice 的發票並獲知其意圖後，要從本地客戶端的歷史數據中，選出和 TEST 資產相關的歷史轉賬記錄，連同新生成的 Bob -> Alice 轉賬，一起交給 Alice 去校驗，證明新的 RGB 交易 / 所有權變更，背後對應的資產所有權來源是有效無誤的。

一般而言，客戶端本地存放的數據稱為 Stash「藏品」，包含了 RGB 資產的過往數據。我們可以把 Stash 當做 RGB 資產合約的日誌記錄。

3.當 Alice 從 Bob 那裡收到數據，以及新聲明的 Bob—>Alice 交易後，會驗證其有效性，如果驗證通過，Alice 便會生成一個「確認簽名」，返回給 Bob。

4.Bob 收到 Alice 的確認簽名後，便把 Bob —> Alice 交易對應的 Commitment（承諾）廣播到 BTC 網路內，最終寫入 BTC 鏈上，使其具備「最終性」。

（Commitment 的結構圖，其實本質是個 merkle root）

如果 Bob—>Alice 轉賬中，聲明 UTXO B 的主人將擁有 30 枚 TEST 代幣，則 Alice 只要證明自己是 UTXO B 的主人，就可以使用這些 TEST 代幣。

5.如果未來 Alice 要把 TEST 代幣轉給別人，當出示這些 TEST 的歷史來源時，對方可以根據位元幣鏈上的 commitment 承諾值進行核驗，看 Alice 提供的數據能否和鏈上的承諾值對應。這樣可以防止偽造數據。

RGB 協定的好處在於，可以在鏈下支持複雜的智慧合約計算。它本質上把計算步驟挪到了 BTC 鏈下，僅在鏈上記錄 Commitment，在保護隱私的同時，在鏈下聲明位元幣 UTXO 和 RGB 資產所有權之間的關聯，藉助位元幣來刻錄並實現 RGB 資產的所有權變更。

由於所有的交易聲明都需要由當事人驗證並授權，所以其安全模型基於「理性人假設」，只要當事人是理智的，只要位元幣是安全的，RGB 資產所有權就「基本安全」。

但 RGB 協定的缺陷也很明顯（前文有提及數據孤島與碎片化存儲問題）。首先，要給其他人轉賬，甚至要先得到對方的同意和確認，雙方基本要同時在線；

其次，因為缺乏全局可見的數據記錄方式，RGB 的合約發佈甚至都採用了非常奇葩的形式，合約使用者要事先從合約發佈者處，獲知合約包含的接口功能，具體的獲知方式可以是通過電子郵件或是掃二維碼。（看官方目前的說辭，估計把合約代碼掛官網首頁、推特置頂也可以）

我們再來探討一下 RGB 協定的合約狀態。在 RGB 協定內，合約的初始狀態 (Genesis) 由創建者在合約創建時就設置好，比如 RBG-20 合約中的代幣名稱、總量等。而後，合約的狀態伴隨著 RGB 交易的持續遞進而變化，但這種合約狀態演進是非線性的，構成了一個有向無環圖 DAG。

（圖中 owner1 的視野範圍是藍色和綠色部分，Owner2 視野範圍是藍色和黃色部分）

比如 Bob 給 Alice 轉賬時，僅出示從合約初始化，到 Bob 獲得代幣的部分轉賬記錄，包含的數據路徑比較狹隘。而 Alice 也僅能獲知此路徑分支包含的交易資訊，難以獲知其他人的轉賬資訊。這雖然保護了 RGB 用戶的隱私，但也帶來了不良後果：用戶很難獲知 RGB 合約的全局狀態，比如每個人有多少 RGB 資產。這會帶來很多麻煩。

比如，當 Bob —> Alice 轉賬進行到最後步驟，其承諾值被寫入 BTC 鏈上且不可逆轉後，Bob 可以在本地刪掉部分數據——假如 Bob 將自己全部的 TEST 代幣都給了別人，可以直接把本地存放的 TEST 代幣相關數據刪掉，以減輕存儲壓力。

而作為代幣接收方的 Alice，則要在本地記錄此次交易所涉及的全部數據。（假如 Bob 刪掉了本地的 TEST 代幣數據，Alice 的客戶端節點又因為事故徹底損壞了，那麼此時，Alice 的資產是不是就永久凍結了？因為沒有其他地方存放 Alice 的 TEST 資產數據，除非事先就備份好。）

這本質上可以歸結為 DA 和數據存儲問題，即 RGB 協定的新增數據無法以一種可靠、全局可見的方式傳播出去，最終會使得不同的客戶端成為「數據孤島」。此前曾在以太坊生態如日中天，但後來遭到廢棄的 Plasma 方案，也是因為無法解決 DA 問題，最終胎死腹中。

此外，RGB 協定還需要交易雙方進行大量通信，很多通信步驟都要依賴中心化設施，在這塊的細節描述還不成熟，官方甚至說可以通過郵件來通信。

比較顯然的是，RGB 協定的設計對於追求易用性的長尾用戶不太友好，雖然擁有較多資產且對隱私有較高追求的大戶會樂於做數據備份和客戶端維護，但對於長尾用戶而言，這些包袱還是太重了，會對大規模採用造成嚴重阻礙。甚至於到目前，人們大多認為沒有出現什麼現象級的 RGB 資產。

下圖中，我們給出了 RGB 資產轉賬的流程圖，讀者可以基於此圖更加深刻理解轉賬的整體流程。

簡而言之，RGB 協定藉助位元幣 UTXO，實現 RGB 資產的所有權變更，並通過在 BTC 鏈上發佈承諾值（Commitment），確保鏈下數據無法被客戶端私自篡改。實際上，RGB 所謂的「一次性密封」，就是通過鏈下的 RGB 交易聲明，把位元幣 UTXO 和 RGB 資產所有權關聯起來，以此藉助位元幣強大的安全性，來保障 RGB 資產安全。但由於 DA 和數據存儲問題，原始 RGB 協定的可用性及 UX 比較差，且資產容易因為數據丟失而凍結（不可用）。

RGB++：基於 CKB 的加強版 RGB 協定

在上文中，我們總結了 RBG 系統的優點與缺點，其中，客戶端數據孤島、合約狀態無法全局可見，構成了影響 RGB 協定易用性的最主要因素。

實際上，RGB 協定的優點和缺點都很明顯，對隱私和安全有較高追求的人會傾向於自己運行客戶端，並做好數據備份，但長尾用戶顯然沒這個耐心（比如，大多數閃電網路用戶會依賴於第三方節點，而不是自己去運行客戶端）。

基於這個理由，Nervos 聯創 Cipher 提出了名為 RGB++ 的方案，嘗試將 RGB 的資產狀態、合約發佈與交易驗證，委託給 CKB 公鏈來進行。CKB 充當了第三方的數據託管與計算平臺，不再需要用戶自己運行 RGB 客戶端。

由於 CKB 本身是拓展的 UTXO 模型（Cell），可以將 RGB 資產的鏈下資訊寫入到 Cell 中，並在 Cell 和位元幣 UTXO 之間建立 1 對 1 的映射關係，實現基於 CKB 的 RGB 資產數據託管與驗證方案，以此解決易用性問題，作為 RGB 原始方案的一種強化補充。

這段話讀起來可能有點繞，對此我們再展開解釋一下：

文章前面提到，RGB 協定本質是通過發佈鏈上承諾與鏈下聲明，把位元幣 UTXO 和 RGB 資產所有權關聯起來。但 RGB 資產合約的數據是碎片化存放在不同客戶端本地的，沒有一個全局可見的視圖。

RGB++ 通過 CKB 的拓展版 UTXO——Cell，把位元幣 UTXO 與對應的 RGB 資產之間的映射關係，直接在 CKB 鏈上展示出來，並且由 CKB 公鏈替代用戶的 P2P 客戶端，驗證每一筆 RGB 轉賬的有效性。

有了這樣一個全局可見的 RGB 數據記錄後，很多難以在 RGB 協定中實現的場景都會更容易落地。

（RGB++ 的交易流程，把 RGB 資產資訊寫入 Cell，再將 Cell 與位元幣 UTXO 建立關聯，最後把 CKB 上發生的 RGB++ 交易，以及與 RGB++ 資產關聯的位元幣 UTXO，一併包含在承諾裡，再把承諾值寫到位元幣鏈上）

可能有人第一時間想到了 EVM。我們是否可以用 EVM 承載 RGB 的狀態與驗證？答案是：很麻煩，因為 RGB 資產本質上寄生於位元幣 UTXO，與位元幣 UTXO 存在 1 對 1 的映射關係。如果要把位元幣 UTXO 與 EVM 合約數據建立映射關係，在技術實現上並不順暢，還不如直接選擇一條 UTXO 公鏈。

而且，以太坊上的「資產」往往是點對池的公共物品，一個合約上記錄無數人的資產數據，合約控制者擁有絕對權力，這種資產處理方式與位元幣 UTXO 以及 RGB 協定嚴重衝突，後兩者的設計思路，是徹底實現資產的私有化，每個人完全控制自己的資產（想想紙幣和微信支付的區別），不必考慮以太坊和 EVM 鏈一貫存在的：資產合約 owner 濫用職權、合約出 bug 導致資金受損、資產合約的數據要遷移時很麻煩 等問題。

（出自極客 web3 過往文章：《技術圈名人響馬：高性能公鏈難出新事，智慧合約涉及權力分配》）

所以，如果要將位元幣 UTXO 與鏈下 RGB 資產之間的映射關係表達的較為順暢，最好的選擇還是通過 UTXO 鏈。而 CKB 支持的是拓展型 UTXO——Cell，且 CKB VM 的指令集基於 RISC-V，比起 EVM 更容易相容不同的密碼學算法，包括位元幣的公私鑰驗證算法，所以更利於實現 RGB++ 提出的技術方案。

RGB++ 的技術實現

RGB++ 用到了 CKB 的拓展型 UTXO——Cell 。而一個 Cell 包含以下欄位:

Capacity 代表此 Cell 擁有的鏈上空間大小，data 指 Cell 內包含的數據集，可以被讀取或修改。

Type 是這個 Cell 綁定的程式代碼，限制了 data 數據的修改條件。比如，你的 Cell 裡有 100 枚 TEST 代幣的數據，但你聲明將 110 枚 TEST 轉給別人，這不符合 Type 裡規定的限制條件，會被拒絕。

而 Lock 則代表 Cell 的所有權驗證邏輯，類似於位元幣 UTXO 的解鎖腳本。

我們可以把 Cell 理解為升級版的 UTXO，多出了 Type 和 Capacity 這兩個欄位，且 data 可以自定義數據類型，至於 Cell 的所有權變更方式，和位元幣 UTXO 差不多，都是通過解鎖腳本來實現。

而 RGB++ 的思路是，用 CKB 鏈上的 Cell，表達 RGB 資產的所有權關係。它把原本存放在 RGB 客戶端本地的資產數據，挪到 CKB 鏈上用 Cell 的形式表達出來，讓 CKB 充當 RGB 資產的公開資料庫。而表示 RGB 資產的 Cell，會和位元幣鏈上的 UTXO 存在 1 對 1 的映射關係，這種映射關係會在 Cell 的 Lock 欄位裡直接展示出來。

比如說，假設某個 RGB 資產關聯著位元幣 UTXO A，則對應的映射版 Cell，可以把自己的所有權驗證條件，設置為和位元幣 UTXO A 一致（就是把 Lock 腳本設置為位元幣 UTXO A 的解鎖條件）。如果你是 UTXO A 的控制者，你就能直接操作 CKB 上的映射 Cell，當然，CKB 會驗證你是不是 UTXO A 的主人。

CKB 鏈上會實現位元幣輕節點，同步位元幣區塊頭。當你聲明 RGB 交易，要對 RGB 資產對應的 Cell 進行操作時，要先證明自己是位元幣 UTXO A 的控制者，證明步驟分兩步：

1. 向 CKB 鏈上實現的位元幣輕節點證明，UTXO A 存在於位元幣鏈上，需要出示 Merkle Proof；

2. 出示數位簽名，證明自己是 UTXO A 的所有者。

在 RGB++ 方案中，用戶在前端聲明一筆 RGB 資產轉賬後，會在 CKB 鏈上觸發一筆交易，對記錄 RGB 資產數據的 Cell 進行改寫，變更其所有權。原本可能是位元幣 UTXO 1 的控制者擁有這個 Cell，所有權變更後，位元幣 UTXO 2 的控制者成為了 Cell 的新主人。這一切都在 CKB 鏈上可見。

這裡要注意的是，與 BTC 鏈上承諾相關的工作流程，依然在 BTC 主網進行，就是說 RGB++ 仍然要在位元幣鏈上發佈 Commitment，與 CKB 上發生的 RGB 資產交易記錄關聯起來。這一步與傳統 RGB 協定並無不同。

但不同的是，傳統 RGB 協定中由客戶端在鏈下自己負責的工作，都由 CKB 來負責，比如交易對手方要驗證資產來源、客戶端要在本地存儲資產來源數據、RGB 合約發佈要通過第三方渠道等，這些繁瑣的包袱都可以由 CKB 負責解決，不需要用戶自己運行客戶端。

這樣解決了 RGB 客戶端數據孤島問題，也解決了合約狀態無法全局可見的缺陷。同時，RGB 合約可以直接部署在 CKB 鏈上，全局可見，供 RGB Cell 來引用，這樣就避免了 RGB 協定合約發佈時的一系列奇葩操作。

概括來講，CKB 利用 Cell 腳本的可編程性，先確定 RGB 轉賬發起者 的確擁有 RGB 資產關聯的位元幣 UTXO，若驗證通過，則允許用戶通過轉賬，將記錄 RGB 資產數據的 Cell 轉讓給別人。

建恩而概之，CKB 充當了 RGB 資產的公開數據託管平臺，提供了數據存儲與全局可見的合約發佈功能，也提供了所有權驗證與計算功能。更加精簡一點來說，就是 CKB 替代了 RGB 中的客戶端，並且順帶解決了其他的問題。

當然，RGB++ 既然實現了全局可見的數據發佈，隱私性相比於 RGB 協定必然是降低的，但好處是易用性得到了極大幅度提升。

所以 RGB++ 本質是用隱私換易用性，同時能帶來 RGB 協定無法實現的場景。如果用戶看重產品的簡單好用和功能完備性，就會青睞 RGB++，如果追求隱私和 Verify by yourself 的安全，就會青睞傳統的 RGB 協定，一切看用戶自己的取捨（思路就和 Vitalik 評論以太坊 Layer2 時表達的差不多，追求安全就去用 Rollup，追求低成本就去用 Validium 和 Optimium 等非 Rollup 方案）。當然，按照 RGB++ 白皮書中的說法，後續也可以在 CKB 鏈上實現隱私交易方案，隱藏用戶的身分與轉賬金額。

RGB++ 的附加特性

交易的非交互性（非常重要）

原始 RGB 協定的一個重要問題在於，收款方要先向付款方發送一條消息（就是前文說過的支票），指明把自己的一個 UTXO 與 RGB 資產綁定，RGB 轉賬才能順利實施。這就要求收款方與付款方之間經過多道互動式通信，才能完成一筆普通交易，顯然增加了用戶的理解難度和產品複雜度。而 RGB++ 利用了 CKB 作為數據託管與計算平臺的特性，允許對手方之間通過非同步、非交互的方法來完成轉賬。

A 向 B 轉賬時，只需要事先知道 B 的地址，聲明向該地址轉賬，不需要收款人在線通信或提供數據。之後，收款人可以自己去領取資產，CKB 鏈上的腳本代碼，會驗證收款人是否是付款人指定的那個。顯然，這種模式更貼近大多數人的習慣，諸如空投、獎勵分發等原本在 RGB 協定中不支持的模式也可以跑的通，這樣也有利於 RGB 資產發行。

此外，RGB 協定的工作模式天然不利於 Defi 場景的展開，比如 Uniswap 這種典型的多對多、非互動式的交易池，在原始 RGB 協定中幾乎無法展開，而 RGB++ 實現了非互動式交易、狀態全局可見可驗證，只要借用 Cell 來實現一個所有滿足條件的人都可以修改其狀態的「無主合約」，就可以把很多 Defi 場景落地。

當然，所有人都可以修改其狀態的無主合約，很容易出現狀態爭用 / 讀寫衝突，就是好幾個人想同時修改合約狀態，這樣會導致混亂。為了解決這個問題，RGB++ 計劃用一個鏈上實現的 Intent Cell 作為「排序器」，對不同的請求進行排序。

交易折疊（聚合多筆交易的承諾發佈）

交易折疊比較好理解，就是把 CKB 作為一個「鏈下預結算層」，等多筆 RGB 轉賬發生後，把一批交易聚合起來，生成一個對應批量交易的 Commitment，一次性發布到位元幣鏈上。

具體表現為以下流程圖：

BTC 資產無需跨鏈直接與 CKB 鏈上資產交互

RGB++ 實現了位元幣 UTXO 與 CKB Cell 之間的關聯映射後，可以直接實現無需資產跨鏈的互操作。你可以通過 RGB++ 交易聲明，把自己的位元幣 UTXO 轉移給別人，對方可以把自己的 CKB 資產所有權轉讓給你。這種模式擁有很大的想像空間，結合前面提到的交易折疊（批量交易），理論上可以實現無需 BTC 資產跨鏈的 BTC——CKB 鏈上資產互操作。

總結

RGB++ 把存放在不同 RGB 客戶端本地的資產數據，直接用 CKB 鏈上的 Cell 表達出來，再把 Cell 與位元幣鏈上的 UTXO 關聯起來。用戶可以通過位元幣賬戶 / 資產，與自己在 CKB 鏈上的 RGB++ 資產進行交互。這種方式比較簡潔，且解決了 RGB 協定中 轉賬需要雙方事先通訊、難以支持全局可見的狀態、數據存儲碎片化、智慧合約及 Defi 不友好等問題。

RGB++ 無需資產跨鏈，就可以實現 BTC—CKB 之間的互操作，且便於 RGB 資產與 Defi 場景結合，極大程度解決了 RGB 協定的易用性問題。但對於追求高度隱私的 RGB 小眾玩家而言，RGB++ 本質是以隱私換易用性，一切還要看用戶的取捨。但理論上來講，隱私問題可以在 CKB 鏈上通過引入 ZK 等方法來解決。

整體而言，RGB++ 展示了 CKB 作為一個位元幣鏈下結算層 / 計算層的潛力，而這種思路會在未來，被越來越多的位元幣 Layer2 或資產協定所採納，可以預見的是，位元幣鏈下的第三方結算層間的角逐，或許不久後就會展開。而主打 POW 和 UTXO、有著多年技術積澱的 CKB，或許能夠在這場模塊化區塊鏈的角逐中表現出自己的技術優勢。