從RGB到RGB++，CKB為何成為了值得期待的BTC L2？

RGB++的想法是，用CKB鏈上的Cell，表達RGB資產的所有權關係。它把原本存放在RGB客戶端本地的資產數據，挪到CKB鏈上用Cell的形式表達出來，與比特幣UTXO之間建立映射關係，讓CKB充當RGB資產的公開數據庫與鏈下預結算層，取代RGB客戶端，實現更可靠的資料託管與RGB合約互動。

作者：Shew & Faust，極客web3

顧問：Cyber​​Orange，Unipass

摘要（較長）：·RGB 協議是比較有潛力的BTC拓展協議，本質是一種鏈下計算系統，它採用了和閃電網絡類似的思想：用戶親自驗證並授權和自身相關的資產變動事宜（ Verify by yourself），把交易發起者認可的結果/承諾提交到比特幣鏈上。

·RGB協議利用了與染色幣及Mastercoin部分類似的思想，在比特幣UTXO上關聯著「寄生資產」。它把鏈下交易數據的Commitment“承諾”，存放到比特幣鏈上，而不是像Ordinals協議那樣發布完整的DA數據。根據比特幣鏈上記錄的承諾值，RGB客戶端可以驗證，其他客戶端提供的RGB歷史資料是否有效。

·同時，單憑hash/Commitment無法還原背後的原像，外界不能直接觀測到鏈上承諾值對應的鏈下數據，這樣可以保護隱私，且相較於銘文，只把承諾上鍊能節省空間。從第三者的視角看，他其實不知道RGB客戶端到底做了什麼。

·RGB也利用了比特幣UTXO一次性花費的特性，透過名為「一次性密封」的思路，把RGB資產所有權，和比特幣UTXO關聯起來。這樣可以藉助比特幣強大的安全性，避免RGB資產被「雙花/雙重支付」（只要比特幣UTXO不被雙花，RGB資產就不會被雙花）。

·但RGB 作為一個在比特幣鏈下實現的智能合約系統，依賴不同的客戶端在本地存放歷史數據，且不同客戶端（用戶）只存放與自己相關的數據，看不到別人的資產狀況。這種「資料孤島」雖然保護了隱私，但也使得RGB在大規模採用上面臨麻煩，更像一個由OTC交易者組成的P2P網路。

·RGB++的想法是，用CKB鏈上的Cell，表達RGB資產的所有權關係。它把原本存放在RGB客戶端本地的資產數據，挪到CKB鏈上用Cell的形式表達出來，與比特幣UTXO之間建立映射關係，讓CKB充當RGB資產的公開數據庫與鏈下預結算層，取代RGB客戶端，實現更可靠的資料託管與RGB合約互動。對於其他基於UTXO的Layer2而言，這種」同構綁定」 是一種趨勢。

·RGB協議本身只支援互動式的轉帳流程，交易雙方要頻繁通信，這種模式難以支援Defi場景，也不利於RGB資產發行。 CKB取代了獨立客戶端之後，可以實現非互動的RGB交易，利於Defi落地和空投等功能，且支援BTC資產無需跨鏈的與CKB鏈上資產互動。

·RGB++本質是用隱私換易用性，同時帶來RGB協定無法實現的場景。如果用戶看重產品的簡單好用和功能完備性，就會青睞RGB++，如果追求隱私和Verify by yourself的安全，就會青睞傳統的RGB協議，一切看用戶自己的取捨。 （理論上RGB++也可以透過ZK等方法解決隱私問題）

RGB協定的原理及其優缺點

RGB協議本身是比較複雜的方案，我們以一筆具體的RGB資產轉帳為例，為大家解釋RGB協議是如何運作的。

假設有一種符合RGB協議要求的代幣，叫TEST。 Alice 希望Bob 將100 個TEST代幣轉給自己，換句話說，希望產生一筆Bob—>Alice 的代幣轉帳。

這裡先解釋下，RGB協議採用了稱為「一次性封裝」的思路，表面上說是Bob給Alice轉賬，實際上是指，Bob控制著比特幣鏈上的UTXO A，而UTXO A透過某些方法，關聯了一些RGB資產。

