比特幣資產發行協議RGB真正潛能在哪裡？

新聞視界時報-記者王自凱

什麼是RGB 協定？

在比特幣上發行資產的想法由來已久。但比特幣協議有自身的特性：其狀態由且僅由比特幣UTXO（「未花費的交易輸出」）來表達；一個UTXO 僅攜帶兩個數據：它本身的面額（比特幣價值），以及一個「腳本公鑰」（也稱為「鎖定腳本」），用於編程這筆資金的花費條件，例如：提供某個公鑰的簽名；允許用來編程鎖定腳本的操作碼由比特幣的共識規則提供，它們不能用來實現任意的安全規則。因此，我們不可能在UTXO 內部創造其它資產—— 比特幣腳本不能編程出這些資產的安全檢查。這意味著，所有在比特幣上發行資產的想法，本質上都是對比特幣區塊空間的創意運用。這意味著，我們需要設計一種鏈外的智慧合約系統，並要求將改變合約狀態的步驟—— 例如，合約A 改變了參數，B 將一定數量的某種資產轉移給了C —— 的訊息上傳到區塊鏈，從而，可以透過收集這些信息，獲得這個智慧合約系統的最新狀態。

一個粗糙的設計想法是，將改變合約狀態的步驟的資訊原封不動地上傳到比特幣區塊鏈。這當然是可以工作的，但是，它會面臨幾個方面的問題：（1）由於上傳了完整的信息，它可能會消耗較多的區塊空間，當用戶需要改變合同的狀態（例如轉賬）時，也將需要付出更多的鏈上手續費。尤其是，當我們希望這樣的鏈外合約系統具備比比特幣更好的可編程性時，可編程性的增加可能以消耗更多的區塊空間為代價；（2）區塊內的幾乎任何一處的信息，都有可能改變鏈外的智能合約，因此，用戶必須獲得所有的比特幣區塊數據，才能得出這個鏈外合約系統的最新狀態，即它的驗證成本更高；（3 ）取決於鏈外智慧合約系統的設計，也許只能獲得跟比特幣相當的隱私性，甚至更差的隱私性；而如果可以提供更多的隱私性，又可能需要消耗更多的區塊空間。

過去，一種使用量較大的協議叫做“Omni”，它不會上傳鏈外合約交易的完整訊息，只會上傳交易的雜湊值。這種做法解決了上述問題1，使鏈外合約交易的複雜性與其經濟成本解耦；但用戶依然需要獲得全量的比特幣區塊數據，才能得出Omni 協議的最新狀態；此外，它也並沒有專門加強隱私性。

而RGB 則使用了新的範式，叫做「一次性密封（single-use seals）」。它的用法很簡單：RGB 要求每一個合約的每一個狀態，都必須附身於某個比特幣UTXO；而一旦要改變這個狀態，就必須花費這個UTXO、讓花費它的交易得到區塊鏈的確認；此外，花費它的比特幣交易還必須提供狀態轉換的內容的雜湊值，以指明變更後的狀態所附身的UTXO。

在RGB 開發者看來，這種設計跟著編號的塑膠密封條有類似的地方：很容易看出它是否被拆過，而且一旦被拆過，就無法再用了。但是，另一個角度是，將被附身的UTXO 當成這個狀態的容器或者說陶瓷存錢罐—— 想要拿出存錢罐裡的錢，就必須打破這個存錢罐，然後把裡面的錢放到新的罐子裡。

這種設計與先前的把整個區塊都當成一個大寫字板的協議形成了鮮明的對比：使用UTXO 當容器，就意味著，不花費這個UTXO 的交易對容器裡面的合約狀態不能構成任何影響，因此，要驗證某一個合約的某一個狀態，我們就不需要獲得全部區塊的數據了，我們需要的只是一連串的比特幣交易、這些比特幣交易在某個區塊中存在在證據、這些比特幣交易所承諾的RGB 狀態轉換（跟相關的比特幣交易一一成對），即可。這些可以串聯成一個鏈條的數據，應該能讓我們上溯到這個合約的初始狀態，使我們能夠辨認出這個狀態的實質。

