BTC:閃電網絡簡史

本文共11806?字

推薦閱讀時間?30?分鐘

TL；DR

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

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

現在為人們所熟知的是BasisofLightningTechnology

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

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

PaymentChannel——BTC代碼里的種子

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

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

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

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

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

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

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

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

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

signaturehash

……

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

Hashcoin——第一個可用支付通道的構想

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

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

Tether、Synonym和OmniBOLT今年致力于通過將代幣帶入閃電網絡推動比特幣經濟發展:官方消息，Tether表示，在2022年，Tether、Synonym和OmniBOLT正致力于通過將代幣帶入閃電網絡推動比特幣經濟發展。

此前消息，Tether創立Synonym公司，旨在通過閃電網絡促進比特幣的采用。

據悉，Omni以推出全球最大穩定幣USDT發行層OmniLayer著稱。Omni制定全球首個閃電網絡內的通證流通規范OmniBOLT，并正在與眾多資產發行方以及其他閃電網絡關聯廠商推進網絡測試。[2022/1/9 8:36:13]

圖片來源：

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

我們可以發現，Hashcoin用了非常巧妙的一個思路，讓支付通道里的接收者先簽署一個可以花費雙方支付通道里output的交易B，然后再由雙方簽署支付通道的output交易A。而期間支付者想要支付錢給接收者時只用更新交易B，最后在hash鎖到期前接收者廣播序列號更大的交易B，完成結算。

這個思路最優秀的一點在于解決了雙方不再合作的時候，支付通道里的錢無法取出的問題。因為想要開啟一個通道，勢必要先簽署允許通道內資金轉出的交易，才會簽署轉入資金的交易。

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

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

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

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

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

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

JeremySpilman的支付通道

直到2013年4月，JeremySpilman搞了一個類似于hashcoin的概念，并且寫了一份概念驗證代碼。由于當時Jeremy提出的這個想法是通過比特幣開發郵件組描述的，所以并沒有一個明確的名字。后來經由MikeHearn(上面公開中本聰對支付通道描述的人)優化，以及bitcoin核心貢獻者，blockstream聯合創始人，MattCorallo(ChaincodeLabs，由BTC開發者組成的專門建設BTC的實驗室)等人的努力下，于2013年6月27日宣布把這個概念加入到了bitcoinj，同樣是由MikeHearn創建）中。

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

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

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

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

雙向支付通道的提出

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

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

閃電網絡節點數量已達15729個:金色財經報道，據1ML.com數據，目前，支撐網絡的節點數量達到15729個，相較30天前數據，環比上漲3.88%；通道數量為36033，相較30天前數據，環比下降0.1%；閃電網絡承載能力目前為1041.78BTC，約合3915.89萬美元。[2021/1/15 16:17:31]

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

至此，除了BTC本身延展性的問題外，Paymentchannel的基礎已初步完成。

PaymentNetwork——拓展paymentchannel的必經之路

上面paymentchannel的歷史基本說完，接下來，我們就應該看paymentnetwork了。回顧下上面的Paymentchannel，會發現整個支付通道的設想都是在兩人之間進行交互的。但是，如果A和B有一個支付通道，B和C有一個支付通道，那么是不是可以讓A直接對C進行支付呢？所以，在第一個支付通道提出之后，一些大佬們已經在考慮offchain的Paymentnetwork。其中不乏像PetterTodd和GavinAndresen這樣的BTC核心開發者。那么，它們都是怎么去做的呢？

早期想法

和paymentchannel類似，在實踐之前，Paymentnetwork已經誕生出很多想法。其中比較出名的想法就是來自于BTC核心開發者群里的PetterTodd于2013年2月23日提出的Fidelity-bondedbanks:decentralized,auditable,private,off-chainpayments，GavinAndresen于2012年7月4日提出的Off-the-chaintransactions，以及CornéPlooy于2011年7月13日提出的AproposalforfastPOStransactionswithBitcoin

有關前兩個大佬提議的具體討論可以在下面的鏈接里找到。但是從設計理念來說，兩者的思路是非常相像的：基本都是引入一個半可信的中間人，實現一個鏈下支付網絡的功能。PetterTodd在這個基礎上加入了隱私的概念，而Gavin的思路則是純粹解決支付的問題。

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

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

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

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

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

buyer發起一筆交易給seller。

動態 | 托管創企Casa披露其產品安全擔憂 并提醒用戶小心閃電網絡:托管初創公司Casa在最近發布的一篇博客文章中披露了圍繞Casa Node 1產品的擔憂，并稱目前“Case Node已沒有已知的未公開漏洞”。博客稱，該產品主要存在兩個方面的問題。首先，一些用戶對使用HTTP連接而不是HTTPS的Casa節點表示了擔憂。該公司聲稱這并非偶然——它特意選擇使用HTTP來避免產生“錯誤的安全感”。因為這是一個內部或家庭連接，Casa稱：“HTTPS在最好的情況下是不切實際的，在最壞的情況下是危險的。”其次，Casa節點有默認的密碼，一些人認為這是一種安全風險。然而，正如Casa所解釋的，“為了訪問命令行，必須將鍵盤和顯示器插入到Casa節點。”因此，這一點是不能妥協的。另外，Casa在推特中還提醒用戶要小心閃電網絡，稱其發展仍然處于早期，并相對魯莽。（BeInCrypto）[2019/10/14]

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

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

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

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

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

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

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

AmikoPay——閃電網絡的前身

