區塊鏈100講：淺談區塊鏈的 Layer2 擴展

**前言：自區塊鏈技術誕生以來，對其「性能」的詬病就歷來沒有中止過。雖然從技術上說，一個基於分佈式對等網絡架構的系統，與成熟的中心化技術相比，其「性能」方面有着自然的劣勢，但業內人士對區塊鏈「擴容」的研究和努力也從沒有中止過。近兩年，所謂的「區塊鏈 Layer2 擴展」的提法已經逐漸在業內達成共識，並出現了一些有潛力的項目。本文就將爲你們介紹一些與區塊鏈「擴容」和「Layer2 擴展」**相關的基礎概念。

本文能夠看做是對區塊鏈的 Layer2 擴展的掃盲性介紹，不會涉及過多的技術細節；但我會假設讀者已經知道比特幣、以太坊是什麼，區塊鏈大概是什麼，咱們會基於這些最基礎的知識來討論擴容的問題。 但願本文能給區塊鏈開發者或愛好者一些有價值的參考。

1

如何評估區塊鏈的「性能」？

若是咱們如今來問一個區塊鏈愛好者或者從業者：你認爲目前比較成熟的公鏈，好比比特幣和以太坊在技術上面臨的最大的問題是什麼？我想大多數人的回答應該都是相似的：交易確認時間長（一個交易從發出到最終確認所通過的時間）、網絡擁堵嚴重（若是同一個時間產生的交易太多，有些交易沒法被立刻處理）等等。這也就是一般意義上講的所謂「性能」問題。

對於目前基於區塊鏈架構的公鏈平臺的所謂「性能」的評估，應該考慮兩個方面。

被討論最多的就是所謂的 TPS（Transactions Per Second），這個維度衡量的是區塊鏈在單位時間內所能處理的交易數量；咱們近幾年最常提到的所謂「擴容」指的就是這個維度。

若是把以太坊比作「世界計算機」，那麼目前，它只能用單核（單線程）來進行計算（同一時間只能有一個礦工來記帳，或者說只有一個礦工記的帳會被接受）；而所謂「擴容」能夠想象爲把這個「世界計算機」擴展爲多核（多線程），使它在單位時間內能夠同時運行多個任務（同時有多個礦工在記帳，他們記的帳均可以被接受），最終反映爲 TPS 的提升。這也就是所謂的 Layer1 擴容。在以太坊裏，指的就是如今已經合二爲一的 Casper + Sharding（我以前曾發過一篇 技術翻譯稿 來說解 Sharding 的原理，有興趣的讀者能夠自行參考，這裏再也不展開了）。

可是在實際應用中還有一個衡量性能的維度是不能忽視的，那就是「平均處理時間」。基於剛剛的比喻，在以太坊中，這個維度就至關於這臺「世界計算機」的單核（單線程）處理能力。

2

什麼是「區塊鏈的 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 擴展的強烈需求。

3

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）」方案就應運而生了。

側鏈能夠認爲是主鏈的分支，是能夠獨立記帳、獨立增加的子區塊鏈，因此其中一樣會有記帳人（礦工）、有永久存儲機制和共識算法（由於參與側鏈記帳的一般會是實現了側鏈協議的多個節點）。

4

側鏈方案簡介

下面我將基於以太坊的 Plasma 協議的思路來簡單介紹側鏈的實現方案。

對於側鏈來說，咱們能夠把它與主鏈的交互抽象爲若干的「狀態遷移（State Transition）」：在側鏈產生時，須要把若干「狀態」轉移到側鏈的「創世區塊」中，做爲側鏈的「初始狀態」；在側鏈本身演進的過程當中，須要按期把側鏈的狀態變更在主鏈進行記錄，以便在發生爭議或者有用戶想「退出」側鏈時能夠恢復相應的狀態。

從應用角度看，側鏈要解決的主要技術問題就是用戶如何「進入」側鏈以及如何「退出」側鏈。

因爲側鏈自己就是個區塊鏈，因此側鏈也能夠擁有本身的地址空間；當主鏈用戶「進入」側鏈時就能夠經過簡單的「地址映射」，將主鏈用戶的「狀態」——好比帳戶餘額或者持有的數字資產（ERC20 或者 ERC721 Token）——所有或者部分轉移到側鏈地址上。

複雜的，固然是「退出」機制。

當一個用戶 A 想從側鏈「退出」的時候，他應該要提出一個申請，將本身在側鏈中的「狀態」變更映射回主鏈。但由於用戶在側鏈中的狀態變更必然是由於與其餘用戶進行了交互（交易）纔會發生的，因此這也將會影響其餘用戶的「狀態」。於是，這須要一個爭議期，在這個期間內，若是側鏈的其餘用戶對用戶 A 的退出狀態有異議，他們能夠發起一個「爭議（dispute）「，提交他們本身所留存的「狀態」數據，並提交「技術證實」（或者請求側鏈上的無利益衝突的第三方證實人提供「技術證實」，好比某個礦工或全節點提供的數據狀態證實）；主鏈上的所謂「仲裁合約」就能夠根據「技術證實」來自動化地判斷誰的狀態變更纔是「合法」的，從而進行最終在主鏈上的狀態更改。

