Hello Lightning Network -0

• 2019 年 12 月 30 日
• 筆記

有許多比特幣社區的先行者們面對小白的提問時，總是真誠的說：「去看看比特幣的白皮書吧，把它真正弄明白吧，你就會理解一切的。」 —–如今，我想對許多質疑閃電網路的比特幣先驅們說：「去看看閃電網路的白皮書吧，把它真正弄明白吧，你就會理解一切的。」

閃電網路是次世代的支付技術，它不僅僅是一個支付技術，更是建立在比特幣主網上的二層網路協議，將來會有許許多多新奇的應用建立在上面，它會為比特幣開啟下一個十年；

但是閃電網路還在實現的早期階段，能耐心去讀懂它的白皮書的人已經非常少了，更不用提現在飛速發展的BOLT規範了；這其實跟比特幣剛誕生時是一樣的，在動輒就大談「區塊鏈技術改變未來」的那一群人中，有幾人會真正花時間，去把已經發表11年的比特幣8頁白皮書弄個明白呢？

閃電網路的基本原理其實非常簡單，在我們之前的文章中已經花費了大量篇幅去介紹；但是在實現過程中，還有數不清的工程細節上的權衡；由於現在的實現還只是一個雛形，我們實操閃電網路交易的時候會有各種各樣的「？」，我打算寫一個系列文章，把一些有趣或者讓人困惑的地方抽絲剝繭，記錄一下自己的學習過程，也把這項迷人的技術介紹給更多人。

我們將在這篇文章中對閃電網路做一個概覽，並介紹如何用lnd建立一個閃電節點，來完成一筆閃電交易。

比特幣的交易網路最為人詬病的一點便是交易性能：全網每秒 7 筆左右的交易速度，遠低於傳統的金融交易系統；同時，等待 6 個塊的可信確認將導致約 1 個小時的最終確認時間。

為了提升性能，社區提出了閃電網路等創新的設計。

閃電網路的主要思路十分簡單——將大量交易放到比特幣區塊鏈之外進行，只把關鍵環節放到鏈上進行確認。該設計最早於 2015 年 2 月在論文《The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments》中提出。

閃電網路需要單獨部署，沒有包含在bitcoin core實現裡面。閃電網路是一個開放的協議，任何人都能自由的實現它，目前比較流行的版本有:

https://github.com/lightningnetwork/

https://github.com/mit-dci/lit

https://github.com/ElementsProject/lightning

讓我們先自己思考一下，A和B之間頻繁有多次交易，最自然，最直接的建立鏈下交易的辦法是什麼？

一個假想的場景，就是在沒有網路，沒有通訊的環境中，兩個人面對面各自手持私鑰簽名，證明自己的賬戶上有多少資金，然後簽訂一份合約，每次交易記錄簽名之後不廣播，只寫在合約上面，等到大批交易做完之後，再統一軋賬清算；如果中間有人耍賴，就拿著寫滿簽名交易的合約去法院仲裁。這個過程中間他們唯一的資訊渠道就是有人單向傳真給他們每筆交易的資金變動；

當然這是一種異想天開，而且依賴於中心化的法院裁決的方式，在現實世界中是行不通的；但是我們可以將這個方案作為起點，代入到電子化的解決方案裡面：

1. 首先，兩個人面對面，一是為了通過驗證簽名檢查賬戶資金，二是防止第三者竊聽；映射到電子方案中，就是通過兩個人建立一個加密的通訊信道來傳遞資訊
2. 另外，兩個人的每一筆交易列印到合約上，就是為了防止某一方作假詐騙，而且兩個人面對面互相監督，就防止有一方私自廣播對方的交易然後閃人，但是放到網路中，沒有法官裁決的威懾，沒有相互監督，怎麼才能信任對方最終一定會根據所有的歷史交易來清算呢？

第一個問題的解決方案稱之 HTLC（Hashed Timelock Contract），解決了支付通道(資金池)的問題；

第二個問題的解決方案稱之為RSMC (Recoverable Sequence Maturity Contract)，解決了鏈下交易的確認問題。

RSMC

概述

Recoverable Sequence Maturity Contract，即「可撤銷的順序成熟度合約」。這個詞很繞，其實主要原理很簡單，類似資金池機制。

再想一下我們之前的問題，為什麼A和B每次交易都要記在合約上，最後一把清算呢？既然是雙方賬戶的加加減減，為什麼不是每發生一筆新交易，立即對交易後產生資金分配結果共同進行確認，然後作廢之前一筆交易呢？

