通證通研究院 × FENBUSHI DIGITAL 聯合出品
文：宋雙傑，CFA；程東鋒
特別顧問：沈波；Rin；JX
導讀
狀態通道是一種比較熱門的擴容方案，以太坊基金會近期披露的3000萬美金的年度資金預算，有1900萬美金用於包括狀態通道和Plasma在內的以太坊2.0的開發。狀態通道有望推進區塊鏈的大規模落地商用。
摘要
區塊鏈不可能三角是指非中心化特性、安全性、擴充套件性三者不可能同時得到很好的滿足。
狀態通道解決方案透過將鏈下互動和鏈上清算隔離開，能夠在保障一定程度的非中心化和資產安全性的同時，實現速度更快、費用更低的交易。狀態通道作為一種鏈下擴容方案，從一般到特殊分為通用狀態通道、狀態通道和支付通道三個層次。
狀態通道面臨的主要問題包括路由問題、通道平衡問題、節點離線問題以及保證金鎖定問題。
透過設計合理的路由策略可以將狀態通道擴充套件為網路結構，目前的方案有雜湊時間鎖合約、虛擬通道和元通道。通道平衡問題的主要解決思路有背壓路由演算法和鏈下重新平衡方案。節點離線問題的主要解決思路是引入第三方來監督鏈下狀態，並加以經濟激勵。保證金鎖定問題的解決思路是從流動性資金供應商那裡吸收閒散資金、共享資金池。
相比於鏈上擴容方案，狀態通道巧妙地將鏈上和鏈下的職能分開，採用該方案無需改變公鏈結構，結合了鏈上的安全性和非中心化特性以及，鏈下的擴充套件性，但從整體生態來說，由於鏈上鍊下通訊過程中可能存在的問題，狀態通道依然屬於安全性、非中心化和擴充套件性的一種新平衡。相比於其他鏈下擴容方案，狀態通道的隱私性較好，可做到即時性，尤其適合於固定雙方的高頻互動，其劣勢在於需要中間節點“墊付”資金、要求節點實時線上或需引入第三方來監督。
風險提示：中介節點壟斷、安全漏洞
目錄
1 狀態通道概述
2 狀態通道的三個層級
2.1 通用狀態通道
2.2 狀態通道
2.3 支付通道
3 狀態通道需攻克的關鍵問題
3.1 路由問題
3.1.1 雜湊時間鎖合約（HTLC，Hashed-Time Lock Contract）
3.1.2 虛擬通道（Virtual Channel）
3.1.3 元通道（Meta Channel）
3.2 通道平衡問題
3.3 節點離線問題
3.4 保證金鎖定問題
4 狀態通道和其他擴容方案的對比
4.1 與鏈上擴容方案的對比
4.2 與其他鏈下方案的對比
正文
狀態通道（State Channel）是區塊鏈鏈下（off-chain）擴容方案之一，目前有眾多知名專案都採用了狀態通道技術方案。
1狀態通道概述
區塊鏈的所有節點執行相同的計算、儲存相同的資料，這樣一種冗餘的架構在保障了安全性和非中心化的同時，也導致區塊鏈處理交易的速度非常慢，且費用昂貴。
鏈下擴容也稱第2層擴容，是不改變公鏈基礎協議的一種應用層上的擴充套件方案，第1層（layer-1）提供安全性，第2層（layer-2）提供擴充套件性。鏈下擴容目前主要有狀態通道、側鏈（或子鏈）和鏈下計算等方案。
狀態通道中的狀態指的是區塊鏈賬本當前的樣子，包括賬戶名稱（或UTXO模型的地址）、餘額（或UTXO模型下的未花費交易輸出）、合約資料等。狀態通道是在兩方或多方之間開闢一條鏈下通道來進行狀態交換，以實現較低的手續費和即時到賬等特性。
利用狀態通道交易的流程一般為：
①交易方在鏈上鎖定一定量的資產，在區塊鏈上記錄並開闢狀態通道；
②在通道內進行相互交易和狀態更新，但不提交到鏈上；
③當任一方想要關閉通道時，提交最終狀態到區塊鏈上進行清算。若另一方有異議，可在規定時間內申請鏈上仲裁。
狀態通道的擴容原理主要是鏈下互動、鏈上清算，避免將每一筆小額交易都放在鏈上進行，只需要把最終的狀態提交到鏈上即可，減輕了鏈上的工作量。當雙方均無異議可以很快完成清算，實現即時終結性（Instant Finality），此外由於在通道內進行鏈下交易，可實現較快的交易速度、較低的手續費，以及較好的隱私性。
當某一方試圖欺詐，提交有利於自己的非最終狀態上鍊時，另一方可以透過提交帶有時間戳的最新狀態向鏈上申訴，坐實後欺詐者會面臨被沒收抵押物的懲罰。但這要求狀態通道的使用者實時線上，如果某一方長時間離線，鏈上清算會強制執行，從而可能造成損失。這種情況下一般會引入第三方來監督是否有欺詐現象發生，但這需要設計出合理的第三方經濟激勵機制。
狀態通道方案比較適合參與方在相對較長的時間裡需多次交換狀態、對單次轉賬的交易手續費比較敏感等場景。例如棋牌類遊戲、物聯網智慧支付（M2M）、博彩平臺、直播打賞等。
2狀態通道的三個層級
狀態通道作為一種鏈下擴容方案，從一般到特殊主要分為通用狀態通道（Generalized State Channel）、狀態通道（State Channel）和支付通道（Payment Channel）三個層級。
2.1 通用狀態通道
通用狀態通道是模組化、標準化的狀態通道開發框架，例項化之後即成為狀態通道或支付通道。開發人員無需很熟悉狀態通道的相關技術細節也可以很容易地開發基於狀態通道的應用，使用者也可在不執行任何鏈上操作的情況下在通道內安裝、執行和終止DApp。
典型的專案有Counterfactual（基於鏈下狀態通道建立應用的開發架構）、Celer Network（layer-2擴充套件平臺，幫助開發者快速構建和執行非中心化應用）。
2.2 狀態通道
狀態通道是在鏈下進行狀態互動的通道。透過將鏈上的圖靈完備智慧合約放到鏈下執行，來實現狀態交換和鏈下擴容的目的。例如基於狀態通道開發的圍棋遊戲，就是在鏈下不斷進行狀態的交換。
典型的專案有Perun Network（支援鏈下智慧合約的執行）、FunFair（基於狀態通道的對賭遊戲）。
2.3 支付通道
支付通道屬於狀態通道在支付領域內的具體應用。交易雙方在狀態通道內可多次進行賬務往來，直到通道關閉時上鍊清算。鏈下轉賬快速無手續費，當一方嘗試在上鍊清算時進行欺詐，會有仲裁和懲罰機制來確保雙方的資產安全。
典型的專案有閃電網路（BTC的狀態通道支付網路）、Raiden（以太坊版的閃電網路）、Trinity（Neo版的閃電網路）Liquidity Network（基於NOCUST協議的支付通道網路）。
3狀態通道需攻克的關鍵問題
3.1 路由問題
為了將支付通道擴充套件為支付網路，在已開闢的狀態通道上透過路由節點建立兩個陌生節點的連線無疑是比較經濟的。正如六度人脈理論闡釋的那樣，我們可以借助六度人脈和世界上其他任何人建立聯絡。目前主要有如下三種路由方案：
3.1.1 雜湊時間鎖合約（HTLC，Hashed-Time Lock Contract）
代表專案：閃電網路
傳送方向接收方傳送BTC到1/2多重簽名地址，如果接收方不能在合約規定的時間內透過“簽名+雜湊密文”的方式將BTC解鎖，那麼BTC就會退還給傳送方。
如圖所示，A想透過B、C向D傳送1個BTC。D作為接收方，首先生成一個隨機私鑰r（相當於鑰匙）和公鑰R（相當於鎖），然後將R傳送給A。
A和B首先搭建了雜湊時間鎖合約，R就是其中的“鎖”，這裡的“時間”是3天，“雜湊密文”就是隻有D才知道的私鑰r。這個合約意味著只要B能在3天之內獲得私鑰r來解鎖R，就可以得到A在智慧合約裡傳送的1個BTC，否則這1個BTC就會退還給A。
B需要獲得私鑰r來解鎖R，按照同樣的思路，B和C的智慧合約規定，只要C能在2天之內獲得私鑰r來解鎖R，就可以得到B在智慧合約裡傳送的1個BTC，否則這1個BTC就會退還給B。
最後C和D的智慧合約也是如此，只要D能在1天之內用私鑰r來解鎖R就可以獲得這1個BTC。相當於D是用私鑰r換取了C“墊付”的1個BTC，C拿到私鑰r後再用它解鎖並換取了B“墊付”的1個BTC，之後B用r解鎖了A的1個BTC。
也就是說，D首先生成了“鎖”和對應的“鑰匙”，然後鎖依次傳到A、B、C；D收到BTC後，“鑰匙”依次傳到C、B、A。這樣幾個節點無需相互信任就實現了從A到D的安全轉賬。實際操作中，中間節點會收到額外的服務費作為經濟激勵（這也意味著經過的中間節點越多，手續費越高）。
3.1.2 虛擬通道（Virtual Channel）
代表專案：Perun Network
如圖所示，A、B都已經與I開闢了狀態通道，分別為通道X和通道Y。現在A、B向中間節點I透過智慧合約發出申請，建立A和B的虛擬通道Z（虛線所示）。
A在X通道鎖定了Z（A）個通證，對應的I在Y通道也鎖定了Z（A）個通證；
B在Y通道鎖定了Z（B）個通證，對應的I在X通道也鎖定了Z（B）個通證。
鎖定之後相當於在A、B之間建立了一個虛擬通道Z，A、B在該通道內對應的可用額度分別是Z（A）、Z（B）。A如果想向B轉賬1個通證，I的左邊會增加1個通證，與此同時右邊會減少1個通證，減少的1個通證轉給了B，達成的效果類似於武俠小說裡的“隔山打牛”，A透過I作為“跳板”向B轉賬了1個通證。虛擬通道也可以進一步擴充套件形成更大的網路。
與雜湊時間鎖合約方案相比，該方案的中間節點無需牽涉到每筆交易中來，只需透過智慧合約自動執行，因此更具隱私性和低延遲性，但是需要中間節點鎖定足夠數量的通證，以為虛擬通道兩端提供“中介服務”。比如在上面的例子中，I節點至少需要鎖定Z（A）+Z（B）個通證。
3.1.3 元通道（Meta Channel）
代表專案：Counterfactual
該方案與虛擬通道類似，只是結構稍有差異。比如Counterfactual，是將通用狀態通道進行例項化後分別建立A和I、B和I的代理狀態通道，在此基礎上建立A、B的支付通道，實現和虛擬通道相同的效果。
3.2 通道平衡問題
在狀態通道網路中，採用傳統計算機網路的最短路徑的路由策略，會造成通道的不平衡狀態，反過來又會使得路由策略失效，尋路遇到“死衚衕”便無法有效傳遞價值。如圖表8所示A、B、C三個節點兩兩組成的雙向狀態通道，採用最短路徑使得節點在某一通道的可用通證變為0，雙向通道變成了單向通道。左上圖是平衡狀態，對應左下圖所示雙向通道。中上圖和右上圖的通證集中到了一邊，分別對應中下和右下的單向通道。
Celer Network提出了背壓（BackPressure）路由演算法，在每個時間切片內衡量區域性網路的擁堵程度和通道失衡度，然後按照背壓權重最大的方向進行路由轉移，減少網路擁堵的同時實現通道平衡。透過對77個節點組成的254個狀態通道組成的支付網路進行測試後發現，背壓路由演算法和閃電網路的最短路徑路由演算法相比，效能提高了15倍，通道利用率提高了20倍。
Liquidity Network提出了一個允許在鏈下重新平衡支付通道的Revive協議。該協議透過使一組支付通道節點執行一組交易，來重新平衡每個節點在多個通道的通證資產量，防止單向通道形成。如下左圖所示的樹形網路結構無法做到重新平衡，而Revive所採用的右圖所示的網路包含環狀結構，可以實現節點在多個通道的通證分佈從集中重新變得均勻。例如，B在和D組成的通道里有200個通證，而在和E組成的通道里有0個通證，對於右圖可以透過（B，D，E，B）環狀結構進行重新調配，使得B和D、B和E組成的兩個通道里各有100個通證。
3.3 節點離線問題
前文提到狀態通道是在鏈下互動、鏈上清算，任何一方都可以關閉狀態通道實現最終的清算和交割。當雙方同時線上且達成一致，可實現即時終結性。但是當一方處於離線狀態，或者另一方發起攻擊（如DDoS攻擊、破壞網線等）使其離線，並提交對自己有利的非最終狀態給鏈上，離線方一旦錯過仲裁期，最終的清算結果將會對離線方造成資產損失，損害狀態通道的公平性、安全性。
這種情況下人們想到透過把監測任務外包給第三方加以解決,例如閃電網路的監督者（Monitors）、Pisa的看管者（Custodians）、Celer Network的狀態保衛網路（State Guardian Network）。
Monitors透過舉證獲得獎勵，Custodians透過質押安全保證金獲得監管機會，State Guardian Network是由狀態守護者組成的一個類似於Plasma的側鏈，CELR通證（Celer Network網路中的通證）持有者透過抵押通證成為鏈下狀態守護者，抵押通證越多則被委派以守護鏈下狀態任務的概率越大，從而獲得更多收益的概率也越大。
隨著鏈下擴容的發展和大規模商用，透過設計合理的第三方經濟激勵機制，將為layer-2的服務提供商帶來機遇。
3.4 保證金鎖定問題
3.1章節提到的路由方案，無論是雜湊鎖定合約，還是虛擬通道、元通道，都需要中間節點“墊付”資金，或鎖定保證金。網路規模越大、平均的轉賬金額越大，整個網路鎖定的保證金也越多，由此產生的機會成本也越高昂。
Liquidity Network和Celer Network都提出了類似於銀行的機制來共享流動性，試圖透過智慧合約從通證持有者處租借通證或支付中心相互“拆借”和共享的方式，減少保證金的鎖定。
下圖為Celer Network的經濟模型，主要由流動性資金支援拍賣機制（LiBA，Liquidity Backing Auction）、流動性資金擔保挖礦機制（PoLC Mining，Proof of Liquidity Commitment Mining）和鏈下狀態守護者網路三部分構成。其中PoLC Mining機制是Celer網路流動性資金的關鍵源頭，簡單來說就是透過質押擔保合約從流動性資金提供商那裡收集閒散資金，類似於銀行從儲戶那裡獲得資金，再透過LiBA機制為狀態通道服務供應商提供流動性資金，類似於銀行放貸。
Liquidity Network基於NOCUST的多方支付中心，透過匯聚和共享抵押資金的方式來減少資金鎖定。而閃電網路需要對所有的交易進行100%的抵押，且抵押金相互隔離，流動性較差。
4狀態通道和其他擴容方案的對比
4.1 與鏈上擴容方案的對比
相比於鏈上擴容方案，狀態通道巧妙地將鏈上和鏈下的職能分開，採用該方案無需改變公鏈結構，結合了鏈上的安全性和非中心化特性以及，鏈下的擴充套件性，但從整體生態來說，由於鏈上鍊下通訊過程中可能存在的問題，狀態通道依然是安全性、非中心化和擴充套件性的一種新平衡。
4.2 與其他鏈下方案的對比
相比於其他鏈下擴容方案，狀態通道的隱私性較好，可做到即時性，尤其適合於固定雙方的高頻互動，其劣勢在於需要中間節點“墊付”資金、要求節點實時線上或需引入第三方來監督。
側鏈（如Plasma）的擴容原理是在主鏈上擴充套件側鏈處理事務，側鏈產生糾紛後可以在“挑戰期（Challenge Period）”向主鏈申請仲裁，類似於中級人民法院和最高人民法院的關係，兼顧了效率和公正。側鏈方案和狀態通道相比，由於強制留有“挑戰期”而不具有即時終結性。
鏈下計算的方案是將複雜的計算放在鏈下進行，將計算結果提交到鏈上進行確認。鏈下計算也是透過引入競爭和激勵的方式來確保鏈下的計算結果是可靠的，例如Truebit的核實遊戲 （Verification Game）。鏈下計算比較適合需要做複雜計算的場景，例如BTC的簡單支付驗證（SPV）可以讓以太坊的智慧合約來檢查某筆交易是否已經發生，但SPV本身的計算量很大，放在鏈上進行昂貴且擁堵。
附註：
因一些原因，本文中的一些名詞標註並不是十分精準，主要如：通證、數字通證、數字currency、貨幣、token、Crowdsale等，讀者如有疑問，可來電來函共同探討。
