RGB++ 的「同構綁定」，如何賦能 RGB、Atomical 和 Runes 等比特幣生態資產協定
編輯：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，可能是更適配同構綁定的功能拓展層。
免責聲明：作為區塊鏈資訊平臺，本站所發佈文章僅代表作者及嘉賓個人觀點，與 Web3Caff 立場無關。 文章內的資訊僅供參考，均不構成任何投資建議及要約，並請您遵守所在國家或地區的相關法律法規。
