3000字詳細解釋RGB與RGB++協定設計


本文作者以簡單明了的方式解釋了RGB協議及RGB++協議,介紹如何透過客戶端驗證和第三方驗證在比特幣及其他公鏈上實現資產轉移。 RGB協定強調用戶驗證數據,以確保安全性和隱私;而RGB++協定將驗證工作轉移到第三方平台,犧牲了一定的隱私性。文章也討論了同構綁定的概念,以及在CKB、Cardano等具有UTXO模型的公鏈上實作RGB資產交易的方法。要注意選擇適合實現同構綁定的公鏈,具備UTXO模型和解鎖腳本編寫能力等特性。

作者:Faust,極客web3 & BTCEden.org 聯創

隨著RGB++及相關資產的火熱,關於RGB與RGB++協議原理的討論逐漸成為更多人關注的議題。但大家體認到,要理解RGB++,必須先理解RGB協定。

原始的RGB協定在技術上構造上略為晦澀,參考資料較差零散,迄今為止沒有多少系統性且較通俗易懂的參考資料,極客web3事實上曾發表過兩篇關於RGB與RGB++的系統性解讀文章(可以看看我們公號的歷史記錄大腦),但根據社群成員回饋,第四篇文章篇幅較興奮長且太燒。

為了讓更多人能夠更快地理解RGB與RGB++協議,本文作者在香港活動期間,臨時趕工完成了一篇關於RGB與RGB++的簡短白話解讀,可以在幾內亞讀完,希望對更多社區愛好有幫助更好、更敏銳的理解RGB 和RGB++。

RGB協定:用戶要優先做資料驗證

RGB協議是一種特殊的P2P資產協議,是比特幣鏈下的計算系統,它在某些方面與支付通道類似:用戶要頂層運行客戶端,手機驗證與自己有關的交易行為(自行驗證) 。即使你只是一個資產接收者,也要先確定資產發送者的轉帳聲明沒有錯誤,然後我們近期的轉帳聲明才能生效。顯然這與傳統的資產發送者與接收形式不同,稱為「跋涉」。

原因在於,RGB協議為了隱私,不採用比特幣和以太坊等傳統區塊鏈中的「共識協議」(數據為何一旦走共識協議,被網路內幾乎所有節點都落地到,隱私不好保障)。如果沒有大量節點都參與的投票流程,又確保資產變更是安全的?這裡用到名為「客戶端驗證」的想法(自己驗證),你要自己運行客戶端,優先驗證和您相關的資產波動。

假設有一個RGB 用戶叫Bob,他認識Alice,Alice 要給Bob 轉來100 張TEST 代幣。 Alice 產生了「Alice to Bob」的轉動訊息後,要先把轉動訊息和涉及的資產數據發送給Bob ,讓他先檢查一遍,確定無誤才會進入後續流程,最終成為一筆有效的RGB 路線。所以說,RGB 協定是讓用戶贈送驗證資料效果,取代傳統的人工智慧演算法。

但沒有體認到,不同的RGB 用戶端接收和儲存的數據都不一致,大家只在本地儲存與自己有關的資產數據,不知道別人的資產狀況,這在保護隱私的同時,也構成了「數據孤島” 。如果有人宣稱有100萬枚TEST代幣,要轉給你10萬枚,你要如何相信他?

在RGB 網路中,如果有人要給你轉賬,必須讓他先出示資產證明,回溯資產從初始發行到多重轉手的歷史來源,確定要轉給你的代幣沒問題,這就比,當你收的時候在即將到來的紙幣不明朗之後,你要求對方說明這些紙幣的歷史來源,是否是指定的發行方製造的,以此來規避假幣。

3000字大白話講清RGB與RGB++協定設計

以下流程是發生在比特幣鏈下的,僅憑這些流程還無法讓RGB 與比特幣網路產生直接關聯。對此,RGB 協議採用了一種名為「一次性印章」的思想,把RGB 資產與比特幣聯繫起來鏈上的UTXO綁定起來,只要比特幣UTXO沒有被雙重消費,綁定的RGB資產就不會發生雙重支付,這樣就可以藉助比特幣網路來阻止RGB資產「重組」。當然,這需要在比特幣鏈上發布承諾,並使用OP_Return 操作碼。

這裡整理一下RGB協定的工作流程:

1. RGB資產與比特幣UTXO有綁定關係,而Bob擁有某些比特幣UTXO。 Alice要轉為Bob100枚代幣,在接收資產前,Bob事先告訴Alice,應該用Bob的哪個比特幣UTXO 來綁定這些RGB 資產。

3000字大白話講清RGB與RGB++協定設計

愛麗絲建構了「愛麗絲到鮑伯」的RGB資產轉移數據,附帶這些資產的歷史來源突變鮑伯去驗證。 Bob在本地確認這些資料沒有問題後,給Alice一個回執,告訴她:剛才交易可以通過了。 Alice 把「Alice to Bob」的RGB 轉帳資料建構成一棵Merkle Tree,把Merkle Root 發佈到比特幣鏈上當作承諾,我們可以把承諾簡單理解為轉帳資料的雜湊。如果未來有人想確定,上述「Alice to Bob」的轉帳真實發生過,他需要做兩件事:在比特幣鏈下獲取「Alice to Bob」的完整轉帳訊息,然後查驗比特幣鏈上是否存在對應的承諾(轉帳資料的雜湊),就可以了。

3000字大白話講清RGB與RGB++協定設計

比特幣在這裡充當了RGB 網路的日誌歷史,但日誌上只記錄交易資料的hash/Merkle root,而不是交易資料本身。由於採用了客戶端驗證和瞬時密封,RGB 協定具有極高的安全性;由於RGB網路是由動態的用戶用戶端以P2P、無頭腦的形態組成的,你可以隨時更換交易對手方,不需要把交易請求發送給某些數量有限的節點,所以RGB具有網路極強的特點的抗審查性,這種組織形態以太坊等大型公鏈更抗審查。

