2 月 23 日，CELL Studio 創始人 / Nervos CKB 聯合創始人 / RGB++ 協議作者 Cipher、Web3 華語 KOL 花椒、RGB 中文布道者大胖墩、極客 Web3 創始人 Fasut、CKB 生態基金 CMO/SeeDAO 發起人 Baiyu 以及 CKB 社區大使 CyberOrange，在 X Space 的直播活動中，和大家聊了 RGB++ 協議的前世今生。
這場直播持續了一個半小時，幹貨非常多，歡迎還沒有收聽的小夥伴點擊下方鏈接收聽音頻回放：https://twitter.com/ckbcell/status/1760995772840268105?s=61&t=IYlGL8YIKMjrbZkcBRmuJA
以下是根據音頻整理的重點內容：
1. RGB 協議的發展歷程#
RGB 協議最早可以追溯到 Peter Todd 在 2016 年提出的客戶端驗證，其核心思想是，我們不需要所有的東西都放在鏈上，我們只需要區塊鏈去做它能做的事情，比如輕量化的驗證。這是一代目。
二代目是 Giacomo Zucco，他受到 Peter Todd 想法的啟發，最初概念化了 RGB 協議，但這個 MVP 做得非常不完全。
三代目是現在的 Maxim Orlovsky。RGB 協議 90% 以上的代碼，是 Maxim 博士貢獻的，他沒有進行融資，全靠捐贈和自掏腰包，但捐贈也只能解決個人的一些經濟問題，沒有足夠的經費去招募大量的工程師。另外，Maxim 博士還成立了 LNP/BP 標準協會，以推動 RGB 協議走向實際應用。
關於 RGB 協議和 LNP/BP 標準協會的更多介紹，歡迎觀看 Web3 華語 KOL 花椒製作的系列 Youtube 視頻：https://www.youtube.com/playlist?list=PL9_Eoig1ztix_j6N6hqswuvDv3FDiSoJO
RGB 中文布道者大胖墩補充說，RGB 被視為比較正統的一種比特幣擴容方案，被很多人寄予希望。但 LNP/BP 標準協會是非盈利性的，主要依賴於捐贈，沒有足夠的經費去招募開發者，導致 RGB 協議進展緩慢，目前還沒有 roadmap，存在很多不確定性，而這又會進一步拖慢其他基於 RGB 的項目的開發進度，形成 “惡性循環”。
另外，目前 RGB 及其協會的控制權主要在 Maxim 博士一個人身上，大胖墩認為該協會應該更開放一些。
2. RGB++ 的誕生背景#
Cipher 介紹說，幾個月前看到一篇介紹 RGB 的文章，文中提到了 RGB 協議存在數據傳輸、用戶交互等方面的劣勢，比如說 RGB 轉賬需要雙方同時在線，需要進行交互式操作，發送方還需要提供資產的歷史數據證明，等等。Cipher 認為 RGB 協議很優雅，但用戶體驗不夠友好，甚至有些麻煩，而且在應用層實踐上存在很多問題，比如 RGB 的數據分散在每個人的手裡，導致做 DeFi 或者是做 DEX 等應用非常困難。
產品經理出身的他，敏銳地察覺到 RGB 協議的這些困難或者說劣勢，其實可以直接在區塊鏈上解決，比如不依賴任何人的 P2P 網絡、共享數據、能驗證交易的虛擬機、非交互式的操作體驗。這也是 RGB++ 最早期的核心想法，即把 RGB 協議鏈外的客戶端驗證要做的事情，委託給一條圖靈完備、基於 UTXO 模型和 PoW 共識機制的區塊鏈去解決。
RGB++ 的優點有很多，比如可以實現交易的非交互性、交易折疊、用戶體驗非常友好等，缺點是隱私性沒有 RGB 本身那麼好，但也只是降低到比特幣區塊鏈的隱私保護水平。另外，需要指出的是，RGB 的隱私保護也不是完美的，因為發送方需要提供資產的所有歷史證明，接收方能看到發送方之前的交易記錄。在 CKB 上，其實可以用 Mimblewimble 協議來隱匿交易金額、斬斷交易歷史，讓 RGB++ 擁有更好的隱私性，不過第一階段團隊沒有精力去做這個。
另外，Cipher 還提到了 X 上關於 RGB++ 協議的一些爭議，他認為大家可以做學術討論，但不應該一上來就扣帽子說它是 scam。點此查看 Cipher 對於爭議的回應。
最後，Cipher 還談到了兼容性問題。RGB 用的是 AIuVM，RGB++ 第一版用的是 CKB-VM，技術上是不兼容的，但得益於 CKB-VM 使用的是 RISC-V 指令集，後續可以把 AIuVM 編譯到 CKB-VM 上，做一個 RGB 兼容層。除此之外，還可以通過 jump 的方式實現資產的打通。
3. RGB++ 協議區別於 RGB 的地方#
CyberOrange 提到，RGB 最重要的兩個技術是一次性密封和客戶端驗證，前者讓 RGB 資產受到比特幣區塊鏈的保護，後者主要是驗證 RGB 資產的交易。RGB++ 協議，除了讓 RGB 用戶使用客戶端驗證之外，還讓他們多了一個選擇 —— CKB 鏈上驗證。如果交易的數額不是很大，用戶可以不用自己去做一個完整的客戶端驗證，而是選擇 CKB 腳本的驗證。
第二點是隱私性，RGB++ 協議把數據放在 CKB 鏈上，讓 CKB 充當 DA 層，其隱私性低於原版的 RGB 協議，這點前面 Cipher 有詳細介紹。正如硬幣有兩面，把 CKB 作為 DA 層，設計 DEX 或者其他 DeFi 應用就會簡單許多。
第三點是擴容能力的區別。理論上 RGB 的擴容能力可能會更強一點，因為它的客戶端驗證不需要區塊鏈，但實際上 RGB++ 協議也可以借助其他的一些機制來實現擴容。
最後，CyberOrange 提到，RGB++ 和 RGB 也是可以實現兼容的。RGB 支持類似 jump 的操作，可以讓 RGB 資產從一條 UTXO 鏈 jump 到另一條 UTXO 鏈，而 CKB 區塊鏈也能支持這項功能，從而打通 RGB 資產和 RGB++ 資產。
「極客 Web3」創始人 Fasut 提到，RGB 的很多理念跟狀態通道有點像，都是需要 verify by yourself（自己驗證）。RGB 網絡就像是無數個 OTC 玩家組成的網絡，轉賬不需要取得所有人的共識，只需交易雙方同意即可，交易的內容也只有交易雙方知道。
不過，Fasut 提到，由於 RGB 交易發送方需要提供資產的所有歷史記錄，如果這筆資產轉手次數特別多，數據量大，可能會帶來存儲壓力和傳輸壓力。另外，RGB 還存在資產碎片化存儲的問題，每個人只存放跟自己有關的資產數據，每個人的客戶端存儲的數據都不一樣，如果某個用戶的客戶端出了問題，數據又沒有備份，那他的資產就永遠動不了了。所以 Fasut 認為 RGB 犧牲了可用性來換取隱私性。
在 Fasut 看來，RGB++ 更像是 “樂觀 RGB”，類似於樂觀匯總（Optimistic Rollup），需要讓用戶相信第三方（這裡指 CKB 區塊鏈）不會作惡。RGB++ 把 RGB 的所有數據放到 CKB 鏈上，同時由 CKB 節點來驗證 RGB 資產的交易，實現了可用性，讓傳統的 RGB 協議省去了很多麻煩。關於 RGB 和 RGB++，「極客 Web3」發布了一篇介紹非常全面的文章，歡迎還未看過的小夥伴點擊鏈接閱讀。
不過在 CyberOrange 看來，RGB++ 並不是強迫用戶要去相信 CKB，而是提供了一個額外的選擇，用戶當然也可以自己使用 RGB 客戶端來驗證所有的交易。
關於前面提到的數據存儲壓力，花椒澄清說這已經不是問題了，Maxim 博士之前就有考慮這點，而且有錢包內嵌了本地的數據庫，不再需要用戶個人去單獨運行 RGB 節點。關於 RGB 交易的 invoice，花椒諮詢了 RGB 開發者，在主網上可以實現離線交易，但在閃電網絡的通道裡不行，必須交易雙方同時在線。關於無主合約，RGB 沒有 global state（全局狀態），所以基於 RGB 做 DeFi 應用會很難，Maxim 博士為此設計了 Bifrost，它相當於閃電網絡的一個子版本，每個 Bifrost 的通道相當於一個 Layer3，可以實現更多意義上的擴容。
4. RGB++ 的時間表#
Cipher 希望在今年 3 月底之前完成 RGB++ 協議第一版的 MVP，包含 RGB++ 在主網的上線，一個在 Layer2 上的支持 fungible token 和 NFT 的 DEX，以及對應的錢包和瀏覽器。
另外，Cipher 也在為 RGB++ 協議招募熟悉 Rust 和 C 語言的開發者，感興趣的小夥伴可以單獨聯繫他。
5. Q&A 環節#
Q1：RGB++ 對開發者的友好程度如何？
Cipher：無論是 RGB 還是 RGB++，開發者的主要工作都是在鏈外，而不是在比特幣鏈上。對於 RGB 來說，開發者的大部分工作是怎麼組裝 RGB 交易、怎麼生成 RGB 證明、在 RGB 上怎麼寫合約等等，在 RGB++ 上要做的事情是一樣的，只不過很多事情 CKB 區塊鏈直接給解決了。以做 DEX 為例，在 CKB 上變成了如何做一個能接受 RGB++ 資產的 DEX，它的開發難度和在 CKB 上開發其他合約的難度差別不大。目前 CKB 上的開發工具相對比較完善了，一個熟練的開發者經過幾天的學習後，大概就可以上手做了。
Q2：RGB++ 和 CKB 代幣之間是什麼關係？
Cipher：每一筆 RGB++ 的交易，都会同步發出一筆比特幣交易和一筆 CKB 交易。每一個 RGB++ 生態裡的用戶，其交易或者資產或者狀態，在 CKB 鏈上都會有一個對應的 UTXO（Cell），會占用和使用一部分的 CKB。另外，開發者也會在 CKB 鏈上去開發合約。
Q3：CKB 獲取到 RGB 的交易後，會壓縮嗎？
Cipher：《RGB++ Protocol Light Paper》裡有提到交易折疊，可以將多筆 CKB 交易與一筆 Bitcoin RGB++ 交易對應，這樣就可以將低速低吞吐量的 Bitcoin 鏈使用高性能的 CKB 鏈進行擴容。
另外就是狀態壓縮，CoTA 協議很早就實現了，你持有不論多少數量的代幣，都可以壓縮到一個 32 字節的空間裡面。RGB++ 能不能實現類似的狀態壓縮，目前還沒有做太多的研究，不過這是一個很好的方向。
Q4：如果在 CKB 上做開發，像 Subgraph、Oracle 等配套工具有嗎？還是說需要等第三方來支持？
CyberOrange：預言機目前 CKB 鏈上還沒有。其他的一些接口，CKB 有一個數據的編解碼標準，可以用那個標準去解析數據，不過可能需要手動去編寫一些東西。
Q5：CKB 的 tps 是多少？
CyberOrange：如果是簡單轉賬的話，CKB 的 tps 可以達到 300 多。
Q6：RGB++ 安全性的文章裡提到，比特幣 6 個區塊確認才幾乎不會被 revert，CKB 大概需要 20 幾個區塊，這會不會對 RGB++ 的用戶體驗產生影響？用戶可能不想等那麼久？
Cipher：如果你只是發一筆一層的交易，它會同步發一筆 CKB 的交易，這個主要取決於比特幣的出塊速度，不需要等那麼多區塊確認，它其實和比特幣上的轉賬體驗一樣。你提到的需要等 6 個區塊確認，是資產從比特幣 Layer1 上 jump 到 CKB 上，為了保證安全性，需要 6 個比特幣區塊確認後，才可以解鎖 jump 過來的資產在 CKB 上的操作。這是由智能合約控制的，不需要多簽或者第三方。之後在 CKB 鏈上的操作，只需等 CKB 上的十秒鐘出塊時間，如果要 jump 回到比特幣鏈上，為了保證安全性，需要等 20 幾個 CKB 區塊確認。jump 的操作並不頻繁，所以對用戶體驗的影響沒有那麼大，而且其他跨鏈方案往往也是要等比較長時間的。
Q7：計劃 3 月底之前出來的 DEX，支持比特幣銘文等資產嗎？
Cipher：是的。