區塊鏈擴容的兩個層次
- Layer 1 （鏈上）
對共識算法和區塊鏈架構（分片）的改進。在鏈上的改進對可擴展性的提高能力非常有限。 - Layer 2 （鏈下）
在主鏈之外建立外圍或第二層交易網絡（例如，狀態通道、側鏈、DAG）。
Example 1：閃電網絡——狀態通道在比特幣上的實現
閃電網絡可以說是Layer 2最有名的擴展項目了。
適用場景
高頻、小額交易。
核心概念
-
RSMC（Recoverable Sequence Maturity Contract）
類似於準備金機制，保障了兩方的直接交易可以在鏈下進行。
雙方都預存一部分資金到“微支付通道”裏，之後每次交易，就對交易後的資金分配方案共同進行確認，同時簽字作廢舊的版本。當需要提現時，將最終交易結果寫到區塊鏈網絡中，被最終確認。（可以看到，只有在提現時候才需要通過區塊鏈）。
任何一個版本的方案都需要經過雙方的簽名認證才合法。任何一方在任何時候都可以提出提現，提現需要提供一個雙方都簽名過的資金分配方案（意味着肯定是某次交易後的結果）。在一定時間內，如果另外一方提出證明表明這個方案其實之前被作廢了（非最新的交易結果），則資金罰沒給質疑成功方。這就確保了沒人會拿一箇舊的交易結果來提現。
另外，即使雙方都確認了某次提現，首先提出提現一方的資金到賬時間要晚於對方，這就鼓勵大家儘量都在鏈外完成交易。 -
HTLC（Hashed Timelock Contract）
HTLC就是一種就是限時轉賬，保證了任意兩人之間的轉賬都可以通過支付通道完成。微支付通道是通過 Hashed Timelock Contract 來實現的。通過智能合約，雙方約定轉賬方先凍結一筆錢，並提供一個哈希值，如果在一定時間內有人能提出一個字符串，使得它哈希後的值跟已知值匹配（實際上意味着轉賬方授權了接收方來提現），則這筆錢轉給接收方。
交易流程
- 雙方建立支付通道
- 資金上鍊
- 鏈下白條交易
- 關閉鏈下通道
- 1. 雙方建立支付通道
- 2. 資金上鍊
![]()
Bob和Coffeeshop都把資金存入到鏈上地址，Bob存入0.05BTC，Coffeeshop存入0BTC。只有通道關閉時，鏈上的資金纔會被釋放，用戶才能真正擁有該資金。
支付通道的建立是在鏈上完成的，因此需要一定的交易費。
這是一個雙向的支付通道。所謂通道，其實就是雙方之間的簽名地址和分配狀態。交易雙方可以在鏈下通道內完成多次交易，將交易餘額上鍊。這樣衆多微小的交易就變成了交易集，大大降低了最終發佈到鏈上的交易數量。
支付通道的建立過程引入了“2-of-2雙重簽名地址”：
該地址就是需要雙方的簽名才能進行轉賬的地址。 其中，第二個2表示總簽名數，第一個2表示拿到幾個數有效。這裏指的是總簽名數爲2個，一筆交易拿到2個簽名後有效。2-of-3指的就是總簽名數爲3個，拿到其中2個簽名後有效。
-
3. 鏈下白條交易
![]()
Bob和Coffeeshop之間的交易在鏈下進行，可以是多次交易。他們在建立的支付通道內通過相互在白條上簽名來完成交易。每次交易，雙方都保存一份相同的帶有雙方簽名的白條。保存的白條是處理後續交易，解決交易糾紛的關鍵。 -
4. 關閉鏈下通道
![]()
任何一方都可以申請關閉鏈下支付通道來進行交易結算。比如BoB 可以拿着白條：Bob 0.045 BTC| Coffeeshop 0.005 BTC，到鏈上申請關閉鏈下支付通道，並進行交易結算，結算完成後 Bob 可以拿到 0.045 BTC，Coffeeshop 拿到 0.005 BTC。
如何防止交易方作弊？
如果Bob實際上買了10杯咖啡，雙方真正的餘額是Bob 0 BTC| Coffeeshop 0.05 BTC。如果此時Bob想作弊，拿着第一次交易的白條Bob 0.045 BTC| Coffeeshop 0.005 BTC到鏈上去申請結算，就會發生詐騙的情況。
閃電網絡給出的解決方案是RSMC（Recoverable Sequence Maturity Contract）。RSMC規定有效交易必須是經雙方共同簽字確認的資金分配方案，且將之前的版本簽字確認作廢。這裏如果Bob提出關閉交易通道進行結算，他向區塊鏈出示雙方簽字的餘額分配方案，如果Coffeeshop在規定時間內未提出異議，那麼區塊鏈纔會中止雙方的支付通道並將資金按協議轉入各自的提現地址。而如果Coffeeshop在規定時間內提出了異議，並向區塊鏈提交了證據證明Bob提交的是一個雙方已同意作廢的餘額分配方案，那麼Bob的資金將被沒收給Coffeeshop。
（這裏有一個缺陷，那就是在這個超時機制中，用戶需要在給定時間內保持一次在線。在線問題是閃電網絡的一個缺陷）。
另外，RSMC還規定了資金到賬順序。爲了鼓勵雙方儘可能多地在該通道內進行交易，RSMC規定：主動關閉方資金到賬時間晚於對方。
雙人通道=>多人通道
即用戶之間的多跳支付。
Alice 和 Bob 已經建立"支付寶"支付通道，Bob 和 Carol 已經建立"微信"支付通道。如果 Alice 給 Carol 之間要進行交易，有兩種方案，第一種是 Alice 和 Carol 再建立一條“Apple”支付通道，另外一種方案是通過 Alice 和 Carol 通過 Bob 進行多跳支付。
中繼者的條件：
- 在可以連接發送方和接收方的支付路徑中
- 指向接受方向的通道內押金大於交易額
在這裏，Bob如果想當Alice和Carol的中繼，那麼他在與Carol的“微信”通道上必須有大於Alice和Carol交易額的押金額。這是因爲，爲了防止中繼不誠實，閃電網絡中採用中繼“墊付”的方式來進行多跳交易。 （在這裏，Carol 就和 Alice 約定一個“謎題”，如果 Alice 從 Bob 哪裏收到的 “答案”能夠解開“謎題”，就說明 Bob 真正的把資金給了 Carol）步驟如下：
- Alice 把“謎題”和轉賬信息給了 Bob。
- Bob 和 Carol 進行協商轉賬，如果 Carol 把“答案”告訴 Bob，Bob 就把錢給 Carol 轉過去。
- Alice 和 Bob 進行了同樣的協商轉賬，如果 Bob 把“答案”告訴 Alice，Alice 就把錢給 Bob 轉過去。
可以看出，在這個過程中，Bob是先進行了墊付才收到的Alice的轉賬，這就避免了Bob收了Alice的錢而不轉給Carol的作弊行爲。
爲什麼閃電網絡支持的是高頻小額交易？
原因就在於其“墊付”機制和資金預存機制。
多跳支付過程中，中繼先墊付了資金，然後才收到發送方的轉賬，也就是說，發送方要給接收方轉賬，要動用整條價值傳輸鏈路上的資金。在只有一箇中間人 Bob 的時候，Alice 和 Bob 的資金都被動用了。如果有 10 箇中間人，那麼動用的資金量就是 Alice 直接支付給 Carol 的 11 倍。
另外，預存到通道中的資金數額直接決定了它可以進行的交易上限。因此閃電網絡只支持高頻小額交易而不支持大額交易，大額交易需要在支付通道中預存的保證金更大。
多人通道=>支付網絡
既然多人之間可以建立狀態通道，那麼推廣開來，在更多人之間就可以建立起一個支付網絡來。現在閃電網絡也已上線。下圖就是閃電網絡主網，它有 2934 個參與者，參與者之間建立 8041 個一對一的支付通道。目前上面的流通資金量還是非常少的，只有 81 個比特幣。
其實從圖中可以看出，還是有幾個比較大的中心化節點的。
閃電網絡總結
優點：
- 擴展性的提高
- 交易時間的縮短
- 沒有鏈上交易費用
缺點：
- 中繼問題
有償中繼。 - 抵押問題
交易雙方在這個微通道中必須先預存一定數量的保證金，由區塊鏈產生的智能合約（資金分配方案）進行監督評判，這使得大量流動資金滯留在通道中。
通道之內允許交易的金額上限（與存入“多重簽名地址”的資金金額強相關）：閃電網絡的通道里允許交易的金額上限和存入“多重簽名地址”的資金金額是強相關的。 A轉賬給B，然後B轉賬給C，假設B之前的餘額是0，那麼A無論給B轉多少幣，B也無法發給C。因爲B必須和C重新建立支付通道，即必須重新抵押大於交易金額的幣。另外，如果在一個通道里只抵押了1 BTC，是沒辦法參與到“高達”1.1BTC的多跳支付場景的。
保證金鎖定在通道中：除此之外，抵押的金額在狀態通道關閉之前，是一直處於鎖定狀態的。那麼到底A要分配多少給B，B又分配多少給C呢？這就涉及到是預分配的問題了，事先很難確定用量。另外，抵押金額是鎖定的，你不僅僅不可以提幣，也不可以充值。假設你On-Chain錢包裏有很多幣，但是狀態通道里的幣用完了以後，你也需要先關閉通道再重新開；假設你On-Chain錢包裏沒有足夠的幣，你也必須等待狀態通道關閉後才能拿出抵押的部分。 - 在線問題
A在申請關閉支付通道時，如果B不在線，協議就只能要求A在申請關閉支付通道後，允許B先轉出餘額，然後A再轉。這個過程是設置了超時機制的，在這個機制下，假設B突然發生不幸，就無法先轉出餘額，那麼這也意味着A永遠都無法轉出自己的那部分餘額了。 - 中心化問題（在閃電網絡中也不是個問題）
微支付通道有向中心化中介演變的傾向。即，將來變成若干個大型的中介通道（比如某大機構可以鎖入更多的資金到閃電網絡中，由此提供充沛的流動性，那麼大家就都會紛紛和他建立起通道來，這個機構就變成了一箇中心化的樞紐）。但大家要明白，首先絕對的去中心化未必可取，其次，這種方案的交易雙方並不需要信任中介、不需要到中介處存錢，其資金安全受到比特幣區塊鏈的充分保護。這種優勢是傳統中心化中介所不具備的。
Example 2：Liquidity network
Liquidity拋棄了雙人通道的概念，轉而直接引入了多人間鏈下交易的樞紐（N-party Hub），而且多個樞紐間可以互聯組成整個網絡。
Liquidity.Network的強大之處在於：
- 可以是多方交易通道，也可以是雙向交易通道；
- 交易通道中的發送和接收都無需中繼（基於Hub網絡結構，路徑在Hub層發揮的作用主要是實現去中心化和信息冗餘方面的高效互連。A直接發給C就行了，不需要B中轉）；
- 沒有閃電網絡類似的在線要求；
- 狀態通道的抵押金額鎖定，縮小了4464倍。
樞紐：
樞紐不再是個封閉的兩人世界，而像一個開放的信用合作社，任何人都可以加入某個特定的樞紐。樞紐的概念也有點像交易所，一個去中心化的交易所，平時都在交易所中進行交易，每個交易之間也會通過特殊的通道進行連接，組成一個全球的交易網絡。但是與交易所不同的是，樞紐並沒有一箇中心化的機構掌握金錢，並且支付行爲是在鏈下發送的，而不是在鏈上進行的。
樞紐減少路由的壓力（假設大部分樞紐都含有成百上千個用戶可以自給自足）。而且樞紐之間也可以互聯，如果同一個用戶同時加入了連接成環的多個樞紐，那麼抵押進這些樞紐的金額可以在彼此之間動態調整。這個想法是從創始人早先的一個研究成果Revive引申而來的。REVIVE是運用在傳統的雙人支付通道中的一個押金再平衡的協議，使用了線性規劃做優化計算。比如下圖裏是一個最簡單的例子，三個人ABC每人都擁有100錢，通過雙向支付通道形成了一個環，但是通道內的金額分配非常不平衡:
AC之間，AB之間和BC之間各自擁有了一條通道。在AC通道里，當前A賬面上有100，C啥都沒有，而AB通道里，A啥都沒有，但是B有100。如果這時候A要再給B轉50，或者有個多跳支付交易希望通過AB通道來走（比如畫面外的一個付款人付給A以50，A付給B以50，B再付給畫面外的最終收款人50），這裏一個比較容易想到的思路就是：把AC通道中屬於A的100裏50通過“動態調整”放到AB通道里給A使用。
動態調整流程如下：
隨機在ABC中選取一個領導者來引導這個再平衡的過程，期間三個通道需要全部凍結，通過每個人的偏好和當前的需要構建出一系列的鏈下支付交易，交給所有人簽字，都通過後，就強制原子性交易執行。比如在上面這個例子裏，再平衡的結果可以是讓A轉給C以50，C轉給B以50，B再轉給A以50。這個時候ABC每個人依舊每人擁有100錢，誰也沒多誰也沒少，不過在每個通道內的所有賬本上都有50了。
關於鎖定金額4464倍的解釋：
整個網絡內需要鎖定的資金可以只是最近十分鐘內的平均交易額度，而不是所有交易金額加起來的總和。舉個例子，假設100個用戶之間會發生各式各樣的支付交易，月平均交易量達100BTC：對於閃電網絡來說，那麼參與其中的每個人都要押入100BTC，總共需要將一萬個BTC鎖定到閃電網絡中。同樣情況下，對Liquidity來說，將時間縮短到十分鐘，那麼平均交易量也就縮小了4464倍（4464 = 31天 * 24小時 * 60分鐘 / 10分鐘，話說官方還是有點“小無恥”的，白皮書裏也是直接算一個月31了，畢竟這樣數據最好看），於是所需要的抵押總額也就縮小了4464倍（其實看下去就會發現押金什麼的感覺已經不重要了）。
Example 3：Celer network
CelerNetwork的分層技術架構：
受互聯網非常成功的分層抽象原則的啓發，我們將Celer Network設計爲一個的簡潔的分層架構，將複雜的離線操作網絡分解爲分層模塊。這種架構大大降低了系統設計，開發和維護的複雜性，並且能夠快速演變爲每個單獨的組件。我們將每層接口的集體規範稱爲cStack（分層結構，清晰的界面。減少系統設計，開發和維護的複雜性。使每個組件的快速演變成爲可能。），包括以下部件構造：
cChannel：廣義狀態通道和側鏈套件。在網絡通道上支持通用依賴DAG的快速狀態轉換。靈活的結構最大限度地提高流動性利用率。
cRoute：具有透明通道平衡的可證明最佳狀態（例如，小額支付）路由。 與最先進的解決方案相比，吞吐量提高了15倍。
cOS：支持離線功能的應用程序的開發框架。提供通用的設計模式，並處理脫鏈狀態的操作，存儲，跟蹤和非鏈狀態的爭議。
cApps：在Celer Network上運行應用程序生態系統。通過區塊鏈系統保證信任，隱私或權力下放，從而擴展到每秒數十億次交易。
在Celer Network中，最終用戶通過cChannel連接到Celer節點的去中心化且無信任的網絡，實現廣義狀態信道功能。在Celer節點中，cRoute用於在最終用戶之間優化和無信任地路由廣義狀態（例如，有條件支付）。對於用戶來說，連接到Celer Network就像連接到互聯網，在那裏你可以與谷歌，Facebook或任何其他互動。一旦連接到Celer Network，基於cOS的所有cApp將可供用戶安裝並以大規模和低成本使用。Celer Network目前具有較高人性化設計，高度可擴展和低成本的優點。
Reference
https://www.jianshu.com/p/b75a6ee8c7cf
https://www.jianshu.com/p/4f0d0d1c6749
</div>
