比特幣生態必讀指南（1）：解鎖萬億市場的力量

“我們期待下一個周期區塊鏈指數型增長來源於比特幣的大規模應用。”

隨著 Web3 Labs 與 Waterdrip Capital 共衕髮起的 Satoshi Lab 實驗室正式在香港成立，比特幣生態繫統的討論熱度在整個加密市場中逐漸攀升。在比特幣腳本上利用客戶端驗證方案構建智能合約，衕時兼容具備無限可擴展性的閃電網絡進行通道交易，可能成爲在衕時保證 “安全性，去中心化，可擴展性” 三角上的區塊鏈大規模應用方案。

本文將針對比特幣生態一些基礎層麵概念進行科普講解。從阻礙大規模應用的“區塊鏈不可能三角”，到剋服“不可能三角的比特幣“閃電網絡”，到目前對比特幣腳本的解決方案及 UTXO 模型原理。

是什麽阻礙了區塊鏈的大規模應用？

以太坊創始人 Vitalik Buterin 和巴比特創始人長鋏均提出過，“區塊鏈網絡無法衕時實現安全性、去中心化和可擴展性”，即“區塊鏈不可能三角”。“不可能三角”的難題，長久以來阻礙了區塊鏈的大規模應用。

在保障安全性的基礎上，以太坊過去十年將重心放在髮展去中心化，併在底層公鏈的基礎設施層不斷創新，以拓展以太坊公鏈的可擴展性。爲了實現這個目標，以太坊十年間也迭代出各種空氣算法，分片，Rollup 等技術。

但對於可擴展性難題，從以太坊及其Layer2的嘗試來看，似乎隻要仍在解決方案局限在區塊鏈上，性能就會存在上限的。即便是我們目前可見性能最強的區塊鏈，仍難突破 TPS (每秒交易量) 上限，離百萬級 TPS 的大規模商業應用的要求，和全球工業級實現數億級 TPS 的目標仍有巨大差距。對於主流公鏈，不論是以太坊還是比特幣，都麵臨一個瓶頸——“如何解決可擴展性？”

閃電網絡是如何運作的？

閃電網絡利用鏈下計算的方式，即 “支付通道 (Payment Channel)”，徹底解決了“不可能三角”的可擴展性問題——隻要建足夠多的通道，就可以跑任意多的併髮交易。

閃電網絡原理

1. 以銀行體繫作比喻，如果 A，B 兩人開戶轉賬。當兩個人在相衕銀行時，在衕一個銀行內部清算。而當 A，B 兩個人不在衕一個銀行時，需要通過央行執行跨行結算操作。
2. 閃電網絡模仿了銀行清算的方式：用戶 A 和 B 通過閃電網絡在兩者之間開通閃電通道。通道開啟時，A 和 B 利用通道直接在閃電網絡進行清算，而不需要在比特幣區塊鏈上結算。隻有當通道關閉時，A 和 B 才需要跨越閃電網絡，在比特幣區塊鏈上結算。

閃電通道操作流程

1. 繳納準備金：類比傳統場景下銀行開戶需要提前繳納準備金，開通閃電網絡通道也需要繳納比特幣準備金。
2. 鏈下交易記賬：通過閃電網絡每筆交易逐筆記賬，每一筆記賬都要簽訂一個懲罰協議。
3. 鏈上結算記録：關閉閃電通道後，把歷史交易數據一次性封裝打包結算，最終髮送到比特幣區塊鏈上。

閃電網絡如何避免鏈上欺詐

如果在通道交易過程中，A 執行欺詐行爲 —— 提前關閉通道結算比特幣。那麽通道關閉時，比特幣鏈上會立刻産生一筆欺詐交易。基於比特幣鏈的開放性，B 就可以及時觀察到，併用提前簽訂的懲罰協議對 A 進行懲罰。懲罰內容就是沒收 A 所有準備金。

閃電網絡的大規模應用瓶頸

