淺談區(qū)塊鏈的 Layer2 擴展

前言:
自區(qū)塊鏈技術誕生以來咕痛,對其“性能”的詬病就從來沒有停止過簿姨。雖然從技術上說油挥,一個基于分布式對等網絡架構的系統(tǒng),與成熟的中心化技術相比款熬,其“性能”方面有著天然的劣勢深寥,但業(yè)內人士對區(qū)塊鏈“擴容”的研究和努力也從沒有停止過。近兩年贤牛,所謂的“區(qū)塊鏈 Layer2 擴展”的提法已經逐漸在業(yè)內達成共識惋鹅,并出現了一些有潛力的項目。本文就將為大家介紹一些與區(qū)塊鏈“擴容”和“Layer2 擴展”相關的基礎概念殉簸。
本文可以看作是對區(qū)塊鏈的 Layer2 擴展的掃盲性介紹闰集,不會涉及過多的技術細節(jié);但我會假設讀者已經知道比特幣般卑、以太坊是什么武鲁,區(qū)塊鏈大概是什么,我們會基于這些最基礎的知識來討論擴容的問題蝠检。
希望本文能給區(qū)塊鏈開發(fā)者或愛好者一些有價值的參考沐鼠。

如何評估區(qū)塊鏈的“性能”?

如果我們現在來問一個區(qū)塊鏈愛好者或者從業(yè)者:你認為目前比較成熟的公鏈叹谁,比如比特幣和以太坊在技術上面臨的最大的問題是什么饲梭?我想大多數人的回答應該都是類似的:交易確認時間長(一個交易從發(fā)出到最終確認所經過的時間)、網絡擁堵嚴重(如果同一個時間產生的交易太多焰檩,有些交易無法被馬上處理)等等憔涉。這也就是通常意義上講的所謂“性能”問題。

對于目前基于區(qū)塊鏈架構的公鏈平臺的所謂“性能”的評估析苫,應該考慮兩個方面兜叨。

被討論最多的就是所謂的 TPS(Transactions Per Second)穿扳,這個維度衡量的是區(qū)塊鏈在單位時間內所能處理的交易數量;我們近幾年最常提到的所謂“擴容”指的就是這個維度国旷。

如果把以太坊比做“世界計算機”矛物,那么目前,它只能用單核(單線程)來進行計算(同一時間只能有一個礦工來記賬议街,或者說只有一個礦工記的賬會被接受)泽谨;而所謂“擴容”可以想象為把這個“世界計算機”擴展為多核(多線程),使它在單位時間內可以同時運行多個任務(同時有多個礦工在記賬特漩,他們記的賬都可以被接受)吧雹,最終反映為 TPS 的提高。這也就是所謂的 Layer1 擴容涂身。在以太坊里雄卷,指的就是現在已經合二為一的 Casper + Sharding(我之前曾發(fā)過一篇 技術翻譯稿 來講解 Sharding 的原理,有興趣的讀者可以自行參考蛤售,這里不再展開了)丁鹉。

但是在實際應用中還有一個衡量性能的維度是不能忽視的,那就是“平均處理時間”悴能〈眨基于剛剛的比喻,在以太坊中漠酿,這個維度就相當于這臺“世界計算機”的單核(單線程)處理能力冯凹。

什么是“區(qū)塊鏈的 Layer2 擴展”?

我們假設某個基于以太坊智能合約的業(yè)務流程需要 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ū)塊時間”巩那。(這是因為智能合約本質上就是一個可定制的狀態(tài)機吏夯,如果它有 6 個單向變化的狀態(tài),那么必須經過 5 次變化才能達到最終狀態(tài)即横,所以 5 個交易是必須的噪生。)而區(qū)塊時間是由公鏈協議所規(guī)定的,比如在比特幣里是 10 分鐘东囚,在以太坊里現在大概是 16 秒跺嗽,這是無法簡單縮減的;整個流程的 5 個區(qū)塊時間是最樂觀的估計页藻,也就是性能上限桨嫁。那么我們如何縮短這個流程的執(zhí)行時間、降低“平均處理時間”呢份帐?

這就是所謂的區(qū)塊鏈 Layer2 擴展要解決的問題璃吧。而答案就是—— off-chain(這個詞的譯法大概還沒有共識,我這里姑且譯為“脫鏈”废境,也就是不在主鏈上處理的意思)畜挨。