如果Bob聲明，要把UTXO A關聯的部分RGB資產轉讓給Alice，它可以如此聲明：把UTXO A關聯的30枚TEST代幣，轉讓給UTXO B來關聯。由於Alice是UTXO B的所有者，所以她就擁有了相關的30枚TEST代幣。

 （圖源：Discoco Labs）

實際上比特幣鏈上的所有權記錄方式，都是透過UTXO來實現的，聲明UTXO B有資格控制xx數額RGB資產，就等價於說UTXO B的主人可以控制xx數額RGB資產，這與我們所習慣的帳戶地址模型並不一致，是比特幣等UTXO公鏈的獨特屬性。

了解這裡後，我們再檢視RGB協議的工作流程，可以感受到他與染色幣及Mastercoin等比特幣UTXO寄生資產的差異：

1.依照RGB協議的原理，Alice 要先為轉帳交易開立發票(issues an invoice)，指明自己的意圖。發票包含以下資訊:

• 合約id： Alice聲明要與哪個RGB資產合約交互
• 接口：讓Bob 了解合約的所有互動接口
• 操作： Alice讓Bob去呼叫的合約介面名
• 狀態： Bob 需要修改的合約狀態，此例中就是Bob 轉給Alice 的代幣數量
• Seal（密封條）：用於一次性密封的UTXO，可以簡單理解為，Alice 用來接受Bob的RGB資產授權的UTXO。

最後，Alice 會獲得一個如下的發票內容:

上述發票遵循如下格式：

2.Alice 需要將上述發票寄給Bob。 Bob 會檢查發票訊息，按照Alice的意圖產生新的RGB交易，把RGB資產轉讓給Alice。

但這裡要格外注意，Bob必須設法證明，自己的確有部分TEST資產所有權。至於為何要這麼做，是因為RGB協定預設為“沒有全域可見的資產狀態記錄”，不會像以太坊那樣用一個公共託管合約來記錄並處理所有人的資產。

RGB協議下，不同的客戶端只記錄和自身相關的資產數據，包括這些資產的當前餘額、歷史來源等，每個客戶端記錄的數據基本上都不一致。這樣一來，每個人都無法確認其他人的資產狀況，所以在P2P交易時要出示資產證明。

用一句生動的比喻就是，你和對面在用紙鈔進行交易，但你不知道對方的紙鈔是不是自己印的假幣，你便要求他說清楚，這些紙鈔是從哪裡弄來的，經過多少人轉手，以此判斷對方是否在用假幣糊弄你。

雙方互相認可後，就可以放心大膽的交易，每一筆RGB交易也只需要參與方彼此認可就行，是完全P2P的（類似OTC）。

顯然，這種模式可以保護隱私，因為每個人的資產狀況、交易記錄，都不會被外界輕易獲知，你和交易對手方做了什麼，外人很難知道。道理就好比，紙鈔可以比銀行轉帳更好隱匿。但顯然，這也會在使用者體驗上造成不便。

在前面談到的Alice和Bob案例中，Bob收到Alice的發票並獲知其意圖後，要從本地客戶端的歷史資料中，選出和TEST資產相關的歷史轉帳記錄，連同新生成的Bob -> Alice 轉賬，一起交給Alice去校驗，證明新的RGB交易/所有權變更，背後對應的資產所有權來源是有效無誤的。

一般而言，客戶端本地存放的資料稱為Stash“藏品”，包含了RGB資產的過往資料。我們可以把Stash當作RGB資產合約的日誌記錄。

3.當Alice從Bob那裡收到數據，以及新聲明的Bob—>Alice 交易後，會驗證其有效性，如果驗證通過，Alice 便會產生一個“確認簽名”，返回給Bob。

4.Bob 收到Alice 的確認簽名後，便把Bob —> Alice交易對應的Commitment（承諾）廣播到BTC 網路內，最終寫入BTC鏈上，使其具備「最終性」。

如果Bob—>Alice轉帳中，聲明UTXO B 的主人將擁有30枚TEST代幣，則Alice只要證明自己是UTXO B的主人，就可以使用這些TEST代幣。

