RGB 智能合約：比特幣上的可程式化資產

RGB 是一種在比特幣上構建智慧合約的協議，採用 client-side validation（客戶端驗證）範式，將複雜的合約邏輯從區塊鏈轉移到客戶端執行。與以太坊等傳統智慧合約平台不同，RGB 不需要消耗區塊鏈資源來執行合約邏輯，而是透過密碼學證明在客戶端進行驗證。這種設計使 RGB 能夠在比特幣的主鏈上實現高度可程式化的資產發行與轉移，同時保持比特幣的核心安全特性。

RGB 與傳統智慧合約的根本差異

區塊鏈驗證 vs 客戶端驗證

傳統區塊鏈智慧合約（如以太坊）的運作方式是：所有節點都會執行相同的合約程式碼，並就執行結果達成共識。這種設計雖然簡單明確，但存在幾個根本性問題。首先是擴展性瓶頸：每一筆合約交易都需要所有節點處理，導致網路吞吐量受限。其次是隱私問題：所有合約狀態都是公開的，任何人都可以查看任意帳戶的餘額和交易歷史。第三是資源浪費：大量的計算資源浪費在重複執行相同的邏輯上。

RGB 採用的 client-side validation 範式完全顛覆了這個設計。RGB 合約的狀態轉換不需要整個網路共識，只需要交易的參與方能夠驗證轉換的有效性。比特幣區塊鏈在 RGB 系統中只扮演兩個角色：作為資料可用性層（data availability layer），儲存狀態承諾（state commitment）；以及作為爭議解決層，在發生爭議時提供最終裁決。

這種設計帶來了顯著的優勢。由於合約邏輯不需要在比特幣網路上共識，RGB 可以實現近乎無限的擴展性。隱私保護也大幅提升：只有交易的直接參與方需要知道完整的狀態資訊，區塊鏈上只儲存加密的承諾。同時，由於不需要浪費計算資源在合約執行上，RGB 可以在比特幣主鏈上支持更複雜的金融邏輯。

UTXO 模型 vs 帳戶模型

RGB 繼承了比特幣的 UTXO（未花費交易輸出）模型，而非採用帳戶模型。在 UTXO 模型中，每一筆比特幣交易都會消耗若干輸入並產生若干輸出，所有未花費的輸出構成系統的當前狀態。這種模型的一個重要特性是天然支援並發處理：多筆獨立的交易可以同時被處理，不需要維護全局狀態。

RGB 將這個模型進一步擴展，引入了「RGB20」和「RGB21」等代幣標準。RGB20 類似於以太坊的 ERC-20 代幣標準，用於發行可替代代幣（fungible tokens）；RGB21 用於發行非同質化代幣（NFT）。每一種代幣標準都定義了合約介面和狀態轉換規則，使得不同類型的資產可以在 RGB 協議上統一管理。

帳戶模型的優勢在於易用性：開發者可以直接修改帳戶餘額，不需要追蹤複雜的 UTXO 歷史。然而，帳戶模型也有明顯的缺點：狀態修改必須順序進行，無法並發；帳戶餘額是全局可見的，隱私較差。RGB 選擇 UTXO 模型是出於對隱私和擴展性的考量，但也增加了開發的複雜度。

RGB 合約的核心元件

Schema 定義

RGB 合約的核心是 schema（綱要）。Schema 定義了合約的狀態結構、轉換規則和介面，相當於傳統智慧合約的程式碼。Schema 使用一種名為 AluScript 的腳本語言編寫，這是一種專為 RGB 設計的宣告式語言，可以表達複雜的狀態轉換邏輯。

一個典型的 RGB schema 包含以下幾個部分：

狀態類型定義：描述合約持有的資料結構。例如，一個代幣合約可能定義以下狀態類型：

• TokenInfo：代幣的基本資訊，包括名稱、符號、供應量、小數位數
• Balance：每個 UTXO 持有的餘額
• Approval：授權記錄，記錄某一 UTXO 有權從另一 UTXO 轉移多少代幣

轉換規則定義：描述狀態之間的合法轉換。例如，代幣轉移的轉換規則可能包括：

• 轉出餘額必須足夠
• 轉入 UTXO 必須是有效的
• 簽名必須有效
• 必須燒毀足夠的手續費

介面定義：定義合約對外提供的功能。一個代幣合約可能提供以下介面：