對於熟悉鏈上智慧合約系統（例如以太坊）的讀者來說，這個過程難以理解的一個地方在於：如果不依賴區塊鏈的共識（它意味著合約的初始狀態和每一次狀態變更都會被每一個節點驗證），這種智慧合約系統的安全性是如何保證的？如何確保自己收到的資產就是自己想要的那一種，如何確保資產沒有被非法增發？

答案也很簡單，叫做「客戶端驗證（client-side validation）」－－你自己驗證。在鏈上合約系統中，節點根據公開的狀態轉換規則，驗證每一次狀態轉換操作、拒絕掉無效的操作，從而根據初始狀態計算出最新的狀態。但是，只要狀態轉換規則和初始狀態是可知的，通過鏈上共識來驗證就不是唯一的辦法，用戶可以根據支付方提供的材料，自己驗證狀態轉換的每一步是否都遵循了最初定義的狀態轉換規則。透過這種辦法，驗證的一方（假設是資產的接收方）同樣能檢查出非法的狀態轉換，並拒絕接受。

最後，我們用一個例子來展現RGB 協定的特點：

現在，Alice 擁有UTXO A'，保存著根據RGB 協議發行的X 單位的資產Y，她希望將Z 單位的Y 轉移給Bob。這批資產一共經歷了5 個前所有者（包括資產發行者），才到達Alice 手上。因此，Alice 要給Bob 提供這4 次狀態轉換的證據（這其中前面3 次的證據都是由前任所有者提供給Alice 的），包括合同的初始狀態和狀態轉換規則、每一次轉移所用的比特幣交易、每一筆比特幣交易所承諾的RGB 交易、這些比特幣交易得到某個區塊確認的證據，一起發送給Bob，Bob 將根據合約的狀態轉換規則，驗證這4 次轉移沒有違反規則，然後再決定是否要接受。當Alice 構造RGB 交易時，由於Z 小於X，她也要給自己安排一個UTXO 來接收剩餘的部分。最後，Alice 將這筆RGB 交易的雜湊值嵌入花費UTXO A' 的比特幣交易中，完成這筆支付。

最終，由於使用了UTXO 容器，一個RGB 的合約的最新狀態可以表示成一個有向無環圖上還沒有後代的點（每個點都表示一個存放在UTXO 容器內的狀態）。並且，對下圖中的所有者P 來說，他將只知道從合約的初始狀態G 到達他的過程，也即紅圈標註的過程，而對灰色的點一無所知

RGB 的優勢

清涼的可驗證狀態

如上所述，與先前在比特幣上出現的資產發行協議（鏈外合約系統）相比，RGB 大幅降低了驗證（一個合約的某一個狀態）的成本。在交易的時候，接收者不再需要遍歷所有區塊來收集合約狀態改變的訊息，而只需獲得一連串的比特幣交易，以及這些交易所承諾的RGB 交易、這些比特幣交易的區塊包含證據（根據區塊頭的梅克爾證據），就能確信支付方真的擁有一定數量的某種資產。

這種驗證成本的降低，也大幅減少了使用者對大型基礎設施供應商的依賴（信任）。在以往的協議中，由於驗證成本較高，用戶難以自行計算合約的最新狀態，因此用戶必須信任一些供應商（例如自己的錢包所使用的合約狀態供應商）；同時，因為可以負擔這樣的計算成本的供應商較少，這也意味著供應商的中心化。但在RGB 中，用戶只需使用比特幣輕客戶端來檢查與比特幣交易的部分、使用RGB 協議來檢查RGB 交易的部分，自己就可以負擔。

跟一些鏈上合約系統相比，RGB 同樣顯得輕量。這體現在RGB 可以針對性地驗證一個合約的某一個狀態；而在那些不是基於UTXO 的系統上，由於缺乏UTXO 這樣控制准入的機制，任意一筆交易都可能改變任意狀態，所以，你幾乎不可能針對性地驗證某一個狀態，而只能在計算出所有最新狀態的同時確定某一個狀態－在這個意義上，被表達為「全域狀態（global state）」的特性實際上應該被稱為“整體狀態（uniform state）”，雖然它提供了合約之間交叉訪問的特性，但這也決定了其驗證成本會更高、更難獲得免信任性。