5.如果未來Alice要把TEST代幣轉給別人，當出示這些TEST的歷史來源時，對方可以根據比特幣鏈上的commitment承諾值進行核驗，看Alice提供的數據能否和鏈上的承諾值對應。這樣可以防止偽造數據。

RGB協定的好處在於，可以在鏈下支援複雜的智能合約計算。它本質上把計算步驟挪到了BTC鏈下，僅在鏈上記錄Commitment，在保護隱私的同時，在鏈下聲明比特幣UTXO和RGB資產所有權之間的關聯，借助比特幣來刻錄並實現RGB資產的所有權變更。

由於所有的交易聲明都需要由當事人驗證並授權，所以其安全模型基於“理性人假設”，只要當事人是理智的，只要比特幣是安全的，RGB資產所有權就“基本安全”。

但RGB協定的缺陷也很明顯（前文有提及資料孤島與碎片化儲存問題）。首先，要給其他人轉賬，甚至要先得到對方的同意和確認，雙方基本上要同時在線；

其次，因為缺乏全域可見的資料記錄方式，RGB的合約發布甚至都採用了非常奇葩的形式，合約使用者要事先從合約發布者處，獲知合約包含的介面功能，具體的獲知方式可以是透過電子郵件或掃二維碼。 （看官方目前的說辭，估計把合約代碼掛官網首頁、推特置頂也可以）

我們再來探討一下RGB 協定的合約狀態。在RGB 協定內，合約的初始狀態(Genesis)由創建者在合約創建時就設定好，例如RBG-20 合約中的代幣名稱、總量等。而後，合約的狀態伴隨著RGB交易的持續遞進而變化，但這種合約狀態演進是非線性的，構成了一個有向無環圖DAG。

例如Bob 轉帳給Alice 時，僅出示從合約初始化，到Bob取得代幣的部分轉帳紀錄，包含的資料路徑比較狹隘。而Alice 也僅能獲知此路徑分支所包含的交易訊息，難以獲知其他人的轉帳資訊。這雖然保護了RGB用戶的隱私，但也帶來了不良後果：用戶很難獲知RGB 合約的全域狀態，例如每個人有多少RGB資產。這會帶來很多麻煩。

例如，當Bob —> Alice轉帳進行到最後步驟，其承諾值被寫入BTC鏈上且不可逆轉後，Bob 可以在本地刪掉部分資料－假如Bob將自己全部的TEST代幣都給了別人，可以直接把本地存放的TEST代幣相關資料刪掉，以減輕儲存壓力。

而作為代幣接收方的Alice，則要在本地記錄此次交易所涉及的全部數據。 （如果Bob刪掉了本地的TEST代幣數據，Alice的客戶端節點又因為事故徹底損壞了，那麼此時，Alice的資產是不是就永久凍結了？因為沒有其他地方存放Alice的TEST資產數據，除非事先就備份好。）

這本質上可以歸結為DA和資料儲存問題，即RGB協定的新增資料無法以可靠、全域可見的方式傳播出去，最終會使得不同的客戶端成為「資料孤島」。先前曾在以太坊生態如日中天，但後來遭到廢棄的Plasma方案，也是因為無法解決DA問題，最後胎死腹中。

此外，RGB協議還需要交易雙方進行大量通信，許多通信步驟都要依賴中心化設施，在這塊的細節描述還不成熟，官方甚至說可以通過郵件來通信。

比較顯然的是，RGB協議的設計對於追求易用性的長尾用戶不太友好，雖然擁有較多資產且對隱私有較高追求的大戶會樂於做數據備份和客戶端維護，但對於長尾用戶而言，這些包袱還是太重了，會對大規模採用造成嚴重阻礙。甚至於到目前，人們大多認為沒有出現任何現象級的RGB資產。

下圖中，我們給出了RGB資產轉帳的流程圖，讀者可以基於此圖更深刻地理解轉帳的整體流程。

