首頁

Partnered With:

研究｜閃電網絡簡史

閱讀本文需 46 分鐘

閃電網絡的概念是一夜成名的還是集大成者？

原文來源： CYC Labs

原文作者： CryptoYC Tech

TL；DR

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

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

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

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

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

Payment Channel——BTC 代碼裏的種子

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

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

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

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

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

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

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

· signaturehash

· ……

啓發一堆大佬開啓了後續的一系列嘗試。

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

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

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

我們可以發現，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 只是一個設想，並沒有去嘗試實現。

Jeremy Spilman 的支付通道

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

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

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

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

雙向支付通道的提出

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

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

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

Payment Network——拓展 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 的思路則是純粹解決支付的問題。

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

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

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

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

3. 買方還會在此基礎上發送交易到一個「快速驗證網絡」中；

4. 該「快速驗證網絡中」的節點將根據原有數據快速驗證該交易；

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

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

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

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

Amiko Pay——閃電網絡的前身

和 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，等等。

我們可以認爲上述的各個方案，無論是 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。

· 等到規定的時間結束，才能花費裏面的錢。在此之前交易並不生效，無法執行。嚴格一點的定義就是在交易腳本里面設置時鐘，必須要等設定時間之後，才能用地址的私鑰簽名解鎖地址裏的比特幣。例如 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 手上買了一隻「貓」。

這也被稱爲「閃電網絡的第一次閃擊」。

然後就是 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 宣佈自己使用閃電網絡買了披薩。

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

總結

第一個總結：天才的聰明才智總是這麼的「不值錢」。

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

兩人的主要成就如下：

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://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://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