來源：字節元 CKB

我知道，一談到這個問題，比特幣純粹主義者可能覺得：比特幣就安靜地做数字黃金不好嗎？為什麼一定要有代幣呢？為什麼非得有 USDT? 不過, 如果你特別在意資產安全的話，就不得不想，以太坊萬一倒了呢？DeFi 誰能接住? 而且，代幣方案與比特幣協議是兼容的，並不會破壞原本的功能，如果不喜歡，可以不下載代幣客戶端，也不會受到很大的影響。

在比特幣上發行代幣：為何不可？

在比特幣上發行代幣，用來將現實世界中的資產交易轉移到鏈上，這個想法在 2010 年左右就在比特幣社區出現了。社區最初的討論是設想把現實世界資產——比如：房產、股票、法幣等資產，都搬到比特幣上進行去中心化的交易。不過由於法律因素，房產和股票這類資產的搬運沒那麼容易。就算你將自己的房子的数字資產代幣支付給了另一個人，政府可能不會承認，或者自動更換現實世界的房產證，還可能需要交各種稅。況且在監管之下還不能隨意在鏈上交易。

因此，更吸引人的方法是發行同法幣掛鈎的代幣 ，即穩定幣。穩定幣與 NFT 不同，它們仍然是同質化的（fungible）代幣，只不過與原本的比特幣做了區分。當作為代幣出現時，它們的價值由所代表的現實世界資產的價格決定，不再有原本的数字貨幣價格（如果数字貨幣的價格漲到比資產價格高太多，捨棄掉資產也不是不行）。這就是為什麼通常比特幣上的代幣都會以聰（Satoshi）為單位。

將数字貨幣作為資產的代幣，需要解決兩個主要問題：

1. 如何用比特幣表示現實世界中的資產；

2. 如何在比特幣十分有限的腳本語言中設置複雜的交易規則和合約。

下面的內容着眼於以上兩點，對目前現有的幾大比特幣資產發行方案做了概括，並從數據可用性、 資產載體、表現力、可擴展性等幾個方面做了比較。

比特幣上的第一個代幣：染色幣

最早在比特幣上設計代幣協議的人已不可考，想法可能產生於比特幣論壇或社區里的討論中。染色幣（Colored Coin）項目是 Yoni Assia 在 2012 年發起的，當時他與 Vitalik Buterin、Lior Hakim、Meni Rosenfeld、Rotem Lev 一起寫了《染色幣白皮書》（Colored Coins whitepaper）[1], 項目在 2013 年開始運行。

染色幣的工作原理是將一個聰標記成為一個特殊的錢幣, 把資產的相關信息寫到這個聰中——這個過程就叫染色。你可以將一個聰染成不同的顏色, 打上不同的標記（tag）, 不過同一種顏色下的硬幣之間還是不能區分的，比如一堆染色成美元的聰，仍然是同質化的。比較早的協議使用的是 nSequence 字段，在交易的第一個 input UTXO 的 nSequence 中加入一個標記。不過 nSequence 存儲上限只有 4 字節，所以後來的代幣設計基本都換成了 OP_RETURN 字段，能儲存更多元數據。

染色幣目前被提起主要還是因為它是比特幣上的第一個代幣項目。由於項目的發展其實並不理想，也沒有得到大規模的應用，項目本身逐漸就被遺忘了。染色幣在當時面臨的問題就是比特幣的功能還不能支持這個比較超前的想法，這個想法要落地，要高效穩定運行是很難的。這可能也是為什麼 Vitalik 在染色幣項目之後走向了比特幣的反面，對智能合約那麼執着。

由於染色幣是以聰的形式存在的，它的驗證就和驗證一個 UTXO 的有效性一樣，都需要下載整個鏈。這個問題在後面會以客戶端驗證（client-side validation）的方式解決。

用 OP_RETURN 發代幣：Counterparty & Omni Layer