Yes! 這樣做之後，在雙方的資金池通道中，不管之前雙方進行了多少筆交易，永遠只存在一筆清算交易，這筆交易就是當前的軋賬結果，不管什麼時候，直接廣播這筆交易，對雙方都是公平的。

那麼，該如何防止一方做了一筆付款之後，沒有廣播，就搶先把資金池裡面的自有資金提現呢？

1. A和B各拿出1BTC放入了資金池通道中，這時候資金池裡面共有2BTC
2. A和B發生了數筆交易之後，A與B的資金變為1.5:0.5BTC，這個時候通道中留著一筆清算交易沒有廣播，但是任何一方都可以直接廣播把這個狀態做實
3. 這個時候A又向B發送了1BTC，但是在B廣播清算交易之前，A要把資金全部提走，也就是1.5BTC；這樣B就損失了1BTC，怎麼預防這種情況呢？

解決方法就是提現一定要雙方都簽名承認才可以：任何一方在任何時候都可以提出提現，提現時需要提供一個雙方都簽名過的資金分配方案（意味著肯定是某次交易後的結果，被雙方確認過，但未必是最新的結果）。在上面的那種情況下，B是無論如何也不會同意的。這就阻止了A的提現。

另外，為了威懾A這種行為，在一定時間內，如果另外一方拿出證明表明這個方案其實之前被作廢了（非最新的交易結果），則資金罰沒給質疑方；否則按照提出方的結果進行分配。罰沒機制可以確保了沒人會故意拿一個舊的交易結果來提現。

最後，即使雙方都確認了某次提現，首先提出提現一方的資金到賬時間要晚於對方，這就鼓勵大家盡量都在鏈外完成交易。通過RSMC，可以實現大量中間交易發生在鏈外。

那麼如果有一方耍小心眼，就是損人不利己，死活不簽名來阻止另一方的提現呢？也沒關係，在這個模型中，有了懲罰機制，提現的一方可以直接拿最後一筆清算交易的狀態來廣播(這筆交易是雙方都簽名承認的)，代價就是晚一點得到資金而已。

• 整個過程裡面，最重要的就是懲罰機制的實現，我如何認定跟我交易的對方也遵從這個懲罰機制呢？這是用多重簽名來保證的。因為多重簽名實際上是個合約，所以這個方案被命名為RSMC。

讓我們詳細的描述這個過程

內容引自： http://book.8btc.com/blockchain-credit

RSMC 創建

Alice和Bob是合作方，經常有比特幣往來，所以他們決定各拿出0.5BTC放入通道中，便於業務往來。解釋一下下方RSMC交易的結構，左側為Alice的視角，右側為Bob的視角。中間Funding Tx為共同可見，C1a和RD1a為Alice持有，C1b和RD1b為Bob持有。交易圖中帶有尖括弧的簽名表示待填入。

1. 雙方各拿出0.5BTC，構建Funding Tx，輸出為Alice和Bob的2/2多重簽名。此時， Funding Tx未簽名，更不廣播。
2. Alice構造Commitment Tx：C1a和RD1a，並交給Bob簽名。C1a的第一個輸出為多重簽名地址，Alice的另一把私鑰Alice2和Bob的2/2多重簽名，第二個輸出為Bob 0.5BTC。
3. RD1a為C1a第一個輸出的花費交易，輸出給Alice0.5BTC，但此類型交易帶有sequence，作用是阻止當前交易進塊，只有前向交易有sequence個確認時才能進塊。
4. Bob構造Commitment Tx：C1b和RD1b，並交給Alice簽名。結構與C1a、RD1a是對稱關係。
5. Bob對C1a和RD1a進行簽名，並將簽名給Alice；同理，Alice對C1b和RD1b簽名，完成後給Bob。此時，由於並未對Funding Tx進行簽名，任何一方均無法作惡，任何一方也不會有任何損失。
6. 雙方均完成對commitment Tx的簽名並交換後，各自再對Funding Tx進行簽名，並交換。此時，Funding Tx是完整的交易，廣播之。上述過程以及結構圖的描述，就是創建RSMC的全部過程。

C1a, C1b兩筆交易花費的是同一個輸出，故他們兩個交易只有一個能進塊。若Alice廣播C1a，則Bob立即拿到0.5BTC（C1a的第二個輸出），而Alice需要等C1a得到1000個確認，才能通過RD1a的輸出拿到0.5BTC。另一方，若Bob廣播C1b，則Alice立即拿到0.5BTC，Bob等待C1b得到1000個確認，才能通過RD1b拿到0.5BTC。也就是說，單方廣播交易終止合約的那一方會延遲拿到幣，而另一放則立即拿幣。

