作者：Faust & 霧月，BTCEden
2024年7月，CKB官方宣布了RGB++ Layer的正式啟動，標誌著先前發布的RGB++協議徹底從理論落地為工程化產物，並將引入更具體、更實際的應用場景。憑藉著在BTC與CKB、Cardano等泛UTXO公鏈之間建構BTCFi生態的願景，RGB++ Layer很快就成為了人們關注的焦點。
概括來說，RGB++ Layer以RGB++協定為基礎，利用同構綁定和Leap技術，為RGB++原生資產或銘文/符文在BTC、CKB、Cardano等UTXO型公鏈之間提供“無需跨鏈橋”的全鏈互動體驗；利用CKB圖靈完備的智慧合約環境，為比特幣建構從資產發行到實現複雜DeFi功能的必要條件。
而由於RGB++ Layer背靠CKB完整的帳戶抽像生態，相容於比特幣帳戶和錢包，可以為比特幣用戶創造良好的體驗，為BTCFi的大規模採用鋪路。
下文中，讓我們深入理解RGB++ Layer的大致運作原理和特性，並展望其為BTCFi生態帶來的改變。由於其理論基礎建立在RGB++協定之上，我們將先從協定本身開始講起。
RGB++協定：RGB++ Layer的理論基石
RGB++協定發佈於今年1月，其核心理念是用CKB鏈上驗證的形式，取代RGB協定的“客戶端驗證”，本質是把CKB當作去中心化的索引器，將資料儲存、資產來源驗證等任務交由CKB完成，由後者作為RGB協定的驗證層和DA層，以解決RGB協定在UX上的弊病、不利於支援Defi的缺陷。
與「一次性封裝」的概念相呼應，RGB++引入了同構綁定的概念，以CKB鏈上的拓展型UTXO－Cell作為銘文/符文類資產的資料載體，再令Cell與比特幣/ Cardano/Liquid鏈上的UTXO建立綁定關係，最終讓RGB++資產繼承比特幣等UTXO公鏈的安全性，以防止雙重支付。
這種「綁定XXX以繼承XXX安全性」的思路，類似現實中銀行帳戶要綁定手機號碼和身分證。
舉個例子，假設Alice要轉去BOB一些TEST代幣，她可以產生一個聲明，將儲存TEST資產資訊的Cell與Bob的比特幣UTXO綁定。如果Bob打算再把TEST代幣轉給別人，綁定的比特幣UTXO也要發生轉移。
這樣一來，承載RGB++資產資料的Cell，和比特幣UTXO之間有1對1綁定的關係，只要比特幣UTXO沒有被雙重消費，綁定的RGB++資產就不會被雙花。
說到RGB++ Layer，它實際上是對RGB++協定進行工程化落地的產物，其主打的兩大特性，包括同構綁定和Leap無橋跨鏈，下面讓我們深入了解下同構綁定和Leap的技術實現原理。
同構綁定與Leap：BTCFi的資產發行與無橋跨鏈層
為了真正理解同構綁定和Leap的思路，我們先簡單說下CKB的Cell模型。
Cell實質是拓展型UTXO，有LockScript、TypeScript、Data等多個字段，LockScript的作用和比特幣的鎖定腳本類似，用於權限驗證；TypeScript類似於智能合約程式碼，Data則用於存放資產資料。
如果你要在CKB鏈上發行RGB++資產，首先要創建一個Cell，並在相關欄位裡寫好代幣符號和合約程式碼，例如代幣符號為TEST。之後你可以把這些Cell拆解，分發給很多人，就跟比特幣UTXO的拆分和轉移方式一樣。
由於Cell與比特幣UTXO在結構上相似，且CKB可以相容於比特幣簽名演算法，用戶可以用比特幣錢包操縱CKB鏈上資產。假如你擁有某個Cell，你可以對鎖定腳本進行設置，使解鎖條件與比特幣UTXO的解鎖條件一致，這樣就可以用比特幣帳戶私鑰操縱CKB鏈上的Cell。
上述特性在CKB、BTC和其他UTXO公鏈之間也可以實現，例如你也可以用Cardano帳戶改寫CKB鏈上的資產數據，RGB++資產的控制權也可以從BTC帳戶轉移到Cardano帳戶，而無需跨鏈橋。下面我們將對這個主題展開解釋。
前面我們曾提到，RGB++資產需要綁定比特幣、Cardano、Liquid等公鏈上的UTXO，類似於現實中銀行帳戶要綁定手機號碼和身分證；其次，RGB++資產本身只是一堆數據，這些資料需要有資料庫之類的儲存媒介，CKB鏈上的Cell可以充當其資料庫。
然後我們可以在權限驗證這塊做設置，允許人們用BTC、Cardano等不同公鏈的帳戶，去改寫CKB鏈上的RGB++資產資料。這便是同構綁定的核心宗旨。
RGB++ Layer提出的“Leap”和無橋跨鏈，其實是基於同構綁定技術，對RGB++資產綁定的UTXO進行“換綁”，比如你的資產之前綁定了比特幣UTXO，現在可以換綁在Cardano、Liquid、Fuel等鏈上的UTXO，這樣就可以把資產控制權限從BTC帳戶轉移到Cardano帳戶。
從使用者感知的角度來看，這其實等價於資產跨鏈，CKB扮演了類似索引器和資料庫的角色。但不同於傳統的跨鏈方式，「Leap」只改變資產資料的使用權限，資料本身還是儲存在CKB鏈上的，這種方式比Lock-Mint模式更簡潔，也免去了對映射資產合約的依賴。
以上只是同構綁定和Leap的產品效果說明。以下讓我們透過具體案例，來理解它們的技術實現想法。
同構綁定的實作方式
讓我們來理解下同構綁定的技術實現方式。假設Alice有100枚TEST代幣，資料存放在Cell#0 中，與比特幣鏈上的UTXO#0 有綁定關係。
現在，Alice要把40枚TEST代幣轉給Bob。首先，她要把Cell#0拆分為兩個新的Cell，其中Cell#1包含40枚TEST代幣，轉讓給Bob；Cell#2包含60枚TEST，還是由Alice自己控制。
在這個過程中，Cell#0 綁定的BTC UTXO#0，也要拆分為UTXO#1 和UTXO#2，分別與Cell#1 和Cell#2綁定。當Alice把Cell#1轉讓給Bob時，可以一鍵操作把BTC UTXO#1也轉讓給Bob，在CKB和BTC鏈上實現同步交易。
我們可以在此深度理解下同構綁定。其實這個概念的核心意義在於，CKB的Cell、Cardano的eUTXO和BTC UTXO都是UTXO模型，且CKB相容於比特幣/Cardano簽章演算法，後兩條鏈上發生的UTXO的分解與轉移，也可以1: 1同步給CKB鏈上的Cell。
這樣一來，當我們對綁定RGB++資產的BTC UTXO進行操作時，可以把操作結果同步給CKB鏈上的Cell，就好像實體和影子的關係一樣。另外我們也要注意，RGB++資產關聯了BTC UTXO和CKB Cell這兩個實體，兩者都是RGB++資產的組成部分，缺一不可。
如果我們檢視上述的Alice給Bob轉帳的案例，其大致流程為：
1. Alice在本地建構一筆CKB交易資料（先不上鍊），這筆交易指明將記錄資產資料的Cell#0銷毀，產生Cell#1送給Bob，Cell#2留給自己；
2. Alice在本地產生一個聲明，把Cell#1綁定到BTC UTXO#1，把Cell#2綁定到BTC UTXO#2，並把Cell#1和BTC UTXO#1都送給Bob；
3. 之後，Alice在本地產生一個Commitment（類似hash），對應的原始內容包含第2步驟中的聲明+第1步中產生CKB交易資料。 Commitment的數據之後要記錄到比特幣鏈上；
4. Alice在比特幣鏈上發起交易，把UTXO#0銷毀，生成UTXO#1送給Bob，UTXO#2留給自己，並把Commitment以OP_Return操作碼的形式寫到比特幣鏈上；
5. 步驟4完成後，再將第1步驟產生的CKB交易傳送至CKB鏈上。
上面省略了一些比較複雜的細節。事實上，當Alice把自己的RGB++資產轉移給Bob時，要先進行複雜的身份證明，證明自己的確是Cell#0 的主人。這裡面所涉及的事情，包括：
1.證明Cell#0 和BTC UTXO#0的確有綁定關係；
2.Alice證明自己是Cell#0和BTC UTXO#0的實際控制者。
注意，寫有RGB++資產資料的Cell和比特幣UTXO可以被比特幣帳戶同步改寫，整個互動流程中，透過比特幣帳戶即可完成一鍵式操作。上述場景不僅限於比特幣和CKB之間的同構綁定，可以拓展到Cardano、Liquid、萊特幣等廣闊的範疇，想像空間還是很大的。
Leap的實作原理與支援場景
前面我們曾提到，Leap功能實際上就是切換RGB++資產綁定的UTXO，例如將其從比特幣換綁到Cardano，之後就可以用Cardano帳戶控制RGB++資產。此後你還可以在Cardano鏈上轉賬，把控制RGB++資產的UTXO拆分轉移給更多人。
透過這種方式，RGB++資產可以在多條UTXO公鏈上轉移和分發，但卻可以繞過傳統跨鏈橋Lock-Mint的模式。在這個過程中，需要由CKB公鏈充當類似索引器的角色，見證並處理Leap請求。
假設你要把BTC綁定的RGB++資產轉移到Cardano帳戶，最核心的幾步無外乎：
1. 在比特幣鏈上發布Commitment，聲明將BTC UTXO綁定的Cell解綁；
2. 在Cardano鏈上發布Commitment，聲明將Cell綁定至Cardano UTXO；
3. 變更Cell的鎖定腳本，將解鎖條件關聯的比特幣UTXO，變成Cardano上的eUTXO。
我們可以注意到，在這整個流程中，RGB++資產數據仍然存放在CKB鏈上，只是把解鎖條件關聯的比特幣UTXO，變更為Cardano鏈上的eUTXO。當然具體的執行流程比上面說的複雜不少，在此不贅述。
此外在leap方案中有一個隱性前提，即CKB公鏈作為一種第三方的見證人、索引以及DA設施。作為公鏈其可信度要遠超傳統跨鏈橋的MPC和多簽等方式。
其實基於Leap功能還可以實現很有趣的場景，例如我們可以實現「全鏈交易」。假設我們橫跨比特幣、Cardano和CKB搭建起索引器，建立一個交易平台，讓買家和賣家交易RGB++資產，買家可以把自己的比特幣轉給賣家，然後用自己的Cardano帳戶接收RGB++資產。
這個過程中，RGB++資產的數據還是記錄在Cell中，但這個Cell會被轉移到買家手中，然後其解鎖權限從賣家的比特幣UTXO變更為買家的Cardano eUTXO。
Wrapper
雖然Leap功能對於RGB++資產是完美的，但還是有一些瓶頸：
對於比特幣和Cardano而言，RGB++資產本質是基於OP_RETURN操作碼的銘文/符文/染色幣。這些公鏈節點無法感知到RGB++資產的存在，而CKB其實是以索引器的身份從中參與協調。也就是說，對於比特幣和Cardano而言，RGB++ Layer主要支援的是銘文/符文/染色幣的Leap，而不是BTC、ADA等原生資產的跨鏈。
對此，RGB++ Layer官方引進了Wrapper，可以簡單理解為一種基於詐欺證明和超額質押的橋。以rBTC wrapper為例，它將BTC橋接到RGB++ Layer，在RGB++ Layer上運行的一組智慧合約會監控橋的守護者。如果守護者有惡意行為，他們的抵押物將被slash。如果守護者串通盜竊鎖定的BTC，rBTC持有者可獲得全額賠償。
在結合了Leap和Wrapper後，BTCFi生態中的各種資產如RGB++原生資產、BRC20、ARC20、符文等都可以跨到其他層或公鏈上去。
下圖是應用LeapX的使用流程的一部分，可以看到它幾乎支援了所有BTCFi主流資產到不同生態體系的互通性。且對不同發行方式的資產都有對應的對應的處理流程，有一部分用的wrapper，有一部分用的是leap。
CKB-VM：BTCFi的智慧合約引擎
上面我們主要解釋了RGB++ Layer的同構綁定與Leap概念。下面讓我們來考察其他的要點。
在傳統的BTCFi中，由於缺乏智能合約的支持，只能實現一些比較簡單的Dapp，有些實現方法會有一定中心化風險，有些則比較笨拙不靈活。
為了實現在區塊鏈上可用的智慧合約層，CKB為RGB++ Layer提供了CKB-VM，任何能夠支援RISC-V虛擬機的程式語言都可以用於在RGB++ Layer上進行合約開發。開發者可以使用他們偏好的工具和語言，在統一的智能合約框架和執行環境下，實現高效、安全的智能合約的開發與部署。
以下是一段用C語言實作的CKB中用戶自訂代幣UDT的transfer方法。可以看到除了語言不同，其基礎邏輯和一般的代幣都是相同的。而由於RISC-V有廣泛的語言和編譯器支持，對開發者的智能合約開發入門要求就比較低，我們可以很輕鬆的用JavaScript、Rust、Go、Java 和Ruby把這段邏輯重寫出來，而非必須學習某種DSL語言才可以編寫合約。
當然，語言只是程式設計的一個方面，具體的智慧合約框架的學習是不可避免的。
原生AA生態：無縫銜接BTC與RGB++
最後讓我們再簡單了解下RGB++ Layer背後的原生AA與帳號抽像生態。由於BTCFi本質是為原生的比特幣資產提供多樣性的Defi體驗，能否兼容主流比特幣錢包將會是BTCFi週邊設施需要考慮的重要因素，而RGB++ Layer直接復用了CKB的原生AA方案，可以在可開發者側和用戶側都盡量與BTC和Cardano等重要的UTXO公鏈相容。
在RGB++ Layer中，使用者可以使用不同的簽章演算法進行鑑權。如，使用者可以使用BTC、Cardano甚至WebAuthn等帳戶、錢包或鑑權方式，直接操縱RGB++ Layer上的資產。
我們以下面的錢包中間件CCC為例，它可以為錢包和dApp提供各種公鏈對CKB的可操作性。
下圖是CCC的連線視窗。我們可以看到，它支援Unisat和Metamask等主流錢包入口。
另一個例子是WebAuthn的實現，CKB生態錢包JoyID就是典型代表。透過JoyID，使用者可以直接透過生物辨識（如指紋或臉部辨識）方式進行身份驗證，實現無縫且高安全性的登入和身分管理。
可以說，同構綁定和Leap能夠成立的基礎就在於RGB++ Layer擁有完備的原生AA方案，可以很好的兼容其他公鏈的賬戶標準，這種特性不但便於支持一些關鍵場景，同時也可以為UX掃清障礙。
總結
在上文中，我們對RGB++ Layer的全貌進行了考察，它可以作為銘文/符文/染色幣等各種Memecoin的重要基礎設施，實現全鏈交互的場景。而RGB++ Layer則是基於RiscV所建構的智慧合約執行環境，可以為BTCFi所需的複雜業務邏輯創造土壤。
礙於篇幅所限，本文只是對RGB++ Layer核心技術的簡單科普，並沒有對許多複雜的細節進行系統性的科普。未來我們將持續關注RGB++ Layer的進展，對該專案相關的一系列技術方案進行更為透徹和深度的解析，大家敬請期待！
