作者：Faust，極客web3 & BTCEden.org 聯創
隨著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 要轉給Bob100 枚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 到比特幣鏈上，這被稱為“交易折疊”功能，可以降低使用成本。
但要注意，同構綁定採用的「容器」，需要支援UTXO 模型的公鏈，或在狀態儲存上有類似特徵的基礎設施，EVM 鏈不太適合，會遇到很多坑。 （此主題可單獨成文，涉及的內容較多，有興趣的讀者可以參考極客web3 先前文章《RGB++ 與同構綁定：CKB、Cardano 與Fuel 如何賦能比特幣生態》；
綜合來看，適合實現同構綁定的公鏈/ 功能拓展層，應該具有以下特性:
- 使用UTXO 模型或類似的狀態儲存方案；
- 具有相當的UTXO 可編程性，允許開發者編寫解鎖腳本；
- 存在UTXO 相關的狀態空間，可儲存資產狀態；
- 存在比特幣相關橋或輕節點；
APP 