這個過程的精巧之處，就在於構造了一個被動機制，將自己的資金放入到一個嵌套多重簽名的地址裡面，任何一方想要提現，一定要先歸還另一個人的資金。並且這個機制構造完成之後，我們才真正在支付通道中充值。

交易更新

Alice和Bob各自0.5BTC的餘額，此時Alice從Bob處購買了一件商品，價格為0.1BTC，那麼餘額應該變為Alice 0.4BTC，Bob 0.6BTC。

於是創建新的Commitment Tx，對於Alice來說是C2a 和RD2a，對於Bob來說是C2b和RD2b，過程與上面類似。

交易更新時的交易結構此時兩個狀態均是有效的，那麼最核心的問題來了，如何才能徹底廢棄掉C1a和C1b呢？

RSMC採用了一個非常巧妙的方法，在C1a的第一個輸出中，採用了Alice2和Bob的多重簽名，Alice將Alice2 的私鑰交給Bob，即表示Alice放棄C1a，承認C2a。

Alice交出Alice2的私鑰給Bob，那麼Bob就可以修改RD1a的輸出給他自己，形成新的交易BR1a。

若Alice破壞合約存在C2a的情況下依然廣播出C1a，那麼Alice的懲罰就是失去她全部的幣。

Alice交出Alice2的私鑰，或者對交易BR1a進行簽名，兩者是等同的，都是對C1a的放棄。反之亦然，Bob交出Bob2的私鑰給Alice即意味放棄C1b，而僅能認可C2b。

引入sequence的目的是，阻止後續交易進塊（RD1a），給出一個實施懲罰窗口期，當發現對方破壞合約時，可以有1000個塊確認的時間去實施懲罰交易，即廣播BR1a代替RD1a。若錯過1000個塊時間窗口，則無法再實施懲罰了（RD1a進塊了）。

交易關閉

關閉RSMC，直接按照最終的餘額構造出一個Commitment TX即可，例如輸出為Alice0.1BTC，Bob0.9BTC，無需再設置多重簽名，構造懲罰交易等。

HTLC 中轉交易

RSMC要求交易的雙方一定要都繳納一筆保證金，我每天都跟不同的商家打交道，不能跟每個人都去建立RSMC，存入一筆資金吧。而且通道的建立和關閉都是需要鏈上廣播的，如果要建立多個支付通道，交易費用也不容小覷，這有點本末倒置了吧。

為了解決這個問題，閃電網路又引入了HTLC ( Hashed Timelock Contract )，中文意思是「哈希的帶時鐘的合約」。這個其實就是限時轉賬。理解起來也很簡單，通過智慧合約，雙方約定轉賬方先凍結一筆錢，並提供一個哈希值，如果在一定時間內有人能提出一個字元串，使得它哈希後的值跟已知值匹配（實際上意味著轉賬方授權了接收方來提現），則這筆錢轉給接收方。

推廣一步，甲想轉賬給丙，丙先發給甲一個哈希值。甲可以先跟乙簽訂一個合約，如果你在一定時間內能告訴我一個暗語，我就給你多少錢。乙於是跑去跟丙簽訂一個合約，如果你告訴我那個暗語，我就給你多少錢。丙於是告訴乙暗語，拿到乙的錢，乙又從甲拿到錢。最終達到結果是甲轉賬給丙。這樣甲和丙之間似乎構成了一條完整的虛擬的「支付通道」。而乙就做了中轉節點。

Alice想要支付0.5BTC給Bob，但她並沒有一個渠道來和他進行交易。幸運的是，她和Charlie有一個交易渠道，而Charlie正好和Bob有一個交易渠道。這樣Alice就能藉助Charlie的交易渠道，通過哈希時間鎖定合約（HTLC）來和Bob進行交易了。

為了完成這次交易，Alice就會給Bob發簡訊說：「嘿！我要給你付筆款。」這時Bob自己將收到一個隨機數字（R），接著Bob便會回一個被哈希的數字（H）（你可以認為被哈希的數字R是隨機數字的一種加密形式）給Alice。

然後Alice的錢包緊接著就會聯繫Charlie說：「嘿，Charlie。如果你給我生成（H）的未加密值（R），那麼我就同意更新我們渠道的支付分配，這樣你就可以得到的就會比0.5BTC多一點，我得的比0.5少一點。」

儘管Charlie並不知道R，但他也會同意。之後Charlie便會去找Bob說：「嘿，Bob。如果你給我那個能生成H的未加密的值R，我將同意更新我們渠道的支付分配，這樣你就可以得到的會比0.5BTC多一點，我得到的比0.5少一點。」因為R就是從Bob這裡生成的，所以他肯定知道。接著他馬上將R告訴Charlie，並更新了其渠道的支付分配。然後Charlie將R告訴給了Alice之後也更新他們的渠道，最後交易完成，Alice以脫鏈的形式付給Bob0.5BTC。