這種 off-chain 解決方案的思路是:我們可以把計算、交易等業(yè)務處理拿到主鏈之外來執(zhí)行噩凹,只在主鏈上反映最終的結果巴元,中間過程不在主鏈做記錄。

這樣驮宴,在上邊例子里逮刨,我們要在主鏈上保存的狀態(tài)就是初始狀態(tài)和最終狀態(tài),中間過程的 4 個狀態(tài)變動我們可以不關心幻赚,那對應的 4 個交易就可以拿到“鏈外”去執(zhí)行禀忆;因為 off-chain 方案通常處理性能會非常高(后文中我會具體解釋技術方案的原理),很有可能在主鏈的一個區(qū)塊時間內就處理完這 4 個交易落恼,并將結果發(fā)送回主鏈(即達到最終狀態(tài))箩退;于是從結果來看,整個處理過程只經過了一個區(qū)塊時間(也就是最終狀態(tài)的確認交易)就完成了佳谦。

很明顯戴涝,如果采用這樣的方案,越復雜的流程得到的性能提升越大钻蔑;比如一些有高交互性能需求的應用——游戲啥刻。另外對于支付的場景,因為相對高昂的交易手續(xù)費咪笑,那些高頻的小額交易從經濟上講也顯然成本過高可帽。所以無論是支付還是合約的應用場景中,都有對 Layer2 擴展的強烈需求窗怒。

Layer2 擴展的技術方案

Off-chain 方案的總體思路是類似的:首先需要把主鏈上的部分“狀態(tài)”拿到鏈外來映跟,可以本地存儲(基于某種客戶端)或者臨時存儲蓄拣;然后在鏈外做具體的操作,比如轉賬或者其他會影響“狀態(tài)”的處理努隙;當處理完成或者到達需要同步“狀態(tài)”的時間點時球恤,再把最終狀態(tài)傳回主鏈保存。

目前已經成體系的 off-chain 技術方案大概可以分為兩大類:

  • 狀態(tài)通道(State Channel):以比特幣的 Lightning Network [1] 和以太坊的 Raiden Network [2] 為代表
  • 側鏈(Side-Chain):以以太坊的 Plasma [3] 協議為代表

我們首先來看看“狀態(tài)通道”荸镊。

狀態(tài)通道是一個臨時的點對點(交易的兩個參與者間)價值轉移通道:在開啟時咽斧,通常會在主鏈上分別鎖定一定的余額,并設定一個有效時間躬存,并可以由任意參與方主動關閉张惹,也就是參與方之間會基于特定的技術協議進行數據交互、價值轉移(數字資產轉移)优构;然后當可以接入網絡诵叁、到達某個約定的時間點或者某方主動向主鏈同步數據時,會將最終結果提交到主鏈钦椭。

狀態(tài)通道主要解決的是前邊提到的高頻拧额、小額支付這樣的場景中手續(xù)費過高的問題,但它的局限也很明顯:

首先彪腔,它是一個臨時的通路侥锦,數據并不是永久存儲的,而是由參與雙方自己本地保存德挣;如果某個參與者使用的設備出現故障恭垦,損失基本上無法避免(雖然絕對的經濟損失大概并不會太高)。

其次格嗅,一個狀態(tài)通道僅能支持兩個用戶之間的價值轉移番挺;當系統(tǒng)中同時存在大量用戶間的狀態(tài)通道時,實際上就構成一個通道網絡:網絡中的兩個用戶有交易需求的時候屯掖,并不是簡單地在他們兩點間創(chuàng)建新的通道玄柏,而是通過特定的路由(routing)算法來查找是否有可用路徑,而后再決定如何創(chuàng)建他們之間的數據通道贴铜;但這本身也增加了實現的難度和相應的技術風險粪摘。

狀態(tài)通道網絡示意圖(取自 Raiden Network 網站)

