RGB++ 的「同構綁定」,如何賦能 RGB、Atomical 和 Runes 等比特幣生態資產協定
編輯:Faust,極客 Web3
![](https://web3caff.com/wp-content/uploads/2024/03/image-497.png)
摘要:· CKB 團隊提出的 RGB++資產協定,提出了 「同構綁定」的思想,本質是將 CKB 和 Cardano、Fuel 等基於 UTXO 程式設計模型的區塊鏈,作為承載 RGB 資產 “容器” 的功能拓展層。 這種同構綁定還適用於 Atomical、Runes 等具有 UTXO 特性的比特幣生態資產協定,便於為比特幣搭建鏈下的智慧合約層。
· RGB++協定中,使用者不必運行客戶端親自驗證交易數據,可以把驗證資產有效性、數據存儲等工作移交給 CKB 和 Cardanao 等 UTXO 鏈。 只要你「樂觀」的認為,上述公鏈的安全性比較可靠,就無需自己去做驗證;
· RGB++協定支援使用者切換回客戶端驗證模式,此時你依然可以將 CKB 作為數據存儲/DA 層,不必自己保管數據。 RGB++協定無需資產跨鏈,可通過比特幣帳戶對 CKB 鏈上資產進行操作,並且可以減少往比特幣鏈上發佈 Commitment 的頻率,也利於支援 Defi 場景;
· 如果是在 EVM 合約體系下,RGB++的許多特性並不好支援。 綜合來看,適合實現同構綁定的公鏈/功能拓展層,應該具有以下特性:
1. 使用 UTXO 模型或類似的狀態存儲方案;
2. 具有相當的 UTXO 可程式設計性,允許開發者編寫解鎖腳本;
3. 存在 UTXO 相關的狀態空間,可以存儲資產狀態;
4. 可以通過智慧合約或其他手段,支援運行比特幣輕節點;
· 除了 CKB 以外,Cardano、Fuel 也可以支援同構綁定,但後兩者在智慧合約語言及合約設計細節上,可能存在一些包袱,目前看來,CKB 比后兩者更適合作為同構綁定的比特幣資產協定功能拓展層。
![](https://web3caff.com/wp-content/uploads/2024/03/image-496.png)
正文:在 RGB++Protocol LightPaper 內,Nervos CKB 聯合創始人 Cipher 第一次提出了同構綁定的產品思路。 相比於其他比特幣 Layer2 方案,同構綁定可以更好的相容 RGB、Runes 和 Atomical 等資產協議,並且可以避免資產跨鏈等帶來額外安全累贅的因素。
簡單來說,同構綁定是用 CKB 和 Cardano 鏈上的 UTXO 做 “容器”,將 RGB 等 UTXO 型資產表達出來,進而為其添加可程式設計性及更多更複雜的場景。 此前,極客 web3 曾在《從 BTC 到 Sui、ADA 與 Nervos:UTXO 模型及其相關拓展》總結過一系列支援可程式設計 UTXO 的區塊鏈,本文將進一步探究這些區塊鏈是否可以適配同構綁定方案。
RGB++和同構綁定
在分析不同 UTXO 鏈對同構綁定的相容程度前,我們要先介紹一下同構綁定的原理。 同構綁定是 CKB 團隊在 RGB++協定中提出的概念,所以此處我們以 RGB++的工作流程,來介紹基於 CKB 的同構綁定是什麼。
在介紹 RGB++協定前,我們先簡單瞭解一下 RGB 協定。 RGB 是一種運行在比特幣鏈下的資產協定/P2P 網路,有點像閃電網路一樣。 此外,RGB 還是一種基於比特幣 UTXO 的寄生資產協定,所謂寄生,是指 RGB 用戶端會在比特幣鏈下,聲明某些 RGB 資產與比特幣鏈上哪個 UTXO 相綁定,你擁有了這個 UTXO,它綁定的 RGB 資產也歸你差遣。
RGB 協定和 ERC-20 等資產協議的運作方式截然不同。 乙太坊上的 ERC-20 合約中,記錄了所有使用者的資產狀態,且乙太坊的節點用戶端會同步並驗證所有的轉帳資訊,把轉帳后的狀態更新記錄在資產合約中。 這其實早已被人們所熟知,無非是靠乙太坊的共識流程,來保證資產的狀態變更沒貓膩。 由於乙太坊節點們的共識很可靠,使用者就算不運行用戶端,也可以默認基於 ERC-20 合約的資產託管平臺「沒問題」。
![](https://web3caff.com/wp-content/uploads/2024/03/image-495.png)
但 RGB 協定卻很奇葩,它為了增強隱私性,乾脆把節點/客戶端共識這個在區塊鏈世界里約定俗成的東西刪掉了。 使用者要自己運行 RGB 用戶端,只接收和存儲「與自己相關的資產數據」,看不到別人都幹了啥,不像乙太坊和 ERC-20 那樣,有鏈上全部可見的轉帳記錄。
這種情況下,如果有人給你轉來一些 RGB 資產,你事先並不知道這些錢是怎麼造出來的,轉手自哪些人。 如果對面那個人憑空聲明一種資產,然後轉給你一部分,這種造假幣的作惡場景怎麼處理?
RGB 協議採用了這樣一種思路:每一筆轉帳生效前,接收者先讓發送者出示該資產的全部歷史記錄,比如從創世階段到現在,這些資產是由誰發行的,中間途經哪些人,在這些人之間發生的每一次資產轉移,是否都不違背會計記帳準則(一人加,一人減)。
這樣一來,你就能知道對面給你的是不是「有問題的錢」,所以說 RGB 本質是讓交易當事人自己運行用戶端做驗證,基於客戶端驗證模式,對應著理性人博弈假設,只要當事人理智,用戶端軟體沒問題,就能保證有問題的資產轉移無法生效,或無法被其他人認可。
值得注意的是,RGB 協定會把這些比特幣鏈下的交易數據,壓縮為 Commitment(本質是個 merkle root),上傳到比特幣鏈上,這就讓鏈下的轉帳記錄,與比特幣主網直接產生關聯。
![](https://web3caff.com/wp-content/uploads/2024/03/image-494.png)
由於 RGB 用戶端之間沒有共識,RGB 資產合約的發佈無法「極其可靠」的傳播給所有節點,合約發行者和用戶乾脆就通過電子郵件或是推特等任意形式,自發的獲知 RGB 資產合約的細節,形式非常隨意。
下圖中展示了惡意的 RGB 資產轉移場景,作為 RGB 使用者,我們要在自己的用戶端本地,存儲 RGB 資產對應的智能合約。 當其他人向我們轉帳時,我們根據本地存儲的資產合約內容,可以知道當前這筆轉帳是否違反合約中定義好的規則。 根據對面提供的資產來源資訊(歷史記錄),可以確認對方的資產來源有沒有問題(是不是憑空聲明出來的)。
![](https://web3caff.com/wp-content/uploads/2024/03/image-493.png)
復盤上述流程,不難看出,不同的 RGB 用戶端接收並存儲的數據往往是獨立的,你往往不知道別人有哪些資產,有多少數額。 反過來,別人基本也不知道你的資產狀況。
這就是典型的數據孤島,也就是大家存儲的數據都不一致。 理論上雖然可以提高隱私程度,但相應的也帶來了很多麻煩。 你必須在自己的用戶端本地維護好 RGB 資產的數據,這些數據一旦丟失,就會造成嚴重後果(資產不可用)。 但事實上,只要你維護好本地數據,RGB 協定就可以為你帶來和比特幣主網基本等價的安全性。
![](https://web3caff.com/wp-content/uploads/2024/03/image-492.png)
此外,RGB 用戶端之間通訊用的 Bifrost 協定,會協助使用者和其他用戶端進行 p2p 通訊,可以把他的資產數據加密後傳播給其他節點,叫對方幫忙存儲(注意是加密後的數據,對面不知道明文)。 只要你不把密鑰也弄丟了,在本地數據丟失時,可以通過網路中其他節點,還原出自己原本擁有的資產數據。
但原始 RGB 協定的缺點還是很明顯,首先每筆交易都要求雙方進行多次通訊,接收方要先驗證發送方的資產來源,然後發送回執,批准發送方的轉帳請求。 這個過程中,雙方之間至少要產生三次消息傳遞。 這種「互動式轉帳」和大多數人所習慣的「非互動式轉帳」嚴重不符合,你能想像,別人要給你轉錢,還要把交易數據發給你來檢查,得到你的回執消息后,才能完成轉帳流程嗎?(流程圖在前文可見)
其次,絕大多數的 Defi 場景都需要數據透明、狀態可驗證的智能合約,但 RGB 協定天生不支援此類場景,所以是對 Defi 非常不友好的; 此外,RGB 協定里用戶必須去運行用戶端做自驗證,如果你偶然間接收到一筆轉手自幾萬人的資產,你甚至還要驗證這筆資產的幾萬次轉手記錄。 很顯然,所有的事情都讓使用者去自行解決,並不利於產品本身的推廣和採用。
對於上述問題,RGB++的解決思路是:讓使用者在用戶端自驗證模式,與第三方託管模式之間自由切換,使用者可以把數據驗證與存儲、智慧合約託管等包袱,甩給 CKB 去承擔,當然使用者要樂觀的信任,CKB 這條 POW 公鏈是可靠的; 如果某些對安全和隱私有更高追求的人,比如手握大量資產的大戶,也可以回退到原始的 RGB 模式。 這裡要強調的是,RGB++和原始的 RGB 協議,理論上是可以彼此相容的,並不是有他無我。
![](https://web3caff.com/wp-content/uploads/2024/03/image-491.png)
在此前的文章 《從 RGB 到 RGB++:CKB 如何賦能比特幣生態資產協定》中,我們曾簡單科普過 RGB++的 “同構綁定”,這裡我們再快速的復盤下:
CKB 有自己的拓展型 UTXO,叫 Cell,它比 BTC 鏈上的 UTXO 多出了可程式設計性。 而「同構綁定」,就是將 CKB 鏈上的 Cell 作為 RGB 資產數據的「容器」,把 RGB 資產的關鍵參數寫入到 Cell 中。
![](https://web3caff.com/wp-content/uploads/2024/03/image-490.png)
由於 RGB 資產和比特幣 UTXO 存在綁定關係,所以在資產的邏輯形式上具備 UTXO 的特性。 而同樣具備 UTXO 特性的 Cell,自然適合作為 RGB 資產的「容器」。。 每當 RGB 資產交易發生時,對應的 Cell 容器,也可以呈現出相似的特徵,就像是實體和影子的關係一樣,這便是 “同構綁定” 的精髓。
For example,假如 Alice 擁有 100 枚 RGB 代幣,以及比特幣鏈上的 UTXO A,同時在 CKB 鏈上有一個 Cell,這個 Cell 上標記著 “RGB Token Balance:100”,解鎖條件與 UTXO A 有關聯。
如果 Alice 想把 30 枚代幣送給 Bob,可以先生成一個 Commitment,對應的聲明是:把 UTXO A 關聯的 RGB 代幣,轉移 30 枚給 Bob,70 枚轉給自己控制的其他 UTXO。
之後,Alice 在比特幣鏈上花費 UTXO A,發佈上述聲明,然後在 CKB 鏈上發起交易,把承載 100 枚 RGB 代幣的 Cell 容器消費掉,生成兩個新容器,一個容納 30 枚代幣(給 Bob),一個容納 70 枚代幣(Alice 控制)。 在此過程中,驗證 Alice 的資產有效性與交易聲明有效性的任務,是由 CKB 網路節點走共識來完成的,不需要 Bob 介入。 CKB 此時充當了一個比特幣鏈下的驗證層與 DA 層。
![](https://web3caff.com/wp-content/uploads/2024/03/image-489.png)
這就類似於乙太坊 ERC-20 合約每次狀態變更,不需要使用者去運行客戶端驗證,道理差不多,由共識協定和節點網路,來替代客戶端驗證。 而且,所有人的 RGB 資產數據都存放在 CKB 鏈上,具有全域可驗證的特性,這利於 Defi 場景的實現,比如流動性池和資產質押協定等。
這裡面其實引入了一個重要的信任假設:使用者往往要樂觀的認為,CKB 這條鏈,或者說由大量節點靠共識協定組成的網路平臺,是可靠無誤的。 如果你不信任 CKB,也可以遵循原始 RGB 協定中的互動式通訊與驗證流程,自己運行用戶端。
當然,如果有人偏要自己運行 RGB++客戶端,驗證別人的資產歷史來源,他可以直接驗證 CKB 鏈上與 RGB 資產容器 Cell 相關的歷史。 只要運行一個 CKB 輕節點,通過接收 Merkle Proof 和 CKB 區塊頭,就可以確信自己收到的歷史數據,沒被網路中的惡意攻擊者篡改。 可以說,CKB 在這裡又充當了歷史數據存儲層。
簡單來說,同構綁定不但適用於 RGB,還適用於 Runes、Atomical 等各種有 UTXO 特性的資產協定,它把存儲在使用者用戶端本地的資產狀態、歷史數據,以及對應的智慧合約,全部挪給 CKB 或 Cardano 等 UTXO 型公鏈來存儲和託管。 上述 UTXO 型資產協定,可以把 CKB 或 Cardano 的 UTXO 模型作為「容器」,藉著容器來展現出資產的形態與狀況,便於配合智慧合約等場景。
而且在同構綁定協定下,使用者無需跨鏈即可直接用比特幣帳戶,操作自己在 CKB 等 UTXO 鏈上的 RGB 資產容器,只需要借助 Cell 的 UTXO 特性,把 Cell 容器的解鎖條件設定為與某個比特幣位址/比特幣 UTXO 相關聯即可。 由於在極客 web3 之前的 RGB++科普文中,我們已經對 Cell 的特性進行過解讀,所以不在此贅述。
![](https://web3caff.com/wp-content/uploads/2024/03/image-488.png)
如果 RGB 資產交易雙方信得過 CKB 的安全性,甚至不必頻繁的在比特幣鏈上發布 Commitment,可以在許多筆 RGB 轉帳進行後,再匯總發送一個 Commitment 到比特幣鏈上,這被稱為 “交易摺疊” 功能,可以降低使用成本。
但需要注意的是,同構綁定採用的「容器」,往往需要支援 UTXO 模型的公鏈,或是在狀態存儲上有類似特徵的 infra,而 EVM 鏈顯然不太適合,在技術實現上會遇到很多坑。 首先,前文提到 RGB++“無需跨鏈即可操作 CKB 鏈上資產容器”,基本就無法在 EVM 鏈身上實現; 就算強行實現,成本也可能很高;
再者,在 RGB++協定中,很多人沒有必要運行用戶端或是把資產數據存放在本地。 如果用 ERC-20 的方式,把所有人的資產餘額都記錄在這個合約中,假如有人要回退到用戶端自驗證的模式,他提出要檢查某個人的資產來源,此時他就可能要把所有和資產合約產生交互的交易記錄,全都掃描一遍,這會帶來巨大壓力。
直白的說,ERC-20 等資產合約,把所有人的資產狀態耦合在一起存儲,如果你要單獨檢驗其中某個人的資產變更歷史記錄,將會變得很難,就好像在一個公用的聊天室中,你想知道有哪些人給王剛發過消息,就不得不把整個聊天室里的消息記錄頂朝天翻一遍。 而 UTXO 就像是一對一的私聊頻道,你要查歷史記錄會很容易。
綜合來看,適合實現同構綁定的公鏈/功能拓展層,應該具有以下特性:
- 使用 UTXO 模型或類似的狀態存儲方案;
- 具有相當的 UTXO 可程式設計性,允許開發者編寫解鎖腳本;
- 存在 UTXO 相關的狀態空間,可以存儲資產狀態;
- 存在比特幣相關橋或者輕節點;
當然,我們也希望用於同構綁定的公鏈具有較強的安全性,另一方面,我們也希望該公鏈上的 UTXO 解鎖條件,應當是可程式設計的,如此一來,使用者就可以直接用 BTC 的簽名方案,解鎖自己在其他公鏈上同構綁定的 UTXO,而不需要再更換簽名演算法。
目前,CKB 上 UTXO 的鎖定腳本是可程式設計的,官方對此還相容了不同公鏈的簽名方案,對於同構綁定而言,CKB 網路基本符合以上幾個特性,那其他基於 UTXO 的公鏈呢?我們對 Fuel 和 Cardano 進行了初步考察,認為他們在理論上都可以支援同構綁定。
Fuel:基於 UTXO 的乙太坊 OP Rollup
Fuel 是一個基於 UTXO 的乙太坊 OP Rollup,還是把欺詐證明概念引入乙太坊 Layer2 生態的先驅。 對於正常的 UTXO 功能支援,Fuel 與 BTC 是基本一致的。
![](https://web3caff.com/wp-content/uploads/2024/03/image-487.png)
在 Fuel 將其內部的 UTXO 分為了以下三類:
Input Coin:標準的 UTXO,用於表示用戶的資產,具有原生的時間鎖,同時允許用戶編寫解鎖腳本 predicate;
Input Contract:用於合約調用的 UTXO,內部包含合約的狀態根和合約資產等數據;
Input Message:用於傳遞資訊的 UTXO,主要包含資訊接受人等字段;
當使用者花費 UTXO 後會產生以下輸出:
Output Coin:用於標準的資產轉帳;
Output Contract : 合約交互產生的輸出,內部包含合約交互后的狀態根;
Output Contract Created : 一種特殊的 UTXO,是創建合約時產生的輸出,內部包含合約的 ID 與狀態根;
與 CKB 的 Cell 內部包含所有的合約狀態不同,Fuel 的 UTXO 實際上並不會攜帶所有的與交易有關的合約狀態。 Fuel 僅在 UTXO 內,攜帶有合約的狀態根 Stateroot,也就是狀態樹的 root。 合約的完整狀態存儲在 Fuel 的狀態庫內部,由智慧合約所擁有。
值得一提的是,對於智慧合約的狀態處理,Fuel 合約與 solidity 合約在思想上一致,甚至在程式設計的形式上也比較接近。 下圖展示了一個用 Fuel 的 Sway 語言編寫的計數器合約,該合約包含一個計數器,當使用者調用 increment_counter 函數時,合約內存儲的計數器就自增 1。
我們可以看到,Sway 合約的編寫邏輯與一般的 Solidity 合約相似,我們首先給出合約的 ABI,然後給出合約的狀態變數,然後給出合約的具體實現。 所有的代碼編寫流程並沒有涉及到 Fuel 的 UTXO 系統。
![](https://web3caff.com/wp-content/uploads/2024/03/image-486.png)
所以,Fuel 的合約程式設計體驗不同於 CKB 和 Cardanao 等 UTXO 型程式設計語言,Fuel 提供了一種更接近 EVM 智慧合約程式設計開發的體驗。 開發者也可以使用 Sway 語言構造解鎖腳本,以實現特殊的簽名演演算法驗證邏輯,或者複雜的多簽等解鎖邏輯。
在 Fuel 內實現同構綁定是基本可行的,但還是存在以下問題:
Fuel 使用的 sway 語言,在智慧合約設計方面,思想更接近 EVM 鏈,而不是契合 BTC 或 CKB 和 Cardano,RGB、Atomicals 等 UTXO 型資產的發行者,要在 Fuel 上專門構造一種智慧合約,在 CKB 等鏈上用另一種,這是相當複雜的。
Cardano:基於 POS 的 eUTXO 公鏈
Cardaon 是另一個使用 UTXO 模型的區塊鏈,但不同於 Fuel,它是一個 Layer1 公鏈。 Cardano 用 eUTXO(拓展型 UTXO)來稱呼其系統內的 UTXO 程式設計模型。 相比於 CKB,Cardano 內的 eUTXO 包含以下幾部分結構:
Script: 智慧合約,用於驗證 UTXO 是否可以被解鎖與執行狀態轉換;
Redeemers: 使用者提供的用於解鎖 UTXO 的數據,一般為簽名數據,類似於比特幣的 Witness;
Datum: 智慧合約的狀態空間,可以存儲資產狀態等數據;
Transaction Context: UTXO 交易的上下文數據,如交易的輸入參數和結果 (UTXO 鏈的交易計算過程在鏈下直接進行,把計算結果提交到鏈上去驗證。 若通過驗證,則交易結果上鏈)
![](https://web3caff.com/wp-content/uploads/2024/03/image-485.png)
開發者可以使用 PlutusCore 語言在 Cardano 鏈上進行 UTXO 的程式設計,與 CKB 類似,開發者可以編寫解鎖腳本和一些用於狀態更新的函數。
我們以基於 UTXO 的拍賣流程介紹 Cardano 的 UTXO 程式設計模式。 假設我們需要實現一個資產拍賣 DAPP,要求使用者可以在拍賣結束前給出報價,具體來說,就是用戶消費自己的 UTXO,與此拍賣合約 UTXO,然後生成一個新的拍賣 UTXO。 當有人給出更高報價時,除了生成新的拍賣合約 UTXO,也會生成對上一個人的退款 UTXO。 具體流程如下圖:
![](https://web3caff.com/wp-content/uploads/2024/03/image-484.png)
實現上述拍賣流程,需要在拍賣智能合約 UTXO 內存儲一些狀態,比如當前拍賣的最高價與給出報價的人。 下圖展示了 PlutusCore 內部的狀態聲明,我們可以看到,bBidder 和 bAmount 展示了拍賣的報價和給出報價的錢包位址。 而 Auction Params 內則包含拍賣的基本資訊。
![](https://web3caff.com/wp-content/uploads/2024/03/image-483.png)
當用戶花費此 UTXO 時,我們可以更新合約內的狀態。 下圖展示了拍賣合約內一些具體的狀態更新和業務邏輯。 比如校驗使用者報價和校驗當前拍賣是否仍在進行的邏輯。 當然,由於 PlutusCore 是 Haskell 程式設計語言,這是一種純函數式程式設計語言,大部分開發者可能無法直接看懂其含義。
![](https://web3caff.com/wp-content/uploads/2024/03/image-482.png)
在 Cardano 上構造同構綁定具有可行性,我們可以使用 Datum 存儲資產狀態,並編寫特定的腳本來相容比特幣相關簽名演算法。 但嚴重的問題是,大部分程式師可能無法適應使用 PlutusCore 進行合約程式設計,而且其程式設計環境是較難搭建的,對開發者而言並不友好。
總結
同構綁定要求鏈具有以下屬性:
- 使用 UTXO 模型
- 具有相當的 UTXO 可程式設計性,允許開發者編寫解鎖腳本
- 存在 UTXO 相關的狀態空間,可以存儲資產狀態
- 可以通過智慧合約或其他手段,支援運行比特幣輕節點
Fuel 由於其智慧合約程式設計思想的特殊性,雖然可以相容同構綁定,但還是會帶來一些包袱; 而 Cardaon 使用 Haskell 程式設計語言進行合約程式設計,大部分開發者很難快速上手。 基於上述理由,採用 RISC-V 指令集並在 UTXO 程式設計的特性上更平衡的 CKB,可能是更適配同構綁定的功能拓展層。
免責聲明:作為區塊鏈資訊平臺,本站所發佈文章僅代表作者及嘉賓個人觀點,與 Web3Caff 立場無關。 文章內的資訊僅供參考,均不構成任何投資建議及要約,並請您遵守所在國家或地區的相關法律法規。