這裏只是一個極簡的描述，實際的技術方案比較複雜，限於文章篇幅，就再也不展開了。

有興趣的讀者能夠自行閱讀參考資料 [3]。 Plasma 協議定義了一套子鏈（側鏈）的實現協議，其中包括  5 個核心組件：

• 爲了從經濟上激勵側鏈自己的永久性存儲而設計的一個激勵層合約

• 爲了最大化下降交易和結算成本而設計的樹狀結構交易數據

• 與上述兩個組件相配合的基於 MapReduce 計算框架的狀態轉移欺詐驗證機制

• 依賴於主鏈的某種側鏈內部的共識算法

• 爲最小化用戶退出成本而設計的一個用於狀態轉移的 bitmap-UTXO  技術證實機制

顯然，由於側鏈自己是一個有永久性存儲的子區塊鏈，裏邊一樣須要礦工來記帳，因此與普通公鏈相似的經濟激勵機制、共識算法以及數據存儲結構設計就都是必然要考慮的東西。在側鏈中，一般爲了達到更高的處理性能，會採用 PoS、DPoS 或者其餘改進算法，而不會採用 PoW 算法。同時還會在側鏈本身的經濟模型中考慮對有欺詐行爲的礦工的懲罰機制。

此外，由於側鏈自己也是一個區塊鏈，因此在側鏈之上再建立側鏈，理論上也是可行的。這就至關於提供了一種多層的、幾乎無限的擴展方案。

看起來這是種「完美」的方案；但事實上並無「完美」的方案，Plasma 中也還有不少須要解決的問題。（能夠在參考資料 [3] 的第 11 章找到相關論述，這裏也再也不展開了。）這也是社區和相關項目在努力研究的方向。

5

側鏈上的智能合約？

既然側鏈能夠提供很高的「性能」，那麼在側鏈上運行智能合約天然就是一件極具吸引力的事了。

這裏必需要提一個項目——Loom。Loom 是一個參考了 Minimal Viable Plasma [4] 構建的側鏈開發框架，已經在今年 6 月發佈了其 SDK，使用它的 SDK 咱們能夠快速地建立本身的側鏈做爲咱們本身的 Dapp 的後端支撐。儘管這個框架目前來說功能還比較弱，但已是一個可用的選擇了。由於它也是開源的，因此對側鏈的具體實現也有很高的參考價值。此外就是 Celer 項目，這是一個通用的區塊鏈 Layer2 擴展框架，有很是宏大的願景；在狀態通道網絡的實現方案上也有本身的創新。不過我我的比較關心的仍是它對側鏈的支持，這也還須要等待後續的工程進展。

在 Plasma 中，爲了簡化「狀態轉換」的驗證，側鏈的數據模型使用了 UTXO 模型，而對帳戶餘額變更的驗證則很天然地採用了所謂的「Merklized Proof」。但這樣的設計也對側鏈上的智能合約執行框架提出了挑戰。

咱們知道，智能合約本質上是一個「狀態機」，因此，必須有永久性的存儲來保存其狀態數據，也就是相似於以太坊中的「存儲樹（Storage Trie）」這樣的設計。因此若是在側鏈上運行智能合約，也就一樣須要某種用來保存合約狀態的機制。

以太坊當初選擇帳戶模型而不是 UTXO 模型的主要緣由就是實現狀態機的難度問題；顯然，基於帳戶模型的狀態機更容易實現，範式也更清晰。因此如何在基於 UTXO 模型的側鏈上實現智能合約運行環境就有了不少能夠研究和討論的東西。咱們能夠基於 UTXO 模型構建狀態驗證機制，問題是這個帳戶狀態（餘額）變更若是不是經過交易直接產生的，而是經過合約代碼產生的，那麼如何證實這個改動是「合法」的就成了側鏈在與主鏈間進行狀態轉移時的驗證機制的關鍵。

咱們固然但願有更多的項目能在這方面拿出可行的、可驗證的方案，由於這將對側鏈技術的繼續發展產生深遠的影響。

6

總結

本文淺嘗輒止地介紹了區塊鏈的 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

內容來源：簡書

做者：楊鎮

原文連接：https://www.jianshu.com/p/d049845a8ac9

《區塊鏈100講》專欄策劃及內容編輯：HiBlock區塊鏈社區Cynthia

如需轉載，需申請並註明專欄及原文出處。

如下是咱們的社區介紹，歡迎各類合做、交流、學習：）