“If a tree falls in the forest and no one is around to hear it, does it make a sound?”这句引言来自于18世纪哲学家George Berkeley，也是Joseph Poon和Thaddeus Dryja在2015年提出的“闪电网络(Lightning Network)”的理念根源。就像无人听闻的陨落无足轻重一样，日常重复的交易也不必人尽皆知。
对于比特币网络来说，交易双方如果有多次交易，大可不必将每次的交易都同步到网络的每个节点。只需将多次交易后，交易双方最终的资金分配状态上报给比特币网络，既可以保证资金状态的最终正确性，也可以缩减交易双方在低效的比特网络上的等待时间提升交易频次，还可以降低对比特币网络的计算及存储资源的消耗。可以说同时解决了比特币网络高延时、低吞吐的问题，打破了困扰比特币多年的性能瓶颈，也为降低交易存储量提供了极好的方案。
本文将探讨“闪电网络”这个看似“完美”的解决方案的技术原理。闪电网络是基于微支付通道演化而来，将其单向支付通道扩展为双向支付通道，并通过RSMC(Revocable Sequence Maturity Contract，序列到期可撤销合约)解决双向通道中历史合约作废的问题，通过HTLC(Hashed Time Lock Contract，哈希时间锁定合约)解决跨节点交易的问题，最终形成了一张比特币链下的不依赖可信第三方和可信交易对手的支付网络。
1. 单向支付的微支付通道
微支付通道的提出为交易双方建立小额的支付通道提供了解决方案，其具有高性能低手续费、安全性强、通道内资金单向流动及通道有时限等4个特点：
1.1高性能，低手续费
1) 仅需发生2笔与比特币网络上的通信(即2次发生在比特币网络上的交易)。交易双方仅需在建立和关闭通道时与比特币网络通信，第一次通信建立微支付通道，第二次通信将在通道内发生的交易的最后结果发布到比特币网络上。
2) 通道内的资金交易以点对点通信方式进行。通道内的支付只需交易双方签名认可，免去了复杂的网络传播与验证，交易速度近实时。且点对点的交易手续费几乎可以忽略。
1.2 安全性强
1) 交易双方利用双签名账户构建支付通道。支付通道内的交易需要有交易双方的签名认可否则无法被发布到主链上。
2) 付款方在收款方消失的情形下仍能取回余额，保障付款方权益。如下图1所示，Alice在签署存款合约(Fund Contract)将10 BTC存入双签名账户之前，会要求Bob先签一份退款合约(Refund Contract)，合约中会确定一个拿回余额的时间点。在这个例子中退款合约表示在4月30之后，Alice可以将这份合约签名并发布到比特币网络上，成功后双签名账户中的10 BTC将退至Alice的账户。如此，Bob无法通过拒绝发布交易合约阻止Alice拿回通道中的余额而进行敲诈。
说明：图中对于签名，加括号的部分表示待签名，不加括号的部分表示已签名
来源：Dryja在MIT的授课内容，火币研究院整理
3) 付款方无法对已发生的交易抵赖，保障收款方权益。如图2所示，每次发生新的交易，Alice都会签署一份余额重新分配的合约发给Bob。图中的tx1表示Alice向Bob付款1 BTC，tx2表示Alice再向Bob付款3 BTC。但如果此时Alice期望通过tx3将10 BTC全部拿回来，抵赖掉之前的两次付款，是做不到的。因为tx3尚未得到Bob的签名，无法发布，而Bob只需忽略tx3，将tx2签名并发布到比特币网络上就可以拿到应得的4 BTC。同时可以注意到，微支付通道对试图抵赖者(此处为Alice)没有惩罚机制，剩余的6 BTC仍将回到Alice的账户。
说明：图中对于签名，加括号的部分表示待签名，不加括号的部分表示已签名
来源：Dryja在MIT的授课内容，火币研究院整理
1.3 通道资金单向流动
微支付通道只适用于Alice向Bob付款的场景，不适用于Alice与Bob互相转账的情形。通道在能力上并没有限制资金的双向流动，但从资金Bob流向Alice的交易是不可信的交易，即便Bob签署了一份付款合约发送给Alice，Bob仍可以将发生该份合约之前的合约签署发布，从而抵赖掉这次付款。
1.4 通道时限
微支付通道通过时间锁机制保障了付款方的权益(上文2.1.2小节中提到)，但同时会使通道最长只能保留到时间锁的到期时间。一旦到达截止时间，即便通道内的金额并没有完全被支付或者交易双方仍存在支付需求，通道会被关闭。如果不关闭，上例中，通道中的10个BTC将全部返还给Alice，Bob显然不会允许这样的情况发生，其会在截止时刻之前发布通道中最新的合约并关闭通道。
2. 更进一步的RSMC
为了给交易双方提供双向的及更长期的支付通道，闪电网络在微支付通道的基础上设计了RSMC(Revocable Sequence Maturity Contract，序列到期可撤销合约)。随之带来的是更复杂的签约机制和防抵赖机制。
RSMC中主要涉及了5种交易：
1) 存款(fund)：建立通道之初通过“存款”交易将双方的资金存入双签名钱包，将存款交易广播到比特币网络就意味着双方建立了支付通道。但在广播之前需要先签署一份“提交”交易，保证对手方消失的情况下仍能取回双签名钱包中的资金(上文的微支付通道中通过“退款”交易实现)。
2) 提交(commit)：支付通道建立后，交易双方在通道内进行资金往来时通过“提交”交易来实现。该交易的特征是一式两份，每一方都会签署好交易信息递交给对手方。参与者如果想终止支付通道可以将对方署过名的合约签字并广播到区块链网络，进行资金分配并关闭支付通道。
3) 分配(delivery)：“分配”交易是具体执行资金派送的交易，该交易执行完成后资金将抵达目标账户。通常指的是不可撤销的分配。
4) 可撤销的分配(revocable delivery)：同样是资金派送的交易，但该交易的执行可能因为其他交易的执行而被撤回。在RSMC中主要会因为“违约补偿”交易的执行而被撤回。
5) 违约补偿(breach remedy)：RSMC中核心的防抵赖机制，当对手方企图通过发布历史交易而抵赖后续交易时，可以通过发布“违约补偿”交易罚没对手方的所有资金。
本文将在Alice与Bob的交易中详细探讨这5种交易如何相互配合实现高效可信的支付通道。
2.1 支付通道的建立与交易
1) 存款交易与信任问题
如图3所示，是Alice与Bob支付通道的建立与通道内的资金往来的流程。最初，Alice出资2 BTC，Bob出资8 BTC，双方签订“存款”交易，计划将钱存储到二人的双签名钱包中。但由于双签名钱包中的资金只有在双方均签名认可的情况下才能被动用，二人都会担心，尤其是出资更多的Bob，如果对方消失自己将无法取回钱包中的余额，甚至对方可能会以不签名为要挟进行敲诈。因此，在广播“存款”交易之前，双方都需要得到能拿回账户余额的保证，这份保证通过一份“提交”交易实现。
2) 提交交易与通道建立
如图3所示，State 1的时候，Alice和Bob各会签署一份提交交易给对方持有。以Alice持有的提交交易C1a为例，该交易输入为双方的签名，此时Bob已经签名但Alice自己尚未签名。
该交易的输出为资金的分配方案的脚本，该脚本此时并不会执行生效，只有当Alice签名并广播该交易时输出中的脚本才会执行。其思想类似于员工与公司签订了竞业协议，但在签订之时协议中的索赔条款并不会被执行，只有当员工违反条款触发竞业时，公司才会起诉员工并执行索赔条款的内容。
来源：Dryja在MIT的授课内容，火币研究院整理
输出脚本的能力包含，1.将8 BTC归属给Bob；2.剩余2 BTC分两种情况处理，如果使用Alice的钥匙取款，则在等待100个区块后2 BTC才能归属给Alice，如果使用AliceR1(这把钥匙将在下文中介绍)和Bob的钥匙共同取款，则2 BTC会立即归属给Bob。因此，即便对手方Bob消失，Alice也可以通过广播C1a，在等待100个区块之后将自己的资金取回。
通过C1a和C1b交易的签订，双方建立了打款的信任基础，此时存款交易会被广播到区块链网络，Alice和Bob之间的支付通道就建立了。
3) 支付通道内的交易
在支付通道建立之后Alice与Bob的交易就可以在通道内进行，不必广播到区块链上。每笔交易只需通过签订“提交”交易并传递给对方即可，在交易双方均在线的情况下可以实时完成，对比区块链上10分钟的等待是一个质的提升。
如图3所示，State 2时Alice与Bob开始了新一轮的交易，通过互换签字后的“提交”交易C2a和C2b，Bob向Alice付款4 BTC。值得注意的是，在Alice与Bob互换合约时，也向对方公布了自己上一轮交易的撤回密钥AliceR1和BobR1，用于向对方声明上一轮持有的“提交”交易C1a、C1b作废，资金的分配以State 2的“提交”交易C2a、C2b为准。
Alice与Bob可以按照此规则在支付通道内进行资金往来，不同于微支付通道的是此处没有时间锁，因此通道理论上可以永远存在，直到交易的一方主动关闭支付通道。
2.2 支付通道的正常关闭
当Alice或者Bob认为二者的资金交易结束或者想要取回双签名钱包中的资金时，可以将最新的“提交”交易在区块链上广播进行资金分配。
如图4所示，以Alice为例，她可以将C2a广播，C2a中的输出脚本将会执行触发D2a“分配”交易。分配时，Bob会立即取回4 BTC，但Alice还需等待100个区块的时间才能取回6 BTC。这是RSMC对率先提出结束交易一方的“惩罚”。
“分配”交易执行结束后，Alice和Bob关闭了交易通道并在比特币网络上登记了自己的最终资金状态。
来源：Dryja在MIT的授课内容，火币研究院整理
2.3 RSMC中的抵赖与违约补偿
由于基于RSMC建立的支付通道并没有在物理上作废历史状态的交易，理论上，参与者仍可以通过广播历史交易来抵赖后续的付款交易。但RSMC巧妙设计了惩罚机制阻止此种情形发生。
来源：Dryja在MIT的授课内容，火币研究院整理
如图5所示，假设Bob企图通过发布State 1 的C1b来抵赖State 2发生的付款交易并关闭支付通道，D1b将会被触发执行，Alice在State 1中的余额2 BTC将立即被分配到Alice的账户中。剩下的8 BTC将通过RD1b“可撤回分配”交易，在C1b发布后100个区块分配到Bob的账户中。但100个区块的产生是很长的一段时间，如果Alice在此期间发现了Bob的抵赖行为，可以拿着Bob给她的BobR1撤回钥匙广播BR1b“违约补偿”交易，将双签名电子钱包中剩余的8 BTC全部拿走，同时使RD1b交易失效。被抵赖者既拿回了自己的资金，也通过罚没钱包中所有资金的方式惩罚了抵赖者。由此消除了支付通道内交易的对手风险。
值得一提的是，2019年瞭望塔机制已经开始逐步应用到闪电网络的节点中，即便用户处于离线状态，也可委托瞭望塔为其监控资金是否遭到窃取，一旦遭到窃取，瞭望塔会代替用户广播“违约补偿”交易。用户不再需要隔一段时间就上线检查对手是否作弊，大大降低了用户对闪电网络的使用成本。关于瞭望塔会在本文的5.1小节做更深入的探讨。
3. 编织网络的HTLC
RSMC在微支付通道的基础上为用户两两之间的资金交易提供了长期、高效的解决方案。但如果每两个用户需要交易时都需要建立新的支付通道，将会大幅增加网络中的连接数，每个通道的建立也都需要比特币网络的处理(必然就涉及了等待和交易费用)，这并不经济。HTLC(Hashed Time Lock Contract，哈希时间锁定合约)提供了借用网络中已经建立的连接，使未直连的用户能够进行可信的资金交易的解决方案。只要网络中有一条路径能连接交易双方就可以进行可信交易，大幅提升了网络的扩展性。
3.1 多方参与问题
如图6在没有HTLC的情况下，如果未建立支付通道的Alice想向Carol转账1 BTC，就需要与二人都建立过支付通道的Bob的帮助。Alice先将1 BTC转给Bob，Bob再将其转给Carol。这需要一个可信的Bob才能保证支付顺利完成，因为Bob可能会将这1 BTC中饱私囊。即便Bob可信，这种交易方式也违背了比特币的初衷——通过分布式账本避免依赖可信的第三方。
来源：Dryja在MIT的授课内容，火币研究院整理
3.2 HTLC的处理流程
HTLC通过巧妙利用哈希时间锁保证了中间的路由节点无法扣留路过的资金，也不需要依赖可信的第三方来做担保。如图7所示为HTLC的处理流程。
交易的发起。当Alice要向Carol付款1 BTC，正式发起交易之前，Carol会先自己准备好一个R，然后对其哈希加密生成H(注意无法通过H反推出R)，即H = Hash(R)，并将这个H传输给Alice。
正向传递H建立HTLC。Alice拿到H后，会将H发送给Bob，并向Bob发起HTLC的转账交易。如果Bob能在15:00(仅是一个示例时间)之前告诉Alice H对应的R是多少，Bob就可以拿到1 BTC，否则，Alice可以拿回1 BTC。Bob在与Alice签订HTLC合约并拿到H之后，会对Carol进行相同的操作，签订合约并传递H，同时设立一个更早的截止时间14:00。
反向传递R清除HTLC。Carol拿到H后发现与自己持有的H相同，于是将R匹配到HTLC中拿到1 BTC，并告知Bob R。同理，Bob可以凭借R拿到Alice的1 BTC同时结束与Alice的HTLC。整个交易结束。
这个过程中，路由节点Bob要通过R才能拿到Alice的1 BTC，但为了拿到R，他不得不先向Carol交出1 BTC，无法中饱私囊，由此解决了中间节点作恶的问题。
来源：Dryja在MIT的授课内容，火币研究院整理
值得注意的是，链路上的锁定时间必须是递减的，假设Alice和Bob约定的截止时间是15:00而Bob与Carol的约定时间是16:00，则Carol可以在15:30时通过R拿走Bob的1 BTC，而Alice的1 BTC已经在15:00时取回了，Bob就会遭受损失。但由于Bob和Carol交易的截止时间是由Bob定的，所以Bob自身通过合理安排时间可以避免这种情况的发生。
同时，RSMC和HTLC可以在同一个“提交”交易中拟定的，具体形式如图8所示。
来源：参考闪电网络白皮书及Dryja在MIT的授课内容整理而得
3.3 路由与手续费
读到这里读者心中可能会有疑问，Alice如何知道Bob可以连接到Carol，而Bob又为什么要帮助Alice向Carol转账呢？这就涉及到HTLC的路由机制与费用机制了。
路由
针对路由，HTLC使用了源路由与洋葱路由的机制。网络上所有的节点会发布自己路由信息和资金限制形成支付通道表。交易的源头(发起方)通过该表计算起点到终点的路径并指定交易通过该路径执行。同时，利用洋葱路由的机制，使得每一个路由节点都只知道相邻的节点，无法了解整条路径，由此达到保护隐私的目的。这两种机制均是已有的路由机制，被应用到了闪电网络的构建中。
手续费
实际上，作为中间节点的Bob可以标明他路由的手续费，如0.01 BTC，那么Alice在向Carol转账1 BTC的交易中，会在与Bob签订交易时向其支付1.01 BTC，而Bob向Carol支付1 BTC，达到了手续费收取的效果。如果Bob是一个天价手续费收取者，Alice在计算路由方案时就会将Bob排除在外，选取别的路由节点。
4. 闪电网络
由此，RSMC与HTLC互为助力，RSMC解决资金单向流动的问题，HTLC解决多方参与的问题，在比特币二层链下形成了高扩展性的支付通道——闪电网络。