簡而言之，RGB協議借助比特幣UTXO，實現RGB資產的所有權變更，並透過在BTC鏈上發布承諾值（Commitment），確保鏈下資料無法被客戶端私自篡改。實際上，RGB所謂的“一次性密封”，就是透過鏈下的RGB交易聲明，把比特幣UTXO和RGB資產所有權關聯起來，以此借助比特幣強大的安全性，來保障RGB資產安全。但由於DA及資料儲存問題，原始RGB協定的可用性及UX比較差，且資產容易因為資料遺失而凍結（不可用）。

RGB++：基於CKB的加強版RGB協議

在上文中，我們總結了RBG 系統的優點與缺點，其中，客戶端資料孤島、合約狀態無法全域可見，構成了影響RGB協定易用性的最主要因素。

實際上，RGB協定的優點和缺點都很明顯，對隱私和安全有較高追求的人會傾向於自己運行客戶端，並做好資料備份，但長尾用戶顯然沒這個耐心（例如，大多數閃電網路使用者會依賴第三方節點，而不是自己去運行客戶端）。

基於這個理由，Nervos聯創Cipher提出了名為RGB++的方案，嘗試將RGB的資產狀態、合約發布與交易驗證，委託給CKB公鏈來進行。 CKB充當了第三方的資料託管與運算平台，不再需要使用者自行執行RGB客戶端。

由於CKB本身是拓展的UTXO模型（Cell），可以將RGB資產的鏈下資訊寫入Cell中，並在Cell和比特幣UTXO之間建立1對1的映射關係，實現基於CKB的RGB資產數據託管與驗證方案，以此解決易用性問題，作為RGB原始方案的一種強化補充。

這段話讀起來可能有點繞，對此我們再展開解釋一下：

文章前面提到，RGB協議本質是透過發布鏈上承諾與鏈下聲明，把比特幣UTXO和RGB資產所有權關聯起來。但RGB資產合約的資料是碎片化存放在不同客戶端本地的，沒有一個全域可見的視圖。

RGB++透過CKB的拓展版UTXO－Cell，把比特幣UTXO與對應的RGB資產之間的映射關係，直接在CKB鏈上展示出來，並且由CKB公鏈取代用戶的P2P客戶端，驗證每一筆RGB轉帳的有效性。

有了這樣一個全域可見的RGB資料記錄後，許多難以在RGB協定中實現的場景都會更容易落地。

可能有人第一時間想到了EVM。我們是否可以用EVM 承載RGB 的狀態與驗證？答案是：很麻煩，因為RGB 資產本質上寄生於比特幣UTXO，與比特幣UTXO有1對1的映射關係。如果要把比特幣UTXO與EVM合約資料建立映射關係，在技術實作上並不順暢，不如直接選擇UTXO公鏈。

而且，以太坊上的「資產」往往是點對池的公共物品，一個合約上記錄無數人的資產數據，合約控制者擁有絕對權力，這種資產處理方式與比特幣UTXO以及RGB協議嚴重衝突，後兩者的設計思路，​​是徹底實現資產的私有化，每個人完全控制自己的資產（想想紙幣和微信支付的區別），不必考慮以太坊和EVM鏈一貫存在的：資產合約owner濫用職權、合約出bug導致資金受損、資產合約的資料要遷移時很麻煩等問題。

所以，如果要將比特幣UTXO與鏈下RGB資產之間的映射關係表達的較為順暢，最好的選擇還是透過UTXO鏈。而CKB支援的是拓展型UTXO－Cell，且CKB VM的指令集是基於RISC-V，比起EVM更容易相容於不同的密碼學演算法，包括比特幣的公私鑰驗證演算法，所以更利於實作RGB++提出的技術方案。

RGB++的技術實現

RGB++用到了CKB的拓展型UTXO——Cell 。而一個Cell包含以下字段:

Capacity代表此Cell擁有的鏈上空間大小，data指Cell 內包含的資料集，可以被讀取或修改。

Type是這個Cell 綁定的程式碼，限制了data資料的修改條件。例如，你的Cell裡有100枚TEST代幣的數據，但你聲明將110枚TEST轉給別人，這不符合Type裡規定的限制條件，會被拒絕。

而Lock則代表Cell 的所有權驗證邏輯，類似比特幣UTXO的解鎖腳本。