• transfer：轉移代幣
• approve：授權他人轉移
• mint：鑄造新代幣（如果允許）
• burn：銷毀代幣

Schema 的版本管理是一個重要課題。隨著時間推移，合約可能需要升級以修復漏洞或添加新功能。RGB 設計了一套 schema 升級機制，允許在保持向後相容性的同時引入新功能。這包括明確的遷移路徑和新舊狀態的轉換規則。

證明系統

RGB 使用嚴格的密碼學證明來確保狀態轉換的有效性。每一筆 RGB 狀態轉換都伴隨著一個「證明」（proof），這個證明可以驗證該轉換是合法的。證明系統的核心是Bulletproofs（一種零知識證明），這種密碼學技術允許驗證者確認某個陳述為真，而不透露任何額外資訊。

Bulletproofs 的選擇有幾個重要考量。首先是證明大小：相對於其他零知識證明系統，Bulletproofs 的證明大小較小，適合在比特幣區塊鏈上儲存。其次是驗證效率：Bulletproofs 的驗證時間與電路大小成對數關係，適合資源受限的客戶端。第三是通用性：Bulletproofs 可以表達任意計算的證明，提供了足夠的靈活性。

一個 RGB 轉換的證明包含以下幾個組成部分：

輸入證明：證明輸入狀態是有效的，且未被雙花。這包括對輸入 UTXO 的承諾、餘額證明和所有權證明。

轉換證明：證明狀態轉換符合 schema 定義的規則。這是核心部分，使用 AluScript 編寫的邏輯被編譯成算術電路，然後使用 Bulletproofs 生成證明。

輸出承諾：承諾輸出狀態的雜湊值。這個承諾將被寫入比特幣區塊鏈，作為未來轉換的輸入。

證明的驗證過程發生在客戶端。當一個新的 RGB 轉換傳播到網路時，每個客戶端都會獨立地驗證證明的有效性。如果驗證通過，客戶端會更新本地的狀態資料；如果驗證失敗，則拒絕該轉換。

比特幣錨定

RGB 使用比特幣區塊鏈作為狀態承諾的儲存層。每當 RGB 合約的狀態發生變化時，新的狀態承諾會被記錄到比特幣區塊鏈上。這個承諾通常採用 OP_RETURN 輸出的形式，儲存狀態雜湊值。

比特幣錨定的設計有幾個關鍵特性：

最小化區塊鏈負擔：每筆 RGB 轉換只需要在比特幣區塊鏈上儲存一個雜湊值（通常是小於 100 位元組），遠小於傳統智慧合約的資料儲存需求。

抗審查性：比特幣區塊鏈是世界上最安全的區塊鏈，狀態承諾一旦寫入就很難被篡改或刪除。這保證了 RGB 合約狀態的持久性。

可驗證性：任何人都可以通過比特幣區塊鏈確認 RGB 狀態承諾的存在，並驗證相關的狀態轉換。

延遲結算：比特區塊鏈的確認時間決定了 RGB 轉換的最終性。通常建議等待 6 個區塊確認（約 60 分鐘）以確保足夠的安全性。

RGB 合約的開發實踐

設計模式

開發 RGB 合約時，需要遵循一些關鍵的設計模式：

最小權限原則：每個合約應該只授予完成其功能所需的最小權限。例如，一個簡單的代幣轉移合約不應該包含修改供應量的功能，即使該功能存在也應該預設為禁用。

可升級性：合約應該設計為可以升級，以修復漏洞或添加新功能。這包括明確定義升級流程、遷移邏輯和回滾策略。

失敗路徑：每個合約應該明確定義各種失敗場景的處理方式。這包括網路錯誤、驗證失敗、資源耗盡等情況。

常見錯誤與規避

狀態漂移：當多個客戶端的狀態副本偏離時，會發生狀態漂移。這通常是由於網路分區、軟體 bug 或攻擊造成的。規避方法包括：使用強一致性的狀態同步機制、實現狀態驗證和修復功能、定期進行狀態審計。

相容性中斷：當 schema 升級破壞了與舊客戶端的相容性時，會發生相容性中斷。規避方法包括：保持向後相容的設計、實現平滑遷移機制、提供足夠的過渡期。

安全漏洞：RGB 合約的安全漏洞可能導致資金損失。常見的漏洞類型包括：簽名繞過、整數溢出、權限提升。規避方法包括：使用形式化驗證工具、進行多次安全審計、實施漏洞獎勵計畫。