和染色幣不一樣，Counterparty[2] 和 Omni Layer[3]（ USDT 背後的協議） 並不直接在聰上染色，而是在交易中設置一個數值為 0 的 UTXO，在這個 UTXO 的 OP_RETURN 中存放元數據。OP_RETURN 可存放 80 個字節，標記了 OP_RETURN 的 UTXO 不能被花費，真正的代幣是 OP_RETURN 中記錄的 i-th output。這個 output 的數值通常是 0.00000546 BTC——系統允許發送的最低值，而且由於代幣的價值並不與 BTC 掛鈎，並沒有必要發比 0.00000546 BTC 多的幣值。

這些項目的驗證都需要在鏈上進行，元數據儲存在鏈上。

Omni Layer 在很長一段時間都是以太坊鏈上的玩家，直到最近才回到比特幣生態，準備發行 BTC-USDT。Counterparty 質押了一部分比特幣，有自己的代幣 XCP。從 Twitter[4] 上看最近應該是在做 NFT。

進一步了解 OP_RETURN，可參考：

1. An analysis of Bitcoin OP RETURN metadata[5]

2. 手動構建 OP_RETURN 發送 USDT[6]

用側鏈錨定比特幣：Rootstock & Liquid Network

Rootstock[7] 和 Liquid Network[8] 這兩個項目大約出現在 2017 年左右，都是側鏈方案——用雙向錨定（Two-way peg）的方式把比特幣置換到側鏈，並在 EVM 兼容的側鏈上使用各種 DeFi 和 dApps。他們有類似 WBTC[9] 的代幣 （RSK 有 RBTC，Liquid 有 L-BTC)，主要面向的是想用 BTC 在以太坊生態上 build 的人。

在 Rootstock 上發行代幣，方法與在以太坊上發行是一樣的，或者可以說 Rootstock 這個側鏈除了挖礦是與比特幣鏈一起，其他的功能都是為適配以太坊生態做的，比如智能合約代碼也是用 Solidity 寫。所以這裏的代幣都是在 RBTC 基礎上發行的，並不直接和 BTC 有聯繫。

由於本文主要關注公鏈，而 Liquid Network 是一個聯盟鏈，這裏不深入討論。

進一步了解 RSK，參考：

• RSK: A Bitcoin sidechain with stateful smart-contracts (RSK paper)[10]

• RSK money[11]

• FAQs[12]

 前面提到的這些項目, 有一些消失了（比如染色幣），有一些打着比特幣的幌子賣的是以太坊的生態。這主要是因為以太坊在擁抱資本之後，DeFi 和 dApps 佔據了絕對的市場優勢，所以不和它玩的 DeFi 項目想要獲得優勢就比較困難。以太坊上的代幣是通過合約來發行和交易的，遵循 ERC-20 等標準。比特幣生態在最近兩年也開始解鎖合約功能，如 BitVM，也有代幣標準 BRC-20 出現。

在比特幣上實現智能合約：RGB

誕生於 2016 年的 RGB（Really Good for Bitcoin）[13] 最初被設計為染色幣的競爭對手。但面對類似的挑戰，它轉向在比特幣上啟用智能合約。儘管它主要關注的是運行智能合約，而非髮型代幣，但由於它們的虛擬機 AluVM 的限制，截至 2024 年，完整的合約功能仍然有限。

RGB 的思路是把能拿到鏈下的數據和智能合約代碼都放在比特幣之外進行，通過 Merkle root 來提供 交易驗證和代幣發行的承諾（commitment），比特幣鏈只做交易承諾的驗證和最終性，證明沒有出現雙花。

RGB 值得一提的地方是同時使用了客戶端驗證和一次性密封條的技術，這樣它並不在 UTXO 上做標記來表示代幣。這兩個概念最早是由 Peter Todd 在 2013 年[14] 提出的，Giacomo Zucco 和 Maxim Orlovsky 在這個基礎上設計了 RGB 協議。

客戶端驗證（Client-side validation） 讓交易使用的數據和代碼都保存在鏈下，不會公開廣播，有些數據可能只會在交易雙方之間私下交換，其他與交易不相關的人可能毫不知情。鏈下狀態的藉助比特幣維護，區塊鏈是作為時間戳發揮作用的，可以證明狀態的先後次序。

