閃電網絡簡史_BTC

本文共 11806?字

推薦閱讀時間?30?分鐘

TL；DR

閃電網絡是集大成者，是天時地利人和的產物

閃電網絡的前輩們或多或少都需要對BTC底層進行改動，導致他們始終無法良好運行

現在為人們所熟知的是Basis of Lightning Technology（BOLT）

19年以后閃電網絡基礎設施日益成熟，后續的發展圍繞優化和生態建設為主

提到閃電網絡，絕大多數人對它的了解還只是聽過這個名字，或者稍微了解多一些的人知道它的一些基本原理。但是我們需要思考一個問題：閃電網絡的概念是一夜成名的還是集大成者？哪怕僅憑直覺來看，我們也認為是后者。但是，它集成了哪些大成？在它之前的那些設想為什么沒有發展起來？這就需要我們回顧下閃電網絡的發展歷史。而從閃電網絡的組成中，我們不難發現，它的核心是payment channel和由此組成的payment network。那么，我們今天就再次回顧下這些值得被銘記的英雄。

閃電網絡集的大成之一就是支付通道。這個從直覺上理解也沒有什么問題。畢竟想要組成點對點的支付網絡，首先要解決的是點對點之間的支付問題。

支付通道的核心思路就是在兩個比特幣賬戶之間建立一個通道，這兩個地址的余額關系只用他們兩個人知道就好，并不需要上鏈，一直到雙方愿意結算的時候廣播一筆交易到鏈上即可。

之所以說它是現在閃電網絡的”種子“，是因為它的理念和BTC誕生一樣早。在Bicoin 0.1版本就包含了支付通道的代碼草稿, 即允許用戶在交易被網絡確認前更新這筆交易。

圖片來源：https://github.com/trottier/original-bitcoin/blob/master/src/main.cpp#L434

當然，通過這個代碼構建的方案還很初級，不過中本聰后來跟bitcoinj開發者Mike Hearn私聊了更多支付通道的細節，并且在2013年，Hearn公開了中本聰對支付通道的解釋（如下圖）

圖片來源：https://www.bitcoin.com/satoshi-archive/emails/mike-hearn/13/

總結起來就是：如果一個交易還在交易池中沒有被打包，應該可以讓用戶發送一個新的交易，這個交易的序列號應該比舊交易的序列號要高，礦工就應該優先打包序列號高的交易。這樣就能讓一個人不停的給另一個人發送交易，更新序列號，礦工只用打包序列號最大的交易即可。

同時，這里面涉及的一些概念，諸如：

nLocktime，BTC交易里的一個字段。任何包含了這個字段的交易，如果該字段的值是一個有意義的值，比如1000個區塊，，那么該交易只能在1000個區塊后才能被打包。

signaturehash

……

啟發一堆大佬開啟了后續的一系列嘗試。

但是我們可以發現在這份初級的解釋中，很難避免雙花的問題，也就是很難做到無需信任。假設支付通道中的某個用戶和礦工合謀讓區塊確認一個對自己有利的舊交易（前面在交易池中的交易都是合法的，所以并不是只有序列號最高的交易才合法），那么就可以讓別人蒙受損失，自己和礦工受益。

所以，基于這個問題，在2011年7月4日（中本聰消失后）的時候，Bitcointalk的用戶”hashcoin“設計了一種雙層結構的支付通道，核心思想就是要求提交多簽交易以及具有互相依賴的有效時間鎖交易（利用了BTC原本的nLocktime字段）。如果一個參與者消失了，另一個參與者可以在時間鎖解鎖后取走支付通道里的所有資金。我們可以看一下具體的過程，以明確這個想法的偉大之處以及對后面一系列解決方案的影響。

圖片來源：

https://bitcointalk.org/index.php?topic=25786.msg320931#msg320931

比特幣閃電網絡節點數量為35060個:2月28日消息，1ML網站數據顯示，比特幣閃電網絡（LightningNetwork）的節點數量為35060個，同比增長3.58%；通道數量為87121個，同比增長1.3%；網絡容量為3462.65BTC，同比增長3%。[2022/2/28 10:19:46]

