本文將用簡短的白話解讀比特幣資產發行協議 RGB 與 RGB++ 的設計原理，希望幫助更多社群愛好者更好、更直觀的理解 RGB 與 RGB++。
（前情提要：BTC資產發行擴展協議 RGB++ 是什麼？如何爭奪比特幣正統Layer2市場 ）
（背景補充：BTC生態下個熱點？RGB協議上值得關注的專案 ）
隨著 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 資產。
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++ 的協議提出了新思路，它把 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 鏈不太適合，會遇到很多坑。
綜合來看，適合實現同構繫結的公鏈 / 功能拓展層，應該具有以下特性:
- 使用 UTXO 模型或類似的狀態儲存方案；
- 具有相當的 UTXO 可程式設計性，允許開發者編寫解鎖指令碼；
- 存在 UTXO 相關的狀態空間，可以儲存資產狀態；
- 存在比特幣相關橋或者輕節點。
相關報導