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）

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網路具有極強的抗審查性，這種組織形式要比以太坊等大型公鏈更抗審查。

（圖片來源：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如何賦能比特幣生態》；

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

1. 使用UTXO模型或類似的狀態存儲方案；
2. 具有相當的UTXO可編程性，允許開發者編寫解鎖腳本；
3. 存在UTXO相關的狀態空間，可以存儲資產狀態；
4. 存在比特幣相關橋或者輕節點；

聲明：

本文轉載自[極客 Web3]，原文標題“幾分鍾速通RGB與RGB++協議設計：白話說明書”，著作權歸屬原作者[Faust]，如對轉載有異議，請聯系Gate Learn團隊，團隊會根據相關流程盡速處理。

免責聲明：本文所表達的觀點和意見僅代表作者個人觀點，不構成任何投資建議。

文章其他語言版本由Gate Learn團隊翻譯， 在未提及Gate.io的情況下不得復制、傳播或抄襲經翻譯文章。