本文希望通過回顧BTC歷史上出現過的資產協定，探尋BTC資產協定發展的未來。

前言

基於 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希望通過這樣的形式創建BTC2.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 的最初概念由 J.R. 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總共解決了三個問題：

1. 證明的發佈（Proof-of-publication）

   證明的發佈本質是解決雙花問題，比如Alice有一些位元幣想要轉給Bob，雖然通過簽署了一筆交易轉賬給了Bob，所以Bob在物理上並不一定知道有這麼一筆轉賬的存在。所以我們需要一個公共的地方進行交易的發佈，並且每個人可以從中對交易進行查詢。

2. 交易定序（Order consensus）

   在電腦系統，並不存在我們平常感受的物理時間。在分佈式系統這個時間通常是分佈式時鐘lamport，這個時鐘並不是為我們的物理時間提供度量，而是為我們的交易進行定序。

3. 交易驗證（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 -> <merkle path> -> CTransaction -> <merkle path> -> CT= xIn

但是我們該如何在鏈上存儲這樣一個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的實現在安全性方面是無法被攻擊者找到兩個不同的消息m1和m2，並使得Verify函數對同一個密封返回true的。

首先一次性密封（Single-Use Seal）是一個概念，它確保某種資產或數據只被使用或鎖定一次。在位元幣的環境中，這通常意味著一個UTXO（未使用的交易輸出）只能被消費一次。因此，位元幣交易的輸出可以被看作是一次性密封，而當這個輸出被用作另一個交易的輸入時，該密封就被“打破”或“使用”了。

對於在BTC上的CSV資產來說，位元幣自己就充當了單次密封的“見證人”（witness）。這是因為，為了驗證一個位元幣交易，節點必須檢查交易的每個輸入是否引用了一個有效且尚未花費的UTXO。如果一個交易試圖雙重花費一個已經被使用的UTXO，那麼位元幣的共識規則和全網的誠實節點會拒絕該交易。

能不能再簡單一點？

single use seal 就是把任意一個區塊鏈當作一個數據庫，我們將某個消息的承諾通過某種方式存入這個資料庫裡，並且為它維護一個已消費或者待消費的狀態。

是的，就是這麼簡單。

綜上所述，客戶端驗證的資產有以下特點：

1. 鏈下數據存儲：客戶端驗證的資產其交易歷史、所有權和其他相關數據大多數都存儲在鏈下。這大大減少了鏈上的數據存儲需求，並有助於提高隱私。

2. 承諾機制：雖然資產數據存儲在鏈外，但對這些數據的更改或轉移會通過承諾（commitments）被記錄到鏈上。這些承諾使得鏈上的交易能夠引用鏈外的狀態，從而確保鏈外數據的完整性和不可篡改性。

3. 鏈上見證者（不一定是BTC）：雖然大部分數據和驗證都在鏈外，但通過嵌入到鏈上的承諾，客戶端驗證的資產仍然可以利用基礎鏈的安全性（證明的發佈，交易的排序）。

4. 驗證工作在客戶端完成：大部分驗證工作都在用戶設備上完成。這意味著不需要全網節點都參與驗證每筆交易，只有涉及到的參與者需要驗證交易的有效性。

對於使用客戶端驗證資產的人來說，還會有一點需要注意：

在鏈下交易和驗證客戶端驗證的資產的時候，不僅要出示持有資產的私鑰，也要同時出示對應資產的完整的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執行的時候限制沒有超出預期的行為，比如RGB20和RGB21，分別負責同質化代幣和非同質化代幣在交易上的一些限制。

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 layer2擴容方向：閃電網路還是側鏈？

客戶端驗證資產沒有辦法在鏈下保證安全的情況下連續交易的。因為客戶端驗證的資產還是依賴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並非傳統意義上的區塊鏈設計，而是一個為客戶端驗證設計的模塊化證明發布層，其由四個部分組成:

1. 時間戳服務
   最快10秒最終確定一個交易序列。

2. 證明
   通過PMT形式存儲與區塊頭一同生產和發佈。

3. 一次性密封
   抽象的單次密封協定，保證防雙花即可。在位元幣上實現，則是可以綁定到UTXO，與當下RGB設計類似。

4. 智慧合約協定
   分片合約-RGB (可替換)

從中其實可以看到，為了解決RGB交易確認時間的問題，Prime採用了一個時間戳服務來快速將鏈下的交易確認，並且將交易和ID裝入區塊中。並且於此同時可以把prime上的交易證明進一步通過PMT合併後再以類似checkpoint的方式錨定上BTC。

基於 Taproot 的 CSV 資產協定：Taproot Assets

Taproot Assets是基於Taproot的CSV資產協定，用於在位元幣區塊鏈上發行客戶端驗證的資產，這些資產可以通過閃電網路進行即時、大容量、低費用的交易。Taproot Assets 的核心是利用位元幣網路的安全性和穩定性以及閃電網路的速度、可擴展性和低費用。該協定是由Lightnling labs的CTO roasbeef設計並開發，roasbeef可能是這個星球上唯一親自主導過位元幣客戶端（BTCD）和閃電網路客戶端（LND）的位元幣研發，對BTC的理解極深。

Taproot交易只攜帶了資產腳本的根哈希，使得外部觀察者難以辨識是否涉及Taproot Assets，因為哈希本身是通用的，能代表任意數據。隨著Taproot升級，位元幣獲得了智慧合約（TapScript）的能力。在此基礎上，Taproot Assets的資產編碼相當於創建了一個與ERC20或ERC721相似的代幣定義。這樣，位元幣不僅擁有了資產定義的功能，還具備了智慧合約的編寫能力，從而為位元幣打下了代幣智慧合約基礎架構的雛形。

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的安全性，這就對能進行的鏈下交易類型和交易方式有了極大的限制。並且鏈下驗證也同時代表數據都在鏈下，由用戶自行保管，這對軟體執行環境安全性還有軟體的穩定性上提出了更高的要求。

擴容演進的趨勢

當下在以太坊流行的Layer2從範式上來講，是通過Layer1去驗證了Layer2的計算有效性，也就是把狀態計算下推到了Layer2，但是驗證還是保留在Layer1之上。在未來我們可以把驗證計算同樣下推到鏈下，進一步釋放當下區塊鏈基礎設施的性能。