在這些鏈上合約協議上，一個重大的優化措施是要求區塊頭承諾最新狀態（「狀態根」），從而允許輕客戶端依據這些承諾驗證從全節點處得到的某個合約的某個狀態。這是一種複用已經發生的計算（全節點已經運行過的計算）的方法，也非常高效，因此，如果不考慮免信任性，可以認為它比RGB 更有效率。但是，它畢竟意味著：輕節點在交易基礎驗證以及合約狀態計算上都依賴全節點。而在使用比特幣輕客戶端的RGB 錢包中，它所依賴的信任假設是相關的比特幣交易是有效交易，而與合約狀態相關的部分則是客戶端親自驗證過的，因此免信任性更好。缺點是驗證的時延更長，需要保管的資料更多。

可擴充性

RGB 的可擴充性體現在兩個面向：

1. 嵌入比特幣交易中的只是一條哈希值，這意味著RGB 交易的體積（除了合約自訂的規則之外）沒有什麼限制—— 即使你把一份RGB 資產分成了100 份（RGB交易本身將非常大），需要嵌入比特幣交易中的只有一條哈希值。如註6 所述，嵌入這樣的哈希值的方法有兩種：一是使用OP_RETURN 輸出，這意味著它會消耗一個哈希值的鏈上空間；二是隱藏在Taproot 輸出的腳本公鑰所承諾的腳本樹上— 這不會消耗任何鏈上空間。這一點同樣也意味著，用戶不必為了可程式性而犧牲經濟性—— 僅考慮鏈上手續費的話。

2. RGB 合約的最新狀態是一個有向無環圖上沒有後代的獨立的點－這意味著這些狀態可以獨立變更、互不影響，也就是允許並發。這其實也是繼承自UTXO 的特性。這一點同樣也意味著，在一個分支上發生的無效變更（無效交易），不會影響其它分支，更不會導致整個合約卡死，因此也可以視為一種安全性好處。

RGB 在可擴展性上被批評的一點是：每一次轉移，都需要接收者驗證從初始狀態到支付者狀態所涉及的所有交易—— 隨著資產轉手的次數增加，後續的接收者的驗證負擔會越來越重。這個批評是真的。而優化它則意味著我們也要找到一種方法來重複使用已經發生過的運算。證明系統技術（如SNARKs）有望提供這樣的解決方案。

資產定義與報關機制的分化

最後一個好處依然跟UTXO 有關，取決於我們如何理解UTXO 的鎖定腳本機制。

鎖定腳本可以用來編程一筆資金的解鎖條件，因此，它可以實現保管規則。例如，假設一個鎖定腳本包含且僅包含了一把公鑰，那就意味著只有對應的私鑰的主人可以控制它。但是，這樣的保管規則同樣也是比特幣合約式協議程式設計的基礎。例如，一個使用2-of-2 的多重簽名鎖定腳本的UTXO 可以是一條閃電通道；在通道運行期間，雙方可以發生幾乎無數次相互支付，而資金的鏈上形式不會有什麼改變。換言之，在此時，2-of-2 的多重簽名鎖定腳本構成了一種價值轉移機制，允許雙方在不變動鏈上資金形式的前提下轉移價值。

這樣的機制可以用在UTXO 所承載的比特幣價值上，自然，也可以用在它所承載的RGB 資產上。我們可以發行一種RGB 資產，讓它附身於一個2-of-2 多重簽名UTXO，從而利用閃電通道的機制，在雙方間無限次相互支付這種資產。同理，RGB 資產也可以進入其它基於比特幣腳本的合約。

在這裡，UTXO 的腳本和RGB 協議形成了功能上的分化：前者致力於實現價值保管和價值轉移的規則；而後者專注於資產定義。從而，資產的保管和資產的定義可以分開。這是一種重要的安全性提升，也是人們在一些別的鏈上合約系統中孜孜以求的東西。

RGB 已完成的設計

上述特性，實際上對所有基於UTXO 一次性密封和客戶端驗證的協定都成立。但在此基礎上，RGB 協定又做出了進一步的設計。

在目前的RGB 協定的開發中，開發者特別關注協定的隱私性，因此RGB 在兩個方面加強了隱私性：

