BiHelix RGB V0.11版本前瞻：資產發行概要

作者: Zoom, Echo, BiHelix

引入

隨著Nervos聯創Cipher提出了名為RGB++的方案，市場上對RGB原生協議的討論與熱議也日益增長。RGB作為由LNP/BP標準協會打造的可擴展且保密的比特幣與閃電網絡智能合約系統，一直備受比特幣生態開發者的青睞，被視為BTC原生拓展協議中具備巨大潛力的一環。作為比特幣去中心化金融（BTCfi）和應用（DApps）的基礎架構，RGB標誌著將比特幣的實用性從單一的價值儲存功能拓展至更為廣泛的領域，這是一項具有歷史意義的里程碑。其引領的技術革新不僅令人振奮，更將為整個加密貨幣生態帶來全新的發展方向與可能性。

2023年年末，RGB原生團隊LNP/BP標準協會為了更好地迎接市場挑戰並促進比特幣生態的蓬勃發展，宣布RGB即將升級並發布v0.11版本。本篇文章將詳細介紹 RGB v0.11 協議升級的功能和技術基礎，全面概述 RGB v0.11 所支持的資產生成功能和交易功能，包括採用可信證明共識、可擴展性優化以及關鍵安全強化。我們深入研究了與現有共識方案相比的信念證明的基本原理和權衡，以及證明 v0.11 解鎖的 Gas 節省和吞吐量增加的量化基準。

RGB 資產生成

目前 RGB 協議V0.11版本中內置三個資產類型，包括RGB20（代幣），RGB21（NFT）和RGB25。以RGB20為例，我們討論目前協議的實現步驟和可執行權利。

1. 首先，合約的發行者需要根據 RGB20 協議設置好關於 RGB 代幣的初始狀態，比如定義合約的細節：資產的名稱、初始發行量，總供應量，增發，重命名，銷毀等權限等。
2. 其次合約發行者指定一個來接收初始發行量的 UTXO，這樣就可以創建一個簡單的 RGB 資產。其中狀態變更可以應用在變更資產所有權的權利上，也可以應用在別的類型的權利上。例如：

• 增發接口：當合約開啟增發權限時，需要指定一個地址接收這筆增發的資產。當然 RGB20 限制了增發的上限，合約發行者不能無限增發。
• 銷毀接口：合約發行者可以指定一個或多個人擁有代幣的銷毀權限。因為RGB20採用P2P交易（交易篇會介紹），所以用戶很難把代幣打入黑洞地址進行銷毀。
• 重命名接口：合約可以進行更新資產名稱。

因為 RGB 合約代碼是存儲在鏈下的，如果合約發行方不授權開源，用戶很難驗證資產信息。RGB合約一旦發行，不管是用戶還是發行方都必須遵守合約發行時的狀態定義，杜絕發行方作惡行為。

RGB 資產轉讓

RGB的交易模式採用 P2P（Peer to Peer）轉讓，這與 ETH 有很大的不同。這種轉讓模式需要雙方都要在線，舉個例子 "A 要發送100代幣給 B "操作如下：

1. B 創建發票指定發送 100 代幣。
2. 接受人 A 提出轉帳。
3. B 確認轉帳並簽名。
4. A 廣播交易。
5. A 和 B 接受交易。

這其中 B 把這個發票發送給 A，A 拿到發票後只能遵從發票內容發送 100 代幣給 B。B 需要確認已經接收到 100 代幣才算成功。

• Q：為什麼說兩方都要在線 ？
• A：因為發票具有時效性，如果一段時間不使用，則失效，所以需要A拿到B的發票後立即轉帳。B 也要確保發票能夠立即被 A 使用，才會創建發票。這裡就約束了雙方需要在發票有效時間內完成轉帳。

圖：閃電網絡通道交易

因為 RGB 使用的交易通道集成了閃電網絡，所以交易過程可以參考閃電網絡的轉讓過程，只是增加了"需要收款方再次確認"的步驟。這樣的交易步驟使得收款方不會收到亂七八糟的釣魚幣，從而保護用戶錢包安全。

RGB 資產交易

RGB 資產轉移過程中的技術點

1. 一次性密封

該技術最早由Peter Todd在2016年提出，主要意思是"把一條消息加上一个密封條，確保這個消息只能被使用一次，因為你要知道消息就必須拆除密封條"。

一種簡單的方法是設置一個公證的第三方服務端，每當某一個密封條打開或者鎖上時就在公開的註冊處發布證書，這樣任何人都能驗證自己關心的密封條的狀態。

如果不使用一個受信任的實體來實現一次性密封的功能，可以使用比特幣的 UTXO 來作為密封條。因為比特幣的任何一個 UTXO 只能被花費一次。因此，把 UTXO 作為密封條，就可以在 UTXO 創建的時候鎖上，在花費它的時候打開。

RGB 利用了這樣的"一次性密封"技術，它將 RGB 資產的信息、合約的狀態等都"包裹"在 UTXO 裡面，當 UTXO 被花費的時候，資產的所有權、合約的狀態就發生了轉變。這意味著，每當一筆 RGB 交易發生時，實際上就是發送者給某個合約（定義了被轉移的權利的那個）創建了一次狀態變更。

2. 客戶端驗證