上圖是一個狀態(tài)通道網絡示意圖。我們可以看到绍坝,如果 A 要向 C 進行轉賬徘意,可以通過 A -> B -> C 的路徑完成的(通過 A -> B -> E -> D -> C 的路徑也可以完成,但這通常會需要更多的網絡傳輸轩褐,所以并不是首選)椎咧;而如果 D 要向 F 轉賬,則可以通過 D -> E -> B -> A -> F 或 D -> C -> B -> A -> F 的路徑完成把介。所以理論上說邑退,如果某個節(jié)點與狀態(tài)通道網絡中的任意一個節(jié)點之間有通道竹宋,那么就不需要再創(chuàng)建新的通道劳澄,而可以通過路由算法找到對應的路徑完成價值轉移地技。

當然,狀態(tài)通道本身就是用來處理小額支付場景的秒拔,所以這些局限是可以接受的莫矗;即使出現不可恢復的故障,實際經濟損失也不會過大砂缩。但這種技術本身顯然限制了擴展的通用性和數據容量作谚。

所以,可以進行永久存儲庵芭、可以容納更多交易妹懒、可以擁有獨立的地址空間的所謂“側鏈(side-chain)”方案就應運而生了。

側鏈可以認為是主鏈的分支双吆,是可以獨立記賬眨唬、獨立增長的子區(qū)塊鏈,所以其中同樣會有記賬人(礦工)好乐、有永久存儲機制和共識算法(因為參與側鏈記賬的通常會是實現了側鏈協議的多個節(jié)點)匾竿。

側鏈方案簡介

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

對于側鏈來講蔚万,我們可以把它與主鏈的交互抽象為若干的“狀態(tài)遷移(State Transition)”:在側鏈產生時岭妖,需要把若干“狀態(tài)”轉移到側鏈的“創(chuàng)世區(qū)塊”中,作為側鏈的“初始狀態(tài)”反璃;在側鏈自己演進的過程中昵慌,需要定期把側鏈的狀態(tài)變動在主鏈進行記錄,以便在發(fā)生爭議或者有用戶想“退出”側鏈時可以恢復相應的狀態(tài)淮蜈。

從應用角度看斋攀,側鏈要解決的主要技術問題就是用戶如何“進入”側鏈以及如何“退出”側鏈。

由于側鏈本身就是個區(qū)塊鏈礁芦,所以側鏈也可以擁有自己的地址空間蜻韭;當主鏈用戶“進入”側鏈時就可以通過簡單的“地址映射”,將主鏈用戶的“狀態(tài)”——比如賬戶余額或者持有的數字資產(ERC20 或者 ERC721 Token)——全部或者部分轉移到側鏈地址上柿扣。

復雜的肖方,當然是“退出”機制。

當一個用戶 A 想從側鏈“退出”的時候未状,他應該要提出一個申請俯画,將自己在側鏈中的“狀態(tài)”變動映射回主鏈。但因為用戶在側鏈中的狀態(tài)變動必然是因為與其他用戶進行了交互(交易)才會發(fā)生的司草,所以這也將會影響其他用戶的“狀態(tài)”艰垂。因而泡仗,這需要一個爭議期,在這個期間內猜憎,如果側鏈的其他用戶對用戶 A 的退出狀態(tài)有異議娩怎,他們可以發(fā)起一個“爭議(dispute)“,提交他們自己所留存的“狀態(tài)”數據胰柑,并提交“技術證明”(或者請求側鏈上的無利益沖突的第三方證明人提供“技術證明”截亦,比如某個礦工或全節(jié)點提供的數據狀態(tài)證明)册踩;主鏈上的所謂“仲裁合約”就可以根據“技術證明”來自動化地判斷誰的狀態(tài)變動才是“合法”的稀颁,從而進行最終在主鏈上的狀態(tài)更改。

這里只是一個極簡的描述们衙,實際的技術方案比較復雜踩官,限于文章篇幅却桶,就不再展開了。

有興趣的讀者可以自行閱讀參考資料 [3]蔗牡。
Plasma 協議定義了一套子鏈(側鏈)的實現協議颖系,其中包括 5 個核心組件:

  • 為了從經濟上激勵側鏈本身的永久性存儲而設計的一個激勵層合約
  • 為了最大化降低交易和結算成本而設計的樹狀結構交易數據
  • 與上述兩個組件相配合的基于 MapReduce 計算框架的狀態(tài)轉移欺詐驗證機制
  • 依賴于主鏈的某種側鏈內部的共識算法
  • 為最小化用戶退出成本而設計的一個用于狀態(tài)轉移的 bitmap-UTXO 技術證明機制

