原文作者：Ben（X: @wooooer）
前言
基於BTC 去做資產發行，一直都是熱門話題。從最早在2011 年出現的Colored Coins 到近來大火的Ordinal 協議，BTC 社群其實總能湧現出新的玩家和共識，但能留下的寥寥無幾。但隨著野心勃勃的Lightling Labs 宣布自己在Taproot Assets 至上構建Stable Coin 的計劃，Tether 也宣布將選擇RGB 進行USDT 在比特幣一層的鑄造。
這代表著曾經名噪一時的OmniLayer(Mastercoin) 不再是BTC 生態最大的玩家，客戶端驗證(CSV) 資產協議由開始進入大家的視野，與傳統的BTC 資產協議的不同在於，它們還帶上了為BTC 擴容的屬性。但面對BTC 生態如此繁多的資產協議，人們不禁要問，他們的差異在哪裡，面對如此眾多的資產協議，我們該如何去選擇和並且從中找到自己的機會。本文希望帶著大家透過回顧BTC 史上出現過的資產協議，也探索BTC 資產協議發展的未來。
染色幣：Colored Coins
Colored Coins 的想法最早由Yoni Assia，現eToro 的CEO 在2012 年3 月27 日的編寫的一篇名為bitcoin 2.X (aka Colored bitcoin)文章提出。文章認為比特幣作為底層技術是完美的，就像HTTP 是網路的基礎一樣。因此在復用BTC 的基礎上去設計了Colored Coins 這個代幣協議。
Yoni Assia 希望透過這樣的形式創造BTC 2.0 的經濟-任何社區都可以透過這種方式來創造多種貨幣。這種將比特幣作為底層技術用於清算交易和避免雙重支付的方式在當時無疑是非常大膽的想法。
Colored Coins 作為基於比特幣發行資產的協議，其做法是將一定數量的比特幣「上色」來表示這些資產。這些標記的比特幣在功能上仍然是比特幣，但它們同時也代表了另一個資產或價值。但是這樣的想法該如何在比特幣上實現呢？
2014 年7 月3 日，ChromaWay 開發了增強型基於填充訂單的著色協議（EPOBC），該協議簡化了開發人員製造彩色硬幣的過程，這便是最早採用Bitcoin Script 的OP_RETURN 功能的協議。
最終實現的效果如下圖所示：
這樣的實現非常簡潔，但也帶來了許多問題：
1. 同質化代幣與最小綁定值
在創世交易中為某個染色幣綁定了1000 sat，則該染色幣的最小分裂單位為1 sat。這意味著該資產或代幣可以被切分或分配為最多1000 份（但是僅為理論上的，為了防止粉塵攻擊，比如當年的sat 都定在546 SAT，後面到ordinal 則是更高）。
2. 驗證問題
為了確定染色幣的真實性和其所有權，需要從該資產的創世交易追踪驗證到當前的UTXO。因此需要專門開發錢包與配套的全節點，甚至是瀏覽器。
3. 潛在的礦工審查風險
因為ColoredTransaction 的特徵較為明顯，即在output 中寫入了metadata 訊息，這給礦工審查帶來了可能性。
染色幣實際上是一種資產追蹤系統，它使用比特幣的驗證規則來追蹤資產轉移。不過，為了證明任何特定的產出（txout）代表某一特定資產，需要提供一整條從資產起源到現在的轉移鏈。這意味著驗證某筆交易的合法性可能需要很長的證明鏈。為了解決這個問題當初也是有人提出了OP_CHECKCOLORVERIFY來幫助在btc 上直接對Colored Coins 的交易正確性進行驗證，但是該提案也並沒有通過。
加密產業的第一個ICO：Mastercoin
Mastercoin 的最初概念由JR Willett 提出。在2012 年，他發布了一個名為"The Second Bitcoin Whitepaper"的白皮書，描述了在比特幣的現有區塊鏈上創建新的資產或代幣的概念，這後來被稱為“MasterCoin”。而再後來則改名為Omni Layer。
Mastercoin 項目在2013 年進行了初步的代幣銷售（今天我們稱之為ICO 或初始代幣銷售），並成功籌集了數百萬美元，這被認為是歷史上第一個ICO。 Mastercoin 最著名的應用是Tether (USDT)，作為最知名的法幣穩定幣，最初是在Omni Layer 上發行的。
其實Mastercoin 的想法是要比Colored Coins 出現得要早的，之所以在這裡放在第二個去講，是因為相對於Colored Coins 來說，MasterCoin 是一個相對來說更重的方案。 MasterCoin 建立了一個完整的節點層，從而提供了更複雜的功能（如智慧合約），Colored Coins 則更加簡單和直接，主要專注於「染色」或標記比特幣UTXO，以代表其他資產。
與Colored Coins 最大的不同是，在鏈上Mastercoin 只會去發佈各種類型的交易行為，而不會記錄相關的資產資訊。在Mastercoin 的節點中，會透過掃描比特幣區塊來維護一個狀態模型的資料庫在鏈下的節點中。
相對於Colored Coins 來說，其能完成的邏輯更加複雜。並且由於不在鏈上記錄狀態和進行驗證，因此其交易之間可以不要求連續（持續染色）。
但為了實現Mastercoin 的複雜邏輯，使用者需要去相信節點中的鏈下資料庫中的狀態，或是自己允許Omni Layer 節點來驗證。
總結：
Mastercoin 與Colored Coins 最大的差異在於，其沒有選擇在鏈上維護協議所需的所有數據，而是通過寄生了BTC 的共識系統，來實現了自己交易發布和排序，然後在鏈下數據庫中維護狀態。
根據OmniBolt 的相關提供的消息：Omni Layer 正在向泰達提出新UBA(UTXO Based Asset) 資產協議，會利用Taproot 升級，把資產信息編入tapleaf，從而做到條件支付等功能。同時OmniBolt 正在將Stark 引入OmniLayer 的閃電網路設施。
客戶端驗證(Client Side Validation) 思想
如果我們要去了解客戶端驗證的概念，那麼我們就要把時間拉回Colored Coins 和Mastercoin 出現的第二年，那便是2013 年。 Peter Todd 在這一年發布文章：Disentangling Crypto-Coin Mining: Timestamping, Proof-of-Publication, and Validation。雖然看文章名字上去跟客戶端驗證沒有關係，但是仔細閱讀便可以發現這便是最早關於客戶端驗證的啟蒙思想。
Peter Todd 是比特幣和密碼學的早期研究者，一直在尋找一種讓比特幣工作方式更有效率的方法。他基於時間戳記的概念開發了一個更複雜的客戶端驗證概念。此外，他還提出了「single use seal」的概念，這將在後面有所提及。
現在讓我們順著Peter Todd 的思想，先要去了解BTC 實際上解決了什麼樣的問題。在Peter todd 看起來BTC 總共解決了三個問題：
證明的發布（Proof-of-publication）
證明的發布本質是解決雙花問題，例如Alice 有一些比特幣想要轉給Bob，雖然通過簽署了一筆交易轉賬給了Bob，所以Bob 在物理上並不一定知道有這麼一筆轉賬的存在。所以我們需要一個公共的地方進行交易的發布，並且每個人可以從中對交易進行查詢。
交易定序（Order consensus）
在電腦系統，並不存在我們平常感受的物理時間。在分散式系統這個時間通常是分散式時鐘lamport，這個時鐘並不是為我們的實體時間提供度量，而是為我們的交易進行定序。
交易驗證（Validation）（可選項）
BTC 上的驗證便是關於簽名和BTC 轉帳金額的驗證。但在這裡，Peter Todd 認為這個驗證對於在BTC 之上建立一個代幣系統是非必要的，只是一個優化選項。
大家看到這裡其實已經想到之前提到的Ominilayer，OminiLayer 本身並沒有把狀態的計算和驗證交給BTC，但是它同樣復用了BTC 安全性。 Colored Coins 則是把狀態的追蹤交給了BTC。這兩者的存在已經證明了驗證並不一定要發生在鏈上。
那麼客戶端驗證如何有效驗證交易？
首先來看看哪些東西是需要被驗證的：
1. 狀態（交易邏輯驗證）
2. 輸入TxIn 是否有效（防止雙花）
很容易可以發現在btc 上發布的資產，每次交易都需要校驗整個相關的交易的歷史，才能確保引用的輸入是沒有被消費並且狀態是正確的。這非常不合理，那又該如何改進呢？
Peter Todd 認為，我們可以透過改變驗證的焦點來簡化這個過程。而不是確認一個輸出沒有被雙重支出，這個方法重點放在了確認交易的輸入已被發布，並且沒有與其他輸入衝突。通過對每個區塊中的輸入進行排序和使用Merkle 樹，可以更有效率地進行這種驗證，因為每次驗證都只需要一小部分的數據，而不是該輸入的整個鏈上的歷史。
Peter Todd 提出的commitment tree 架構如下：
CTxIn -> CTxOut ->
但是我們該如何在鏈上儲存這樣一個commitment tree 呢？所以在這裡我們就可以引出一次性密封（single use seal）的概念了。
一次性密封Single Use Seal
Single use seal 是理解客戶端驗證的核心概念之一，這與實際世界中用於保護貨運集裝箱的物理、單次使用的密封相類似。 Single use seal 是一個獨特的對象，可以確切地在一個訊息上關閉一次。簡而言之，一次性密封是一個抽象的機制，用來防止雙花。
對SealProtocol 來說，有三個要素，兩個動作。
基礎要素：
l： seal,即是密封
m： message,訊息
w：witness,見證人
基本操作：有兩個基礎操作：
Close(l,m) → w：在訊息m 上關閉密封l，產生一個證人w。
Verify(l, w,m) → bool：驗證密封l 是否在訊息m 上關閉。
single use seal 的實現在安全性方面是無法被攻擊者找到兩個不同的訊息m 1 和m 2 ，並且使得Verify 函數對同一個密封回傳true 的。
首先一次性密封（Single-Use Seal）是一個概念，它確保某種資產或資料只被使用或鎖定一次。在比特幣的環境中，這通常意味著一個UTXO（未使用的交易輸出）只能被消費一次。因此，比特幣交易的輸出可以被視為一次性密封，而當這個輸出被用作另一個交易的輸入時，該密封就被「打破」或「使用」了。
對於在BTC 上的CSV 資產來說，比特幣自己就充當了單次密封的「見證人」（witness）。這是因為，為了驗證一個比特幣交易，節點必須檢查交易的每個輸入是否引用了一個有效且尚未花費的UTXO。如果交易試圖雙重花費一個已經被使用的UTXO，那麼比特幣的共識規則和全網的誠實節點會拒絕該交易。
能不能再簡單一點？
single use seal 就是把任何一個區塊鏈當作一個資料庫，我們將某個訊息的承諾透過某種方式存入這個資料庫裡，並且為它維護一個已消費或待消費的狀態。
是的，就是這麼簡單。
綜上所述，客戶端驗證的資產有以下特點：
鏈下資料儲存：客戶端驗證的資產其交易歷史、所有權和其他相關資料大多數都儲存在鏈下。這大大減少了鏈上的資料儲存需求，並有助於提高隱私。
承諾機制：雖然資產資料儲存在鏈外，但對這些資料的變更或轉移會透過承諾（commitments）被記錄到鏈上。這些承諾使得鏈上的交易能夠引用鏈外的狀態，從而確保鏈外資料的完整性和不可篡改性。
鏈上見證者（不一定是BTC）：雖然大部分數據和驗證都在鏈外，但透過嵌入到鏈上的承諾，客戶端驗證的資產仍然可以利用基礎鏈的安全性（證明的發布，交易的排序）。
驗證工作客戶端完成：大部分驗證工作都在使用者設備上完成。這意味著不需要全網節點都參與驗證每筆交易，只有涉及的參與者需要驗證交易的有效性。
對於使用客戶端驗證資產的人來說，還會有一點要注意：
在鏈下交易和驗證客戶端驗證的資產的時候，不僅要出示持有資產的私鑰，也要同時出示對應資產的完整的merkel 路徑的證明。
客戶端驗證（CSV）的先行者：RGB
RGB 的概念在2015 年後由社群中的知名人物Giacomo Zucco 提出，由於以太坊的興起和ICO 開始氾濫，以及在ICO 之前，許多人都嘗試在比特幣之外做一些事情，如Mastercoin 和Colored Coins 項目。
Giacomo Zucco 對此表示失望。他認為這些項目都不如比特幣，他認為之前在比特幣上實現代幣的方式都不恰當。在這個過程中，他遇到了Peter Todd，對Peter todd 在客戶端驗證(Client-Side-Validation) 的想法開始著迷。便開始提出了RGB的想法。
RGB 同先前的資產協議的最大的差異除了先前提到的客戶端驗證資產的那些特點，還增加了執行的VM 來進行圖靈完備的合約執行引擎。此外為了確保合約資料的安全性，也設計了Schema 和Interface。 Schema 和以太坊的比較相似，聲明合約的內容和功能，而Interface 則負責具體功能的實現，與程式語言中的interface 一樣。
這些合約的schema 負責在vm 執行的時候限制沒有超出預期的行為，例如RGB 20 和RGB 21 ，分別負責同質化代幣和非同質化代幣在交易上的一些限制。
RGB 的承諾機制PerdersenHash
從承諾機制來看，RGB 採用了Perdersen 哈希。它的優點在於可以承諾某個值而不用披露它。將Pedersen 雜湊用於建立Merkle 樹意味著你可以建立一個隱私保護的Merkle 樹，它可以隱藏其中的值。這種結構可用於某些特定的隱私保護協議中，例如一些匿名加密貨幣項目。但也許並不適用於CSV 資產，在後面和Taproot Assets 的對比裡會提到。
RGB 的虛擬機器設計Simplicity → AluVM
RGB 的目標不僅在於實現一個用戶端驗證的資產協議，更在於擴展到圖靈完備的虛擬機器執行和合約程式進行擴充。在早期的RGB 的設計中，它聲稱自己是用一個叫Simplicity 的編程語言，該語言的特點是在執行表達式的時候會產生一個執行證明，並且能對其編寫的合同更容易去做形式化驗證（避免產生bug）。但是該語言的開發並不理想，最後陷入了困境。這最後直接導致了當年RGB 整個協議難產。最後RGB 開始使用一個稱為AluVM，由Maxim 開發的VM，目標是避免任何未定義的行為，這和最初的Simplicity 類似。新的AluVM 據稱在未來會使用一門叫Contractum 的程式語言來替換當下使用的Rust。
RGB layer 2 擴容方向：閃電網絡還是側鏈？
客戶端驗證資產沒有辦法在鏈下保證安全的情況下連續交易的。因為客戶端驗證的資產還是依賴L1 去進行交易發布和定序，所以在沒有L2 擴容方案的時候，其交易速度還是會受到其L1 見證者的出塊速度限制。這代表如果直接在比特幣上進行RGB 的交易，在嚴格的安全要求下，兩筆相關的交易的時間需要最長間隔十分鐘(BTC 的出塊時間)。毫無疑問，在大部分的時候這樣的交易速度是難以接受的。
RGB 與閃電網絡
閃電網絡的原則簡單來說，就是交易的雙方之間會在鏈下簽一堆合同(承諾交易)，用於保證交易雙方中任何一方在違背合同的情況下，被侵害的一方能夠把合同(承諾交易) 遞交到BTC 結算，取回自己的資金並懲罰對方。也就是說閃電網絡是透過協議和博弈的設計，保證在鏈下交易的安全性。
RGB 可以透過設計適用於RGB 自己的支付通道合約細則來建造自己的閃電網絡設施，但閃電網絡的複雜度極高，建造這套設施並不是容易的事。但相對於Lightnling labs 已經在這個領域的多年耕耘，並且LND 在市場上有著超過90% 的佔有率。
RGB 的側鏈Prime
LNP-BP作為當下RGB 協定的維護者，Maxim 在2023 年6 月發布了一篇提案叫**Prime**的客戶端驗證資產擴容方案，並在其中批評了現有的側鍊和閃電網絡擴容方案在開發方面太複雜。Maxim表示他認為除了Prime 以外的擴展方式還有NUCLEUS 多節點閃電通道和Ark/Enigma 通道工廠, 這兩個方案都需要開發兩年以上。但Prime 只需要一年便可以完成。
Prime 並非傳統意義上的區塊鏈設計，而是為客戶端驗證設計的模塊化證明發布層，其由四個部分組成:
時間戳服務：最快10 秒最終確定一個交易序列。
證明：通過PMT 形式儲存與區塊頭一同生產與發布。
一次性密封：抽象的單次密封協議，保證防雙花即可。在比特幣上實現，則是可以綁定到UTXO，與當下RGB 設計類似。
智能合約協定：分片合約-RGB (可替換)
從中其實可以看到，為了解決RGB 交易確認時間的問題，Prime 採用了一個時間戳服務來快速將鏈下的交易確認，並且將交易和ID 裝入區塊中。而且同時可以把prime 上的交易證明進一步透過PMT 合併後再以類似checkpoint 的方式錨定上BTC。
基於Taproot 的CSV 資產協議：Taproot Assets
Taproot Assets 是基於Taproot 的CSV 資產協議，用於在比特幣區塊鏈上發行客戶端驗證的資產，這些資產可以透過閃電網路進行即時、大容量、低費用的交易。 Taproot Assets 的核心是利用比特幣網絡的安全性和穩定性以及閃電網絡的速度、可擴展性和低費用。該協議由Lightnling labs 的CTO roasbeef 設計並開發，roasbeef 可能是這個Odaily 上唯一親自主導過比特幣客戶端（BTCD）和閃電網絡客戶端（LND）的比特幣研發，對BTC 的理解極深。
Taproot 交易只攜帶了資產腳本的根哈希，使得外部觀察者難以識別是否涉及Taproot Assets，因為哈希本身是通用的，能代表任意資料。隨著Taproot 升級，比特幣獲得了智慧合約（TapScript）的能力。在此基礎上，Taproot Assets 的資產編碼相當於創建了一個與ERC 20 或ERC 721 相似的代幣定義。這樣，比特幣不僅擁有了資產定義的功能，還具備了智慧合約的編寫能力，從而為比特幣打下了代幣智慧合約基礎架構的雛形。
Taproot Assets 編碼結構如下：
圖片來自Lightning Labs CTO roasbeef
同樣作為CSV 資產協議，Taproot Assets 相對於RGB 的設計更加簡潔。並且最大利用了當下BTC 生態的進展，例如Taproot 升級，PSBT 等。 Taproot Assets 在應用程式擴充性上同RGB 最大的差異在於執行VM，Taproot Assets 使用的是和BTC 原生預設相同的TaprootScriptVM。近年來許多針對BTC 的基礎設施研究都是基於TapScript 進行的，但受限於BTC 的升級緩慢在短時間內得不到應用，可預見Taproot Assets 未來會是這些新鮮想法的試驗田。
Taproot Assets 和RGB 的差別在哪裡？
1. 交易的校驗與輕節點友善性
Taproot Assets 由於sum tree 的實現，驗證效率和安全性高（僅透過持有證明便可以進行驗證狀態和進行交易，不需要遍歷輸入所有的交易歷史）。 RGB 使用的pedersen 承諾導致其無法有效去驗證輸入的有效性，導致RGB 需要回溯輸入的交易歷史，交易衍生到後期將是一個非常沉重的負擔。 Merkel sum 的設計，也讓Taproot Assets 輕鬆實現了輕節點驗證，這相對於以往在BTC 之上的資產協議都不存在的。
2. 執行VM
Taproot Assets 是順應Taproot 升級而生，其使用的TaprootScriptVM 是比特幣在Taproot 升級後自帶的腳本執行引擎，並且使用的vPSBT 是BTC 的PSBT 的翻版，這代表一旦Taproot Assets 的閃電通道機制開發完成，可以立刻重複使用所有目前LND 的基礎設施，還有以往Lightning labs 的產品（LND 在閃電網絡目前的佔有率在90% 以上）。而最近火熱的BitVM 提案都是基於TaprootScript 的，理論上所有的這些改進最後都可以助力Taproot Assets。
但對於RGB 而言它的VM 還有驗證規則(SCHEMA) 都是自成體系的，從某種程度上是一個相對封閉的小生態。基於RGB 的建構只能在自己的生態裡運轉，和比特幣生態的關係都不如大家想像那麼緊密。以Taproot 升級的後續舉例，RGB 和Taproot 升級唯一的關係就是把鏈上承諾資料編碼到Witness 的TapLeaf 中。
3. 智能合約
當下RGB 的實踐設計裡，合約和VM 是一個被濃墨重彩的部分。但在Taproot Assets 中，暫時沒有看到智慧合約的身影。不過當下RGB 在當下Global State 的修改如何跟各個獨立合約分片(UTXO) 進行同步還沒解釋。而Pedersen 承諾只能對資產總數進行保證，對於別的狀態如何保證篡改被識別，目前看起來也沒有更多解釋。而對於Taproot Assets 來講，雖然設計簡潔，但目前對於狀態的儲存也僅有資產餘額，並沒有更多狀態，暫無法談智慧合約。不過據Lightning Labs 透露，明年Taproot Assets 將會在智慧合約設計上發力。
4. 同步中心
從先前提到的在客戶端驗證的資產的基本原則中可以了解到，持有Proof 和持有私鑰同樣重要，但是Proof 一直在用戶客戶端則可能會是容易丟失的，那又該怎麼辦呢？在Taproot Assets 中，我們可以透過universe 來避免這樣的問題。 Universe 是一個公開可審計的（MS-SMT），涵蓋一個或多個資產。與普通的Taproot 資產樹不同，Universe 不用來託管Taproot 資產。相反，Universe 承諾了一個或多個資產歷史的子集。
在RGB 之中負責這個部分的則是Storm，會把鏈下的證明數據通過p2p 的方式進行同步存儲，但是由於RGB 的開發團隊的歷史原因，這些團隊的證明格式目前都各不相容。 RGB 生態團隊DIBA 目前表示會開發carbonado來解決這個問題，不過尚不清楚進展。
5. 工程實現
Taproot Assets 所使用的所有lib 都是久經考驗的，因為Lightning labs 有自己的比特幣客戶端（BTCD），閃電網絡客戶端（LND），以及大量wallet lib 實踐。反觀RGB 實踐所使用的lib 大部分來自自己定義，從工業標準看RGB 的實踐尚處於實驗室階段。
淺談BTC 擴容的未來
討論到這裡，大家也就發現了客戶端驗證的資產協議已經脫離了協議的範疇，開始邁向了運算擴容方向。
很多人都說未來比特幣將作為數字黃金去存在，而由其他鏈去打造應用生態。但對此，我有不同的看法。就像在btc 論壇上很多討論都是關於各種山寨幣(alt-coin) 和它們短暫的生命。這些山寨幣的快速的消亡，讓曾經圍繞著它們的資本和努力都化為泡沫。我們已經有了像比特幣這樣強大的共識基礎，沒有必要為了應用協議而建立新的L1。我們要做的就是如何將比特幣這個最強的基礎設施用好，從而建立一個更長期的去中心化的世界。
更少的鏈上計算，更多的鏈上驗證
從應用設計來看，比特幣很早就選擇了不是以鏈上計算為核心目標，而是以驗證為主的設計哲學（Turing completeness and state for smart contract）。區塊鏈本質就是一個複製狀態機，如果一個鏈的共識放在了鏈上計算，那麼其實我們很難說最後讓網絡裡所有的節點都重複這些計算是合理可擴展的做法。若是以驗證為主，那麼透過驗證鏈下交易的有效性可能是最適合BTC 擴容的方案。
驗證發生在哪裡？這很重要
對於在比特幣之上的協議開發者而言，如何使用比特幣做關鍵的驗證，甚至說是把驗證放在鏈下，如何設計安全方案，其實都是協議設計者自己的事情，不需要也不應該和鏈本身有所關聯。那麼如何實現驗證，就會衍生出BTC 不同的擴容方案。
那麼基於驗證實現的視角，我們有三個擴容的方向：
1. 驗證發生在鏈上（OP-ZKP）
如果在TaprootScriptVM 直接去實現OP-ZKP，相當於讓BTC 本身加入ZKP 驗證的能力，從而再配合一些Covenant 設計結算協議，就可以打造出能夠繼承BTC 的安全性的Zk-Rollup 擴容方案。但不同於在以太坊上部署驗證合約，BTC 的升級本身就緩慢，再加入這樣非通用並且可能需要後續升級的op-code 注定是艱難的。
2. 驗證發生在半鏈上（BitVM）
BitVM 的設計注定了它不會是為了普通的交易邏輯服務，Robin linus 也表明了BitVM 的未來是做各個SideChain 的自由跨鏈市場。之所以說BitVM 的方案是發生在半鏈上，是因為大部分時候這些驗證計算都不會在鏈上發生，而是說發生在鏈下。但是圍繞BTC 的Taproot 去設計的重要原因是為了在必要的時刻也能夠利用TapScriptVM 進行計算驗證，這也是為了從理論上繼承BTC 的安全性。在這個過程中也同時產生了一個驗證信任鏈條，例如n 個驗證人裡面只要有一個是誠實的就行，也就是Optimistic Rollups。
BitVM 在鏈上的開銷龐大，但是能夠使用ZK 詐騙證明進行效率提升嗎？答案是否定的，因為ZK 詐騙證明的實現是建立在鏈上可以進行ZKP 的驗證的基礎上，這就回到了OP-ZKP 方案的困窘。
3. 驗證發生在鏈下（Client-Side-Validation, Lightning Network）
驗證完全發生在鏈下，那就是之前的討論過這些CSV 的資產協議還有閃電網絡了。在之前討論裡可以看到在CSV 的設計裡，我們沒有辦法完全杜絕共謀篡改的發生，我們能做的就是利用密碼學和協議設計讓這種惡意共謀傷害的範圍在可控範圍內，使得這種行為無利可圖。
在鏈下驗證的優點和缺點同樣是非常明顯，優點在於對鏈上的資源佔用極少，擴容的潛力巨大。缺點是幾乎不可能去完全復用到BTC 的安全性，這對能進行的鏈下交易類型和交易方式有了極大的限制。而鏈下驗證也同時代表資料都在鏈下，由使用者自行保管，這對軟件執行環境安全性還有軟件的穩定性提出了更高的要求。
擴容演進的趨勢
當下在以太坊流行的Layer 2 從範式上來講，是通過Layer 1 去驗證了Layer 2 的計算有效性，也就是把狀態計算下推到了Layer 2 ，但是驗證還是保留在Layer 1 之上。在未來我們可以把驗證計算同樣下推到鏈下，進一步釋放當下區塊鏈基礎設施的效能。
References
Assia, Y. (n.d.). Colored Bitcoin. Retrieved from https://yoniassia.com/coloredbitcoin/
CryptoAdventure. (n.d.). A Brief History of Colored Coins: What Made Them Special. Retrieved from https://cryptoadventure.com/a-brief-history-of-colored-coins-what-made-them-special/
Bitcoil. (n.d.). BitcoinX.pdf. Retrieved from https://bitcoil.co.il/BitcoinX.pdf
Mastering Bitcoin. (n.d.). Chapter 9. Retrieved from https://www.8btc.com/books/261/master_bitcoin/_book/9/9.html
Livera, S. (n.d.). Episode 501. Retrieved from https://stephanlivera.com/episode/501/
Gradually Then Suddenly. (n.d.). Pay Me in Bitcoin Theory. Retrieved from https://graduallythensuddenly.xyz/pay-me-in-bitcoin-theory/
Coinmonks. (n.d.). ZK-Rollups on Bitcoin. Retrieved from https://medium.com/coinmonks/zk-rollups-on-bitcoin-ce35869b940d
Burtey, N. (n.d.). Twitter Post. Retrieved from https://twitter.com/nicolasburtey/status/1703705962664669225
Burtey, N. (n.d.). Twitter Post. Retrieved from https://x.com/nicolasburtey/status/1703710347889127585?s=20
Bosworth, A. (n.d.). Twitter Post. Retrieved from https://twitter.com/alexbosworth/status/1703423563288473769
BitcoinShooter. (n.d.). Video Title (in English if available). Retrieved from https://www.youtube.com/watch?v=9fz34ef5GSk&ab_channel=BitcoinShooter
Bitcoin Magazine. (n.d.). RGB: Magic Client Contracts on Bitcoin. Retrieved from https://bitcoinmagazine.com/technical/rgb-magic-client-contracts-on-bitcoin
Bitcrab.eth. (n.d.). Article Title (in English if available). Retrieved from https://mirror.xyz/bitcrab.eth/T3gIfKepjfs3YUiRWTgCTqS6gc8LaC5z7lYKQY-HLEE
Todd, P. ( 2016). OpenTimestamps Announcement. Retrieved from https://petertodd.org/2016/opentimestamps-announcement
Bitcoin Optech. (n.d.). Client-Side Validation. Retrieved from https://bitcoinops.org/en/topics/client-side-validation/
Todd, P. ( 2016). Commitments and Single-Use Seals. Retrieved from https://petertodd.org/2016/commitments-and-single-use-seals
Todd, P. ( 2014). Setting the Record: Proof of Publication. Retrieved from https://petertodd.org/2014/setting-the-record-proof-of-publication
Bitcoin Magazine. (n.d.). The Long Road to SegWit: How Bitcoin's Biggest Protocol Upgrade Became Reality. Retrieved from https://bitcoinmagazine.com/technical/the-long-road-to-segwit-how-bitcoins-biggest-protocol-upgrade-became-reality
Linux Foundation. ( 2015). Mailing List Post Title (if applicable). Retrieved from https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
Zucco, G. (n.d.). Chapter 2: About Eidoo. Retrieved from https://medium.com/@giacomozucco83/chapter-2-about-eidoo-ab0f9d3bdb59
Trust Machines. (n.d.). What is the RGB Protocol on Bitcoin?. Retrieved from https://trustmachines.co/learn/what-is-the-rgb-protocol-on-bitcoin/
Linux Foundation. ( 2023). Mailing List Post Title (if applicable). Retrieved from https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-May/021719.html
Salvatoshi. (n.d.). Twitter Profile. Retrieved from https://twitter.com/salvatoshi
Merkle. (n.d.). Website or Article Title (if applicable). Retrieved from https://merkle.fun/
Muneeb. (n.d.). Twitter Post. Retrieved from https://twitter.com/muneeb/status/1712853971948229042
Nakamoto Institute. (n.d.). Appcoins are Snake Oil. Retrieved from https://nakamotoinstitute.org/mempool/appcoins-are-snake-oil/
Todd, P. ( 2013). Disentangling Crypto Coin Mining. Retrieved from https://petertodd.org/2013/disentangling-crypto-coin-mining
