來源：位元組元CKB
我知道，一談到這個問題，比特幣純粹主義者可能覺得：比特幣就安靜地做數位黃金不好嗎？為什麼一定要有代幣呢？為什麼非得有USDT? 不過, 如果你特別在意資產安全的話，就不得不想，以太坊萬一倒了呢？ DeFi 誰能接住? 而且，代幣方案與比特幣協議是兼容的，並不會破壞原本的功能，如果不喜歡，可以不下載代幣客戶端，也不會受到很大的影響。
在比特幣上發行代幣：為何不可？
在比特幣上發行代幣，用來將現實世界中的資產交易轉移到鏈上，這個想法在2010 年左右就在比特幣社群中出現了。社群最初的討論是設想把現實世界資產──例如：房產、股票、法幣等資產，都搬到比特幣上去中心化的交易。不過由於法律因素，房產和股票這類資產的搬運沒那麼容易。就算你將自己的房子的數位資產代幣支付給了另一個人，政府可能不會承認，或自動更換現實世界的房產證，還可能需要繳各種稅。況且在監管之下還不能隨意在鏈上交易。
因此，更吸引人的方法是發行同法幣掛鉤的代幣，即穩定幣。穩定幣與NFT 不同，它們仍然是同質化的（fungible）代幣，只不過與原本的比特幣做了區分。當作為代幣出現時，它們的價值由所代表的現實世界資產的價格決定，不再有原本的數位貨幣價格（如果數位貨幣的價格漲到比資產價格高太多，捨棄掉資產也不是不行）。這就是為什麼通常比特幣上的代幣都會以聰（Satoshi）為單位。
將數位貨幣作為資產的代幣，需要解決兩個主要問題：
-
如何用比特幣表示現實世界中的資產；
-
如何在比特幣十分有限的腳本語言中設定複雜的交易規則和合約。
以下的內容著重於以上兩點，對目前現有的幾大比特幣資產發行方案做了概括，並從數據可用性、 資產載體、表現力、可擴展性等幾個方面做了比較。
比特幣上的第一個代幣：染色幣
最早在比特幣上設計代幣協議的人已不可考，想法可能產生於比特幣論壇或社群裡的討論。染色幣（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，可參考：
-
An analysis of Bitcoin OP RETURN metadata[5]
-
手動建構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，參考：
-
Client-side validation[18]
-
Off-Chain Transactions: The Evolution of Bitcoin Asset Protocols[19]
-
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，參考：
-
Ordinals: A common ground for Ethereum and Bitcoin maximalists?[23]
-
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++，參考：
-
RGB++ Protocol Light Paper[28]
-
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
