淺談區塊鏈的 Layer2 擴展
公眾號回復「1」，拉你進區塊鏈技術討論微信群
作者：風靜縠紋平
本文約5500字+，閱讀（觀看）需要31分鐘
如何評估區塊鏈的「性能」？
如果我們現在來問一個區塊鏈愛好者或者從業者：你認為目前比較成熟的公鏈，比如比特幣和以太坊在技術上面臨的最大的問題是什麼？我想大多數人的回答應該都是類似的：交易確認時間長（一個交易從發出到最終確認所經過的時間）、網路擁堵嚴重（如果同一個時間產生的交易太多，有些交易無法被馬上處理）等等。這也就是通常意義上講的所謂「性能」問題。
對於目前基於區塊鏈架構的公鏈平台的所謂「性能」的評估，應該考慮兩個方面。
被討論最多的就是所謂的 TPS（Transactions Per Second），這個維度衡量的是區塊鏈在單位時間內所能處理的交易數量；我們近幾年最常提到的所謂「擴容」指的就是這個維度。
如果把以太坊比做「世界計算機」，那麼目前，它只能用單核（單線程）來進行計算（同一時間只能有一個礦工來記賬，或者說只有一個礦工記的賬會被接受）；而所謂「擴容」可以想像為把這個「世界計算機」擴展為多核（多線程），使它在單位時間內可以同時運行多個任務（同時有多個礦工在記賬，他們記的賬都可以被接受），最終反映為 TPS 的提高。這也就是所謂的 Layer1 擴容。在以太坊里，指的就是現在已經合二為一的 Casper + Sharding（我之前曾發過一篇 技術翻譯稿 來講解 Sharding 的原理，有興趣的讀者可以自行參考，這裡不再展開了）。
但是在實際應用中還有一個衡量性能的維度是不能忽視的，那就是「平均處理時間」。基於剛剛的比喻，在以太坊中，這個維度就相當於這台「世界計算機」的單核（單線程）處理能力。
什麼是「區塊鏈的 Layer2 擴展」？
我們假設某個基於以太坊智能合約的業務流程需要 5 個步驟（交易）才能完成，也就是說，我大概有個智能合約，這個合約會有 6 個狀態：初始狀態，狀態1，...，狀態4，最終狀態。那麼要完成整個流程，就至少需要 5 個區塊時間（從初始狀態變為狀態 1，需要交易 1 來完成，以次類推，則至少需要 5 個交易才能把狀態變為最終狀態）。
很顯然，在這個例子里，區塊鏈性能的瓶頸就變成了「區塊時間」。（這是因為智能合約本質上就是一個可定製的狀態機，如果它有 6 個單向變化的狀態，那麼必須經過 5 次變化才能達到最終狀態，所以 5 個交易是必須的。）而區塊時間是由公鏈協議所規定的，比如在比特幣里是 10 分鐘，在以太坊里現在大概是 16 秒，這是無法簡單縮減的；整個流程的 5 個區塊時間是最樂觀的估計，也就是性能上限。那麼我們如何縮短這個流程的執行時間、降低「平均處理時間」呢？
這就是所謂的區塊鏈 Layer2 擴展要解決的問題。而答案就是—— off-chain（這個詞的譯法大概還沒有共識，我這裡姑且譯為「脫鏈」，也就是不在主鏈上處理的意思）。
這種 off-chain 解決方案的思路是：我們可以把計算、交易等業務處理拿到主鏈之外來執行，只在主鏈上反映最終的結果，中間過程不在主鏈做記錄。
這樣，在上邊例子里，我們要在主鏈上保存的狀態就是初始狀態和最終狀態，中間過程的 4 個狀態變動我們可以不關心，那對應的 4 個交易就可以拿到「鏈外」去執行；因為 off-chain 方案通常處理性能會非常高（後文中我會具體解釋技術方案的原理），很有可能在主鏈的一個區塊時間內就處理完這 4 個交易，並將結果發送回主鏈（即達到最終狀態）；於是從結果來看，整個處理過程只經過了一個區塊時間（也就是最終狀態的確認交易）就完成了。
很明顯，如果採用這樣的方案，越複雜的流程得到的性能提升越大；比如一些有高交互性能需求的應用——遊戲。另外對於支付的場景，因為相對高昂的交易手續費，那些高頻的小額交易從經濟上講也顯然成本過高。所以無論是支付還是合約的應用場景中，都有對 Layer2 擴展的強烈需求。
Layer2 擴展的技術方案
Off-chain 方案的總體思路是類似的：首先需要把主鏈上的部分「狀態」拿到鏈外來，可以本地存儲（基於某種客戶端）或者臨時存儲；然後在鏈外做具體的操作，比如轉賬或者其他會影響「狀態」的處理；當處理完成或者到達需要同步「狀態」的時間點時，再把最終狀態傳回主鏈保存。
目前已經成體系的 off-chain 技術方案大概可以分為兩大類：
狀態通道（State Channel）：以比特幣的 Lightning Network [1] 和以太坊的 Raiden Network [2] 為代表
側鏈（Side-Chain）：以以太坊的 Plasma [3] 協議為代表
我們首先來看看「狀態通道」。
狀態通道是一個臨時的點對點（交易的兩個參與者間）價值轉移通道：在開啟時，通常會在主鏈上分別鎖定一定的餘額，並設定一個有效時間，並可以由任意參與方主動關閉，也就是參與方之間會基於特定的技術協議進行數據交互、價值轉移（數字資產轉移）；然後當可以接入網路、到達某個約定的時間點或者某方主動向主鏈同步數據時，會將最終結果提交到主鏈。
狀態通道主要解決的是前邊提到的高頻、小額支付這樣的場景中手續費過高的問題，但它的局限也很明顯：
首先，它是一個臨時的通路，數據並不是永久存儲的，而是由參與雙方自己本地保存；如果某個參與者使用的設備出現故障，損失基本上無法避免（雖然絕對的經濟損失大概並不會太高）。
其次，一個狀態通道僅能支持兩個用戶之間的價值轉移；當系統中同時存在大量用戶間的狀態通道時，實際上就構成一個通道網路：網路中的兩個用戶有交易需求的時候，並不是簡單地在他們兩點間創建新的通道，而是通過特定的路由（routing）演算法來查找是否有可用路徑，而後再決定如何創建他們之間的數據通道；但這本身也增加了實現的難度和相應的技術風險。
狀態通道網路示意圖（取自 Raiden Network 網站）
上圖是一個狀態通道網路示意圖。我們可以看到，如果 A 要向 C 進行轉賬，可以通過 A -> B -> C 的路徑完成的（通過 A -> B -> E -> D -> C 的路徑也可以完成，但這通常會需要更多的網路傳輸，所以並不是首選）；而如果 D 要向 F 轉賬，則可以通過 D -> E -> B -> A -> F 或 D -> C -> B -> A -> F 的路徑完成。所以理論上說，如果某個節點與狀態通道網路中的任意一個節點之間有通道，那麼就不需要再創建新的通道，而可以通過路由演算法找到對應的路徑完成價值轉移。
當然，狀態通道本身就是用來處理小額支付場景的，所以這些局限是可以接受的；即使出現不可恢復的故障，實際經濟損失也不會過大。
但這種技術本身顯然限制了擴展的通用性和數據容量。
所以，可以進行永久存儲、可以容納更多交易、可以擁有獨立的地址空間的所謂「側鏈（side-chain）」方案就應運而生了。
側鏈可以認為是主鏈的分支，是可以獨立記賬、獨立增長的子區塊鏈，所以其中同樣會有記賬人（礦工）、有永久存儲機制和共識演算法（因為參與側鏈記賬的通常會是實現了側鏈協議的多個節點）。
側鏈方案簡介
下面我將基於以太坊的 Plasma 協議的思路來簡單介紹側鏈的實現方案。
對於側鏈來講，我們可以把它與主鏈的交互抽象為若干的「狀態遷移（State Transition）」：在側鏈產生時，需要把若干「狀態」轉移到側鏈的「創世區塊」中，作為側鏈的「初始狀態」；在側鏈自己演進的過程中，需要定期把側鏈的狀態變動在主鏈進行記錄，以便在發生爭議或者有用戶想「退出」側鏈時可以恢復相應的狀態。
從應用角度看，側鏈要解決的主要技術問題就是用戶如何「進入」側鏈以及如何「退出」側鏈。
由於側鏈本身就是個區塊鏈，所以側鏈也可以擁有自己的地址空間；當主鏈用戶「進入」側鏈時就可以通過簡單的「地址映射」，將主鏈用戶的「狀態」——比如賬戶餘額或者持有的數字資產（ERC20 或者 ERC721 Token）——全部或者部分轉移到側鏈地址上。
複雜的，當然是「退出」機制。
當一個用戶 A 想從側鏈「退出」的時候，他應該要提出一個申請，將自己在側鏈中的「狀態」變動映射回主鏈。但因為用戶在側鏈中的狀態變動必然是因為與其他用戶進行了交互（交易）才會發生的，所以這也將會影響其他用戶的「狀態」。因而，這需要一個爭議期，在這個期間內，如果側鏈的其他用戶對用戶 A 的退出狀態有異議，他們可以發起一個「爭議（dispute）「，提交他們自己所留存的「狀態」數據，並提交「技術證明」（或者請求側鏈上的無利益衝突的第三方證明人提供「技術證明」，比如某個礦工或全節點提供的數據狀態證明）；主鏈上的所謂「仲裁合約」就可以根據「技術證明」來自動化地判斷誰的狀態變動才是「合法」的，從而進行最終在主鏈上的狀態更改。
這裡只是一個極簡的描述，實際的技術方案比較複雜，限於文章篇幅，就不再展開了。
有興趣的讀者可以自行閱讀參考資料 [3]。
Plasma 協議定義了一套子鏈（側鏈）的實現協議，其中包括 5 個核心組件：
為了從經濟上激勵側鏈本身的永久性存儲而設計的一個激勵層合約
為了最大化降低交易和結算成本而設計的樹狀結構交易數據
與上述兩個組件相配合的基於 MapReduce 計算框架的狀態轉移欺詐驗證機制
依賴於主鏈的某種側鏈內部的共識演算法
為最小化用戶退出成本而設計的一個用於狀態轉移的 bitmap-UTXO 技術證明機制
顯然，因為側鏈本身是一個有永久性存儲的子區塊鏈，裡邊同樣需要礦工來記賬，所以與普通公鏈類似的經濟激勵機制、共識演算法以及數據存儲結構設計就都是必然要考慮的東西。在側鏈中，通常為了達到更高的處理性能，會採用 PoS、DPoS 或者其他改進演算法，而不會採用 PoW 演算法。同時還會在側鏈自己的經濟模型中考慮對有欺詐行為的礦工的懲罰機制。
此外，因為側鏈本身也是一個區塊鏈，所以在側鏈之上再創建側鏈，理論上也是可行的。這就相當於提供了一種多層的、幾乎無限的擴展方案。
看起來這是種「完美」的方案；但事實上並沒有「完美」的方案，Plasma 中也還有很多需要解決的問題。（可以在參考資料 [3] 的第 11 章找到相關論述，這裡也不再展開了。）這也是社區和相關項目在努力研究的方向。
側鏈上的智能合約？
既然側鏈可以提供很高的「性能」，那麼在側鏈上運行智能合約自然就是一件極具吸引力的事了。
這裡必須要提一個項目——Loom。Loom 是一個參考了 Minimal Viable Plasma [4] 構建的側鏈開發框架，已經在今年 6 月發布了其 SDK，使用它的 SDK 我們可以快速地創建自己的側鏈作為我們自己的 Dapp 的後端支撐。儘管這個框架目前來講功能還比較弱，但已經是一個可用的選擇了。因為它也是開源的，所以對側鏈的具體實現也有很高的參考價值。此外就是 Celer 項目，這是一個通用的區塊鏈 Layer2 擴展框架，有非常宏大的願景；在狀態通道網路的實現方案上也有自己的創新。不過我個人比較關心的還是它對側鏈的支持，這也還需要等待後續的工程進展。
在 Plasma 中，為了簡化「狀態轉換」的驗證，側鏈的數據模型使用了 UTXO 模型，而對賬戶餘額變動的驗證則很自然地採用了所謂的「Merklized Proof」。但這樣的設計也對側鏈上的智能合約執行框架提出了挑戰。
我們知道，智能合約本質上是一個「狀態機」，所以，必須有永久性的存儲來保存其狀態數據，也就是類似於以太坊中的「存儲樹（Storage Trie）」這樣的設計。所以如果在側鏈上運行智能合約，也就同樣需要某種用來保存合約狀態的機制。
以太坊當初選擇賬戶模型而不是 UTXO 模型的主要原因就是實現狀態機的難度問題；顯然，基於賬戶模型的狀態機更容易實現，範式也更清晰。所以如何在基於 UTXO 模型的側鏈上實現智能合約運行環境就有了很多可以研究和討論的東西。我們可以基於 UTXO 模型構建狀態驗證機制，問題是這個賬戶狀態（餘額）變動如果不是通過交易直接產生的，而是通過合約代碼產生的，那麼如何證明這個改動是「合法」的就成了側鏈在與主鏈間進行狀態轉移時的驗證機制的關鍵。
我們當然希望有更多的項目能在這方面拿出可行的、可驗證的方案，因為這將對側鏈技術的繼續發展產生深遠的影響。
小結
本文淺嘗輒止地介紹了區塊鏈的 Layer2 擴展的相關概念，僅僅希望作為區塊鏈開發者或者愛好者進入這一領域的簡單嚮導，更深入的學習理解自然也需要讀者投入更多的時間和精力。比如你可以從精讀下邊列出的參考資料開始。
參考資料：
[1] Lightning Network:. https://lightning.network/lightning-network-paper.pdf
[2] Raiden Network: https://raiden.network/
[3] Plasma: https://plasma.io/plasma.pdf
[4] Minimal Viable Plasma: https://ethresear.ch/t/minimal-viable-plasma/426
文章發布只為分享區塊鏈技術內容，版權歸原作者所有，觀點僅代表作者本人，絕不代表區塊鏈兄弟贊同其觀點或證實其描述。
TAG:區塊鏈兄弟 |