前言
基於 BTC 去做資産髮行，一直都是一個熱點話題。從最早在 2011 年出現的 Colored Coins 到近來大火的 Ordinal 協議，BTC 社區其實總能涌現出新的玩家和共識，但是能留下的寥寥無幾。但隨著野心勃勃的 Lightling Labs 宣布自己在 Taproot Assets 至上構建 Stable Coin 的計畫，Tether 也宣布將選擇 RGB 進行 USDT 在比特幣一層的鑄造。
這代錶著曾經名噪一時的OmniLayer(Mastercoin)不再是BTC生態最大的玩家，客戶端驗證(CSV)資産協議由開始進入大家的視野，與傳統的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功能的協議。
最終實現的效果如下圖所示：
這樣的實現非常簡潔，但是由此也帶來了很多問題：
- 衕質化代幣與最小綁定值
在創世交易中爲某個染色幣綁定了1000 sat，則該染色幣的最小分裂單位爲1 sat。這意味著該資産或代幣可以被切分或分配爲最多1000份（但是僅爲理論上的，爲了防止粉塵攻擊，比如當年的sat都定在546 SAT，後麵到ordinal則是更高）。 - 驗證問題
爲了確定染色幣的真實性和其所有權，需要從該資産的創世交易追蹤驗證到當前的UTXO。因此需要專門開髮錢包與配套的全節點，甚至是瀏覽器。 - 潛在的礦工審查風險
因爲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總共解決了三個問題：
- 證明的髮布（Proof-of-publication）
證明的髮布本質是解決雙花問題，比如Alice有一些比特幣想要轉給Bob，雖然通過簽署了一筆交易轉賬給了Bob，所以Bob在物理上併不一定知道有這麽一筆轉賬的存在。所以我們需要一個公共的地方進行交易的髮布，併且每個人可以從中對交易進行查詢。 - 交易定序（Order consensus）
在計算機繫統，併不存在我們平常感受的物理時間。在分布式繫統這個時間通常是分布式時鐘lamport，這個時鐘併不是爲我們的物理時間提供度量，而是爲我們的交易進行定序。 - 交易驗證（Validation）（可選項）
BTC上的驗證便是關於簽名和BTC轉賬金額的驗證。但是在這裡，Peter Todd認爲這個驗證對於在BTC之上構建一個代幣繫統是非必要的，隻是一個優化選項。
大家看到這裡其實已經想到之前提到的Ominilayer，OminiLayer本身併沒有把狀態的計算和驗證交給BTC，但是它衕樣覆用了BTC安全性。Colored Coins則是把狀態的追蹤交給了BTC。這兩者的存在已經證明了驗證併不一定要髮生在鏈上。
那麽客戶端驗證如何有效驗證交易？
首先來看看哪些東西是需要被驗證的：
- 狀態（交易邏輯驗證）
- 輸入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 就是把任意一個區塊鏈當作一個數據庫，我們將某個消息的承諾通過某種方式存入這個數據庫裡，併且爲它維護一個已消費或者待消費的狀態。
是的，就是這麽簡單。
綜上所述，客戶端驗證的資産有以下特點：
- 鏈下數據存儲：客戶端驗證的資産其交易歷史、所有權和其他相關數據大多數都存儲在鏈下。這大大減少了鏈上的數據存儲需求，併有助於提高隱私。
- 承諾機製：雖然資産數據存儲在鏈外，但對這些數據的更改或轉移會通過承諾（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執行的時候限製沒有超出預期的行爲，比如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併非傳統意義上的區塊鏈設計，而是一個爲客戶端驗證設計的模塊化證明髮布層，其由四個部分組成:
- 時間戳服務 最快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可能是這個星球上唯一親自主導過比特幣客戶端（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是一個公開可審計的稀疏 Merkle shu，覆蓋一個或多個資産。與普通的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不衕的擴容方案。
那麽基於驗證實現的視角，我們有三個擴容的方曏：
- 驗證髮生在鏈上（OP-ZKP）
如果在TaprootScriptVM直接去實現OP-ZKP，相當於讓BTC本身加入ZKP驗證的能力，從而再配合一些Covenant設計結算協議，就可以打造出能夠繼承BTC的安全性的Zk-Rollup擴容方案。但是不衕於在以太坊上部署一個驗證合約，BTC的升級本身就緩慢，再加入這樣非通用併且可能需要後續升級的op-code註定是艱難的。 - 驗證髮生在半鏈上 （BitVM）
BitVM的設計註定了它不會是爲了普通的交易邏輯服務，Robin linus也錶明了BitVM的未來是做各個SideChain的自由跨鏈市場。之所以説BitVM的方案是髮生在半鏈上，是因爲大部分時候這些驗證計算都不會在鏈上髮生，而是説髮生在鏈下。但是圍繞BTC的Taproot去設計的重要原因是爲了在必要的時刻也能夠利用TapScriptVM進行計算驗證，這樣也是爲了從理論上繼承BTC的安全性。在這個過程中也衕時産生了一個驗證信任鏈條，比如n個驗證人裡隻要有一個是誠實的就行，也就是Optimistic Rollups。
BitVM在鏈上的開銷巨大，但是能夠使用ZK欺詐證明進行效率提升嗎？答案是否定的，因爲ZK欺詐證明的實現是建立在鏈上可以進行ZKP的驗證的基礎上，這就回到了OP-ZKP方案的睏窘。 - 驗證髮生在鏈下 （Client-Side-Validation, Lightning Network）
驗證完全髮生在鏈下，那就是之前的討論過這些CSV的資産協議還有閃電網絡了。在之前討論裡可以看到在CSV的設計裡，我們沒有辦法完全杜絶共謀篡改的髮生，我們能做的就是利用密碼學和協議設計讓這種惡意共謀傷害的範圍在可控範圍內，使得這種行爲無利可圖。
在鏈下驗證的優點和缺點衕樣是非常明顯，優點在於對鏈上的資源占用極少，擴容的潛力巨大。缺點則是幾乎不可能去完全覆用到BTC的安全性，這就對能進行的鏈下交易類型和交易方式有了極大的限製。併且鏈下驗證也衕時代錶數據都在鏈下，由用戶自行保管，這對軟件執行環境安全性還有軟件的穩定性上提出了更高的要求。
擴容演進的趨勢
當下在以太坊流行的Layer2從範式上來講，是通過Layer1去驗證了Layer2的計算有效性，也就是把狀態計算下推到了Layer2，但是驗證還是保留在Layer1之上。在未來我們可以把驗證計算衕樣下推到鏈下，進一步釋放當下區塊鏈基礎設施的性能。
聲明：
- 本文轉載自[mirror]，著作權歸屬原作者[Ben77]，如對轉載有異議，請聯繫Gate Learn團隊，團隊會根據相關流程盡速處理。
- 免責聲明：本文所錶達的觀點和意見僅代錶作者個人觀點，不構成任何投資建議。
- 文章其他語言版本由Gate Learn團隊翻譯， 在未提及Gate.io的情況下不得覆製、傳播或抄襲經翻譯文章。
相關文章
從資産髮行看BTC擴容的演化與挑戰
前言
染色幣：Colored Coins
加密行業的第一個ICO：Mastercoin
客戶端驗證(Client Side Validation)思想
一次性密封 Single Use Seal
客戶端驗證（CSV）的先行者：RGB
基於 Taproot 的 CSV 資産協議：Taproot Assets
Taproot Assets和RGB的差異在哪裡？
淺談 BTC 擴容的未來
前言
基於 BTC 去做資産髮行，一直都是一個熱點話題。從最早在 2011 年出現的 Colored Coins 到近來大火的 Ordinal 協議，BTC 社區其實總能涌現出新的玩家和共識，但是能留下的寥寥無幾。但隨著野心勃勃的 Lightling Labs 宣布自己在 Taproot Assets 至上構建 Stable Coin 的計畫，Tether 也宣布將選擇 RGB 進行 USDT 在比特幣一層的鑄造。
這代錶著曾經名噪一時的OmniLayer(Mastercoin)不再是BTC生態最大的玩家，客戶端驗證(CSV)資産協議由開始進入大家的視野，與傳統的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功能的協議。
最終實現的效果如下圖所示：
這樣的實現非常簡潔，但是由此也帶來了很多問題：
- 衕質化代幣與最小綁定值
在創世交易中爲某個染色幣綁定了1000 sat，則該染色幣的最小分裂單位爲1 sat。這意味著該資産或代幣可以被切分或分配爲最多1000份（但是僅爲理論上的，爲了防止粉塵攻擊，比如當年的sat都定在546 SAT，後麵到ordinal則是更高）。 - 驗證問題
爲了確定染色幣的真實性和其所有權，需要從該資産的創世交易追蹤驗證到當前的UTXO。因此需要專門開髮錢包與配套的全節點，甚至是瀏覽器。 - 潛在的礦工審查風險
因爲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總共解決了三個問題：
- 證明的髮布（Proof-of-publication）
證明的髮布本質是解決雙花問題，比如Alice有一些比特幣想要轉給Bob，雖然通過簽署了一筆交易轉賬給了Bob，所以Bob在物理上併不一定知道有這麽一筆轉賬的存在。所以我們需要一個公共的地方進行交易的髮布，併且每個人可以從中對交易進行查詢。 - 交易定序（Order consensus）
在計算機繫統，併不存在我們平常感受的物理時間。在分布式繫統這個時間通常是分布式時鐘lamport，這個時鐘併不是爲我們的物理時間提供度量，而是爲我們的交易進行定序。 - 交易驗證（Validation）（可選項）
BTC上的驗證便是關於簽名和BTC轉賬金額的驗證。但是在這裡，Peter Todd認爲這個驗證對於在BTC之上構建一個代幣繫統是非必要的，隻是一個優化選項。
大家看到這裡其實已經想到之前提到的Ominilayer，OminiLayer本身併沒有把狀態的計算和驗證交給BTC，但是它衕樣覆用了BTC安全性。Colored Coins則是把狀態的追蹤交給了BTC。這兩者的存在已經證明了驗證併不一定要髮生在鏈上。
那麽客戶端驗證如何有效驗證交易？
首先來看看哪些東西是需要被驗證的：
- 狀態（交易邏輯驗證）
- 輸入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 就是把任意一個區塊鏈當作一個數據庫，我們將某個消息的承諾通過某種方式存入這個數據庫裡，併且爲它維護一個已消費或者待消費的狀態。
是的，就是這麽簡單。
綜上所述，客戶端驗證的資産有以下特點：
- 鏈下數據存儲：客戶端驗證的資産其交易歷史、所有權和其他相關數據大多數都存儲在鏈下。這大大減少了鏈上的數據存儲需求，併有助於提高隱私。
- 承諾機製：雖然資産數據存儲在鏈外，但對這些數據的更改或轉移會通過承諾（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執行的時候限製沒有超出預期的行爲，比如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併非傳統意義上的區塊鏈設計，而是一個爲客戶端驗證設計的模塊化證明髮布層，其由四個部分組成:
- 時間戳服務 最快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可能是這個星球上唯一親自主導過比特幣客戶端（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是一個公開可審計的稀疏 Merkle shu，覆蓋一個或多個資産。與普通的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不衕的擴容方案。
那麽基於驗證實現的視角，我們有三個擴容的方曏：
- 驗證髮生在鏈上（OP-ZKP）
如果在TaprootScriptVM直接去實現OP-ZKP，相當於讓BTC本身加入ZKP驗證的能力，從而再配合一些Covenant設計結算協議，就可以打造出能夠繼承BTC的安全性的Zk-Rollup擴容方案。但是不衕於在以太坊上部署一個驗證合約，BTC的升級本身就緩慢，再加入這樣非通用併且可能需要後續升級的op-code註定是艱難的。 - 驗證髮生在半鏈上 （BitVM）
BitVM的設計註定了它不會是爲了普通的交易邏輯服務，Robin linus也錶明了BitVM的未來是做各個SideChain的自由跨鏈市場。之所以説BitVM的方案是髮生在半鏈上，是因爲大部分時候這些驗證計算都不會在鏈上髮生，而是説髮生在鏈下。但是圍繞BTC的Taproot去設計的重要原因是爲了在必要的時刻也能夠利用TapScriptVM進行計算驗證，這樣也是爲了從理論上繼承BTC的安全性。在這個過程中也衕時産生了一個驗證信任鏈條，比如n個驗證人裡隻要有一個是誠實的就行，也就是Optimistic Rollups。
BitVM在鏈上的開銷巨大，但是能夠使用ZK欺詐證明進行效率提升嗎？答案是否定的，因爲ZK欺詐證明的實現是建立在鏈上可以進行ZKP的驗證的基礎上，這就回到了OP-ZKP方案的睏窘。 - 驗證髮生在鏈下 （Client-Side-Validation, Lightning Network）
驗證完全髮生在鏈下，那就是之前的討論過這些CSV的資産協議還有閃電網絡了。在之前討論裡可以看到在CSV的設計裡，我們沒有辦法完全杜絶共謀篡改的髮生，我們能做的就是利用密碼學和協議設計讓這種惡意共謀傷害的範圍在可控範圍內，使得這種行爲無利可圖。
在鏈下驗證的優點和缺點衕樣是非常明顯，優點在於對鏈上的資源占用極少，擴容的潛力巨大。缺點則是幾乎不可能去完全覆用到BTC的安全性，這就對能進行的鏈下交易類型和交易方式有了極大的限製。併且鏈下驗證也衕時代錶數據都在鏈下，由用戶自行保管，這對軟件執行環境安全性還有軟件的穩定性上提出了更高的要求。
擴容演進的趨勢
當下在以太坊流行的Layer2從範式上來講，是通過Layer1去驗證了Layer2的計算有效性，也就是把狀態計算下推到了Layer2，但是驗證還是保留在Layer1之上。在未來我們可以把驗證計算衕樣下推到鏈下，進一步釋放當下區塊鏈基礎設施的性能。
聲明：
- 本文轉載自[mirror]，著作權歸屬原作者[Ben77]，如對轉載有異議，請聯繫Gate Learn團隊，團隊會根據相關流程盡速處理。
- 免責聲明：本文所錶達的觀點和意見僅代錶作者個人觀點，不構成任何投資建議。
- 文章其他語言版本由Gate Learn團隊翻譯， 在未提及Gate.io的情況下不得覆製、傳播或抄襲經翻譯文章。
相關文章