測試策略

RGB 合約的測試需要特別的策略：

單元測試：測試各個獨立的模組和函數。這包括 schema 邏輯測試、密碼學操作測試、狀態轉換測試。

整合測試：測試多個模組之間的互動。這包括客戶端之間的狀態同步測試、比特幣錨定測試、錯誤處理測試。

回放測試：驗證同一個歷史記錄是否能夠重建相同的最終狀態。這是檢測狀態漂移的重要手段。

模擬攻擊：模擬各種攻擊場景，驗證合約的安全性。這包括雙花攻擊、審查攻擊、隱私攻擊。

RGB 代幣標準詳解

RGB20：可替代代幣

RGB20 是 RGB 協議的可替代代幣標準，類似於以太坊的 ERC-20。RGB20 代幣是可以互換的：每個代幣單元都是等價的，任意兩個代幣單元可以互換。

RGB20 代幣的核心介面包括：

interface RGB20 {
    // 取得代幣資訊
    fn name() -> String;
    fn symbol() -> String;
    fn decimals() -> u8;
    fn total_supply() -> u64;

    // 餘額查詢
    fn balance(utxo: Outpoint) -> u64;

    // 轉移
    fn transfer(to: Outpoint, amount: u64) -> StateTransition;

    // 授權
    fn approve(spender: Outpoint, amount: u64) -> StateTransition;
    fn allowance(owner: Outpoint, spender: Outpoint) -> u64;
}

RGB20 的一個重要特性是支援「分割」（split）和「合併」（merge）操作。一個 UTXO 可以持有任意數量的代幣，轉移時可以將代幣分割到多個輸出。這提供了比以太坊帳戶模型更大的靈活性。

RGB21：非同質化代幣

RGB21 是 RGB 協議的非同質化代幣標準，類似於以太坊的 ERC-721。與可替代代幣不同，每個 NFT 都是唯一的，不可互換。

RGB21 代幣的核心介面包括：

interface RGB21 {
    // 取得 NFT 資訊
    fn name() -> String;
    fn symbol() -> String;

    // NFT 查詢
    fn owner(token_id: u64) -> Outpoint;
    fn tokens(utxo: Outpoint) -> Vec<u64>;

    // 轉移
    fn transfer(token_id: u64, to: Outpoint) -> StateTransition;

    // 元資料
    fn metadata(token_id: u64) -> Metadata;
    fn set_metadata(token_id: u64, metadata: Metadata) -> StateTransition;
}

RGB21 還支援「衍生代幣」（derivative tokens），即從屬於某個主 NFT 的子代幣。這可以用於表示會員資格、等級系統等場景。

RGB25：非同質化可分割代幣

RGB25 是 RGB 協議的非同質化可分割代幣標準，結合了 RGB20 和 RGB21 的特性。每個代幣單位雖然是唯一的，但可以分割成更小的單位。這適用於表示份額、票據等場景。

RGB 的擴展應用

去中心化交易所

RGB 協議可以支持原生的去中心化交易所功能。由於 RGB 採用 UTXO 模型，可以實現原子交換（atomic swap）：兩方可以直接交換不同類型的代幣，不需要可信的第三方。

原子交換的原理是使用哈希時間鎖合約（HTLC）。假設 Alice 想要用她的 RGB 代幣交換 Bob 的比特幣，流程如下：

1. Alice 創建一個 HTLC，設定一個秘密雜湊和鎖定時間
2. Bob 將比特幣發送到 HTLC 合約
3. Alice 使用秘密揭露比特幣，完成比特幣轉移
4. Bob 看到比特幣被揭露，取得秘密
5. Bob 使用同一個秘密完成 RGB 代幣轉移

這個過程是原子的：要么雙方都完成轉換，要么都不完成。

借貸協議

RGB 可以支持去中心化借貸。用戶可以將自己的 RGB 代幣作為抵押品借款，借款利率由市場決定。借貸合約需要處理以下核心邏輯：

抵押品管理：記錄每個借款人的抵押品數量和價值。當抵押品價值下降到閾值以下時，觸發清算。

利率模型：根據供需關係動態調整借款利率。這通常使用「利用率」指標：利用率越高，借款利率越高。

清算機制：當抵押不足時，任何人都可以發起清算，拍賣抵押品並償還借款人。

衍生性商品