理論上閃電網絡實現了無窮大的可擴展性，剋服了區塊鏈不可能三角。但阻礙閃電網絡實現大規模應用最關鍵的問題是：閃電網絡使用和比特幣相衕的腳本，而比特幣鏈上沒有智能合約，隻有簡單的腳本，無法承載覆雜應用。即比特幣鏈是圖靈不完備的，圖靈完備的意味著理論上可以解決任何計算性的問題。使用圖靈完備的腳本語言，可以在邏輯上做到和其他編程語言兼容，併在理論上能夠實現任何其他語言所能實現的邏輯，以及最大限度的覆製現實的商業邏輯。比特幣區塊鏈上沒有智能合約，更不用説基於智能合約搭建應用。所以閃電網絡需要剋服的最大問題就是“如何在比特幣上實現智能合約”。

現有提升比特幣區塊鏈“功能”的方案

1. 側鏈（Side Chain）
2. 側鏈是指做一條具有智能合約功能的鏈，覆製它與比特幣主鏈雙曏掛鉤，從而使比特幣資産在主鏈與側鏈間無縫遷移，從而實現智能合約，但目前沒有足夠去中心化的雙曏掛鉤技術。側鏈對於主鏈的覆製和資産遷移需要第三方中心化服務商，目前隻有泛中心化方案。如“WBTC”，由 BitGo 髮行在以太坊網絡上的一種 ERC-20 代幣，作爲衍生資産與 BTC 1：1 錨定。側鏈方案因爲第三方髮行的中心化問題始終未得到比特幣核心開髮者社區支持。
3. 彩色幣（Colored Coins）
4. 2012年比特幣協會主席 Meni Rosenfeld 髮錶了《彩色幣概述》論文，文中介紹了一種利用比特幣“可替代性”的機製，通過爲某些硬幣“著色”，將特定的代幣與其他代幣分開，從而創建適合這些硬幣的應用程序。具體方式是利用比特幣腳本裡 OP_RETURN 指令，在後麵增加 80 個字節的任意字符，在 80 個字節裡按照指定格式設計字符串，通過人爲指定字符串含義標記 “彩色幣”，併且做更覆雜的智能合約。但 80 個字節的空間太小，無法實現覆雜功能。
5. 後續“彩色幣”方案也推出了新技術。比如“Ordinals”銘刻技術，通過利用比特幣區塊內 3 M 的“隔離見證”空間，用在其中塞入小圖片，髮行NFT。比如 BRC-20，用一串代碼錶達比 80 個字節更豐富的內容。但這些彩色幣會産生額外的嚴重問題——占用了“隔離見證”空間，原先用來存放比特幣轉賬交易簽名的空間，擠占了“隔離見證”空間會導緻了比特幣上可執行的交易數量減少，使比特幣性能下降。彩色幣方案衕樣遭到比特幣核心開髮者強烈抵製，原因是彩色幣污染了原生比特幣，另外人爲指定的形式仍然需要中心化的第三方進行服務器解析。
6. 客戶端驗證（Client-Validation）

2016 年比特幣核心開髮者 Peter Todd 髮錶論文提出了客戶端驗證範式，通過模擬傳統的合衕簽約方式保證隻有雙方知道合約內容的隱私性前提，無需任何第三方參與，實現完全去中心化。衕時，在交易執行時，採用由交易髮起方提供必要的完整交易歷史數據，另一方自行驗證的方式，來防止欺詐問題的産生。既不存在中心化睏擾，又是鏈下驗證不受性能限製的特徵，使其目前被多數人認爲是解決比特幣區塊鏈圖靈完備性不足的“最優”方案。

傳統合衕簽署vs區塊鏈智能合約簽署

1. 傳統合衕簽署：A 和 B 之間有一筆交易，先簽署一個合衕，雙方確認合衕內容後簽字，簽字時合衕不可篡改。未來合衕執行過程的任何交易都是 A 和 B 兩個人的交易，不需要第三方介入。
2. 區塊鏈智能合約簽署：交易過程公布給全網，所有礦工進行執行與驗證。整個執行過程無隱私可言，且由於需要公布到全網達成共識，性能受到局限。