我們可以發現，Hashcoin用了非常巧妙的一個思路，讓支付通道里的接收者先簽署一個可以花費雙方支付通道里output的交易B（再次強調UTXO模型，沒有余額一說，只有Output和input，一個input一定能追溯到一個output），然后再由雙方簽署支付通道的output交易A。而期間支付者想要支付錢給接收者時只用更新交易B（交易B的初始序列為0，更新一次加一次），最后在hash鎖到期前接收者廣播序列號更大的交易B，完成結算。

這個思路最優秀的一點在于解決了雙方不再合作的時候，支付通道里的錢無法取出的問題。因為想要開啟一個通道，勢必要先簽署允許通道內資金轉出的交易（萬一接收者不想和支付者玩兒了，等時間鎖解鎖后依舊可以拿回自己的幣，而不是鎖在payment channel里），才會簽署轉入資金的交易。

但是這個構想的缺點在于：

整個通道是單向的。只能A給B或者B給A，反過來就得另外新開通道，很不方便。

不知道接受者是誰的情況下，怎么使用支付通道。

nlocktime只能證明在未來有可能花費一個output，但是并沒有證明在到期之前不可能花費這筆output。

由于當時BTC的hash方法需要簽名（segwit之前），所以想要完成交易B就需要先有交易A的資金輸入才行，這就形成了一個悖論。這也是當時較為出門的BTC延展性（可塑性）問題。

而且更為重要的是hashcoin只是一個設想，并沒有去嘗試實現。

直到2013年4月，Jeremy Spilman搞了一個類似于hashcoin的概念，并且寫了一份概念驗證代碼。由于當時Jeremy提出的這個想法是通過比特幣開發郵件組描述的，所以并沒有一個明確的名字。后來經由Mike Hearn(上面公開中本聰對支付通道描述的人) 優化，以及bitcoin核心貢獻者，blockstream聯合創始人，Matt Corallo(Chaincode Labs，由BTC開發者組成的專門建設BTC的實驗室)等人的努力下，于2013年6月27日宣布把這個概念加入到了bitcoinj（BTC開發庫，許多比特幣應用程序和服務都建立在它之上（例如，https://bisq.network/, bitcoin wallet, rsk.co），同樣是由Mike Hearn創建）中。

圖片來源：https://gist.github.com/jspilman/5424310

但是我們可以發現，hashcoin的幾個缺點依舊沒有被解決。

好在nLocktime的問題在2014年11月10日的BIP-0065提案中被解決，通過軟分叉的形式加入新的OPCODE字段——CHECKLOCKTIMEVERIFY. ?允許交易在某個時間點前不可使用。

具體的改動就不說了，總之就是加入這個字段使得這種單向支付通道在理論上變的可用（在一定條件下）。

關于BTC hash方法的問題我們暫時不論。但是單向支付的問題是可以在不動底層的前提下進行優化的。在2014年10月7日，Alex Akselrod（現在是lightning labs 的工程師）第一次提出了雙向支付通道的提案。核心思路是引入遞減時間鎖，可以讓接收者有限次的發送資金給發送者。雖然這個方案一直沒有被實現過，但是我們依舊可以看下當時Alex的思路是什么。

圖片來源：https://bitcointalk.org/index.php?topic=814770.msg9185225#msg9185225

可以看到基于這個提案的討論圍繞的是依靠nLocktime來進行支付角色的轉換。舉個例子來說，假設Alice和Bob構建了一個雙向支付通道。由Alice向Bob支付。假設Alice向Bob轉了1 BTC, 同時在這個交易上標記nLocktime為1000， 那么Bob可以反向向Alice支付BTC， 但是Bob發起的這筆交易nlocktime會從1000開始遞減，比如是999，并且Bob發起的每筆交易都會減少nLocktime，所以Bob最多只可以發起1000筆交易。