顯然,因為側鏈本身是一個有永久性存儲的子區(qū)塊鏈蛋逾,里邊同樣需要礦工來記賬集晚,所以與普通公鏈類似的經濟激勵機制、共識算法以及數據存儲結構設計就都是必然要考慮的東西区匣。在側鏈中偷拔,通常為了達到更高的處理性能,會采用 PoS亏钩、DPoS 或者其他改進算法莲绰,而不會采用 PoW 算法。同時還會在側鏈自己的經濟模型中考慮對有欺詐行為的礦工的懲罰機制姑丑。

此外蛤签,因為側鏈本身也是一個區(qū)塊鏈,所以在側鏈之上再創(chuàng)建側鏈栅哀,理論上也是可行的震肮。這就相當于提供了一種多層的、幾乎無限的擴展方案留拾。

看起來這是種“完美”的方案戳晌;但事實上并沒有“完美”的方案,Plasma 中也還有很多需要解決的問題痴柔。(可以在參考資料 [3] 的第 11 章找到相關論述沦偎,這里也不再展開了。)這也是社區(qū)和相關項目在努力研究的方向。

側鏈上的智能合約豪嚎?

既然側鏈可以提供很高的“性能”搔驼,那么在側鏈上運行智能合約自然就是一件極具吸引力的事了。

這里必須要提一個項目——Loom侈询。Loom 是一個參考了 Minimal Viable Plasma [4] 構建的側鏈開發(fā)框架舌涨,已經在今年 6 月發(fā)布了其 SDK,使用它的 SDK 我們可以快速地創(chuàng)建自己的側鏈作為我們自己的 Dapp 的后端支撐妄荔。盡管這個框架目前來講功能還比較弱泼菌,但已經是一個可用的選擇了。因為它也是開源的啦租,所以對側鏈的具體實現也有很高的參考價值。此外就是 Celer 項目荒揣,這是一個通用的區(qū)塊鏈 Layer2 擴展框架篷角,有非常宏大的愿景;在狀態(tài)通道網絡的實現方案上也有自己的創(chuàng)新系任。不過我個人比較關心的還是它對側鏈的支持恳蹲,這也還需要等待后續(xù)的工程進展。

在 Plasma 中俩滥,為了簡化“狀態(tài)轉換”的驗證嘉蕾,側鏈的數據模型使用了 UTXO 模型,而對賬戶余額變動的驗證則很自然地采用了所謂的“Merklized Proof”霜旧。但這樣的設計也對側鏈上的智能合約執(zhí)行框架提出了挑戰(zhàn)错忱。

我們知道,智能合約本質上是一個“狀態(tài)機”挂据,所以以清,必須有永久性的存儲來保存其狀態(tài)數據,也就是類似于以太坊中的“存儲樹(Storage Trie)”這樣的設計崎逃。所以如果在側鏈上運行智能合約掷倔,也就同樣需要某種用來保存合約狀態(tài)的機制。

以太坊當初選擇賬戶模型而不是 UTXO 模型的主要原因就是實現狀態(tài)機的難度問題个绍;顯然勒葱,基于賬戶模型的狀態(tài)機更容易實現,范式也更清晰巴柿。所以如何在基于 UTXO 模型的側鏈上實現智能合約運行環(huán)境就有了很多可以研究和討論的東西凛虽。我們可以基于 UTXO 模型構建狀態(tài)驗證機制,問題是這個賬戶狀態(tài)(余額)變動如果不是通過交易直接產生的篮洁,而是通過合約代碼產生的涩维,那么如何證明這個改動是“合法”的就成了側鏈在與主鏈間進行狀態(tài)轉移時的驗證機制的關鍵。

我們當然希望有更多的項目能在這方面拿出可行的、可驗證的方案瓦阐,因為這將對側鏈技術的繼續(xù)發(fā)展產生深遠的影響蜗侈。

小結

本文淺嘗輒止地介紹了區(qū)塊鏈的 Layer2 擴展的相關概念,僅僅希望作為區(qū)塊鏈開發(fā)者或者愛好者進入這一領域的簡單向導睡蟋,更深入的學習理解自然也需要讀者投入更多的時間和精力踏幻。比如你可以從精讀下邊列出的參考資料開始。


