本文共 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
Damus：正通过比特币闪电网络随机向用户发放小额比特币:金色财经报道，据官方推特，Nostr协议第三方客户端Damus表示，会利用比特币闪电网络随机向该客户端用户发放小额比特币。
金色财经此前报道，Nostr协议第三方客户端Damus内置比特币闪电网络功能，可以直接调用第三方闪电网络钱包支付。[2023/2/3 11:45:00]
我们可以发现，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笔交易。
比特币闪电网络节点数量为17,658个:金色财经报道，1ML网站数据显示，比特币闪电网络（LightningNetwork）的节点数量为17,658个，同比增长1.24%；通道数量为85,329个，同比增长1.0%；网络容量为3,994.31BTC，同比增长5%。[2022/6/12 4:19:17]
至此，除了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损失。
比特币开发人员Matt Corallo发现潜在闪电网络漏洞:比特币核心贡献者、Blockstream联合创始人Matt Corallo以及支付巨头Square旗下加密团队发现了一个潜在的比特币闪电网络漏洞。在回顾闪电网络交易机制的一个新方面时，Corallo偶然发现了这一漏洞，该漏洞理论上允许用户提取哈希时间锁定合同(Hash Time-Locked Contract，简称HTLC)中持有的资金。HTLC本质上是一种智能合约，它要求付款接收者通过生成付款的加密证据来确认交易，或者放弃要求全部付款的能力。如果付款未被确认，寄件人可以要求退款。该漏洞使收件人可以拒绝发件人收到此退款。Corallo提交了几个修复程序，但是没有一个特别容易或“正常”的。但他指出，这并不是一个紧迫的问题，因为利用该漏洞是不切实际的。尽管如此，考虑到只有十分之一的闪电网络节点持有其80%的比特币，这种利用可能会造成比最初想象的更多的问题。(Decrypt)[2020/5/2]
由上图可以看到，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，等等。
动态 | 闪电网络节点数量达10933个:据1ML.com数据显示，闪电网络节点数量呈持续上升趋势。目前，支撑网络的节点数量达到10933个，在过去的30天中上涨了2.70%，而通道数量为35362，在过去的30天中增长了0.9%。闪电网络承载能力目前为863.24BTC，约合623.95万美元。[2019/12/31]
我们可以认为上述的各个方案，无论是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。
声音 | 闪电网络浏览器添加LTC支持:莱特币创始人李启威发布推文称：闪电网络浏览器1ml.com添加LTC支持。经查证，现可查询LTC相关信息。[2018/10/30]
等到规定的时间结束，才能花费里面的钱。在此之前交易并不生效，无法执行。严格一点的定义就是在交易脚本里面设置时钟，必须要等设定时间之后，才能用地址的私钥签名解锁地址里的比特币。例如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
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。