數據：閃電網絡BTC容量超過3300枚:11月30日，閃電網絡的BTC容量為3302枚。而10月17日，其容量為3098枚。這意味著閃電網絡的BTC容量在逐步提升。據悉，閃電網絡支付的成本約為1聰，約合0.0036元。[2021/11/30 12:40:54]

至此，除了BTC本身延展性（可塑性）的問題外，Payment channel的基礎已初步完成。

上面payment channel的歷史基本說完，接下來，我們就應該看payment network了。回顧下上面的Payment channel，會發現整個支付通道的設想都是在兩人之間進行交互的。但是，如果A和B有一個支付通道，B和C有一個支付通道，那么是不是可以讓A直接對C進行支付呢（這個問題換一個說法就是上面提到的Hashcoin的缺點，在不知道對手方是誰的情況下，如何用payment channel進行交易）？所以，在第一個支付通道提出之后（hashcoin），一些大佬們已經在考慮offchain的Payment network。其中不乏像Petter Todd（上面說過的BIP-0065的提出這）和 Gavin Andresen（當時中本聰欽定的BTC開發接班人，后來由于相信了假的中本聰，被社區踢出）這樣的BTC核心開發者。那么，它們都是怎么去做的呢？

和payment channel類似，在實踐之前，Payment network已經誕生出很多想法。其中比較出名的想法就是來自于BTC核心開發者群里的Petter Todd于2013年 2月23日提出的 Fidelity-bonded banks: decentralized, auditable, private, off-chain payments ，Gavin Andresen于2012年7月4日提出的 Off-the-chain transactions，以及Corné Plooy（現在的閃電網絡開發者，同時在荷蘭的交易所BL3P工作）于2011年7月13日提出的A proposal for fast POS transactions with Bitcoin

有關前兩個大佬提議的具體討論可以在下面的鏈接里找到。但是從設計理念來說，兩者的思路是非常相像的：基本都是引入一個半可信的中間人（”半可信“是說雖然中間人無法竊取用戶資金，但是中間人選擇不合作，那么處于Payment network的錢就無法取出），實現一個鏈下支付網絡的功能。Petter Todd在這個基礎上加入了隱私的概念，而Gavin的思路則是純粹解決支付的問題。

圖片來源：https://bitcointalk.org/index.php?topic=146307.0

圖片來源：http://gavintech.blogspot.com/2012/07/off-chain-transactions.html

但是，針對出現最早的Plooy的方案，我們有必要單獨說下。它的思路更加符合我們對于payment network里的network的定義。

圖片來源：https://bitcoinmagazine.com/technical/history-lightning-brainstorm-beta

黑色箭頭是標準的BTC轉賬流程示意，但是Plooy在此基礎上加入了紅色箭頭的部分，這部分就是off-chain結算網絡的精髓部分。整個流程大致如下：

buyer發起一筆交易給seller（以一種標準化的信息格式）。

同時buyer會將這筆交易發布到BTC網絡，進行常規的6789的確認步驟。

買方還會在此基礎上發送交易到一個“快速驗證網絡”中

該“快速驗證網絡中”的節點將根據原有數據快速驗證該交易。

快速驗證網絡將會在幾秒鐘內將初步檢測結果告知seller。

最終結算（驗證）還是通過經典BTC網絡進行驗證。出現雙花問題，將由快速驗證網絡中的節點賠償seller損失。

閃電網絡客戶端Eclair發布0.5.0版本更新 新增集群模式和Watchdog:據官方消息，比特幣閃電網絡客戶端Eclair發布0.5.0版本更新，官方稱該版本包含了許多新功能、API變化以及修復和改進，并兼容之前的0.4.2版本和之前所有的版本。該版本的主要變化為增加了集群模式（Cluster Mode），允許用戶在多個服務器上擴展一個閃電網絡的邏輯節點，該功能對于穩健和可擴展的企業部署非常關鍵。另外，該版本Eclair包含了一個Watchdog（監視器）功能，通過各種渠道獲得比特幣的區塊頭數據，以檢測數據是否安全。[2020/12/21 15:58:16]

