《從RGB 到RGB++：CKB 如何賦能比特幣生態資產協議》是一篇關於RGB協議和RGB++的詳細介紹和分析的文章。 RGB協議是一種有潛力的BTC拓展協議，採用了鏈下計算系統，將交易發起者認可的結果提交到比特幣鏈上。 RGB++在CKB鏈上使用Cell表達RGB資產的數據，與比特幣UTXO關聯起來，實現了非互動式交易，解決了RGB協議的一些問題，並支援比特幣資產跨鏈的與CKB鏈上資產互動。 RGB++展現了CKB作為比特幣鏈下結算層的潛力，對比特幣生態有很大的賦能作用。
原文標題：《從RGB 到RGB++：CKB 如何賦能比特幣生態資產協議》
譯者：Shew & Faust，極客web3
顧問：CyberOrange，Unipass
摘要（全部）：RGB協議是有潛力的BTC拓展協議，本質上是一種鏈下計算系統，它採用了和閃電網絡類似的思想：用戶驗證並授權和自身相關的資產波動比較（Verify）你自己），把交易發起者認可的結果/承諾提交到比特幣鏈上。
RGB 協議利用了與染色幣及Mastercoin 部分類似的思想，在比特幣UTXO 上關聯著「寄生資產」。它將鏈下交易數據的承諾“承諾”，存放到比特幣鏈上，而不是像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++，如果追求隱私和自己驗證的安全性，就會青睞RGB++傳統青睞的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交易的承諾（承諾）廣播到BTC網路內，最終寫入BTC鏈上，從而具備「最終性」。
（承諾的結構圖，其實本質是個merkle root）
如果Bob—>Alice 轉帳中，聲明UTXO B 的主人將擁有30 個TEST 代幣，則Alice 只要證明自己是UTXO B 的主人可以，就使用這些TEST 代幣。
5.未來Alice決定TEST代幣轉給別人，當出示這些TEST的歷史來源時，對方可以根據比特幣鏈上的承諾值進行核驗，看Alice是否提供的數據延續性和鏈上的承諾值這樣可以防止數據偽造。
RGB協定的好處在於，可以在鏈下支援複雜的智能合約計算。它本質上把計算步驟挪到了BTC鏈下，僅在鏈上記錄承諾，在保護隱私的同時，在鏈下聲明比特幣UTXO和RGB 資產交易所之間的關聯，借助比特幣來刻錄並實現RGB資產的交易所變更。
由於所有的交易聲明都需要由相關驗證並授權，因此其安全模型基於“理性人假設”，只要符合合理的，只要比特幣是安全的，RGB資產數據就“基本安全”。
但RGB協定的缺陷也很明顯（前文有資料孤島與碎片化儲存問題）。首先，要給其他人回合，甚至要先得到對方的同意和確認，雙方基本上要同時在線；
其次，由於缺乏全域可見的資料記錄方式，RGB的合約發布甚至都採用了非常奇葩的形式，合約使用者要事先從合約發布者處，獲知合約包含的介面功能，具體的獲知方式可以是透過電子郵件或二維碼。 （看官方目前的說辭，估計把合約代碼掛官網首頁、推特置頂也可以）
我們接下來討論一下RGB協定的合約狀態。在RGB協定內部，合約的底層狀態（Genesis）由創建者在合約創建時就設定好，例如RBG-20合約中的代名稱、介面等。然後，合約的狀態伴隨著RGB交易的持續遞減，但這種合約狀態演進是非線性的，構成了一個有向無環圖的DAG。
（假設owner1的視野範圍是藍色和綠色部分，Owner2的視野範圍是藍色和黃色部分）
比如說Bob給Alice的轉帳時，僅出示從合約初始化，到Bob取得代幣的部分轉帳紀錄，包含的資料路徑比較張力。而Alice也只能獲知該路徑分支包含的交易信息，獲悉難以獲知其他人的轉賬信息這雖然保護了RGB用戶的隱私，但也帶來了不良後果：用戶很難獲知RGB的全局狀態，比如每個人都有多少RGB資產。這會帶來很多麻煩。
比如說，當Bob—>Alice轉帳進行到最後步驟，其承諾值被寫入BTC鏈上且不可逆轉後，Bob可以在本地刪掉部分資料——假設Bob將自己的全部測試代幣都給了別人，可以直接把本地存放的測試代幣相關資料刪掉，以減弱儲存壓力。
而作為代幣接收方的愛麗絲，則要在本地記錄涉及交易所的全部資料。 （假設鮑伯刪掉了本地的測試代幣數據，愛麗絲的客戶端節點又因為事故徹底損壞了，所以此當時，Alice的資產是不是就永久凍結了？因為其他地方沒有Alice的TEST資產數據，預留事先就備份好。）
這本質上可以歸結為DA和資料儲存問題，即RGB協定的新增資料能夠以可靠、全域可見的方式傳播出去，最終會讓不同的客戶端成為「資料孤島」。鄰居曾在以太坊生態如日中天，但最終被毀壞的等離子方案，也是因為無法解決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 協定中實現的難以實現的場景將會更容易落地。
（RGB++的交易流程，把RGB資產資訊寫入Cell，再將Cell與比特幣UTXO建立關聯，最後把CKB上發生的RGB++交易，以及與RGB++資產關聯的比特幣UTXO，並在包含承諾裡，再承諾把值寫到比特幣鏈上）
可能有人第一次想到EVM。我們是否可以用EVM 承載RGB 的狀態與驗證？答案是：很麻煩，因為RGB 資產本質上寄生於比特幣UTXO，與比特幣UTXO 有1 對1 的映射關係。如果假定比特幣UTXO 與EVM 一致性資料建立映射關係，在技術實作上並不不止，不如直接選擇一條UTXO 公鏈。
而且，以太坊上的「資產」往往是點對礦池的公共物品，一個合約上記錄無數人的資產數據，合約控制者擁有絕對權力，這種資產處理方式與幣種UTXO 以及RGB 協議嚴重衝突，之後兩者的設計思路，是徹底實現資產的考慮化，每個人完全控制自己的資產（注意紙幣和微信支付的區別），本質上以太坊和EVM鏈始終存在的：資產契約所有者剝奪職權、契約出bug導致資金損失、資產契約的資料要遷移時很麻煩等問題。
（取自極客web3過往文章：《科技圈名人響馬：高性能公鏈難出新事，智能合約涉及權力分配》）
所以，如果推斷比特幣UTXO 與鏈下RGB 資產之間的映射關係表達的至少大於，最好的選擇還是透過UTXO 鏈。而CKB 支援拓展的是類型UTXO－Cell，且CKB VM 的指令集是基於RISC-V，Link EVM更容易相容於不同的密碼學演算法，包括比特幣的公私金鑰驗證演算法，因此更利於實作RGB++提出的技術方案。
RGB++的技術實現
RGB++使用了CKB的擴展型UTXO——Cell。而一個Cell包含以下字段：
容量代表該Cell擁有的鏈上空間大小，data指Cell內部包含的資料集，可以被讀取或修改。
Type 是這個Cell 綁定的程式碼，限制了資料資料的修改條件。例如，你的Cell 裡有100 張TEST 代幣的數據，但你聲明將110 張TEST 轉給別人，這不符合Type 裡規定的限制條件，會被拒絕。
而Lock則代表Cell的驗證邏輯，類似比特幣UTXO的解鎖腳本。
我們可以把Cell 理解為升級版的UTXO，多生長類型和容量這兩個字段，且資料可以自訂資料類型，至於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++ 仍然要在比特幣鏈上發布承諾，與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++，如果追求隱私和自己驗證的安全性，就會青睞傳統的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 轉帳發生後，把各個交易聚合起來，產生一個對應批量交易的承諾，一次性發佈到比特幣鏈上具體進行以下流程圖：
BTC 資產跨鏈直接與CKB 鏈上資產交易
RGB++ 實作了比特幣UTXO 與CKB Cell 之間的關聯映射後，可以直接實作消耗資產跨鏈的互通性。你可以透過RGB++ 交易聲明，把自己的比特幣UTXO 轉移給別人，對方可以把自己的CKB這種模式擁有很大的想像空間，結合前面提到的交易折疊（批量交易），理論上可以實現取代BTC 資產跨鏈的BTC－CKB 鏈上資產互通。
總結
RGB++把存放在不同RGB客戶端本地的資產數據，直接用CKB鏈上的Cell表達出來，再把Cell與比特幣鏈上的UTXO關聯起來。用戶可以透過比特幣帳戶/資產，與自己在CKB鏈上這種方式比較簡潔，並且解決了RGB協議中需要雙方事先通訊、難以支援全局可見的狀態、儲存資料碎片化、智能合約及Defi不一致性等問題。
RGB++消耗資產跨鏈，就可以實現BTC—CKB之間的互通，同時考慮RGB資產與Defi場景結合，極大程度上解決了RGB協議的數學性問題。但對於追求高度隱私的RGB小眾玩家就而言，RGB++本質上要達到隱私換易用性，一切都要看用戶的取捨。但理論上來說，隱私問題可以在CKB 鏈上透過引入ZK 等方法來解決。
整體而言，RGB++展示了CKB作為比特幣鏈下結算層/計算層的潛力，而這種想法將在未來，被越來越多的比特幣Layer2或資產協議所採納，可以預見的是，比特幣鏈下的第三方結算層間的角逐，或許很快就會展開。而主打POW和UTXO、經歷了多年技術累積的CKB，或許能夠在淨化區塊鏈的角逐中展現自己的技術優勢。
原文連結
資訊來源：0x資訊編譯自網際網路。版權所有，未經許可，不得轉載