擴展

HTLC給了任意兩個點之間，通過路由轉發達到支付的目標。這樣用戶無需打開過多的通道，只需要存入一筆資金跟一個比較大的中介機構建立通道就好了。之後所有的支付行為，我們都期望這個中介機構能自動路由到商家。

在閃電網路的極大繁榮時間，可以看作是現在互聯網模型的克隆。

優缺點大辯論

關於支付通道建立

• 樂觀： 建立的閃電網路渠道可以與現有錢包和系統內置無縫過程。當收到和支付比特幣時，資金需要存到某個地方。資金可以在收到時立即進入閃電網路的通道中，因此建立該通道不需要額外的步驟或成本。
• 悲觀：為了建立閃電網路渠道，用戶必須手動創建一個新的昂貴的鏈上交易。

關於通道關閉

• 樂觀:可能不需要關閉渠道，用戶可以無限期地或長時間地將錢存放在通道中。
• 悲觀:一旦支付完成，就需要透過手動創建昂貴的在線交易來關閉通道。

關於網路路由

• 樂觀:現有的P2P網路已經需要網路拓撲和消息傳遞，節點通常具有八個連接。閃電網路拓撲結構只是其中的一個延伸。路由不是一個重要的問題，因為即使在大規模網路中，用戶之間路徑的平均步數也是很小的。即使路由有問題，也可以簡單地在鏈上進行支付，而用戶甚至感覺不到兩者的差異。少數大型渠道運營商可以防止路由發生任何問題。
• 悲觀:路由可能是一個較大的問題，因為找到各方之間最短的路徑對於演演算法來說是個難題。如果找不到清晰的路線，則用戶和商戶將不得不通過繁瑣的過程來手動改變並選擇在鏈上交易的過程。

關於支付通道的中心化

• 樂觀:有些經濟獎勵措施是用來對抗這種中心化的，任何人都可以設立節點，因為進入門檻低。除此之外，還可以通過收取較低的費用來削減其他節點對網路的影響力。即使網路集中在幾個大型交易樞紐上，閃電網路仍然提供了一個有用而有趣的系統。比特幣已經有一些像 Coinbase 這樣的大機構來管理大量的資金。在閃電網路下，這些機構沒有資金保管權，只是用來傳遞用於支付的數據。
• 悲觀: 網路將集中圍繞在幾個大型交易樞紐，因為這是最有效的模式。這種集中化增加了系統性渠道失效的風險，即少數大渠道出現故障，導致支付渠道同時大量外流，造成連鎖擁堵，使部分資金在到期前無法退出渠道。

關於流動性

• 樂觀:將有機制激勵用戶運行閃電網路節點，並提供流動性，以收取費用，網路便可以用於小額支付，支付額度可以遠小於最大渠道容量，確保有足夠的流動性。
• 悲觀:支付渠道流動性不足，因此其規模將受到限制。任何較具規模的支付幾乎可以立即消耗掉整個渠道的流動性，癱瘓閃電網路的支付渠道。

關於要求收款人在收款時在線

• 樂觀:雖然收件人必須在線才能收到付款，但這與大多數在線支付系統沒有顯著不同，因為如果收款人不在線上，他們不知道或無法驗證收款。直接收款的用戶或設備也不需要存儲私鑰。例如，商店 PoS 終端或加密 ATM 機可以在收款前通過互聯網從公司的總部確認簽署回收交易，因為無論如何雙方在收款時都需要溝通。
• 悲觀:通過鏈上交易，發件人需要的是收款地址，而收件人不需要在線。與此相反，收款人在接收付款之前需要簽署收回交易。這是一個重大的限制，意味著收件人必須將私鑰暴露在熱錢包中。這使得閃電網路在下列許多情況下便的不切實際，例如在 ATM 上，在商店 PoS 系統上進行大額支付，或者支付給那些難以連上互聯網的收款人。

閃電網路較大的安全風險