由上圖可以看到，Plooy的思路就是在傳統的BTC網絡上搭建一層快速結算的網絡。那么這里面的核心就在這層快速結算網絡上。而出現雙花等問題造成的損失由于是由快速結算網絡中的節點支付，這就要求有明確的追責機制。在Pooly的設計中，這種追責制度是根據第5步里seller接收到的驗證節點簽名來進行追責的。這就說明快速驗證網絡中的節點不是和BTC節點一樣是隨機鏈接的，而是只有當兩個節點互相信任的時候才會建立鏈接，然后就可以一層層的去追責，最終追蹤到終端buyer頭上。同時也因為這個追責制度要求終端買家在加入快速驗證網絡的時候必須先付款。

可以看到Plooy的思路還是會落在信任上。并不是完全的無需信任。不過在2011年就提出這種設計，很了不起。同時也為后續的幾個真實落地的項目提供了很好的參照。

和hashcoin一樣，Plooy一開始也并沒有具體的去落地，但是期間一直在有人去嘗試改進這個想法，其中包括BTC核心開發者和Gregory Maxwell（blockstream CTO）以及Ryan Fugger(Ripple創始人)等人。最終，在2012年7月22日，一篇?Combining Bitcoin and the Ripple to create a fast, scalable, decentralized, anonymous, low-trust payment network (draft 1)?的文章宣布了Amiko Pay的誕生。

Amiko Pay可以看成是Plooy落地的嘗試。但是在這版草稿中，沒有用到Payment Channel的東西，導致整個網絡依舊需要信任：如果某個用戶拒絕與另一個用戶結算余額，后者沒有任何辦法。雖然在2013年1月15日發布了第二版的草稿，但是其內容并沒有很大的改動。

后續Amiko Pay一直在做改動，最終（2015年）設計出了一套無需信任的解決方案，但是鑒于當時的BTC本身編程模型的限制，類似的方案難以實現，需要對BTC做”一定“的改動, 最終不了了之。Amiko Pay最后一次更新自己的roadmap進度是在2016年6月：

如果對Amiko Pay有更多的興趣，除了本文中附帶的超鏈接外，還可以點擊他們主頁進行詳細的了解：https://cornwarecjp.github.io/amiko-pay/

但是，就如同上面寫的一樣，Amiko Pay本身并沒有很好得結合Payment channel的優點，所以給了其他人一些機會，最終變成了前浪。

雖然Amiko Pay這一派系并沒有很好得結合支付通道的設計，但是，早在2012年的時候就有人提出過結合兩者的思路。2012年7月5日，Meni Rosenfeld在bitcointalk上提出了一個想法，Trustless, instant, off-the-chain Bitcoin payments，在Hashcoin的基礎上加入了中繼人的角色，形成由支付通道組成的簡單支付網絡。這樣使用只需要和“中繼人”建立支付通道，再通過中繼人鏈接其他用戶。這里需要注意的是，中繼人的角色同樣不會控制任何人的錢包，只負責通道的建立。同時允許中繼人競爭上崗，進一步分散資金，哪怕出現什么問題也只會損失小部分資金。當然，這一樣需要用戶信任中繼人。

當然，類似的想法在過去的幾年里一直斷斷續續的出現。比如提到很多次的Petter todd在2014年12月的BTC開發者郵件組里提到過類似的概念（Near-zero fee transactions with hub-and-spoke micropayments ，里面還提到了彩色幣的嵌入式共識方案），甚至在更早的2013年，Alex Akselrod就提出過類似的草案并且還在稍晚的2014年公布了測試代碼。。Bitpay（做BTC支付服務的，用戶付BTC，商家可以收到美元，減少波動風險）也在2015年發布了類似概念的“Impulse”白皮書和實際落地方案，當然也有類似于Strawpay這種公司做了Stroem，等等。

