閃電網路的技術原理
“If a tree falls in the forest and no one is around tohear it, does it make a sound?”這句引言來自於18世紀哲學家George Berkeley，也是Joseph Poon和Thaddeus Dryja在2015年提出的“閃電網路(Lightning Network)”的理念根源。就像無人聽聞的隕落無足輕重一樣，日常重複的交易也不必人盡皆知。
對於比特幣網路來說，交易雙方如果有多次交易，大可不必將每次的交易都同步到網路的每個節點。只需將多次交易後，交易雙方最終的資金分配狀態上報給比特幣網路，既可以保證資金狀態的最終正確性，也可以縮減交易雙方在低效的位元網路上的等待時間提升交易頻次，還可以降低對比特幣網路的計算及儲存資源的消耗。可以說同時解決了比特幣網路高延時、低吞吐的問題，打破了困擾比特幣多年的效能瓶頸，也為降低交易儲存量提供了極好的方案。
本小節將探討“閃電網路”這個看似“完美”的解決方案的技術原理。閃電網路是基於微支付通道演化而來，將其單向支付通道擴充套件為雙向支付通道，並透過RSMC(Revocable Sequence Maturity Contract，序列到期可撤銷合約)解決雙向通道中歷史合約作廢的問題，透過HTLC(Hashed Time Lock Contract，雜湊時間鎖定合約)解決跨節點交易的問題，最終形成了一張比特幣鏈下的不依賴可信第三方和可信交易對手的支付網路。
1. 單向支付的微支付通道
微支付通道的提出為交易雙方建立小額的支付通道提供瞭解決方案，其具有高效能低手續費、安全性強、通道內資金單向流動及通道有時限等4個特點：
1.1高效能，低手續費
1)僅需發生2筆與比特幣網路上的通訊(即2次發生在比特幣網路上的交易)。交易雙方僅需在建立和關閉通道時與比特幣網路通訊，第一次通訊建立微支付通道，第二次通訊將在通道內發生的交易的最後結果釋出到比特幣網路上。
2)通道內的資金交易以點對點通訊方式進行。通道內的支付只需交易雙方簽名認可，免去了複雜的網路傳播與驗證，交易速度近實時。且點對點的交易手續費幾乎可以忽略。
2.1.2安全性強
1)交易雙方利用雙簽名賬戶構建支付通道。支付通道內的交易需要有交易雙方的簽名認可否則無法被髮布到主鏈上。
2)付款方在收款方消失的情形下仍能取回餘額，保障付款方權益。如下圖1所示，Alice在簽署存款合約(Fund Contract)將10 BTC存入雙簽名賬戶之前，會要求Bob先簽一份退款合約(Refund Contract)，合約中會確定一個拿回餘額的時間點。在這個例子中退款合約表示在4月30之後，Alice可以將這份合約簽名併發布到比特幣網路上，成功後雙簽名賬戶中的10 BTC將退至Alice的賬戶。如此，Bob無法透過拒絕釋出交易合約阻止Alice拿回通道中的餘額而進行敲詐。
3)付款方無法對已發生的交易抵賴，保障收款方權益。如圖2所示，每次發生新的交易，Alice都會簽署一份餘額重新分配的合約發給Bob。圖中的tx1表示Alice向Bob付款1BTC，tx2表示Alice再向Bob付款3BTC。但如果此時Alice期望透過tx3將10 BTC全部拿回來，抵賴掉之前的兩次付款，是做不到的。因為tx3尚未得到Bob的簽名，無法釋出，而Bob只需忽略tx3，將tx2簽名併發布到比特幣網路上就可以拿到應得的4BTC。同時可以注意到，微支付通道對試圖抵賴者(此處為Alice)沒有懲罰機制，剩餘的6BTC仍將回到Alice的賬戶
1.3通道資金單向流動
微支付通道只適用於Alice向Bob付款的場景，不適用於Alice與Bob互相轉賬的情形。通道在能力上並沒有限制資金的雙向流動，但從資金Bob流向Alice的交易是不可信的交易，即便Bob簽署了一份付款合約傳送給Alice，Bob仍可以將發生該份合約之前的合約簽署釋出，從而抵賴掉這次付款。
1.4通道時限
微支付通道透過時間鎖機制保障了付款方的權益(上文2.1.2小節中提到)，但同時會使通道最長只能保留到時間鎖的到期時間。一旦到達截止時間，即便通道內的金額並沒有完全被支付或者交易雙方仍存在支付需求，通道會被關閉。如果不關閉，上例中，通道中的10個BTC將全部返還給Alice，Bob顯然不會允許這樣的情況發生，其會在截止時刻之前釋出通道中最新的合約並關閉通道。
2. 更進一步的RSMC
為了給交易雙方提供雙向的及更長期的支付通道，閃電網路在微支付通道的基礎上設計了RSMC(Revocable Sequence Maturity Contract，序列到期可撤銷合約)。隨之帶來的是更復雜的簽約機制和防抵賴機制。RSMC中主要涉及了5種交易：
1)存款(fund)：建立通道之初透過“存款”交易將雙方的資金存入雙簽名錢包，將存款交易廣播到比特幣網路就意味著雙方建立了支付通道。但在廣播之前需要先簽署一份“提交”交易，保證對手方消失的情況下仍能取回雙簽名錢包中的資金(上文的微支付通道中透過“退款”交易實現)。
2)提交(commit)：支付通道建立後，交易雙方在通道內進行資金往來時透過“提交”交易來實現。該交易的特徵是一式兩份，每一方都會簽署好交易資訊遞交給對手方。參與者如果想終止支付通道可以將對方署過名的合約簽字並廣播到區塊鏈網路，進行資金分配並關閉支付通道。
3)分配(delivery)：“分配”交易是具體執行資金派送的交易，該交易執行完成後資金將抵達目標賬戶。通常指的是不可撤銷的分配。
4)可撤銷的分配(revocabledelivery)：同樣是資金派送的交易，但該交易的執行可能因為其他交易的執行而被撤回。在RSMC中主要會因為“違約補償”交易的執行而被撤回。
5)違約補償(breachremedy)：RSMC中核心的防抵賴機制，當對手方企圖透過釋出歷史交易而抵賴後續交易時，可以透過釋出“違約補償”交易罰沒對手方的所有資金。
本小節將在Alice與Bob的交易中詳細探討這5種交易如何相互配合實現高效可信的支付通道。
2.1支付通道的建立與交易
1)存款交易與信任問題如圖3所示，是Alice與Bob支付通道的建立與通道內的資金往來的流程。最初，Alice出資2BTC，Bob出資8BTC，雙方簽訂“存款”交易，計劃將錢儲存到二人的雙簽名錢包中。但由於雙簽名錢包中的資金只有在雙方均簽名認可的情況下才能被動用，二人都會擔心，尤其是出資更多的Bob，如果對方消失自己將無法取回錢包中的餘額，甚至對方可能會以不簽名為要挾進行敲詐。因此，在廣播“存款”交易之前，雙方都需要得到能拿回賬戶餘額的保證，這份保證透過一份“提交”交易實現。
2)提交交易與通道建立
如圖3所示，State1的時候，Alice和Bob各會簽署一份提交交易給對方持有。以Alice持有的提交交易C1a為例，該交易輸入為雙方的簽名，此時Bob已經簽名但Alice自己尚未簽名。
該交易的輸出為資金的分配方案的指令碼，該指令碼此時並不會執行生效，只有當Alice簽名並廣播該交易時輸出中的指令碼才會執行。其思想類似於員工與公司簽訂了競業協議，但在簽訂之時協議中的索賠條款並不會被執行，只有當員工違反條款觸發競業時，公司才會起訴員工並執行索賠條款的內容。
輸出指令碼的能力包含，1.將8BTC歸屬給Bob；2.剩餘2BTC分兩種情況處理，如果使用Alice的鑰匙取款，則在等待100個區塊後2BTC才能歸屬給Alice，如果使用AliceR1(這把鑰匙將在下文中介紹)和Bob的鑰匙共同取款，則2BTC會立即歸屬給Bob。因此，即便對手方Bob消失，Alice也可以透過廣播C1a，在等待100個區塊之後將自己的資金取回。
透過C1a和C1b交易的簽訂，雙方建立了打款的信任基礎，此時存款交易會被廣播到區塊鏈網路，Alice和Bob之間的支付通道就建立了。
3)支付通道內的交易
在支付通道建立之後Alice與Bob的交易就可以在通道內進行，不必廣播到區塊鏈上。每筆交易只需透過簽訂“提交”交易並傳遞給對方即可，在交易雙方均線上的情況下可以實時完成，對比區塊鏈上10分鐘的等待是一個質的提升。
如圖3所示，State2時Alice與Bob開始了新一輪的交易，透過互換籤字後的“提交”交易C2a和C2b，Bob向Alice付款4BTC。值得注意的是，在Alice與Bob互換合約時，也向對方公佈了自己上一輪交易的撤回金鑰AliceR1和BobR1，用於向對方宣告上一輪持有的“提交”交易C1a、C1b作廢，資金的分配以State 2的“提交”交易C2a、C2b為準。
Alice與Bob可以按照此規則在支付通道內進行資金往來，不同於微支付通道的是此處沒有時間鎖，因此通道理論上可以永遠存在，直到交易的一方主動關閉支付通道。
2.2支付通道的正常關閉
當Alice或者Bob認為二者的資金交易結束或者想要取回雙簽名錢包中的資金時，可以將最新的“提交”交易在區塊鏈上廣播進行資金分配。
如圖4所示，以Alice為例，她可以將C2a廣播，C2a中的輸出指令碼將會執行觸發D2a“分配”交易。分配時，Bob會立即取回4BTC，但Alice還需等待100個區塊的時間才能取回6BTC。這是RSMC對率先提出結束交易一方的“懲罰”。
“分配”交易執行結束後，Alice和Bob關閉了交易通道並在比特幣網路上登記了自己的最終資金狀態。
2.3RSMC中的抵賴與違約補償
由於基於RSMC建立的支付通道並沒有在物理上作廢歷史狀態的交易，理論上，參與者仍可以透過廣播歷史交易來抵賴後續的付款交易。但RSMC巧妙設計了懲罰機制阻止此種情形發生。
如圖5所示，假設Bob企圖透過釋出State1 的C1b來抵賴State2發生的付款交易並關閉支付通道，D1b將會被觸發執行，Alice在State1中的餘額2BTC將立即被分配到Alice的賬戶中。剩下的8BTC將透過RD1b“可撤回分配”交易，在C1b釋出後100個區塊分配到Bob的賬戶中。但100個區塊的產生是很長的一段時間，如果Alice在此期間發現了Bob的抵賴行為，可以拿著Bob給她的BobR1撤回鑰匙廣播BR1b“違約補償”交易，將雙簽名電子錢包中剩餘的8BTC全部拿走，同時使RD1b交易失效。被抵賴者既拿回了自己的資金，也透過罰沒錢包中所有資金的方式懲罰了抵賴者。由此消除了支付通道內交易的對手風險。
值得一提的是，2019年瞭望塔機制已經開始逐步應用到閃電網路的節點中，即便使用者處於離線狀態，也可委託瞭望塔為其監控資金是否遭到竊取，一旦遭到竊取，瞭望塔會代替使用者廣播“違約補償”交易。使用者不再需要隔一段時間就上線檢查對手是否作弊，大大降低了使用者對閃電網路的使用成本。關於瞭望塔會在本文的5.1小節做更深入的探討。
3. 編織網路的HTLC
RSMC在微支付通道的基礎上為使用者兩兩之間的資金交易提供了長期、高效的解決方案。但如果每兩個使用者需要交易時都需要建立新的支付通道，將會大幅增加網路中的連線數，每個通道的建立也都需要比特幣網路的處理(必然就涉及了等待和交易費用)，這並不經濟。HTLC(Hashed Time Lock Contract，雜湊時間鎖定合約)提供了借用網路中已經建立的連線，使未直連的使用者能夠進行可信的資金交易的解決方案。只要網路中有一條路徑能連線交易雙方就可以進行可信交易，大幅提升了網路的擴充套件性。
3.1多方參與問題
如圖6在沒有HTLC的情況下，如果未建立支付通道的Alice想向Carol轉賬1BTC，就需要與二人都建立過支付通道的Bob的幫助。Alice先將1BTC轉給Bob，Bob再將其轉給Carol。這需要一個可信的Bob才能保證支付順利完成，因為Bob可能會將這1BTC中飽私囊。即便Bob可信，這種交易方式也違背了比特幣的初衷——透過分散式賬本避免依賴可信的第三方。
3.2HTLC的處理流程
HTLC透過巧妙利用雜湊時間鎖保證了中間的路由節點無法扣留路過的資金，也不需要依賴可信的第三方來做擔保。如圖7所示為HTLC的處理流程。
交易的發起。當Alice要向Carol付款1BTC，正式發起交易之前，Carol會先自己準備好一個R，然後對其雜湊加密生成H(注意無法透過H反推出R)，即H=Hash(R)，並將這個H傳輸給Alice。
正向傳遞H建立HTLC。Alice拿到H後，會將H傳送給Bob，並向Bob發起HTLC的轉賬交易。如果Bob能在15:00(僅是一個示例時間)之前告訴AliceH對應的R是多少，Bob就可以拿到1BTC，否則，Alice可以拿回1BTC。Bob在與Alice簽訂HTLC合約並拿到H之後，會對Carol進行相同的操作，簽訂合約並傳遞H，同時設立一個更早的截止時間14:00。
反向傳遞R清除HTLC。Carol拿到H後發現與自己持有的H相同，於是將R匹配到HTLC中拿到1BTC，並告知BobR。同理，Bob可以憑藉R拿到Alice的1BTC同時結束與Alice的HTLC。整個交易結束。
這個過程中，路由節點Bob要透過R才能拿到Alice的1BTC，但為了拿到R，他不得不先向Carol交出1BTC，無法中飽私囊，由此解決了中間節點作惡的問題。
值得注意的是，鏈路上的鎖定時間必須是遞減的，假設Alice和Bob約定的截止時間是15:00而Bob與Carol的約定時間是16:00，則Carol可以在15:30時透過R拿走Bob的1BTC，而Alice的1BTC已經在15:00時取回了，Bob就會遭受損失。但由於Bob和Carol交易的截止時間是由Bob定的，所以Bob自身透過合理安排時間可以避免這種情況的發生。
同時，RSMC和HTLC可以在同一個“提交”交易中擬定的，具體形式如圖8所示。
3.3路由與手續費
讀到這裡讀者心中可能會有疑問，Alice如何知道Bob可以連線到Carol，而Bob又為什麼要幫助Alice向Carol轉賬呢？這就涉及到HTLC的路由機制與費用機制了。
路由
針對路由，HTLC使用了源路由與洋蔥路由的機制。網路上所有的節點會發布自己路由資訊和資金限制形成支付通道表。交易的源頭(發起方)透過該表計算起點到終點的路徑並指定交易透過該路徑執行。同時，利用洋蔥路由的機制，使得每一個路由節點都只知道相鄰的節點，無法瞭解整條路徑，由此達到保護隱私的目的。這兩種機制均是已有的路由機制，被應用到了閃電網路的構建中。
手續費
實際上，作為中間節點的Bob可以標明他路由的手續費，如0.01 BTC，那麼Alice在向Carol轉賬1 BTC的交易中，會在與Bob簽訂交易時向其支付1.01 BTC，而Bob向Carol支付1 BTC，達到了手續費收取的效果。如果Bob是一個天價手續費收取者，Alice在計算路由方案時就會將Bob排除在外，選取別的路由節點。
4. 閃電網路
由此，RSMC與HTLC互為助力，RSMC解決資金單向流動的問題，HTLC解決多方參與的問題，在比特幣二層鏈下形成了高擴充套件性的支付通道——閃電網路。
