menu-icon
anue logo
澳洲房產鉅亨號鉅亨買幣
search icon
區塊鏈

速通RGB與RGB++協議設計:白話說明書

BlockBeats 律動財經 2024-04-07 16:00

cover image of news article
律動財經圖片

隨著 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)

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 如何賦能比特幣生態》;

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

· 使用 UTXO 模型或類似的狀態儲存方案;

· 具有相當的 UTXO 可編程性,允許開發者編寫解鎖腳本;

· 存在 UTXO 相關的狀態空間,可以儲存資產狀態;

· 存在比特幣相關橋或者輕節點;

原文連結

暢行幣圈交易全攻略,專家駐群實戰交流

▌立即加入鉅亨買幣實戰交流 LINE 社群(點此入群
不管是新手發問,還是老手交流,只要你想參與虛擬貨幣現貨交易、合約跟單、合約網格、量化交易、理財產品的投資,都歡迎入群討論學習!

前往鉅亨買幣找交易所優惠

文章標籤





Empty