閃電網絡節點數量已達13947個:金色財經報道，據1ML.com數據，目前，支撐網絡的節點數量達到13947個，相較30天前數據，環比上漲2.62%；通道數量為37061，相較30天前數據，環比下降0.2%；閃電網絡承載能力目前為1110.22BTC，約合1185.77萬美元。[2020/9/26]

我們可以認為上述的各個方案，無論是Amiko Pay還是Impulse還是Storem都是可以實現閃電網絡的那些功能的。但是，他們要不需要對BTC做出“較大”的改動（這里的“較大”放到其他公鏈上可能就是很簡單的事情，但是在BTC上，任何一個改動都非常難。有一句話是這么說的，“BTC上任何成功的改動都是一篇論文”）或者需要在某些方面進行妥協。所以，這些人在那個年代想出這些方案并且去盡力實現已經非常厲害了，但是還不夠，必須要有更為天才的人能夠在BTC限定的框框內展露才華。

前面諸多英雄豪杰已成云煙，但是遺留的問題依舊需要解決。那么在主角登場前，我們再來看看目前的支付網絡和支付通道遺留的問題是什么。

如何做到無需信任？

如何對BTC網絡的改動最小？

而這第一個問題本質上來說都是因為第二個問題才導致沒有一個較好的解決方案。那么問題就變成了，如何在BTC編程模式的限制下，實現無需信任的BTC高效支付網絡。

前面已經有很多的技術積累，加上2015年BTC社區關于擴容的討論日漸火熱，所以我們發現很多重要的突破的都是在那一年誕生（甚至在出現狹義上閃電網絡白皮書之前，blockstream就已經成立在研究相關領域的東西）。其中，一篇蘇黎世理工的論文《A Fast and Scalable Payment Network with Bitcoin Duplex Micropayment Channels》于2015年晚期發布。這篇論文的解決方案重度依賴于時間鎖來作為通道有效性的“倒計時裝置”，以及一種叫做 “無效樹” 的密碼學技巧來作廢陳舊的通道交易。這也成為了后來閃電網絡賴以為生的技術原型。而這篇論文的兩個作者Christian Decker 和Roger Wattenhofer后來都加入了blockstream。

天時、地利、人和，三者不得，雖勝有殃——《孫臏兵法·月戰》

2015年的BTC擴容逐漸火熱（2015年組織了兩次著名的擴容會議，9月的Scaling Bitcoin Montreal和 12 月的Scaling Bitcoin Hong Kong），此曰天時。前面眾多技術積累和那篇論文提出的兩個關鍵設計，為閃電網絡鋪平道路，此曰地利。

那么，天時地利有了，只差一個人和。或許這就是主角吧，在2015年即將結束的時候，BTC核心開發者之一的大佬Gregory Maxwells總結了最近一段時間有關BTC擴容的討論（Capacity increases for the Bitcoin system ， 基本上也是當時BTC社區的意思），里面奶了閃電網絡一口。而他當時就是blockstream創始團隊成員之一。有關Maxwells的成就，大家可以看一個科普：https://academy.bit2me.com/en/who-is-gregory-maxwell/

總之，對于閃電網絡來說，天時地利人和湊齊，下面就是它表演的時間了！（在2015年2月23日《The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments》初稿在舊金山的BTC開發研討會發布）。

那么接下來，我們就來看下lightning network是怎么做到比前輩優秀的？我們將從兩個角度的優化來看待它。

Payment channel（lightning network里叫Poon-Dryja 通道）

閃電網絡將雙方的time span擴充到無限。只要雙方愿意，這個channel可以一直存在。而此前的payment channel方案需要在nlocktime到期前關閉（否則會自動結算）

雙向支付而且是無限次的。

Payment network

利用HTLC（哈希時間鎖），將Channel連在一起，形成網絡。這個東西是什么意思呢？其他它包含兩個“或”關系的條件。