• 在收款時必須在線的要求：如上所述，在收款之前，收款人需要簽署收回交易，以便匯款人知道如果渠道不正常的關閉或拒絕簽署的情況發生，他們可以收回資金。因此，收錢需要一個熱錢包，這意味著如果發生安全事件，私鑰可能被暴露。
• 監督渠道的要求：可能需要閃電網路參與者或瞭望塔主動監督網路渠道。這可能給用戶或瞭望塔帶來負擔，並且與存儲在區塊鏈上的比特幣相比，潛在地降低了渠道內的資金安全性。未能適當監督渠道或由在線網路造成的擁塞可能增加用戶錯過了回收交易截止日期的風險。
• 礦工可以審查渠道關閉交易：作為不屬於交易雙方的礦工可以通過審查渠道關閉交易，一旦他們具有 51％ 的哈希率便可能有能力從閃電網路用戶竊取資金。雖然這種類型的攻擊就算在沒有應用閃電網路的情況下已經具有破壞性的後果，但閃電網路的應用可能會提供一個更大的攻擊面。

小結

RSMC 保障了兩個人之間的直接交易可以在鏈下完成，HTLC保障了任意兩個人之間的轉賬都可以通過一條「支付」通道來完成。閃電網路整合這兩種機制，就可以實現任意兩個人之間的交易都在鏈下完成了。

在整個交易中，智慧合約起到了中介的重要角色，而區塊鏈網路則確保最終的交易結果被確認。

閃電網路似乎可以在整體網路交易規模上帶來重大改進。從而導致交易速度提高和交易費用大幅下降，而整體又不會影響核心基礎安全性。然而，至關重要的是，閃電網路自身在安全性上的不足可能使閃電網路不適合用於大額支付（或者至少用其進行大額支付的行為可能是不負責任的）。投機和投資等行為是需要大額支付的，而這些行為目前看來是加密貨幣領域的主要的交易推動力，相比之下，零售小額支付的數量相對較小。

最後附贈一個技術講解比較好但是旗幟鮮明反對閃電網路的影片教程：

當然再為閃電網路聲援一下，閃電網路的思想發源於微支付通道，Satoshi實際上早期對微支付通道已經有了基本的設想：

https://en.bitcoin.it/wiki/Payment_channels

孰對孰錯，是非只能自己判斷。

架設一個閃電網路節點，完成一筆交易

光說不練假把式，增加一把實戰

運行一個bitcoind全節點

我們選用bitcoind運行一個testnet模式的全節點，配置文件如下:

bitcoin.conf:

啟動bitcoind:

建立閃電網路節點

我們採用lightningnetwork這個Go版本的實現(全程需要翻牆)：

https://github.com/lightningnetwork/lnd/blob/master/docs/INSTALL.md

• 安裝go環境

• 設置環境變數

• Clone && 編譯

• 啟動lnd

建立一個新錢包，充值

之後按照提示一路回車下去，建立一個新錢包，然後執行下列命令得到一個新地址

• 去下面這幾個網址列表領取一些免費的TestNet Bitcoin:

https://lnroute.com/testnet-faucets/

• 執行下面命令看看餘額

連接通道

• 首先執行下面命令確認我們的節點的同步狀態

確認synced_to_chain欄位已經變成true，代表區塊頭同步完畢。

• 然後去下面的網址找一個可用的閃電節點:

https://explorer.acinq.co/

• 我們選一個channel數比較多的然後連接這個節點：cosmicApotheosis

• 下一步建立通道，這裡我們存0.1btc到通道里:

• 查看節點連接狀態：

這裡我們還需要等待3次確認，通道才能建立成功，記住剛才建立完的transaction id，去網上查詢等待3次確認。

• 檢查通道的狀態：

當通道打開的時候，就可以用閃電網路支付啦！

支付

• 我們去satoshi.place 隨便來幾筆塗鴉，得到一個支付地址:

• 在命令行里支付：

順利的話，瞬間支付成功。

小結

看起來是不是很麻煩，相信我，實際做一遍的話坑也不少。

目前有小部分錢包實現了閃電網路支付；但是拍腦袋想想就知道錢包裡面無法包含閃電節點的全部功能：因為收款需要時時刻刻的監控，所以不可避免的需要一個類似於瞭望塔式的服務，最合理的辦法就是將這個功能的實現剝離出來，單獨部署到一台伺服器上。

electrum輕錢包在這裡討論了典型的實現方式。

可以預見到將來，實現閃電網路的錢包除了要自建全節點之外，還需要建立穩定的閃電網路節點實現類似瞭望塔的功能，當閃電網路極大繁榮的時候，錢包服務商實際上會佔據及其有利的地位，閃電網路的發展，需要比特幣錢包軟體的進化，這是一個非常大的商機。

參考資料:

https://yeasy.gitbooks.io/blockchain_guide/content/bitcoin/lightning_network.html

http://book.8btc.com/blockchain-credit

https://www.8btc.com/article/92887

閃電網路

https://en.bitcoin.it/wiki/Payment_channels

The History of Lightning: From Brainstorm to Beta