盲化UTXO。在RGB 交易中，接收者只需使用混淆後的UTXO 識別碼來接收資產，而無需暴露真正接收資產的UTXO 的特徵。這絲毫無損接收者向下一任所有者提供證據的能力，同時又使後續的資產接收者可以對抗前任資產所有者的窺探。
Bulletproof。可用來隱藏每一次交易中的具體金額。但後續的資產所有者依然能驗證先前沒有出現過增發。

可探索的空間

在這一部分，我將討論RGB 協定還可以繼續探索的空間，主要跟可程式性有關。

目前，已經提出的RGB 合約範本（schema）都集中在資產發行上。但是，由於RGB 使用了「客戶端驗證」範式，實際上，我們可以為它添加任何可以用客戶端驗證來確保的特性—— 僅受UTXO 這種結構的限制。

限制條款

而在UTXO 的基礎上，一個可以拓寬可程式性的概念叫做「限制條款（covenants）」。限制條款的本意是限制一筆資金可以轉移的目的地。有了這種能力，我們就可以編程許多有趣的應用，例如：

非互動式提款的資金池。我們可以讓許多人的資金匯集在同一個UTXO 中，並使用限制條款保證他們任何人都無需其他人幫助，就可以取出屬於自己的資金。這可以起到在區塊空間需求高漲時以低成本幫助人們從高風險的地方退出的作用。
保險箱合約。讓一筆資金必須先花費到某個地方、經過一個時間鎖才能自由花費；而在時間鎖期間，保險櫃主人可以用一把緊急密鑰打斷這個過程、將資金立即轉移到別的地方。這種裝置可以為自主保管提供極大的幫助。

目前的比特幣腳本並沒有這種能力，因此，在比特幣腳本上啟用限制條款需要軟分叉。

但是，只要我們願意犧牲一些由「資產定義與保管機制的分化」帶來的好處的話，我們就可以在RGB 資產上實驗這樣的特性，我們可以在RGB 合約層面實現這樣功能—— 雖然它只能對使用它的RGB 資產生效（而不能對比特幣生效），但無疑會開啟一個有趣的空間。

已有的限制條款的研究表明，它可以拓寬基於UTXO 的交易的程式空間，提供許多特性。但這些研究基本上是基於比特幣的，而在比特幣這樣的協議上，我們會更保守一些。而在RGB 上，我們可以大膽地將限制條款的核心能力—— 在腳本層面讀取花費自身的交易的能力—— 進一步泛化，從而提供更靈活的可編程性：交叉訪問合約的能力。

交叉訪問

最小的限制條款意味著一個UTXO 在被花費的時候，其腳本可以讀取花費交易的輸出。但完全泛化的限制條款則意味著：它可以讀取花費它的交易的所有部分。這就意味著，它也可以讀取交易的其它輸入，如果我們不限定其它輸入必須來自同一個合約，那就意味著，它可以讀取其它合約的狀態。

在RGB 中，我們預設每一個合約都是一個獨立的宇宙，有屬於自身的有向無環圖。但是，依然有可能出現一個用戶同時持有兩個不同合約的狀態的情況。如果RGB 交易允許同時花費來自兩種合約的資產，這樣的交叉存取能力也許就有應用場景（儘管可以想像它會讓交易的驗證變得更加複雜）。

實際上，已經有基於UTXO 類似結構的鏈上合約系統（例如：Nervos Network），使用這一點來實現合約的交叉存取能力11。這是一個非常新的領域，開向以往的比特幣研究很少觸及的領域，也許埋藏著什麼驚喜也說不定。

結論

在本文中，讀者會發現，有一個概念被頻繁提及、貫穿了推理和幻想的所有過程：「UTXO」。這正是我的用意。如果你不理解UTXO，你就無法理解RGB 這樣的協定的設計的起點，也不能理解RGB 協定設計的優點，也無法想像人們使用它的方式。RGB 協定的特性在很大程度上正是由其UTXO 這種一次性密封的形式所塑造的。相應地，比特幣研究領域累積的對UTXO 的研究，也可以我們化用到對RGB 的研究中。

這也解釋了，為什麼不理解比特幣的人，將很難理解RGB。而喜歡比特幣的人，會認同RGB 已經做出的設計。