創建一個條件支付，比如A給B一筆錢，需要B解出一道題才能花費里面的錢（必須是B，不能是任何人）。即收款方揭露一個信息，提供有這個信息的證明才能花這筆錢。嚴格一點的定義是：哈希秘鑰鎖定，基于hash的單向性，可以把一個密文的哈希值放入交易的輸出當中充當哈希密文鎖，也就是必須得輸入該哈希值對應的密文才能解鎖腳本中的比特幣。例如，例如Alice收到了一筆2BTC轉賬，但是對方設定了哈希值鎖定，所以Alice必須得到交易方的密文，同時配合自己的密鑰簽名才能簽署交易，花費其中的BTC轉給Bob。

數據：比特幣閃電網節點數量為13715個:當前比特幣閃電網絡節點數為13715個，過去30天內增加2.96%；通道數量為36572個，過去30天內減少1.6%；網絡容量達到1056.84個BTC，過去30天內增加6%。[2020/9/7]

等到規定的時間結束，才能花費里面的錢。在此之前交易并不生效，無法執行。嚴格一點的定義就是在交易腳本里面設置時鐘，必須要等設定時間之后，才能用地址的私鑰簽名解鎖地址里的比特幣。例如Alice收到了一筆2 BTC轉賬，但是對方設定了1000個區塊之后才能解鎖，所以Alice必須等待1000個區塊之后才能用自己的私鑰簽署交易,花費其中的BTC轉給Bob。

那么閃電網絡具體是怎么做的呢？我們在前面的設計中也知道，如何保證雙方記賬的誠實是閃電網絡需要解決的難題。這里就涉及兩個東西:?

如何知道是誰作惡

作惡如何受到懲罰

這時候，我們就需要看下閃電網絡在payment channel的幾次轉賬是如何進行。具體的過程和原理大家可以去參閱白皮書。

今天主要講的是歷史，所以對于原理我就概括下：假設A和B構建了一個閃電網絡通道，對于每次的交易，實際上會產生4個交易證明：

記錄在A賬本的轉賬記錄

記錄在B賬本的轉賬記錄

記錄在A賬本用來作廢前一筆交易的記錄

記錄在B賬本用來作廢前一筆交易的記錄

我們可以看到，這4個證明實際上分為兩類。但是需要注意的是A和B的賬本記錄的同一類交易證明是不同的。

假設A給B轉了一個BTC，現在總的賬本是A: 4 B :6, 這時候在A的賬本和B的賬本記錄的對于BTC分配的內容是一致的，不一致的是為了區分在作惡情況時知道是誰發送的惡意交易，所以在構成交易的其他信息上做了文章。假設又發生了一筆交易，A又轉了1BTC給B，此時的交易記錄應該是A:3 B:7, 但是A想作惡，搶先把上次一交易發送到了鏈上，這時候閃電網絡有意思的設計來了，A發送的這個交易（A:4 B :6）里，B的6個BTC是能被B立刻取走，但是A的4個BTC必須等哈希時間鎖到期后才能取走，通過這種方式給了受害人反應時間。

這時候，用來作廢前一筆交易的記錄就派上用場了。假設B發現了A的惡意行為，他可以馬上把最新的交易記錄和作廢前一筆交易的記錄發送到鏈上。由于此前A已經把4，6這個交易發到鏈上，B可以馬上取回自己的6個BTC，然后這個作廢前一個記錄的作用就是可以讓B馬上或得原本需要等待時間鎖到期的A的4個BTC，也就是相當于整個channel里10個BTC都歸了B，A受到了懲罰。

而對于將不同的channel鏈接成網絡的事情，用到了上面的HTLC。

假設A要通過B給C轉賬。這個過程可以簡單概括為：

C哈希一個密文給A，A構建一個交易給B，但是這筆交易需要B拿到C的密文才能解鎖，如果到期內沒有解鎖，則錢退給A。

然后B構建一個交易給C，同樣需要C的密文C才能解鎖交易。這樣，C一旦拿到錢，B也就知道了C的密文，也就能拿到A的錢。