參考資料:

[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

?著作權歸作者所有,轉載或內容合作請聯系作者
  • 序言:七十年代末戳杀,一起剝皮案震驚了整個濱河市该面,隨后出現的幾起案子,更是在濱河造成了極大的恐慌信卡,老刑警劉巖隔缀,帶你破解...
    沈念sama閱讀 218,682評論 6 507
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現場離奇詭異傍菇,居然都是意外死亡猾瘸,警方通過查閱死者的電腦和手機,發(fā)現死者居然都...
    沈念sama閱讀 93,277評論 3 395
  • 文/潘曉璐 我一進店門丢习,熙熙樓的掌柜王于貴愁眉苦臉地迎上來牵触,“玉大人,你說我怎么就攤上這事咐低±克迹” “怎么了?”我有些...
    開封第一講書人閱讀 165,083評論 0 355
  • 文/不壞的土叔 我叫張陵见擦,是天一觀的道長钉汗。 經常有香客問我,道長锡宋,這世上最難降的妖魔是什么儡湾? 我笑而不...
    開封第一講書人閱讀 58,763評論 1 295
  • 正文 為了忘掉前任,我火速辦了婚禮执俩,結果婚禮上徐钠,老公的妹妹穿的比我還像新娘。我一直安慰自己役首,他們只是感情好尝丐,可當我...
    茶點故事閱讀 67,785評論 6 392
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著衡奥,像睡著了一般爹袁。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上矮固,一...
    開封第一講書人閱讀 51,624評論 1 305
  • 那天失息,我揣著相機與錄音譬淳,去河邊找鬼。 笑死盹兢,一個胖子當著我的面吹牛邻梆,可吹牛的內容都是我干的。 我是一名探鬼主播绎秒,決...
    沈念sama閱讀 40,358評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼浦妄,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了见芹?” 一聲冷哼從身側響起剂娄,我...
    開封第一講書人閱讀 39,261評論 0 276
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎玄呛,沒想到半個月后阅懦,有當地人在樹林里發(fā)現了一具尸體,經...
    沈念sama閱讀 45,722評論 1 315
  • 正文 獨居荒郊野嶺守林人離奇死亡把鉴,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 37,900評論 3 336
  • 正文 我和宋清朗相戀三年故黑,在試婚紗的時候發(fā)現自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片庭砍。...
    茶點故事閱讀 40,030評論 1 350
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖混埠,靈堂內的尸體忽然破棺而出怠缸,到底是詐尸還是另有隱情,我是刑警寧澤钳宪,帶...
    沈念sama閱讀 35,737評論 5 346
  • 正文 年R本政府宣布揭北,位于F島的核電站,受9級特大地震影響吏颖,放射性物質發(fā)生泄漏搔体。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 41,360評論 3 330
  • 文/蒙蒙 一半醉、第九天 我趴在偏房一處隱蔽的房頂上張望疚俱。 院中可真熱鬧,春花似錦缩多、人聲如沸呆奕。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,941評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽梁钾。三九已至,卻和暖如春逊抡,著一層夾襖步出監(jiān)牢的瞬間姆泻,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 33,057評論 1 270
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留拇勃,地道東北人四苇。 一個月前我還...
    沈念sama閱讀 48,237評論 3 371
  • 正文 我出身青樓,卻偏偏與公主長得像潜秋,于是被迫代替她去往敵國和親蛔琅。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 44,976評論 2 355

推薦閱讀更多精彩內容

  • 西江月——四月 淡淡云煙繚繞峻呛,一川芳草凄迷罗售。綠衣紅傘相與攜,擁擠游人滯滯钩述。入我蓬門小徑寨躁,有風招引情致。轟然天雨落花...
    八歲檀歌閱讀 331評論 1 2
  • 中國中高端市場容量 從GFK的數據來看牙勘,15年中高端市場(2500~3500價格段)容量大概為2300萬职恳,同比增長...
    Ocn閱讀 443評論 0 1
  • 昨天已經從畫面這方面說出該片的精彩之處,今天我們來聊聊這部片的世界觀設定方面。 在世界之初放钦,地球并不存在太陽和月亮,一...
    Wenshan閱讀 578評論 0 0