我們可以把Cell理解為升級版的UTXO，多出了Type和Capacity這兩個字段，且data可以自訂資料類型，至於Cell的所有權變更方式，和比特幣UTXO差不多，都是透過解鎖腳本來實現。

而RGB++的想法是，用CKB鏈上的Cell，表達RGB資產的所有權關係。它把原本存放在RGB客戶端本地的資產數據，並挪到CKB鏈上用Cell的形式表達出來，讓CKB充當RGB資產的公開資料庫。而表示RGB資產的Cell，會和比特幣鏈上的UTXO有1對1的映射關係，這種映射關係會在Cell的Lock欄位裡直接展示出來。

比方說，假設某個RGB資產關聯著比特幣UTXO A，則對應的映射版Cell，可以把自己的所有權驗證條件，設定為和比特幣UTXO A一致（就是把Lock腳本設定為比特幣UTXO A的解鎖條件）。如果你是UTXO A的控制者，你就能直接操作CKB上的映射Cell，當然，CKB會驗證你是不是UTXO A的主人。

CKB鏈上會實現比特幣輕節點，同步比特幣區塊頭。當你聲明RGB交易，要對RGB資產對應的Cell進行操作時，要先證明自己是比特幣UTXO A的控制者，證明步驟分兩步驟：

1.向CKB鏈上實現的比特幣輕節點證明，UTXO A存在於比特幣鏈上，需要出示Merkle Proof；

2.出示數位簽名，證明自己是UTXO A的所有者。

在RGB++方案中，使用者在前端宣告一筆RGB資產轉帳後，會在CKB鏈上觸發一筆交易，對記錄RGB資產資料的Cell進行改寫，變更其所有權。原本可能是比特幣UTXO 1的控制者擁有這個Cell，所有權變更後，比特幣UTXO 2的控制者成為了Cell的新主人。這一切都在CKB鏈上可見。

這裡要注意的是，與BTC鏈上承諾相關的工作流程，依然在BTC 主網進行，就是說RGB++仍然要在比特幣鏈上發布Commitment，與CKB上發生的RGB資產交易記錄關聯起來。這一步與傳統RGB協定並無不同。

但不同的是，傳統RGB協定中由客戶端在鏈下自己負責的工作，都由CKB來負責，例如交易對手方要驗證資產來源、客戶端要在本地儲存資產來源資料、RGB合約發布要通過第三方管道等，這些繁瑣的包袱都可以由CKB負責解決，不需要使用者自行運作客戶端。

這樣解決了RGB客戶端資料孤島問題，也解決了合約狀態無法全域可見的缺陷。同時，RGB合約可以直接部署在CKB 鏈上，全域可見，供RGB Cell來引用，這樣就避免了RGB協定合約發佈時的一系列奇葩操作。

概括來講，CKB 利用Cell腳本的可編程性，先確定RGB轉賬發起者的確擁有RGB資產關聯的比特幣UTXO，若驗證通過，則允許用戶通過轉賬，將記錄RGB資產數據的Cell轉讓給別人。

簡而概之，CKB 擔任了RGB資產的公開資料託管平台，提供了資料儲存與全域可見的合約發布功能，也提供了所有權驗證與運算功能。更精簡一點來說，就是CKB 取代了RGB 中的客戶端，並且順帶解決了其他的問題。

當然，RGB++既然實現了全局可見的資料發布，隱私性相比於RGB協定必然是降低的，但好處是易用性得到了極大幅度提升。

所以RGB++本質就是用隱私換易用性，同時能帶來RGB協定無法實現的場景。如果用戶看重產品的簡單好用和功能完備性，就會青睞RGB++，如果追求隱私和Verify by yourself的安全，就會青睞傳統的RGB協議，一切看用戶自己的取捨（思路就和Vitalik評論以太坊Layer2時表達的差不多，追求安全就去用Rollup，追求低成本就去用Validium和Optimium等非Rollup方案）。當然，依照RGB++白皮書中的說法，後續也可以在CKB鏈上實現隱私交易方案，隱藏用戶的身分與轉帳金額。

RGB++的附加特性

交易的非互動性（非常重要）