和hashcoin一樣，Plooy一開始也并沒有具體的去落地，但是期間一直在有人去嘗試改進這個想法，其中包括BTC核心開發者和GregoryMaxwell以及RyanFugger(Ripple創始人)等人。最終，在2012年7月22日，一篇?CombiningBitcoinandtheRippletocreateafast,scalable,decentralized,anonymous,low-trustpaymentnetwork(draft1)?的文章宣布了AmikoPay的誕生。

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

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

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

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

結合支付通道和支付網絡的其他方案

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

動態 | 閃電網絡通道數量達到31204個 過去30天漲幅超過30%:據1ml.com數據顯示，閃電網絡節點和通道數量呈現持續上升趨勢。目前，支撐網絡的節點數量達到6902個，在過去的30天中上漲了18.90%，而通道數量已經超過30000個，目前達到31204個，在過去的30天中上漲了37.70%。閃電網絡承載能力目前為733.69個BTC，相當于280萬6653美元。[2019/3/3]

當然，類似的想法在過去的幾年里一直斷斷續續的出現。比如提到很多次的Pettertodd在2014年12月的BTC開發者郵件組里提到過類似的概念，甚至在更早的2013年，AlexAkselrod就提出過類似的草案并且還在稍晚的2014年公布了測試代碼。。Bitpay也在2015年發布了類似概念的“Impulse”白皮書和實際落地方案，當然也有類似于Strawpay這種公司做了Stroem，等等。

我們可以認為上述的各個方案，無論是AmikoPay還是Impulse還是Storem都是可以實現閃電網絡的那些功能的。但是，他們要不需要對BTC做出“較大”的改動或者需要在某些方面進行妥協。所以，這些人在那個年代想出這些方案并且去盡力實現已經非常厲害了，但是還不夠，必須要有更為天才的人能夠在BTC限定的框框內展露才華。

劍來！———閃電網絡正式登場

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

如何做到無需信任？

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

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

前面已經有很多的技術積累，加上2015年BTC社區關于擴容的討論日漸火熱，所以我們發現很多重要的突破的都是在那一年誕生。其中，一篇蘇黎世理工的論文《AFastandScalablePaymentNetworkwithBitcoinDuplexMicropaymentChannels》于2015年晚期發布。這篇論文的解決方案重度依賴于時間鎖來作為通道有效性的“倒計時裝置”，以及一種叫做“無效樹”的密碼學技巧來作廢陳舊的通道交易。這也成為了后來閃電網絡賴以為生的技術原型。而這篇論文的兩個作者ChristianDecker和RogerWattenhofer后來都加入了blockstream。

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

2015年的BTC擴容逐漸火熱，此曰天時。前面眾多技術積累和那篇論文提出的兩個關鍵設計，為閃電網絡鋪平道路，此曰地利。

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

總之，對于閃電網絡來說，天時地利人和湊齊，下面就是它表演的時間了！。

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

Paymentchannel

閃電網絡將雙方的timespan擴充到無限。只要雙方愿意，這個channel可以一直存在。而此前的paymentchannel方案需要在nlocktime到期前關閉

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

Paymentnetwork

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

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

Edge首席執行官Paul Puey：閃電網絡其實是一種山寨幣:多資產區塊鏈錢包和證券平臺Edge的首席執行官Paul Puey表示，閃電網絡實際上是一種altcoin（山寨幣／替代幣）。從他的角度來看，閃電實際上就是一個小額信貸，是一個替代鏈條。這是一種恰好與比特幣相關的替代共識機制。從其它各個角度來看 ，閃電網絡有不同的地址格式，有不同的錢包，不同的交易方式，不同的約束條件，以及不同的服務器連接，是一個不同的系統。[2018/4/9]

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

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

如何知道是誰作惡

作惡如何受到懲罰

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

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

記錄在A賬本的轉賬記錄

記錄在B賬本的轉賬記錄

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

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

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

假設A給B轉了一個BTC，現在總的賬本是A:4B:6,這時候在A的賬本和B的賬本記錄的對于BTC分配的內容是一致的，不一致的是為了區分在作惡情況時知道是誰發送的惡意交易，所以在構成交易的其他信息上做了文章。假設又發生了一筆交易，A又轉了1BTC給B，此時的交易記錄應該是A:3B:7,但是A想作惡，搶先把上次一交易發送到了鏈上，這時候閃電網絡有意思的設計來了，A發送的這個交易里，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可塑性問題。針對這個問題，閃電網絡白皮書里提到了signaturehash-withoutinput的形式去解決，但是最終沒有成功，反而是利用了后來的sigwit達到了一樣的目的。

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

此后不久，一家名叫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月舉辦的ScalingBitcoinMilan三次會議。在這個會議上，各個項目方達成了互操作的一致性，產生了一個叫“BOLT”的閃電網絡協議規范。所以說，閃電網絡白皮書是理論上的第一，BOLT才是我們今天所知的、實際上的閃電網絡的基礎。

邁向可用性

至于另一條故事線，就是圍繞btc延展性而展開了。從之前PetterTodd在2015年提出的CLTV,到相對時間鎖的實現，一直到后來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月，LightningLabs做了第一筆跨區塊鏈的閃電網絡交易。12月，來自Blockstream、LightningLabs和ACINQ的開發團隊宣布他們已經通過了互操作性測試。

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

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

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

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

總結

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

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

兩人的主要成就如下：

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

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

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

圖片來源：CYC整理

文獻參考：

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

https://bitcoinmagazine.com/technical/history-lightning-brainstorm-beta

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

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

https://bitcointalk.org/index.php?topic=146307.0

http://gavintech.blogspot.com/2012/07/off-chain-transactions.html

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://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：BTCCOINOINCOIBTCRED價格RiseCoinPoSW CoinCoinControllerCash

XRP