RGB 的驗證和傳統的"全球共識"驗證不同，採用的是"客戶端驗證"的技術。在傳統的比特幣驗證方式裡，一個連接到網絡的節點會持續不斷地下載和驗證區塊以及交易池中的交易（全節點）。這樣的節點對整條鏈上的 UTXO 集（區塊鏈上所有未花費的輸出的集合）有一個實時更新的視圖，當它看到一筆新交易時，要驗證其有效性，只需要驗證該交易的所有輸入都是該 UTXO 集的最新狀態的一部分即可。

但是對於 RGB 而言，沒有全局傳播的數據，因此也沒有這樣的 UTXO 集的全局視圖。一個 RGB 客戶端在接受一筆交易後，不僅需要驗證交易的最新狀態是有效的，還必須對與交易相關的以往所有的狀態轉化作同樣的驗證，一路追溯到發行合約的創始狀態。這看起來會帶來一個明顯的缺點：導致驗證時間很長。但是這僅僅出現在"一項具有很長的交易歷史的資產時"才會出現，而且可以通過一個數據分享層（自願的情況下）提前開始驗證這部分交易歷史數據。

這同時可以帶來明顯的優點：客戶端不需要知道、也不需要驗證全局中發生的所有交易。 因為它只需要知道跟自己錢包相關的交易即可，它不需要驗證其他的交易，因此每個客戶端要驗證的數據量都更小，系統擴展性明顯增強。客戶端驗證完整鏈條的問題，BiHelix 提出遞歸零知識證明方案加以徹底解決。

3. 確定性的比特幣承諾

RGB 防止"雙花"是通過RGB承諾來實現的。這樣的承諾需要實現：

• 涉及合約的多次狀態轉換可以承諾到單筆比特幣交易中
• 每一次合約的狀態轉換都只能被承諾進比特幣交易一次

實現的具體方式是：

1. 首先，跟某一個合約（或者說資產 ID）相關的所有狀態轉換，要確定性地聚合成一個承諾。
2. 然後，所有被轉移的資產的承諾，要被聚合成一棵默克爾樹。
3. 最終的根哈希值，就是最終的 RGB 承諾。
4. 為了保證跟其它無關 RGB、但同樣也需要使用確定性比特幣承諾的協議的兼容性，RGB 承諾和其它協議的承諾要再一次聚合（如 LNPBP-4 標準所述），如此得到的哈希值，才是實際上被嵌入比特幣交易中的消息。
5. 批處理降低成本

由上節可以知道，我們可以將任何數量的狀態變化"包裹"在單個比特幣承諾裡面，理論上可以實現大規模的批處理，從而為 UTXO 服務供應商提供更多應用場景。

• 場景：A 想同時給多人支付，給B轉移一個 RGB20 資產，給 C 轉移一個 RGB21 資產，給 D 轉移一個合約的所有權
• 結果： A 只需為 B、C、D 各創建一個狀態轉換，並將所有的狀態轉換都承諾到同一筆比特幣交易中就可以了，不需要佔用更多字節。這意味著，不同狀態的狀態變化，因為包裹在一個承諾內，實現了批量處理。每筆 RGB 支付的鏈上手續費邊際成本都可以非常小，因為同一筆手續費被任意數量的轉帳平攤了。

這裡也存在局限性，即：這些狀態轉換信息必須要"包裹"在同一個 UTXO 裡面，如果是存在多個，那麼就需要增加這筆交易的輸入，相應的成本等也會提高。但是相對於傳統的每一個狀態變化都需要一筆交易的情況，已經可以實現極大的改善。

5. 客戶端之間的通信

客戶端通信常見於一筆 RGB 轉帳的實現過程中。發送者需要給接收者（們）分享"consignment"，這種數據結構包含了驗證轉帳所需的一切信息，包括可以追溯到合約創始狀態的所有狀態轉換，需要從發送者通過通信方式轉移給接收者。但是在 RGB 協議中不受通信渠道限制，有多種數據分享方式。常見的兩種分享數據的方法：

• Storm：一種點對點的即時通信和存儲系統，基於閃電網絡。
• RGB 代理服務端：一種標準化的 HTTP JSON-RPC 服務端，其客戶端可以上傳和下載數據。用戶可以運行自己的代理服務端，也是在使用第三方的服務端。依賴於第三方的服務端會影響隱私性和抗審查性，但不影響安全性

客戶端通信 BiHelix 也提出了自適應通信協議加以優化。

結論

儘管當前RGB v0.11版本仍處於Beta階段，然而我們不難窺見，眾多的RGB生態項目團隊正積極為其貢獻心血，共同攜手推進v0.11版本的精細優化。作為RGB生態項目及RGB協議的倡導者，BiHelix團隊一直在全力以赴，致力於實現RGB協議的工程化和商業化落地。加速推進閃電網絡和RGB協議的兼容性，同時積極吸納更多高質量的應用生態開發者，讓他們深入學習和應用RGB協議將是其首要目標。

相信RGB協議愈加成熟的資產發行功能集，將為比特幣生態帶來更多創新，再一次將整個比特幣生態推向新的高度。隨著RGB協議在比特幣網絡中的廣泛應用，本文也將成為理解RGB背後機制和設計的不可或缺的重要參考資料。在這個充滿活力的生態系統中，RGB的前景顯得一片光明，正為比特幣的演進注入新的活力和可能性。