而一次性封條（single-use seal）——它也是客戶端驗證最常出現的樣子——是数字版的一次性密封條。它藉助每個 UTXO 只能被花費一次的性質，把鏈下狀態的信息寫到一個 UTXO 中。這樣如果某個時刻這個 UTXO 被花掉了，我們就知道狀態被更新了，更新之後的狀態信息寫到新生成的 UTXO 中。這個鏈下狀態信息可以是 USDT 代幣的所有權，也可以是某個合約中有多少代幣。

比如 Alice 想把一個 USDT 轉給 Bob，這個 USDT 並不是存在比特幣鏈上，它的信息是在鏈下維護的，但是它會和一個由 Alice 控制的 UTXO 有聯繫。它的信息保存於生成這個 UTXO 的那筆交易中 數值為零的 UTXO 的 OP_RETURN 字段中。這樣，只有 Alice 能花掉這個 USDT，而且 Bob 可以通過鏈上的交易追蹤到這個 USDT 在過往交易中曾被保存在哪些 UTXO 中，這些 UTXO 是不是有效的，以及交易是不是合法的。這樣，當 Alice 發起交易，把這個 USDT 的 承諾信息轉移到一個由 Bob 控制的 UTXO 時，Bob 就可以確定他獲得了這個 USDT。

RGB 也可以在閃電網絡上運行，因為它的狀態是鏈下的，只需要把承諾放到鏈上或者閃電網絡上。在 Taproot 升級之後，RGB 可以把承諾嵌入到一個 Taproot 交易中，這可以讓 RGB 以更靈活的方式將承諾 嵌入到比特幣鏈上。

進一步了解 RGB，參考：RGB Blueprint[15] 

只支持代幣不支持智能合約：Taproot 資產

Taproot Asset 是  Lightning Network Daemon (LND)[16] 團隊開發的項目。它的原理和 RGB 類似，但並不支持複雜的智能合約，只支持代幣（參考這裏對 Taproot 詞條[17] 的解釋）。

進一步了解 Client-Side Validation、RGB 和 Taproot，參考：

1. Client-side validation[18]

2. Off-Chain Transactions: The Evolution of Bitcoin Asset Protocols[19]

3. Counterparty vs RGB vs TARO[20]

讓每個聰都與眾不同：Ordinals & Inscriptions

Casey Rodarmor 在 2023 年初發布了 Ordinal Protocol[21]。這個項目最初是從這樣一個想法而來：如何給聰編號，讓每一個聰都有一個獨一無二的序列號從而被排序。這個想法和染色幣是同時期的，只是在去年才被再次提出。而且由於 SegWit 和 Taproot 功能的加入，它的實現變得不那麼難了。Ordinal 讓每一個聰都彼此不同，這就使得 NFT 可以直接在比特幣鏈上發行。

Inscriptions[22] 就是一個這樣的 NFT 項目。NFT 的數據保存在交易的 witness 數據中，而不是之前項目使用的 OP_RETURN 字段，這樣可以存下大小為 4MB 以內的元數據。與以太坊上 NFT 不同，Inscription 是鏈上存儲，包括元數據和圖片。

進一步了解 Ordinals，參考：

1. Ordinals: A common ground for Ethereum and Bitcoin maximalists?[23]

2. The Ultimate Guide to Bitcoin Ordinals and Inscriptions[24]

雙向綁定任一 UTXO 鏈：RGB++ 同構綁定

RGB++[25] 最初是作為 BTC 與 CKB（Nervos Network[26] 的基礎）之間的同構綁定協議（isomorphic binding protocol）出現，而現在它的適用範圍很廣，不是只局限於 CKB 和 BTC 之間，只要是兩個 UTXO 鏈理論上都能用這個協議綁定在一起。

