前言：
自區(qū)塊鏈技術(shù)誕生以來，對其“性能”的詬病就從來沒有停止過。雖然從技術(shù)上說，一個基于分布式對等網(wǎng)絡(luò)架構(gòu)的系統(tǒng)，與成熟的中心化技術(shù)相比，其“性能”方面有著天然的劣勢，但業(yè)內(nèi)人士對區(qū)塊鏈“擴容”的研究和努力也從沒有停止過。近兩年，所謂的“區(qū)塊鏈 Layer2 擴展”的提法已經(jīng)逐漸在業(yè)內(nèi)達成共識，并出現(xiàn)了一些有潛力的項目。本文就將為大家介紹一些與區(qū)塊鏈“擴容”和“Layer2 擴展”相關(guān)的基礎(chǔ)概念。
本文可以看作是對區(qū)塊鏈的 Layer2 擴展的掃盲性介紹，不會涉及過多的技術(shù)細(xì)節(jié)；但我會假設(shè)讀者已經(jīng)知道比特幣、以太坊是什么，區(qū)塊鏈大概是什么，我們會基于這些最基礎(chǔ)的知識來討論擴容的問題。
希望本文能給區(qū)塊鏈開發(fā)者或愛好者一些有價值的參考。
如何評估區(qū)塊鏈的“性能”？
如果我們現(xiàn)在來問一個區(qū)塊鏈愛好者或者從業(yè)者：你認(rèn)為目前比較成熟的公鏈，比如比特幣和以太坊在技術(shù)上面臨的最大的問題是什么？我想大多數(shù)人的回答應(yīng)該都是類似的：交易確認(rèn)時間長（一個交易從發(fā)出到最終確認(rèn)所經(jīng)過的時間）、網(wǎng)絡(luò)擁堵嚴(yán)重（如果同一個時間產(chǎn)生的交易太多，有些交易無法被馬上處理）等等。這也就是通常意義上講的所謂“性能”問題。
對于目前基于區(qū)塊鏈架構(gòu)的公鏈平臺的所謂“性能”的評估，應(yīng)該考慮兩個方面。
被討論最多的就是所謂的 TPS（Transactions Per Second），這個維度衡量的是區(qū)塊鏈在單位時間內(nèi)所能處理的交易數(shù)量；我們近幾年最常提到的所謂“擴容”指的就是這個維度。
如果把以太坊比做“世界計算機”，那么目前，它只能用單核（單線程）來進行計算（同一時間只能有一個礦工來記賬，或者說只有一個礦工記的賬會被接受）；而所謂“擴容”可以想象為把這個“世界計算機”擴展為多核（多線程），使它在單位時間內(nèi)可以同時運行多個任務(wù)（同時有多個礦工在記賬，他們記的賬都可以被接受），最終反映為 TPS 的提高。這也就是所謂的 Layer1 擴容。在以太坊里，指的就是現(xiàn)在已經(jīng)合二為一的 Casper + Sharding（我之前曾發(fā)過一篇 技術(shù)翻譯稿 來講解 Sharding 的原理，有興趣的讀者可以自行參考，這里不再展開了）。
但是在實際應(yīng)用中還有一個衡量性能的維度是不能忽視的，那就是“平均處理時間”?；趧倓偟谋扔鳎谝蕴恢?，這個維度就相當(dāng)于這臺“世界計算機”的單核（單線程）處理能力。
什么是“區(qū)塊鏈的 Layer2 擴展”？
我們假設(shè)某個基于以太坊智能合約的業(yè)務(wù)流程需要 5 個步驟（交易）才能完成，也就是說，我大概有個智能合約，這個合約會有 6 個狀態(tài)：初始狀態(tài)，狀態(tài)1，...，狀態(tài)4，最終狀態(tài)。那么要完成整個流程，就至少需要 5 個區(qū)塊時間（從初始狀態(tài)變?yōu)闋顟B(tài) 1，需要交易 1 來完成，以次類推，則至少需要 5 個交易才能把狀態(tài)變?yōu)樽罱K狀態(tài)）。
很顯然，在這個例子里，區(qū)塊鏈性能的瓶頸就變成了“區(qū)塊時間”。（這是因為智能合約本質(zhì)上就是一個可定制的狀態(tài)機，如果它有 6 個單向變化的狀態(tài)，那么必須經(jīng)過 5 次變化才能達到最終狀態(tài)，所以 5 個交易是必須的。）而區(qū)塊時間是由公鏈協(xié)議所規(guī)定的，比如在比特幣里是 10 分鐘，在以太坊里現(xiàn)在大概是 16 秒，這是無法簡單縮減的；整個流程的 5 個區(qū)塊時間是最樂觀的估計，也就是性能上限。那么我們?nèi)绾慰s短這個流程的執(zhí)行時間、降低“平均處理時間”呢？
這就是所謂的區(qū)塊鏈 Layer2 擴展要解決的問題。而答案就是—— off-chain（這個詞的譯法大概還沒有共識，我這里姑且譯為“脫鏈”，也就是不在主鏈上處理的意思）。
這種 off-chain 解決方案的思路是：我們可以把計算、交易等業(yè)務(wù)處理拿到主鏈之外來執(zhí)行，只在主鏈上反映最終的結(jié)果，中間過程不在主鏈做記錄。
這樣，在上邊例子里，我們要在主鏈上保存的狀態(tài)就是初始狀態(tài)和最終狀態(tài)，中間過程的 4 個狀態(tài)變動我們可以不關(guān)心，那對應(yīng)的 4 個交易就可以拿到“鏈外”去執(zhí)行；因為 off-chain 方案通常處理性能會非常高（后文中我會具體解釋技術(shù)方案的原理），很有可能在主鏈的一個區(qū)塊時間內(nèi)就處理完這 4 個交易，并將結(jié)果發(fā)送回主鏈（即達到最終狀態(tài)）；于是從結(jié)果來看，整個處理過程只經(jīng)過了一個區(qū)塊時間（也就是最終狀態(tài)的確認(rèn)交易）就完成了。
很明顯，如果采用這樣的方案，越復(fù)雜的流程得到的性能提升越大；比如一些有高交互性能需求的應(yīng)用——游戲。另外對于支付的場景，因為相對高昂的交易手續(xù)費，那些高頻的小額交易從經(jīng)濟上講也顯然成本過高。所以無論是支付還是合約的應(yīng)用場景中，都有對 Layer2 擴展的強烈需求。
Layer2 擴展的技術(shù)方案
Off-chain 方案的總體思路是類似的：首先需要把主鏈上的部分“狀態(tài)”拿到鏈外來，可以本地存儲（基于某種客戶端）或者臨時存儲；然后在鏈外做具體的操作，比如轉(zhuǎn)賬或者其他會影響“狀態(tài)”的處理；當(dāng)處理完成或者到達需要同步“狀態(tài)”的時間點時，再把最終狀態(tài)傳回主鏈保存。
目前已經(jīng)成體系的 off-chain 技術(shù)方案大概可以分為兩大類：
- 狀態(tài)通道（State Channel）：以比特幣的 Lightning Network [1] 和以太坊的 Raiden Network [2] 為代表
- 側(cè)鏈（Side-Chain）：以以太坊的 Plasma [3] 協(xié)議為代表
我們首先來看看“狀態(tài)通道”。
狀態(tài)通道是一個臨時的點對點（交易的兩個參與者間）價值轉(zhuǎn)移通道：在開啟時，通常會在主鏈上分別鎖定一定的余額，并設(shè)定一個有效時間，并可以由任意參與方主動關(guān)閉，也就是參與方之間會基于特定的技術(shù)協(xié)議進行數(shù)據(jù)交互、價值轉(zhuǎn)移（數(shù)字資產(chǎn)轉(zhuǎn)移）；然后當(dāng)可以接入網(wǎng)絡(luò)、到達某個約定的時間點或者某方主動向主鏈同步數(shù)據(jù)時，會將最終結(jié)果提交到主鏈。
狀態(tài)通道主要解決的是前邊提到的高頻、小額支付這樣的場景中手續(xù)費過高的問題，但它的局限也很明顯：
首先，它是一個臨時的通路，數(shù)據(jù)并不是永久存儲的，而是由參與雙方自己本地保存；如果某個參與者使用的設(shè)備出現(xiàn)故障，損失基本上無法避免（雖然絕對的經(jīng)濟損失大概并不會太高）。
其次，一個狀態(tài)通道僅能支持兩個用戶之間的價值轉(zhuǎn)移；當(dāng)系統(tǒng)中同時存在大量用戶間的狀態(tài)通道時，實際上就構(gòu)成一個通道網(wǎng)絡(luò)：網(wǎng)絡(luò)中的兩個用戶有交易需求的時候，并不是簡單地在他們兩點間創(chuàng)建新的通道，而是通過特定的路由（routing）算法來查找是否有可用路徑，而后再決定如何創(chuàng)建他們之間的數(shù)據(jù)通道；但這本身也增加了實現(xiàn)的難度和相應(yīng)的技術(shù)風(fēng)險。
上圖是一個狀態(tài)通道網(wǎng)絡(luò)示意圖。我們可以看到，如果 A 要向 C 進行轉(zhuǎn)賬，可以通過 A -> B -> C 的路徑完成的（通過 A -> B -> E -> D -> C 的路徑也可以完成，但這通常會需要更多的網(wǎng)絡(luò)傳輸，所以并不是首選）；而如果 D 要向 F 轉(zhuǎn)賬，則可以通過 D -> E -> B -> A -> F 或 D -> C -> B -> A -> F 的路徑完成。所以理論上說，如果某個節(jié)點與狀態(tài)通道網(wǎng)絡(luò)中的任意一個節(jié)點之間有通道，那么就不需要再創(chuàng)建新的通道，而可以通過路由算法找到對應(yīng)的路徑完成價值轉(zhuǎn)移。
當(dāng)然，狀態(tài)通道本身就是用來處理小額支付場景的，所以這些局限是可以接受的；即使出現(xiàn)不可恢復(fù)的故障，實際經(jīng)濟損失也不會過大。但這種技術(shù)本身顯然限制了擴展的通用性和數(shù)據(jù)容量。
所以，可以進行永久存儲、可以容納更多交易、可以擁有獨立的地址空間的所謂“側(cè)鏈（side-chain）”方案就應(yīng)運而生了。
側(cè)鏈可以認(rèn)為是主鏈的分支，是可以獨立記賬、獨立增長的子區(qū)塊鏈，所以其中同樣會有記賬人（礦工）、有永久存儲機制和共識算法（因為參與側(cè)鏈記賬的通常會是實現(xiàn)了側(cè)鏈協(xié)議的多個節(jié)點）。
側(cè)鏈方案簡介
下面我將基于以太坊的 Plasma 協(xié)議的思路來簡單介紹側(cè)鏈的實現(xiàn)方案。
對于側(cè)鏈來講，我們可以把它與主鏈的交互抽象為若干的“狀態(tài)遷移（State Transition）”：在側(cè)鏈產(chǎn)生時，需要把若干“狀態(tài)”轉(zhuǎn)移到側(cè)鏈的“創(chuàng)世區(qū)塊”中，作為側(cè)鏈的“初始狀態(tài)”；在側(cè)鏈自己演進的過程中，需要定期把側(cè)鏈的狀態(tài)變動在主鏈進行記錄，以便在發(fā)生爭議或者有用戶想“退出”側(cè)鏈時可以恢復(fù)相應(yīng)的狀態(tài)。
從應(yīng)用角度看，側(cè)鏈要解決的主要技術(shù)問題就是用戶如何“進入”側(cè)鏈以及如何“退出”側(cè)鏈。
由于側(cè)鏈本身就是個區(qū)塊鏈，所以側(cè)鏈也可以擁有自己的地址空間；當(dāng)主鏈用戶“進入”側(cè)鏈時就可以通過簡單的“地址映射”，將主鏈用戶的“狀態(tài)”——比如賬戶余額或者持有的數(shù)字資產(chǎn)（ERC20 或者 ERC721 Token）——全部或者部分轉(zhuǎn)移到側(cè)鏈地址上。
復(fù)雜的，當(dāng)然是“退出”機制。
當(dāng)一個用戶 A 想從側(cè)鏈“退出”的時候，他應(yīng)該要提出一個申請，將自己在側(cè)鏈中的“狀態(tài)”變動映射回主鏈。但因為用戶在側(cè)鏈中的狀態(tài)變動必然是因為與其他用戶進行了交互（交易）才會發(fā)生的，所以這也將會影響其他用戶的“狀態(tài)”。因而，這需要一個爭議期，在這個期間內(nèi)，如果側(cè)鏈的其他用戶對用戶 A 的退出狀態(tài)有異議，他們可以發(fā)起一個“爭議（dispute）“，提交他們自己所留存的“狀態(tài)”數(shù)據(jù)，并提交“技術(shù)證明”（或者請求側(cè)鏈上的無利益沖突的第三方證明人提供“技術(shù)證明”，比如某個礦工或全節(jié)點提供的數(shù)據(jù)狀態(tài)證明）；主鏈上的所謂“仲裁合約”就可以根據(jù)“技術(shù)證明”來自動化地判斷誰的狀態(tài)變動才是“合法”的，從而進行最終在主鏈上的狀態(tài)更改。
這里只是一個極簡的描述，實際的技術(shù)方案比較復(fù)雜，限于文章篇幅，就不再展開了。
有興趣的讀者可以自行閱讀參考資料 [3]。
Plasma 協(xié)議定義了一套子鏈（側(cè)鏈）的實現(xiàn)協(xié)議，其中包括 5 個核心組件：
- 為了從經(jīng)濟上激勵側(cè)鏈本身的永久性存儲而設(shè)計的一個激勵層合約
- 為了最大化降低交易和結(jié)算成本而設(shè)計的樹狀結(jié)構(gòu)交易數(shù)據(jù)
- 與上述兩個組件相配合的基于 MapReduce 計算框架的狀態(tài)轉(zhuǎn)移欺詐驗證機制
- 依賴于主鏈的某種側(cè)鏈內(nèi)部的共識算法
- 為最小化用戶退出成本而設(shè)計的一個用于狀態(tài)轉(zhuǎn)移的 bitmap-UTXO 技術(shù)證明機制
顯然，因為側(cè)鏈本身是一個有永久性存儲的子區(qū)塊鏈，里邊同樣需要礦工來記賬，所以與普通公鏈類似的經(jīng)濟激勵機制、共識算法以及數(shù)據(jù)存儲結(jié)構(gòu)設(shè)計就都是必然要考慮的東西。在側(cè)鏈中，通常為了達到更高的處理性能，會采用 PoS、DPoS 或者其他改進算法，而不會采用 PoW 算法。同時還會在側(cè)鏈自己的經(jīng)濟模型中考慮對有欺詐行為的礦工的懲罰機制。
此外，因為側(cè)鏈本身也是一個區(qū)塊鏈，所以在側(cè)鏈之上再創(chuàng)建側(cè)鏈，理論上也是可行的。這就相當(dāng)于提供了一種多層的、幾乎無限的擴展方案。
看起來這是種“完美”的方案；但事實上并沒有“完美”的方案，Plasma 中也還有很多需要解決的問題。（可以在參考資料 [3] 的第 11 章找到相關(guān)論述，這里也不再展開了。）這也是社區(qū)和相關(guān)項目在努力研究的方向。
側(cè)鏈上的智能合約？
既然側(cè)鏈可以提供很高的“性能”，那么在側(cè)鏈上運行智能合約自然就是一件極具吸引力的事了。
這里必須要提一個項目——Loom。Loom 是一個參考了 Minimal Viable Plasma [4] 構(gòu)建的側(cè)鏈開發(fā)框架，已經(jīng)在今年 6 月發(fā)布了其 SDK，使用它的 SDK 我們可以快速地創(chuàng)建自己的側(cè)鏈作為我們自己的 Dapp 的后端支撐。盡管這個框架目前來講功能還比較弱，但已經(jīng)是一個可用的選擇了。因為它也是開源的，所以對側(cè)鏈的具體實現(xiàn)也有很高的參考價值。此外就是 Celer 項目，這是一個通用的區(qū)塊鏈 Layer2 擴展框架，有非常宏大的愿景；在狀態(tài)通道網(wǎng)絡(luò)的實現(xiàn)方案上也有自己的創(chuàng)新。不過我個人比較關(guān)心的還是它對側(cè)鏈的支持，這也還需要等待后續(xù)的工程進展。
在 Plasma 中，為了簡化“狀態(tài)轉(zhuǎn)換”的驗證，側(cè)鏈的數(shù)據(jù)模型使用了 UTXO 模型，而對賬戶余額變動的驗證則很自然地采用了所謂的“Merklized Proof”。但這樣的設(shè)計也對側(cè)鏈上的智能合約執(zhí)行框架提出了挑戰(zhàn)。
我們知道，智能合約本質(zhì)上是一個“狀態(tài)機”，所以，必須有永久性的存儲來保存其狀態(tài)數(shù)據(jù)，也就是類似于以太坊中的“存儲樹（Storage Trie）”這樣的設(shè)計。所以如果在側(cè)鏈上運行智能合約，也就同樣需要某種用來保存合約狀態(tài)的機制。
以太坊當(dāng)初選擇賬戶模型而不是 UTXO 模型的主要原因就是實現(xiàn)狀態(tài)機的難度問題；顯然，基于賬戶模型的狀態(tài)機更容易實現(xiàn)，范式也更清晰。所以如何在基于 UTXO 模型的側(cè)鏈上實現(xiàn)智能合約運行環(huán)境就有了很多可以研究和討論的東西。我們可以基于 UTXO 模型構(gòu)建狀態(tài)驗證機制，問題是這個賬戶狀態(tài)（余額）變動如果不是通過交易直接產(chǎn)生的，而是通過合約代碼產(chǎn)生的，那么如何證明這個改動是“合法”的就成了側(cè)鏈在與主鏈間進行狀態(tài)轉(zhuǎn)移時的驗證機制的關(guān)鍵。
我們當(dāng)然希望有更多的項目能在這方面拿出可行的、可驗證的方案，因為這將對側(cè)鏈技術(shù)的繼續(xù)發(fā)展產(chǎn)生深遠(yuǎn)的影響。
小結(jié)
本文淺嘗輒止地介紹了區(qū)塊鏈的 Layer2 擴展的相關(guān)概念，僅僅希望作為區(qū)塊鏈開發(fā)者或者愛好者進入這一領(lǐng)域的簡單向?qū)?，更深入的學(xué)習(xí)理解自然也需要讀者投入更多的時間和精力。比如你可以從精讀下邊列出的參考資料開始。
參考資料：
[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