原始RGB 協議的一個重要問題在於，收款方要先向付款方發送一條訊息（就是前文說過的支票），指明把自己的一個UTXO與RGB資產綁定，RGB轉帳才能順利實施。這就要求收款方與付款方之間經過多道互動式通信，才能完成一筆普通交易，顯然增加了用戶的理解難度和產品複雜度。而RGB++則利用了CKB作為資料託管與運算平台的特性，讓對手之間透過非同步、非互動的方法來完成轉帳。

A 向B 轉帳時，只需要事先知道B的地址，聲明向該地址轉賬，不需要收款人在線通信或提供資料。之後，收款人可以自己去領取資產，CKB鏈上的腳本代碼，會驗證收款人是否是付款人指定的那個。顯然，這種模式更貼近多數人的習慣，諸如空投、獎勵分發等原本在RGB協議中不支持的模式也可以跑的通，這樣也有利於RGB資產發行。

此外，RGB協議的工作模式自然不利於Defi場景的展開，例如Uniswap這種典型的多對多、非互動式的交易池，在原始RGB協議中幾乎無法展開，而RGB++實現了非互動式交易、狀態全局可見可驗證，只要藉用Cell來實現一個“所有滿足條件的人都可以修改其狀態的“無主合約”，就可以把很多Defi場景落地。

當然，所有人都可以修改其狀態的無主合約，很容易出現狀態爭用/讀寫衝突，就是好幾個人想同時修改合約狀態，這樣會導致混亂。為了解決這個問題，RGB++計劃用一個鏈上實現的Intent Cell 作為“排序器”，對不同的請求進行排序。

交易折疊（聚合多筆交易的承諾發布）

交易折疊比較好理解，就是把CKB作為一個“鏈下預結算層”，等多筆RGB轉賬發生後，把一批交易聚合起來，生成一個對應批量交易的Commitment，一次性發佈到比特幣鏈上。

具體表現為以下流程圖：

BTC資產無需跨鏈直接與CKB鏈上資產交互

RGB++ 實作了比特幣UTXO與CKB Cell之間的關聯映射後，可以直接實作無需資產跨鏈的互通性。你可以透過RGB++交易聲明，把自己的比特幣UTXO轉移給別人，對方可以把自己的CKB資產所有權轉讓給你。這種模式擁有很大的想像空間，結合前面提到的交易折疊（批量交易），理論上可以實現無需BTC資產跨鏈的BTC——CKB鏈上資產互通。

總結

RGB++把存放在不同RGB客戶端本地的資產數據，直接用CKB鏈上的Cell表達出來，再把Cell與比特幣鏈上的UTXO關聯起來。用戶可以透過比特幣帳戶/資產，與自己在CKB鏈上的RGB++資產互動。這種方式比較簡潔，且解決了RGB協定中轉帳需要雙方事先通訊、難以支援全域可見的狀態、資料儲存片段化、智慧合約及Defi不友善等問題。

RGB++無需資產跨鏈，即可實現BTC—CKB間的互通，且便於RGB資產與Defi場景結合，極大程度解決了RGB協定的易用性問題。但對於追求高度隱私的RGB小眾玩家而言，RGB++本質是以隱私換易用性，一切都要看用戶的取捨。但理論上來講，隱私問題可以在CKB鏈上透過引入ZK等方法來解決。

整體而言，RGB++展示了CKB作為一個比特幣鏈下結算層/計算層的潛力，而這種思路將在未來，被越來越多的比特幣Layer2或資產協議所採納，可以預見的是，比特幣鏈下的第三者結算層間的角逐，或許不久後就會展開。而主打POW和UTXO、有著多年技術累積的CKB，或許能夠在這場模組化區塊鏈的角逐中展現自己的技術優勢。

第四届PANews年度评选暨 PARTY AWARD 2024 开启报名！

本届评选以「CONNECT」为主题，旨在链接及表彰优秀的Web3建设者，链接Web3与现实世界，链接新老周期。将通过数据初选、公开征集、线上投票及专业评议，评选出9大类共21个年度权威奖项，欢迎Web3领域各优秀项目方、机构、社区及KOL报名参与。

点击图片报名！