閃電網絡的大概過程就是這些，只是大概提一下，有需要的話后面可以詳細講講。我們繼續講閃電網絡的進化史。

既然白皮書有了，那么就是實現的問題了。我們之前講過的BTC 可塑性問題（B的交易ID需要A的交易HASH，而A的交易HASH需要對應的簽名，但是我們之前講過閃電網絡開啟通道需要先構建B的交易，再構建A，這就是上面引用悖論的問題）。針對這個問題，閃電網絡白皮書里提到了signaturehash-withoutinput的形式去解決（簡而言之就是不管input，只簽output），但是最終沒有成功，反而是利用了后來的sigwit達到了一樣的目的。

而且，不僅如此，由于第一版白皮書包含很多技術概念，很少能有人能徹底理解。但 Linux 系統內核長期開發者 Rusty Russell 學習了這份白皮書后，大家的基礎認識提高了一大截。在 2015 年初的系列博客中，Russell 為更廣泛的讀者 “翻譯” 了這份白皮書（但還是比較挑人的）。在同年3月，Russell應邀加入了Blockstream，開發了第一個閃電網絡的實現：C-lightning。后來，Blockstream 的 Christian Decker 也加入了 Russell；其他人（包括 Corné Plooy） 也為這個開源項目做了貢獻。

此后不久，一家名叫ACINQ的小公司加入閃電網絡的研究中，在2017年3月22日宣布用Scala寫出了自己的閃電網絡協議——eclair。

但是，我們熟知的閃電實驗室呢？嗯，他們是在2016年1月由閃電網絡白皮書的兩個作者Poon和Dryja成立的。后來大家就知道了，他們做了LND。并且16年底Dryja離開閃電實驗室去了MIT的數字貨幣計劃，做了類似LND的LIT（兩者差異在于它把錢包和節點封裝成了一個整體，同時支持多種幣）。

同時，因為延展性的問題，著名的挖礦公司Bitfury將lnd分叉并且權衡了延展性問題，做了一個哪怕不需要解決BTC延展性問題也能用的閃電網絡。但是現在這個項目停滯了。

再后來，Blockchain（錢包公司）開發了一個叫Thunder的簡化版閃電網絡，在犧牲“無需信任”的前提下，推出了實際意義上最早的閃電網絡—Thunder的alpha版本。雖然現在也沒聲音了。

可以發現，當時的閃電網絡各式各樣，那么每到這個時候，總會有一個會議來規范大家，讓大家的東西可以互通。這個會議就是2016年10月舉辦的Scaling Bitcoin Milan三次會議。在這個會議上，各個項目方達成了互操作的一致性，產生了一個叫“BOLT”的閃電網絡協議規范（Basis of Lightning Technology）。所以說，閃電網絡白皮書是理論上的第一，BOLT 才是我們今天所知的、實際上的閃電網絡的基礎。

至于另一條故事線，就是圍繞btc延展性而展開了。從之前Petter Todd在2015年提出的CLTV（CheckLockTimeVerify）,到相對時間鎖的實現（CSV, CheckSequenceVerify），一直到后來segwit的升級，最終讓閃電網絡正式進入應用階段。而正式使用閃電網絡的第一個例子，就是在segwit測試網, segNet部署不到半年后的2016年10月，blockstream的Decker就用c-lighting從Russell手上買了一只“貓”

圖片來源：https://blog.blockstream.com/en-blockstream-lightning-first-strike/

這也被稱為?“閃電網絡的第一次閃擊”。

然后就是2017年1月，LND推出了alpha版本。一直到17年夏天，隔離見證正式激活。blockstream在3個月后宣布了第一筆BTC主網閃電網絡交易，11 月，Lightning Labs 做了第一筆跨區塊鏈（從比特幣到萊特幣）的閃電網絡交易。12 月，來自 Blockstream、Lightning Labs 和 ACINQ 的開發團隊宣布他們已經通過了互操作性測試。

