白話說明書：

一文讀懂RGB與RGB++協議設計

隨着 RGB++ 及相關資產發行的火熱，關於 RGB 與 RGB++ 協議原理的討論逐漸成爲更多人關注的話題。但大家意識到，要理解 RGB++，必須先理解 RGB 協議。

原始的 RGB 協議在技術構造上略爲晦澀，參考資料較爲零散，至今沒有多少系統性且較通俗易懂的參考資料

RGB 協議：用戶要親自做數據驗證

RGB 協議是一種特殊的 P2P 資產協議，是比特幣鏈下的計算系統，它在某些方面與支付通道類似：用戶要親自運行客戶端，自行驗證與自己有關的轉賬行爲（Verify by yourself）。即便你只是一個資產接收者，也要先確定資產發送者的轉賬聲明沒有錯誤，然後這筆轉賬聲明才能生效。顯然這與傳統的資產發送與接收形式截然不同，我們將其稱之爲「交互式轉賬」。

爲什麼要這樣？原因在於，RGB 協議爲了保障隱私，沒有采用比特幣和以太坊等傳統區塊鏈中的「共識協議」（數據一旦走共識協議，就會被網絡內幾乎所有節點都觀測到，隱私不好保障）。如果沒有大量節點都參與的共識流程，該如何保證資產變更是安全的？這裏用到名爲「客戶端驗證」的思想（Verify by yourself），你要自己運行客戶端，親自驗證和你相關的資產變動。

假設有個 RGB 用戶叫 Bob，他認識 Alice，Alice 要給 Bob 轉來 100 枚 TEST 代幣。Alice 生成了「Alice to Bob」的轉賬信息後，要先把轉賬信息和涉及的資產數據發送給 Bob，讓他親自檢查一遍，確定無誤纔會進入後續流程，最終成爲一筆有效的 RGB 轉賬。所以說，RGB 協議是讓用戶親自驗證數據有效性，取代傳統的共識算法。

但沒有了共識，不同 RGB 客戶端接收和存儲的數據都不一致，大家只在本地存儲與自己有關的資產數據，不知道別人的資產狀況，這在保護隱私的同時，也構成了「數據孤島」。如果有人聲稱有 100 萬枚 TEST 代幣，要轉給你 10 萬枚，你如何相信他？

在 RGB 網絡中，如果有人要給你轉賬，必須讓他先出示資產證明，回溯資產從初始發行到多次轉手的歷史來源，確定要轉給你的 Token 沒問題，這就好比，當你收到來路不明的紙幣後，你要求對方說明這些紙幣的歷史來源，是否是指定的發行方製造的，以此來規避假幣。

上述流程是發生在比特幣鏈下的，僅憑這些過程還無法讓 RGB 與比特幣網絡產生直接關聯。對此，RGB 協議採用了名爲「single use seal」的思想，把 RGB 資產與比特幣鏈上的 UTXO 綁定起來，只要比特幣 UTXO 沒有被雙重消費，綁定的 RGB 資產就不會發生雙重支付，這樣就可以藉助比特幣網絡來防止 RGB 資產發生「Re-organization」。當然，這需要在比特幣鏈上發佈 Commitment，並用到 OP_Return 操作碼。

在此梳理一下 RGB 協議的 workflow：

1. RGB 資產與比特幣 UTXO 有着綁定關係，而 Bob 擁有某些個比特幣 UTXO。Alice 要給 Bob 轉賬 100 枚代幣，在接收資產前，Bob 事先告訴 Alice，應該用 Bob 的哪個比特幣 UTXO 綁定這些 RGB 資產。

* Alice 構造一筆 「Alice to Bob」 的 RGB 資產轉賬數據，附帶這些資產的歷史來源交給 Bob 去驗證。

* Bob 在本地確認這些數據沒問題後，給 Alice 發送一個回執，告訴她：這筆交易可以通過了。

* Alice 把這筆「Alice to Bob」的 RGB 轉賬數據構建成一棵 Merkle Tree，把 Merkle Root 發佈到比特幣鏈上作爲 Commitment，我們可以把 Commitment 簡單理解爲轉賬數據的 hash。

* 如果未來有人想確定，上述「Alice to Bob」的轉賬真實發生過，他需要做兩件事：在比特幣鏈下獲取「Alice to Bob」的完整轉賬信息，然後查驗比特幣鏈上是否存在對應的 Commitment（轉賬數據的 hash），就可以了。

比特幣在此充當了 RGB 網絡的歷史日誌，但日誌上只記錄交易數據的 hash/Merkle root，而非交易數據本身。由於採用了客戶端驗證和一次性密封，RGB 協議具有極高的安全性；由於 RGB 網絡是由動態的用戶客戶端以 P2P、無共識的形態組成的，你可以隨時更換交易對手方，不需要把交易請求發送給某些個數量有限的節點，所以 RGB 網絡具有極強的抗審查性，這種組織形式要比以太坊等大型公鏈更抗審查。

