API/RSS

Social

研究｜闪电网络简史

22-07-23 15:42

阅读本文需 46 分钟

AI 总结

看总结

原文来源： 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