RGB 可以支持各種衍生性商品合約，包括：

期貨合約：允許用戶在未來某個時間以特定價格買賣資產。RGB 的客戶端驗證非常適合期貨合約，因為結算邏輯可以在客戶端執行，只需要比特幣區塊鏈提供最終裁決。

選擇權合約：賦予持有人在未來某個時間以特定價格買賣資產的權利。選擇權的定價和結算邏輯複雜，但可以使用 RGB 的強大表達能力實現。

結構化產品：將多個基礎金融工具組合成單一產品。RGB 的模組化設計使得組合不同金融工具變得相對簡單。

RGB 與其他比特幣智慧合約方案的比較

RGB vs 以太坊 VM

RGB 和以太坊 VM（EVM）代表了兩種截然不同的智慧合約設計哲學。EVM 是圖靈完全的：任何可計算的程式都可以在 EVM 上執行。這提供了最大的靈活性，但也帶來了安全性問題和擴展性限制。

RGB 採用了更保守的設計：不是圖靈完全的，但足以表達大多數金融合約邏輯。這種設計的好處是更容易進行形式化驗證，安全性更容易保證。

在隱私方面，RGB 遠優於 EVM。EVM 合約的所有狀態都是公開的；RGB 的狀態只在交易參與方之間共享，只有承諾被公開在區塊鏈上。

在擴展性方面，RGB 也有優勢。EVM 的每筆交易都需要整個網路處理；RGB 的交易只需要客戶端驗證，區塊鏈只儲存承諾。

RGB vs 閃電網路

閃電網路是比特幣的第二層支付通道，專注於快速、小額的支付。RGB 更加通用，可以用於構建各種類型的智慧合約，而不只是支付。

兩者可以結合使用：RGB 合約可以在閃電網路上進行狀態轉換，實現更快、更私密的支付。

RGB vs Stacks

Stacks 是另一個比特幣智慧合約層，使用不同的共識機制（Proof of Transfer）連接到比特幣區塊鏈。Stacks 有自己的區塊鏈和代幣（STX），智慧合約使用 Clarity 語言編寫。

RGB 的優勢是完全依賴比特幣區塊鏈的安全性，不需要額外的共識機制。Stacks 的優勢是開發體驗更接近傳統智慧合約平台，有更成熟的開發工具。

RGB 的發展現狀與未來

生態系統

RGB 生態系統正在快速發展。主要的開發團隊和項目包括：

LNP/BP 標準協會：推動 RGB 協議的標準化，維護核心庫和工具鏈。

My Citadel：一個 RGB 錢包和瀏覽器，提供資產管理、轉移和質押功能。

Satoshi Lab：開發 RGB 相關的開發工具和 SDK。

RGB DAO：一個去中心化自治組織，協調 RGB 生態系統的發展。

技術挑戰

RGB 面臨幾個主要的技術挑戰：

工具成熟度：相對於以太坊，RGB 的開發工具鏈還不夠成熟。調試、測試和部署工具需要進一步完善。

用戶體驗：客戶端驗證範式對用戶來說是新的概念，需要更好的使用者介面和說明文件。

標準化：RGB 的各項標準還在演進中，不同實現之間的相容性需要時間建立。

未來發展方向

RGB 的未來發展方向包括：

更好的隱私：目前 RGB 的隱私特性依賴於客戶端的嚴格保密。未來可能引入更強的隱私機制，如零知識證明用於餘額證明。

跨鏈互操作性：支持與其他區塊鏈的資產跨鏈轉移，提供更大的流動性。

Layer 2 擴展：在 RGB 之上構建第二層解決方案，進一步提高吞吐量。

形式化驗證：為 RGB 合約開發形式化驗證工具，提供數學級別的安全性保證。

總結

RGB 代表了一種創新的比特幣智慧合約範式。通過將合約邏輯從區塊鏈轉移到客戶端，RGB 實現了更好的隱私保護和擴展性，同時保持了比特幣主鏈的安全性。

RGB 的客戶端驗證、UTXO 模型和比特幣錨定設計，共同構成了一個強大而獨特的智慧合約平台。雖然工具鏈還在成熟中，但 RGB 已經展現出在比特幣上構建複雜金融應用的潛力。

對於開發者和投資者來說，RGB 值得持續關注。它的設計哲學——犧牲部分圖靈完全性以換取更好的安全性和隱私——可能更適合構建金融應用。