當然，極高的安全性與抗審查性、隱私保護，帶來的代價也是明顯的：用戶要自己運行客戶端驗證數據，如果對面發過來一些轉手幾萬次、歷史記錄很長的資產，你也要頂着壓力全部驗證完；

此外，每筆交易都要求雙方進行多次通訊，接收方要先驗證發送方的資產來源，然後發送回執，批准發送方的轉賬請求。這個過程中，雙方之間至少要產生三次消息傳遞。這種「交互式轉賬」和大多數人所習慣的「非交互式轉賬」嚴重不符合，你能想象，別人要給你轉錢，還要把交易數據發給你來檢查，得到你的回執消息後，才能完成轉賬流程嗎？

此外，我們曾提到，RGB 網絡沒有共識，每個客戶端都是孤島，不利於把傳統公鏈上的複雜智能合約場景遷移到 RGB 網絡中，因爲以太坊或 Solana 上的 Defi 協議都依賴於全局可見、數據透明的賬本。如何優化 RGB 協議，提高用戶體驗並解決上述問題？這成爲了 RGB 協議繞不開的一個問題。

RGB++：客戶端驗證變爲樂觀的託管

名爲 RGB++ 的協議提出了新思路，它把 RGB 協議與 CKB、Cardano、Fuel 等支持 UTXO 的公鏈結合起來，由後者作爲 RGB 資產的驗證層與數據存儲層，把原本由用戶進行的數據驗證工作，移交給 CKB 等第三方平臺 / 公鏈，這相當於把客戶端驗證替換爲「第三方去中心化平臺做驗證」，只要你信任 CKB、Cardano、Fuel 等公鏈即可，如果你不信任他們，也可以切換回傳統的 RGB 模式。

RGB++ 和原始的 RGB 協議，理論上是可以彼此兼容的，並不是有他無我。

要實現上面提到的效果，需要藉助一種名爲「同構綁定」的思想。CKB 和 Cardano 等公鏈有自己的拓展型 UTXO，它比 BTC 鏈上的 UTXO 多出了可編程性。而「同構綁定」，就是將 CKB、Cardano、Fuel 鏈上的拓展型 UTXO 作爲 RGB 資產數據的「容器」，把 RGB 資產的參數寫入到這些容器中，在區塊鏈上直接展示出來。每當 RGB 資產交易發生時，對應的資產容器也可以呈現出相似特徵，就像是實體和影子的關係一樣，這便是「同構綁定」的精髓。

For example，假如 Alice 擁有 100 枚 RGB 代幣，以及比特幣鏈上的 UTXO A，同時在 CKB 鏈上有一個 UTXO，這個 UTXO 上標記着「RGB Token Balance： 100 」，解鎖條件與 UTXO A 有關聯。

如果 Alice 想把 30 枚代幣送給 Bob，可以先生成一個 Commitment，對應的聲明是：把 UTXO A 關聯的 RGB 代幣，轉移 30 枚給 Bob， 70 枚轉給自己控制的其他 UTXO。

之後，Alice 在比特幣鏈上花費 UTXO A，發佈上述聲明，然後在 CKB 鏈上發起交易，把承載 100 枚 RGB 代幣的 UTXO 容器消費掉，生成兩個新容器，一個容納 30 枚代幣（給 Bob），一個容納 70 枚代幣（Alice 控制）。在此過程中，驗證 Alice 的資產有效性與交易聲明有效性的任務，是由 CKB 或 Cardano 等網絡節點走共識來完成的，不需要 Bob 介入。此時，CKB 和 Cardano 等充當了比特幣鏈下的驗證層與 DA 層。

所有人的 RGB 資產數據都存放在 CKB 或 Cardano 鏈上，具有全局可驗證的特性，利於 Defi 場景的實現，比如流動性池和資產質押協議等。當然上述做法也犧牲了隱私性，本質是在隱私和產品易用性之間做取捨，如果你追求極致的安全與隱私，可以切換回傳統 RGB 模式；如果你不在意這些，就可以放心採用 RGB++ 的模式，完全看你個人的需求。（其實藉助 CKB 和 Cardano 等公鏈強大的功能完備性，可以藉助 ZK 來實現隱私交易）

這裏要強調，RGB++ 引入了一個重要的信任假設：用戶要樂觀的認爲，CKB/Cardano 這條鏈，或者說由大量節點靠共識協議組成的網絡平臺，是可靠無誤的。如果你不信任 CKB，也可以遵循原始 RGB 協議中的交互式通訊與驗證流程，自己運行客戶端。

在 RGB++ 協議下，用戶無需跨鏈即可直接用比特幣賬戶，操作自己在 CKB/Cardano 等 UTXO 鏈上的 RGB 資產容器，只需要藉助上述公鏈中 UTXO 的特性，把 Cell 容器的解鎖條件設定爲與某個比特幣地址 / 比特幣 UTXO 相關聯即可。如果 RGB 資產交易雙方信得過 CKB 的安全性，甚至不必頻繁的在比特幣鏈上發佈 Commitment，可以在許多筆 RGB 轉賬進行後，再彙總發送一個 Commitment 到比特幣鏈上，這被稱爲「交易摺疊」功能，可以降低使用成本。