客戶端驗證是否無懈可擊？

看到這裡，似乎會有人産生疑問，去中心化的比特幣區塊鏈本身解決了傳統商業中的安全問題，但隨著客戶端驗證的引入，解決方案又回到鏈下，即便其解決了欺詐問題，那麽又該如何有效地防止雙花問題産生？

引入“一次性密封”

由於客戶端驗證本身併不包含雙花防止機製，我們不得不需要引入第三方輔助來解決這個問題。爲了實現這一目標，我們將客戶端驗證中需要驗證的每個合約的每個狀態，與特定比特幣的未使用交易輸出(UTXO)綁定。由於UTXO僅存在兩種形態，”花費”與“未花費”。而一旦要變更驗證合約的狀態，就必鬚花費綁定的UTXO（任意金額均可），讓花費它的交易得到區塊鏈的確認。此外，花費它的比特幣交易還必鬚提供狀態轉換的內容的證明（作用類似於哈希值）。簡單來説，可以將被綁定的UTXO視爲這個狀態“信封”的封蠟一一想要打開信封，就必鬚開啟封蠟。

UTXO模型的補充説明

區別於以太坊的賬戶模型，未花費的交易輸出（UTXO）是從一個地址髮送到另一個地址但尚未被接收方贖回的加密貨幣總和，以便在後續交易中將資金髮送給其他人。

1. 例如，如果愛麗絲曏鮑勃髮送 1 個比特幣，那麽隻要鮑勃沒有花掉從愛麗絲那裡收到的 BTC，他就擁有 UTXO。一旦 Bob 花費了 1 個 BTC，UTXO 的生命周期就結束了。
   

2. 假設Bob的錢包隻參與過一筆交易，其中Bob從Alice那裡收到了1 BTC，交易驗證者就知道Bob的UTXO餘額是1 BTC。如果 Bob 將 1 BTC 髮送給 Carol，他的 UTXO 立即變爲 0 BTC。如果 Bob 然後嘗試在第二筆傳出交易中雙花-MN4DXX5)他的幣，驗證者將髮現他的 UTXO 餘額不足以用作第二筆交易的輸入，併且誠實的驗證者將不會傳播或確認他的雙花交易。

下一個指數增長：比特幣生態全麵爆髮

在比特幣的演進過程中，客戶端驗證的設計精妙地規避了側鏈和彩色幣方案的中心化問題，併引入了一次性密封機製，使其進一步提升了安全性。此刻，比特幣生態正在迎來一繫列全新協議的誕生，其中，RGB協議不僅沿用了上述理念，還提出與閃電網絡兼容，爲無限可擴展性打下基石。盡管RGB協議與閃電網絡的兼容性尚未完美，但我們對未來充滿信心，相信幫助協議不斷優化的基礎設施將突破長期以來的“區塊鏈不可能三角”局限。

我們更加有理由期待下一個周期區塊鏈指數型增長來源於比特幣生態的爆髮所帶動的區塊鏈大規模採用。相信比特幣將突破原有的單一價值存儲，彰顯其貨幣屬性的衕時，不斷通過多樣化的解決方案爲比特幣生態嫁接更多應用，促進生態可擴展和可持續髮展，繼續爲區塊鏈世界帶來無限可能。

聲明：

1. 本文轉載自[Waterdrip]，著作權歸屬原作者[Echo, Infinitas]，如對轉載有異議，請聯繫Gate Learn團隊，團隊會根據相關流程盡速處理。
2. 免責聲明：本文所錶達的觀點和意見僅代錶作者個人觀點，不構成任何投資建議。
3. 文章其他語言版本由Gate Learn團隊翻譯， 在未提及Gate.io的情況下不得覆製、傳播或抄襲經翻譯文章。