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

原始的 RGB 協議在技術構造上略為晦澀，參考資料較為零散，至今沒有多少系統性且較通俗易懂的參考資料，極客 web3 此前雖曾發表過兩篇關於 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 資產。

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

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

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

4.如果未來有人想確定，上述「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 到比特幣鏈上，這被稱為「交易摺疊」功能，可以降低使用成本。

但要注意，同構綁定採用的「容器」，需要支持 UTXO 模型的公鏈，或是在狀態儲存上有類似特徵的基礎設施，EVM 鏈不太適合，會遇到很多坑。（此話題可以單獨成文，涉及的內容較多，有興趣的讀者可以參考極客 web3 此前文章 《RGB++ 與同構綁定：CKB、Cardano 與 Fuel 如何賦能比特幣生態》；

綜合來看，適合實現同構綁定的公鏈 / 功能拓展層，應該具有以下特性：

· 使用 UTXO 模型或類似的狀態儲存方案；

· 具有相當的 UTXO 可編程性，允許開發者編寫解鎖腳本；

· 存在 UTXO 相關的狀態空間，可以儲存資產狀態；

· 存在比特幣相關橋或者輕節點；

原文連結