鏈下轉移：比特幣資產協議的演進之路

作者：Ben77，來源：Mirror

前言

基於 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 -> -> CTransaction -> -> 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之上。在未來我們可以把驗證計算同樣下推到鏈下，進一步釋放當下區塊鏈基礎設施的性能。

鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播信息之目的，不構成任何投資建議，如有侵權行為，請第一時間聯絡我們修改或刪除，多謝。

---

標題：鏈下轉移：比特幣資產協議的演進之路

地址：https://www.torrentbusiness.com/article/74761.html

標籤：BTC  RGB