原文作者：Faust，極客web3 & BTCEden.org 聯創
原文來源： 極客 Web3
随着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沒問題，這就好比，當你收到來路不明的紙币後，你要求對方說明這些紙币的曆史來源，是否是指定的發行方制造的，以此來規避假币。
（圖檔來源：Coinex）
上述流程是發生在比特币鍊下的，僅憑這些過程還無法讓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資産。
（圖檔來源：極客web3/ GeekWeb3）
2.Alice構造一筆 “Alice to Bob” 的RGB資産轉賬資料，附帶這些資産的曆史來源交給Bob去驗證。
3.Bob在本地确認這些資料沒問題後，給Alice發送一個回執，告訴她：這筆交易可以通過了。
4.Alice把這筆“Alice to Bob”的RGB轉賬資料建構成一棵Merkle Tree，把Merkle Root釋出到比特币鍊上作為Commitment，我們可以把Commitment簡單了解為轉賬資料的hash。
5.如果未來有人想确定，上述“Alice to Bob”的轉賬真實發生過，他需要做兩件事：在比特币鍊下擷取“Alice to Bob”的完整轉賬資訊，然後查驗比特币鍊上是否存在對應的Commitment（轉賬資料的hash），就可以了。
比特币在此充當了RGB網絡的曆史日志，但日志上隻記錄交易資料的hash/Merkle root，而非交易資料本身。由于采用了用戶端驗證和一次性密封，RGB協定具有極高的安全性；由于RGB網絡是由動态的使用者用戶端以P2P、無共識的形态組成的，你可以随時更換交易對手方，不需要把交易請求發送給某些個數量有限的節點，是以RGB網絡具有極強的抗審查性，這種組織形式要比以太坊等大型公鍊更抗審查。
（圖檔來源：BTCEden.org ）
當然，極高的安全性與抗審查性、隐私保護，帶來的代價也是明顯的：使用者要自己運作用戶端驗證資料，如果對面發過來一些轉手幾萬次、曆史記錄很長的資産，你也要頂着壓力全部驗證完；
此外，每筆交易都要求雙方進行多次通訊，接收方要先驗證發送方的資産來源，然後發送回執，準許發送方的轉賬請求。這個過程中，雙方之間至少要産生三次消息傳遞。這種“互動式轉賬”和大多數人所習慣的“非互動式轉賬”嚴重不符合，你能想象，别人要給你轉錢，還要把交易資料發給你來檢查，得到你的回執消息後，才能完成轉賬流程嗎？
此外，我們曾提到，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資産交易發生時，對應的資産容器也可以呈現出相似特征，就像是實體和影子的關系一樣，這便是“同構綁定”的精髓。
（圖檔來源：RGB++ LightPaper）
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++ LightPaper）
所有人的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相關的狀态空間，可以存儲資産狀态；
- 存在比特币相關橋或者輕節點；