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

聲明：

1. 本文轉載自[極客 Web3]，著作權歸屬原作者[Shew]，如對轉載有異議，請聯系Gate Learn團隊，團隊會根據相關流程盡速處理。
2. 免責聲明：本文所表達的觀點和意見僅代表作者個人觀點，不構成任何投資建議。
3. 文章其他語言版本由Gate Learn團隊翻譯， 在未提及Gate.io的情況下不得復制、傳播或抄襲經翻譯文章。