RGB++ 將 RGB 的 Client-Side Validation 和 Single-Use-Seals 思路做了近一步發揮。如前所述，RGB 協議最大的問題就是數據由用戶自己保存在本地。如果用戶不小心把數據弄丟了，是沒有備份，也找不回來的。而且，由於用戶只保存和自己的代幣相關的數據，其他數據想要驗證就比較難。同構綁定層的方案就是不僅僅把代幣綁定到比特幣 UTXO 的 OP_RETURN 字段中，也把相應的比特幣交易信息綁定到 CKB 鏈上的交易里（通過在 CKB Cell[27] 的 Lock Script 里，使用一個特殊的 IB-lock-script 而實現）。當判斷 CKB 鏈上的交易是否合法時，Lock Script 會用 CKB 上 BTC light client 的數據，看對應的 UTXO 有沒有被花費，以及被花掉之後新生成的 UTXO 是不是綁定了目前這筆的代幣交易信息（作為不含簽名的部份信息）。

RGB++ 值得關注的特點：

• 通過雙向綁定解決數據可用性問題：CKB Cell 承諾綁定在 UTXO 的 OP_RETURN 字段；UTXO 信息綁定在 CKB 交易的 Output Cell。

• 與閃電網絡和 Fiber Network（基於 CKB 的閃電網絡）兼容

• 支持多資產

• 可以和任何 UTXO 鏈綁定

進一步了解 RGB++，參考：

1. RGB++ Protocol Light Paper[28]

2. The Ultimate Guide to RGB, RGB++, and Client-Side Validation[29] 

為了更清楚地了解各項目的優勢和局限，我們將以上項目放入下面的表格中比較。其中需要重點關注的指標有：

• 數據可用性（Data availability）：同構鏈（isomorphic-chain）和側鏈相差無幾，而鏈下的數據可用性要弱於其他方案。此項從強到弱的排序為：鏈上 ≥ 同構鏈 ≥ 側鏈 > 鏈下；

• 資產載體（Asset carrier）：直接同 BTC 關聯的代幣方案要優於非直接關聯的方案；

• 同質性（Fungibility）：這裏指的是項目的原生代幣是否可相互置換，並不是說項目不支持發行 NFT，後者可以通過增加額外協議來實現；

• 表現力（Expressiveness）：指處理複雜智能合約的能力。

文中提到的部分鏈接：[1]https://docs.google.com/document/d/1AnkP_cVZTCMLIzw4DvsW6M8Q2JC0lIzrTLuoWu2z1BE/edit?pli=1&tab=t.0#heading=h.pr8n14cpqri5 

[2] https://www.counterparty.io/

[3] https://www.omnilayer.org/

[4] https://x.com/counterpartyxcp 

[5] https://arxiv.org/pdf/1702.01024 

[6] https://juejin.cn/post/6844903769327534088 

[7] https://rootstock.io/ 

[8] https://liquid.net/ 

[9] https://www.wbtc.network/ 

[10] https://eprint.iacr.org/2022/684.pdf 

[11] https://wiki.moneyonchain.com/getting-started/what-do-i-need-to-know-first

[12] https://dev.rootstock.io/resources/faqs/ 

[13] https://rgb.tech/ 

[14] https://petertodd.org/2013/disentangling-crypto-coin-mining 

[15] https://rgb-org.github.io/ 

[16] https://docs.lightning.engineering/ 

[17] https://bitcoinops.org/en/topics/client-side-validation/ 

[18] https://bitcoinops.org/en/topics/client-side-validation/ 

[19] https://mirror.xyz/0x5CCF44ACd0D19a97ad5aF0da492AC0388469DfE9/h7XChxETK-cBfGdc0sTq_cCuWeo13-sp1j-g0ZYoYdc 

[20] https://mandelduck.medium.com/counterparty-vs-rgb-vs-taro-8cd707d544f7 

[21] https://docs.ordinals.com/ 

[22] https://ordinals.com/inscriptions 

[23] https://blog.kraken.com/crypto-education/ordinals-a-common-ground-for-ethereum-and-bitcoin-maximalists 

[24] https://www.nervos.org/knowledge-base/guide_to_inscriptions 

[25] https://www.rgbppfans.com/ 

[26] https://www.nervos.org/ 

[27] https://docs.nervos.org/docs/tech-explanation/cell 

[28] https://github.com/utxostack/RGBPlusPlus-design/blob/main/docs/light-paper-en.md 

[29] https://www.nervos.org/knowledge-base/ultimate_guide_to_rgb_rgbpp_and_client_side_validation