閃電網絡屬於狀態通道技術範疇，是區塊鏈技術的一個發展方向之一，其核心思想是將本來在鏈上結算的交易在鏈下通過狀態通道維護中間態，並且在發生糾紛時回到鏈上仲裁。鏈上仲裁的公平性和安全性在博弈論上保證了鏈下交易的對手不會作惡。通過這種方式實現擴容。下面是閃電網絡技術概要。
一、閃電網絡——幣鏈下擴容方案
【1】當前比特幣網絡的問題？
我們都知道比特幣系統的交易吞吐量是非常之低的，爲了解決比特幣系統交易吞吐量低的問題，閃電網絡被提出，它並不是通過增加區塊大小等鏈上擴容方案，而是一種通過離線交易形式的鏈下擴容方案。
【2】閃電網絡解決問題的思路——針對微支付場景
要提升比特幣系統的交易吞吐量，直接在鏈上廣播大量的交易是不可行的，吞吐量是有限的，解決的辦法是壓縮交易。在微支付應用場景下，如果交易雙方之間會進行大量的微支付交易，那麼將所有這些微支付交易都上鍊是沒有絕對必要的，那些中間狀態其實可以不用上鍊，只要最終所有的微支付交易的最終狀態上鍊就可以了，因爲即使所有微支付交易上鍊，最後的狀態也還是最終狀態。所以，在鏈下，記錄大量的微支付交易狀態信息，而在鏈上，只對創建狀態及最終狀態上鍊。將大量的微支付交易壓縮爲少量鏈上交易。這樣就大大提升了交易吞吐量。簡要概括就是：將大量交易放到比特幣區塊鏈之外進行，只把關鍵環節放到鏈上進行確認。
【3】支付通道
具體的是通過支付通道完成大量微支付交易。在支付通道打開後，參與方可離線發送任何數量的交易，無需廣播到比特幣的網絡上。除了最開始創建支付通道（funding交易）和關閉支付通道是需要廣播上鍊，其中間的交易過程是由一系列交易記錄構成。創建支付通道類似於雙發各自建立一個賬本用來記錄雙發的交易記錄，當不想再與對方交易時，可以關閉通道，根據賬本中的交易記錄進行最終結算，上鍊。
【4】支付通道組網
閃電網絡中需要交易雙發建立支付通道，但每次與不同的人進行交易都要新建立支付通道是很低效的（佔用你大量的資金成本+時間成本）。例如A->C進行交易，可以是雙發直接創立新的支付通道（A->C），但如果A->B，B->C已建立通道，此時可以通過A->B->C的方式進行交易。即，可以用已有的通道進行交易。
這樣，隨着新創立的支付通道越來越多，最終，所有的支付通道會形成一個巨大的網絡，此時，只要你有一條與有這個巨大網絡的支付通道，你就可以通過這個巨大的網絡與任何人通過支付通道進行交易。
爲了維護這個巨大的通道網絡，需要激勵人們貢獻自己的支付通道，就像礦工可以獲取手續費一樣，如果有人用了你的支付通道，你可以收取一定的費用。當然，你也可以把費用設爲負值，即使如果有人使用你的支付通道，你可以給他一筆錢。
到這裏，閃電網絡就形成了。
二、閃電網絡主要工作機制
閃電網絡怎麼保證鏈下可信交易？主要依靠RSMC和HTLC，RSMC保障了兩個人之間的直接交易可以在鏈下完成，HTLC保障了任意兩個人之間的轉賬都可以通過一條支付通道來完成。閃電網絡整合這兩種機制，就可以實現任意兩個人之間的交易都在鏈下完成了。
【1】RSMC
Recoverable Sequence Maturity Contract，序列到期可撤銷合約。其主要原理類似資金池機制。
首先假定交易雙方之間存在一個“微支付通道”（資金池）。交易雙方先預存一部分資金到“微支付通道”裏，初始情況下雙方的分配方案等於預存的金額。每次發生交易（不能超過預存金額），需要對交易後產生資金分配結果共同進行確認，同時簽字把舊版本的分配方案作廢掉。 任何一方需要提現時，可以將他手裏雙方簽署過的交易結果寫到區塊鏈網絡中，從而被確認。從這個過程中可以看到，只有在提現時候才需要通過區塊鏈。
任何一個版本的方案都需要經過雙方的簽名認證才合法。任何一方在任何時候都可以提出提現，提現時需要提供一個雙方都簽名過的資金分配方案（意味着肯定是某次交易後的結果，被雙方確認過，但未必是最新的結果）。在一定時間內，如果另外一方拿出證明表明這個方案其實之前被作廢了（非最新的交易結果），則資金罰沒給質疑方；否則按照提出方的結果進行分配。罰沒機制可以確保了沒人會故意拿一箇舊的交易結果來提現。
另外，即使雙方都確認了某次提現，首先提出提現一方的資金到賬時間要晚於對方，這就鼓勵大家儘量都在鏈外完成交易。通過RSMC，可以實現大量中間交易發生在鏈外。
相關交易：funding transaction, commitment transaction, closing transaction, penalty transaction
【2】HTLC
Hashed Time Lock Contract，哈希時間鎖合約。這個類似限時轉賬，通過智能合約，雙方約定轉賬方先凍結一筆錢（發送比特幣到一個多重簽名地址），並由最終接收方生成的一個密碼R的哈希值H(R)加鎖，如果在一定時間內接收方知曉了密碼R，使得它哈希值H(R)跟已知值匹配（實際上意味着轉賬方授權了接收方來提現），則這筆錢轉給接收方。如果約定時間內，接收方未知曉密碼R，則轉賬方可取回已凍結資金。主要由2部分構成：
- 哈希值鎖定，確保了只有知曉最終接收方生成的密碼
R纔可以解鎖（即確保最終接收方已經拿到比特幣後，中間節點纔可以解鎖去幣，在最終接收方拿到比特幣前，中間節點是無法知曉密碼R的）。 - 時間鎖定，即確保了轉賬方在一定時間內（最終接收方解鎖取走比特幣前）無法取走，又能保證在一段時間後如果最終接收方沒有取走比特幣的情況下，轉賬方可以拿回自己的比特幣。
![在這裏插入圖片描述]()
舉個例子：A經過B向C轉賬1個比特幣，過程如下：
- C隨機生成一個密碼
R，計算哈希值H(R)，發給A； - A用哈希值
H(R)創建和B的HTLC合約：A轉1比特幣給一個多重簽名地址Q，如果B能在2天內知曉密碼R，解鎖Q，取到A支付的1個比特幣；如果2天內，B沒有R，2天后Q解鎖，A取回自己支付的1個比特幣。 - B用哈希值
H(R)創建和C的HTLC合約：B轉1比特幣給一個多重簽名地址，如果C能在1天內知道密碼R，則解鎖，取到B支付的1個比特幣；如果1天內，C無法知曉密碼R，1天后解鎖，B取回自己支付的1個比特幣。 - 密碼
R是C生成的，它自然知曉密碼R，所以C能在1天內，解鎖B的HTLC，取到B支付的1個比特幣。在這個過程中，B也看到了密碼R。 - 在C解鎖B後，B知曉了密碼
R，依此B解鎖A，取到A支付的1個比特幣。 - 至此，A給了B一個比特幣，B給了C一個比特幣，等同於A給了C一個比特幣，轉賬完成。
三、閃電網絡——路由部分
如果交易的雙發都加入了這個支付通道網絡，你就可以通過這個支付通道網絡與任何加入閃電網絡的交易方進行交易。具體的，在確定了你的交易接收方後，你需要選擇中間節點構建一條發起者到接收者的路由去完成交易。如何建立這條路徑呢？
【1】節點及通道發現
僅僅知道當前有哪些節點，本節點連接了哪些節點，這些信息是不夠的。你需要知道當前網絡拓撲以及各個支付通道的費用、離線餘額等更多信息，才能選擇一條滿足要求的最佳路徑。這就需要一個實現一個協議來同步全網的網絡拓撲以及支付通道的費用、離線餘額等信息。這裏使用Gossip協議對這些信息進行同步。
主要同步節點和通道信息：
- 同步通道信息，使得我們維護一個全網通道網絡拓撲，以進行路由選擇。
- 同步節點信息，使得節點間建立連接以及建立支付通道。
相關消息：channel_announcement、node_announcement、channel_update等
【2】路由算法選擇最佳路徑
有了上面這些信息，我們就能設計路由算法來建立這條路徑。前面提到，進行交易時它們需要先建立一個通道，中間會經過若干支付通道，會有很多路由選擇，不同的通道交易費用不同，同時有些通道可能不滿足要求（額度太小），考慮到經過太多的支付通道也是不好的，最好有路由跳數的限制，即，選擇一條經過有限跳數的的費用最低的一條路徑。綜上，這個路由算法歸結爲一個在有限跳數(閃電網絡設爲20)條件下，帶有（負）權值的單源最短路徑問題（這裏路徑中權值指的是費用，費用可能爲正，也可能爲負）。
解決這個問題的路由算法就是：Bellman-Ford-Gibson
/* Bellman-Ford-Gibson: like Bellman-Ford, but keep values for every path length. */
構建通道時，滿足條件的路由沒有找到怎麼辦？與對方新創建直接支付通道。
【3】 （補充）閃電網絡規模巨大時的路由方案——Flare
Flare，一種用於閃電網絡支付路由的混合路由算法。是一種兩階段(proactive and reactive )算法：
(1) 主動更新節點的路由圖，存儲有關網絡拓撲的信息；
(2) 根據閃電網絡請求的需要，按需被動收集信息。
考慮閃電網絡的節點規模，閃電網絡相互連接的節點可能會達到數以百萬計。此時現有的路由方案可能無法滿足要求。可採用Flare路由方案。
該路由算法借鑑了MANET（移動自組織網絡）路由算法的思路。
【4】 洋蔥路由
經過前面的路由算法確定了一條路徑。發送數據時需要一跳一跳的（origin node --> hop --> ... --> hop --> final node）經過中間節點最終到達目的節點。如何確保數據的安全性及滿足一定程度的匿名隱私保護要求？例如，發送的數據只有最終目的節點可以看到，中間節點無法知道數據。
爲了滿足上面要求，閃電網絡的“路由部分”的一個重要特性是匿名網絡路徑。只有發起節點知道完整路線，其他節點只知道上一跳和下一跳節點。具體實現是通過Sphinx方案的洋蔥路由協議。
在洋蔥路由的網絡中，消息一層一層的加密包裝成像洋蔥一樣的數據包，每經過一個節點會將數據包的最外層解密，直至目的地時將最後一層解密，目的地因而能獲得原始消息。而因爲透過這一系列的加密包裝，每一個網絡節點（包含目的地）都只能知道上一個節點的位置，但無法知道整個發送路徑以及原發送者的地址。
參考文檔：
The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments
Lightning Network Specifications
Bellman–Ford algorithm
Routing, Dijkstra, Bellman-Ford and BFG!
Flare: An Approach to Routing
in Lightning Network
Tor: The Second-Generation Onion Router
Sphinx: A Compact and Provably Secure Mix Format
什麼是多重簽名錢包？
移動自組織網絡路由協議簡介
Scaling Bitcoin workshop : Milan 2016 Onion routing in lightning
洋蔥路由
洋蔥路由的起點 — Hiding Routing Information
精通比特幣
如何在CKB上實現閃電網絡