市場新聞

RGB++與同構綁定:CKB、Cardano與Fuel如何賦能比特幣生態

By 極客 Web3 2024-03-22 00:35
RGB++與同構綁定:CKB、Cardano與Fuel如何賦能比特幣生態

作者:Shew,極客web3

摘要:

· 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比後兩者更適合作爲同構綁定的比特幣資產協議功能拓展層。

在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合約的資產托管平台“沒問題”。

RGB協議卻很奇葩,它爲了增強隱私性,幹脆把節點/客戶端共識這個在區塊鏈世界裏約定俗成的東西刪掉了。用戶要自己運行RGB客戶端,只接收和存儲“與自己相關的資產數據”,看不到別人都幹了啥,不像以太坊和ERC-20那樣,有鏈上全部可見的轉账記錄。

這種情況下,如果有人給你轉來一些RGB資產,你事先並不知道這些錢是怎么造出來的,轉手自哪些人。如果對面那個人憑空聲明一種資產,然後轉給你一部分,這種造假幣的作惡場景怎么處理?

RGB協議採用了這樣一種思路:每一筆轉账生效前,接收者先讓發送者出示該資產的全部歷史記錄,比如從創世階段到現在,這些資產是由誰發行的,中間途經哪些人,在這些人之間發生的每一次資產轉移,是否都不違背會計記账准則(一人加,一人減)。

這樣一來,你就能知道對面給你的是不是“有問題的錢”,所以說RGB本質是讓交易當事人自己運行客戶端做驗證,基於客戶端驗證模式,對應着理性人博弈假設,只要當事人理智,客戶端軟件沒問題,就能保證有問題的資產轉移無法生效,或無法被其他人認可。

值得注意的是,RGB協議會把這些比特幣鏈下的交易數據,壓縮爲Commitment(本質是個merkle root),上傳到比特幣鏈上,這就讓鏈下的轉账記錄,與比特幣主網直接產生關聯。

(RGB協議交互流程圖)

由於RGB客戶端之間沒有共識,RGB資產合約的發布無法“極其可靠”的傳播給所有節點,合約發布者和用戶幹脆就通過電子郵件或是推特等任意形式,自發的獲知RGB資產合約的細節,形式非常隨意。

下圖中展示了惡意的RGB資產轉移場景,作爲RGB用戶,我們要在自己的客戶端本地,存儲RGB資產對應的智能合約。當其他人向我們轉账時,我們根據本地存儲的資產合約內容,可以知道當前這筆轉账是否違反合約中定義好的規則。根據對面提供的資產來源信息(歷史記錄),可以確認對方的資產來源有沒有問題(是不是憑空聲明出來的)。

復盤上述流程,不難看出,不同的RGB客戶端接收並存儲的數據往往是獨立的,你往往不知道別人有哪些資產,有多少數額。反過來,別人基本也不知道你的資產狀況。

這就是典型的數據孤島,也就是大家存儲的數據都不一致。理論上雖然可以提高隱私程度,但相應的也帶來了很多麻煩。你必須在自己的客戶端本地維護好RGB資產的數據,這些數據一旦丟失,就會造成嚴重後果(資產不可用)。但事實上,只要你維護好本地數據,RGB協議就可以爲你帶來和比特幣主網基本等價的安全性。

此外,RGB客戶端之間通訊用的Bifrost協議,會協助用戶和其他客戶端進行p2p通訊,可以把他的資產數據加密後傳播給其他節點,叫對方幫忙存儲(注意是加密後的數據,對面不知道明文)。只要你不把密鑰也弄丟了,在本地數據丟失時,可以通過網絡中其他節點,還原出自己原本擁有的資產數據。

但原始RGB協議的缺點還是很明顯,首先每筆交易都要求雙方進行多次通訊,接收方要先驗證發送方的資產來源,然後發送回執,批准發送方的轉账請求。這個過程中,雙方之間至少要產生三次消息傳遞。這種“交互式轉账”和大多數人所習慣的“非交互式轉账”嚴重不符合,你能想象,別人要給你轉錢,還要把交易數據發給你來檢查,得到你的回執消息後,才能完成轉账流程嗎?(流程圖在前文可見)

其次,絕大多數的Defi場景都需要數據透明、狀態可驗證的智能合約,但RGB協議天生不支持此類場景,所以是對Defi非常不友好的;此外,RGB協議裏用戶必須去運行客戶端做自驗證,如果你偶然間接收到一筆轉手自幾萬人的資產,你甚至還要驗證這筆資產的幾萬次轉手記錄。很顯然,所有的事情都讓用戶去自行解決,並不利於產品本身的推廣和採用。

對於上述問題,RGB++的解決思路是:讓用戶在客戶端自驗證模式,與第三方托管模式之間自由切換,用戶可以把數據驗證與存儲、智能合約托管等包袱,甩給CKB去承擔,當然用戶要樂觀的信任,CKB這條POW公鏈是可靠的;如果某些對安全和隱私有更高追求的人,比如手握大量資產的大戶,也可以回退到原始的RGB模式。這裏要強調的是,RGB++和原始的RGB協議,理論上是可以彼此兼容的,並不是有他無我。

(RGB++協議交互流程圖【簡略版】)

在此前的文章《從RGB到RGB++:CKB如何賦能比特幣生態資產協議》中,我們曾簡單科普過RGB++的“同構綁定”,這裏我們再快速的復盤下:

CKB有自己的拓展型UTXO,叫Cell,它比BTC鏈上的UTXO多出了可編程性。而“同構綁定”,就是將CKB鏈上的Cell作爲RGB資產數據的“容器”,把RGB資產的關鍵參數寫入到Cell中。

由於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層。

這就類似於以太坊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的特性進行過解讀,所以不在此贅述。

如果RGB資產交易雙方信得過CKB的安全性,甚至不必頻繁的在比特幣鏈上發布Commitment,可以在許多筆RGB轉账進行後,再匯總發送一個Commitment到比特幣鏈上,這被稱爲“交易折疊”功能,可以降低使用成本。

但需要注意的是,同構綁定採用的“容器”,往往需要支持UTXO模型的公鏈,或是在狀態存儲上有類似特徵的infra,而EVM鏈顯然不太適合,在技術實現上會遇到很多坑。首先,前文提到RGB++“無需跨鏈即可操作CKB鏈上資產容器”,基本就無法在EVM鏈身上實現;就算強行實現,成本也可能很高;

再者,在RGB++協議中,很多人沒有必要運行客戶端或是把資產數據存放在本地。如果用ERC-20的方式,把所有人的資產余額都記錄在這個合約中,假如有人要回退到客戶端自驗證的模式,他提出要檢查某個人的資產來源,此時他就可能要把所有和資產合約產生交互的交易記錄,全都掃描一遍,這會帶來巨大壓力。

直白的說,ERC-20等資產合約,把所有人的資產狀態耦合在一起存儲,如果你要單獨檢驗其中某個人的資產變更歷史記錄,將會變得很難,就好像在一個公用的聊天室中,你想知道有哪些人給王剛發過消息,就不得不把整個聊天室裏的消息記錄頂朝天翻一遍。而UTXO就像是一對一的私聊頻道,你要查歷史記錄會很容易。

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

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

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

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

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

當然,我們也希望用於同構綁定的公鏈具有較強的安全性,另一方面,我們也希望該公鏈上的UTXO解鎖條件,應當是可編程的,如此一來,用戶就可以直接用BTC的籤名方案,解鎖自己在其他公鏈上同構綁定的UTXO,而不需要再更換籤名算法。

目前,CKB上UTXO的鎖定腳本是可編程的,官方對此還兼容了不同公鏈的籤名方案,對於同構綁定而言,CKB網絡基本符合以上幾個特性,那其他基於UTXO的公鏈呢?我們對Fuel和Cardano進行了初步考察,認爲他們在理論上都可以支持同構綁定。

Fuel:基於UTXO的以太坊OP Rollup

Fuel是一個基於UTXO的以太坊OP Rollup,還是把欺詐證明概念引入以太坊Layer2生態的先驅。對於正常的UTXO功能支持,Fuel與BTC是基本一致的。

在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系統。

所以,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鏈的交易計算過程在鏈下直接進行,把計算結果提交到鏈上去驗證。若通過驗證,則交易結果上鏈)

开發者可以使用PlutusCore語言在Cardano鏈上進行UTXO的編程,與CKB類似,开發者可以編寫解鎖腳本和一些用於狀態更新的函數。

我們以基於UTXO的拍賣流程介紹Cardano的UTXO編程模式。假設我們需要實現一個資產拍賣DAPP,要求用戶可以在拍賣結束前給出報價,具體來說,就是用戶消費自己的UTXO,與此拍賣合約UTXO,然後生成一個新的拍賣UTXO。當有人給出更高報價時,除了生成新的拍賣合約UTXO,也會生成對上一個人的退款UTXO。具體流程如下圖:

實現上述拍賣流程,需要在拍賣智能合約UTXO內存儲一些狀態,比如當前拍賣的最高價與給出報價的人。下圖展示了PlutusCore內部的狀態聲明,我們可以看到,bBidder和bAmount展示了拍賣的報價和給出報價的錢包地址。而Auction Params內則包含拍賣的基本信息。

當用戶花費此UTXO時,我們可以更新合約內的狀態。下圖展示了拍賣合約內一些具體的狀態更新和業務邏輯。比如校驗用戶報價和校驗當前拍賣是否仍在進行的邏輯。當然,由於PlutusCore是Haskell編程語言,這是一種純函數式編程語言,大部分开發者可能無法直接看懂其含義。

在Cardano上構造同構綁定具有可行性,我們可以使用Datum存儲資產狀態,並編寫特定的腳本來兼容比特幣相關籤名算法。但嚴重的問題是,大部分程序員可能無法適應使用PlutusCore進行合約編程,而且其編程環境是較難搭建的,對开發者而言並不友好。

總結

同構綁定要求鏈具有以下屬性:

  1. 使用UTXO模型

  2. 具有相當的UTXO可編程性,允許开發者編寫解鎖腳本

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

  4. 可以通過智能合約或其他手段,支持運行比特幣輕節點

Fuel由於其智能合約編程思想的特殊性,雖然可以兼容同構綁定,但還是會帶來一些包袱;而Cardaon使用 Haskell 編程語言進行合約編程,大部分开發者很難快速上手。基於上述理由,採用RISC-V指令集並在UTXO編程的特性上更平衡的CKB,可能是更適配同構綁定的功能拓展層。

鄭重聲明:本文版權歸原作者所有,轉載文章僅為傳播信息之目的,不構成任何投資建議,如有侵權行為,請第一時間聯絡我們修改或刪除,多謝。

標題:RGB++與同構綁定:CKB、Cardano與Fuel如何賦能比特幣生態

地址:https://www.pressbased.com/post/4594.html