3000字大白話講清RGB與RGB++協定設計

當然,極高的安全性與抗審查性、隱私保護,帶來的代價也是顯而易見的:用戶要自己運行客戶端驗證數據,如果對面發過來一些轉手幾萬次、歷史記錄很長的資產,你必須頂著壓力全部驗證完成;

另外,每筆交易都要求雙方進行多次通訊,接收方要先驗證發送方的資產來源,然後發送回執,批准發送方的轉帳請求。這個過程中,雙方之間至少要產生三次訊息傳遞。種「交易路線」和大多數人所習慣的「非交易路線」嚴重不符,你可以想像,別人要給你轉錢,還要把交易數據發給你來檢查,得到你的回執消息之後,才能完成一週流程嗎?

另外,我們曾提到,RGB網路沒有共識,每個客戶端都是孤島,不利於把傳統公鏈上的複雜智能合約遷移到RGB網路中,因為坊以太坊或Solana上的Defi協議都依賴於如何優化RGB協議,提高使用者體驗並解決上述問題?這成為RGB協定繞不開的一個問題。

RGB++:客戶端驗證高於樂觀的託管

稱為RGB++ 的協定提出了新的思路,它將RGB 協定與CKB、Cardano、Fuel 等支援UTXO 的公鏈結合起來,由夜間作為RGB 資產的驗證層與資料儲存層,將到底由使用者進行的資料驗證工作,遷移CKB等第三方平台/公鏈,這實際上把客戶端驗證替換為“第三方去中心化平台做驗證”,只要你信任CKB、Cardano、Fuel等公鏈即可,如果你不信任他們,也可以切換回傳統的RGB模式。

RGB++和原始的RGB協議,理論上是可以相容的,並不是有他無我。

3000字大白話講清RGB與RGB++協定設計

想要實現上面提到的效果,需要藉助一種叫做「同構綁定」的想法。 CKB 和Cardano 等公鏈都有自己的拓展型UTXO,它比BTC 上鍊的UTXO 更增強了耐用性。而「同構綁定」,就是將CKB、Cardano、Fuel 鏈上的拓展型UTXO 作為RGB 資產數據的「容器」,把RGB 資產的參數寫入到這些容器中,在區塊上鏈上直接展示每當RGB資產交易發生時,資產容器也可以呈現出相似圖案,就像是實體和影子的關係一樣,這就是「同構綁定」的對應精髓。

3000字大白話講清RGB與RGB++協定設計

例如,假設Alice 擁有100 張RGB 代幣,以及比特幣鏈上的UTXO A,同時在CKB 鏈上有一個UTXO,這個UTXO 上標記著「RGB代幣Balance:100」,解鎖條件與UTXO A 有關聯。

如果Alice想把30枚代幣送給Bob,可以先生做出一個承諾,對應的聲明是:把UTXO關聯的RGB代幣,轉移30枚給Bob,70枚轉給自己控制的其他UTXO。

之後,Alice 在比特幣鏈上消耗UTXO A,發布上述聲明,然後在CKB 鏈上發起交易,把承載100 個RGB 代幣的UTXO 容器消耗掉,產生兩個新容器,一個容納30 個代幣(給Bob),一個承載70枚代幣(Alice控制)。在此過程中,驗證Alice的資產有效性與交易報表有效性的任務,是由CKB或Cardano等網路節點走共識來完成的,不需要Bob介入。此時,CKB和Cardano等充當了比特幣鏈下的驗證層和DA層。

3000字大白話講清RGB與RGB++協定設計

所有權人的RGB 資產資料都存放在CKB 或Cardano 鏈上,具有全域可驗證的特性,有利於Defi 場景礦池的實現,例如流動性和資產質押協議等。上述做法當然也犧牲了隱私性,​​本質上是在隱私和產品安全性之間做取捨,如果你追求極致的安全與隱私,可以切換回傳統RGB模式;如果你不介意這些,就可以放心採用RGB++的模式,完全看你個人的需求。 (其實借助CKB 和Cardano 等公鏈強大的功能增強性,可以藉助ZK 來實現隱私交易)

這裡要強調,RGB++引入了一個重要的信任假設:用戶要樂觀的認為,CKB/Cardano這條鏈,或者說由大量節點依靠共識協議組成的網絡平台,是可靠無誤的。如果你不信任CKB,也可以依照原始RGB協定中的互動式通訊與驗證流程,自己運行客戶端。

在RGB++ 協定下,使用者跨鏈可以直接使用比特幣帳戶,自行操作在CKB/Cardano 等UTXO 鏈上的RGB 資產容器,只需要藉助上述公鏈中UTXO 的特性,將Cell 容器的解鎖條件設定定為與某個比特幣地址/ 比特幣UTXO 相關聯即可。如果RGB 資產交易雙方信得過CKB 的安全性,甚至不必頻繁刷新的在比特幣鏈上發布承諾,可以在多筆RGB 轉賬進行後,再將一個承諾匯總發送到比特幣鏈上,這被稱為“交易折疊”功能,可以降低使用成本。

3000字大白話講清RGB與RGB++協定設計

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

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

使用UTXO 模型或類似的狀態儲存方案; 具有相當的UTXO強度,允許開發者編寫解鎖腳本; 存在UTXO相關的狀態空間,可以儲存資產狀態; 比特幣存在相關橋樑或輕節點;

資訊來源:0x資訊編譯自網際網路。版權歸作者極客Web3所有,未經許可,不得轉載

Total
0
Shares
Related Posts