到了這一年的末尾，越來越多的閃電通道打開。到了 12 月，開發者 Alex Bosworth 用閃電網絡通道向支付處理商 Bitrefill 支付了自己的手機賬單：這是閃電網絡上最早一批把比特幣當錢來用的交易之一。

又過了一個月，Blockstream 開設了一個網上商店，讓人可以用比特幣來購買實體商品 —— 雖然 c-lightning 實現還只是 beta 版本。2018 年 2 月，在閃電網絡仍處在 alpha 階段時，比特幣世界的傳奇人物、以“比特幣買披薩” 趣事聞名世界的 Lazlo Hanyecz 宣布自己使用閃電網絡買了披薩。

圖片來源：http://eclipse.heliacal.net/~solar/bitcoin/lightning-pizza/

后面的故事就屬于順風順水了。各種閃電網絡方案紛紛落地，相關生態也日漸完善。關于閃電網絡到目前為止個人覺得重要的歷史事件也就是這些。

第一個總結：天才的聰明才智總是這么的“不值錢”。

如果稍微看下下閃電網絡白皮書的兩個作者的相關事跡就能得出第二個結論：天才總是會搞事情。

兩人的主要成就如下：

Thaddeus Dryja，做過一個叫mirro的項目，點對點的交易系統，并且加入了prediction market的概念。同時也搞過一個PoW算法（Hashimoto），是以太坊PoW算法ethash上線前的替代算法（Dagger Hashimoto）的前身：http://diyhpl.us/~bryan/papers2/bitcoin/meh/hashimoto.pdf。

另一個作者，Joseph Poon，還是plasma的作者之一。在BTC提出了基于channel的閃電網絡，在以太坊提出了基于鏈的plasma。同時也做了handshake(https://handshake.org/)，繼承了namecoin思想的項目。當然，割沒割人就不在我們的討論范圍內。

最后，附上我們整理的閃電網絡相關大事件時間線：

圖片來源：CYC整理

文獻參考：

https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki

https://voltage.cloud/blog/bitcoin-lightning-network/life-of-lightning/

https://en.wikipedia.org/wiki/Lightning_Network

https://bitcointalk.org/index.php?topic=28565.msg359408#msg359408

http://www.ultimatestunts.nl/bitcoin/ripple_bitcoin_draft_1.pdf

https://bitcointalk.org/index.php?topic=91732.msg1010405#msg1010405

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-December/006988.html

https://en.bitcoin.it/wiki/User:Aakselrod/Draft

https://www.strawpay.com/docs/stroem-payment-system.pdf

https://tik-old.ee.ethz.ch/file//716b955c130e6c703fac336ea17b1670/duplex-micropayment-channels.pdf

https://montreal2015.scalingbitcoin.org/

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html

https://lightning.network/lightning-network-paper.pdf

https://github.com/mpegavi/bitcoincn/blob/master/%E6%AF%94%E7%89%B9%E5%B8%81%E9%97%AA%E7%94%B5%E7%BD%91%E7%BB%9C%E7%99%BD%E7%9A%AE%E4%B9%A6%EF%BC%9A%E5%8F%AF%E6%89%A9%E5%B1%95%E7%9A%84%20off-chain%20%E5%8D%B3%E6%97%B6%E6%94%AF%E4%BB%98%EF%BC%88%E4%B8%AD%E6%96%87%EF%BC%89.pdf

https://github.com/ElementsProject/lightning

https://bitcoinmagazine.com/technical/segwit-or-not-bitfury-ready-lightning-successful-bitcoin-main-net-test

https://medium.com/@ACINQ/eclair-0-2-alpha1-is-out-3caaff242567

https://github.com/blockchain/thunder

https://github.com/lightning/bolts/blob/master/00-introduction.md

https://github.com/bitcoin/bips/blob/master/bip-0112.mediawiki

Tags：BTCCOIOINCOINsupersbtcESB CoinCreditcoinHuobi Bitcoin Cash

以太坊價格今日行情