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,可能是更適配同構綁定的功能拓展層。

Total
0
Shares
Related Posts