作者：Shew，極客web3
編輯：Faust，極客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客戶端之間通訊用的Bifrost協議，會協助用戶和其他客戶端進行p2p通訊，可以把他的資產數據加密後傳播給其他節點，叫對方幫忙儲存（注意是加密後的數據，對面不知道明文）。只要你不把金鑰也弄丟了，在本地資料遺失時，可以透過網路中其他節點，還原出自己原本擁有的資產資料。
但原始RGB協議的缺點還是很明顯，首先每筆交易都要求雙方進行多次通訊，接收方要先驗證發送方的資產來源，然後發送回執，批准發送方的轉帳請求。這個過程中，雙方之間至少要產生三次訊息傳遞。這種「互動式轉帳」和大多數人所習慣的「非互動式轉帳」嚴重不符合，你能想像，別人要給你轉錢，還要把交易資料發給你來檢查，得到你的回執訊息後，才能完成轉帳流程嗎？ （流程圖在前文可見）
其次，絕大多數的Defi場景都需要資料透明、狀態可驗證的智能合約，但RGB協定天生不支援此類場景，所以是對Defi非常不友善的；此外，RGB協定裡用戶必須去運行客戶端做自驗證，如果你偶然間接收到一筆轉手自幾萬人的資產，你甚至還要驗證這筆資產的幾萬次轉手記錄。很顯然，所有的事情都讓使用者去自行解決，並不利於產品本身的推廣與採用。
對於上述問題，RGB++的解決想法是：讓使用者在客戶端自驗證模式，與第三方託管模式之間自由切換，使用者可以把資料驗證與儲存、智慧合約託管等包袱，甩給CKB去承擔，當然使用者要樂觀的信任，CKB這條POW公鍊是可靠的；如果某些對安全和隱私有更高追求的人，比如手握大量資產的大戶，也可以回退到原始的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就像是一對一的私聊頻道，你要查歷史記錄會很容易。
綜合來看，適合實現同構綁定的公鏈/功能拓展層，應該具有以下特性:
- 使用UTXO模型或類似的狀態儲存方案；
- 具有相當的UTXO可編程性，允許開發者編寫解鎖腳本；
- 存在UTXO相關的狀態空間，可儲存資產狀態；
- 存在比特幣相關橋或輕節點；
當然，我們也希望用於同構綁定的公鏈具有較強的安全性，另一方面，我們也希望該公鏈上的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進行合約編程，而且其編程環境是較難搭建的，對開發者而言並不友善。
總結
同構綁定要求鏈具有下列屬性:
- 使用UTXO模型
- 具有相當的UTXO可編程性，允許開發者編寫解鎖腳本
- 存在UTXO相關的狀態空間，可儲存資產狀態
- 可以透過智能合約或其他手段，支援運行比特幣輕節點
Fuel由於其智能合約編程思想的特殊性，雖然可以兼容同構綁定，但還是會帶來一些包袱；而Cardaon使用Haskell 編程語言進行合約編程，大部分開發者很難快速上手。基於上述理由，採用RISC-V指令集並在UTXO編程的特性上更平衡的CKB，可能是更適配同構綁定的功能拓展層。