1 摘要

比特币闪电网络是一个去中心化的即时、大吞吐量微支付系统，该系统无需委托可信的第三方代管资金，也没有相应的风险。实现的方法是创新性的利用比特币内置脚本构建支持链下（off-chain）安全确认交易的通道网络，并利用比特币区块链作为法庭确保链下交易确认安全。

闪电网络的思路并不局限于比特币，也适用于类似的数字货币（如以太坊），其方法甚至可以扩展为一种跨链技术以实现在不同账本之间转移价值。

本文仅做概念性的介绍，并不涉及闪电网络实现的细节，有关闪电网络实现的细节，可以参阅闪电网络论文原文 (by Joseph Poon, Thaddeus Dryja, 2016)。

2 比特币区块链可扩展性问题

  1. 交易确认缓慢 - 每 10 分钟一个区块，交易要安全的确认需要至少 6 个区块，使得交易确认缓慢
  2. 可扩展性问题：
    • 交易吞吐量有限：所有交易均广播上链，单个区块容量有限，每秒中仅支持小于 10 笔交易
    • 区块大小迅速增长限制节点参与并导致集中化风险： 随着比特币交易需求的快速增加，动辄数百 Gigabyte 甚至数十 Terabyte 的区块大小限制普通节点（如个人 PC 和移动终端）加入网络，也会导致参与节点的集中化风险。

有关比特币可扩展性问题，比特币社区有很多讨论和提案，有兴趣的朋友可以参阅比特币扩展方案评论 (Bryan Bishop, 2015) 。

3 闪电网络方案

解决问题的基本思路是，在无需引入可信任第三方中介的前提下，如果有合适的方法能够在链下安全的确认交易，就不必要把所有的交易广播上链。

Figure 1: 比特币闪电网络示意图

Figure 1: 比特币闪电网络示意图

闪电网络是由微支付通道相互链接形成一个巨大网络，能够实现链下确认交易，链上（on-chain）实施不合作节点惩罚和有效交易净额清算（Net-settlement），并且能够以去信任（Trustless）的方式实现网络中任意节点之间的价值转移。

闪电网络的设计目标：

  • 即时支付：闪电网络的交易不需要区块确认，交易可即时在链下完成确认。
  • 微支付低费用： 闪电网络使用真正的比特币交易，却最小化交易结算（交易广播上链）的需要，可以以极低的费用实现小到 0.00000001 比特币的交易。
  • 大容量可扩展：闪电网络交易在链下确认，允许用户执行近乎无限的微支付交易，可以满足诸如物联网设备间的自动大量交易。

3.1 微支付通道和 RSMC

闪电网络支持交易双方共同出资以创建一个双向微支付通道，随后双方可以通过该通道链下确认相互之间的一系列交易而不用交易广播至链上确认，只有在需要最终结算和其中一方不再合作的情形下才需要广播交易上链。作为类比，闪电网络通过将比特币区块链作为法庭，算法做法官，结合RSMC（可撤销序列成熟度合约）机制提供证据，共同确保链下确认支付的安全：

  • 可撤销序列成熟度合约机制提供链下交易确认证据 - 有效交易和无效交易证据
  • 净额清算 - 通过广播上链有效交易（即最后一笔交易）就可以实施净额清算
  • 违规惩罚 - 一方违规，如上链对自己有利的老旧交易，另外一方则可以通过上链相应的违规补偿交易（Breach Remedy Transaction）作为证据，即可实施违规惩罚，结果是所有通道资金均归能够提供违规证据的一方所有，惩罚由算法强制执行。

3.1.1 微支付通道创建和链下交易确认

[[006tNc79gy1ftqx4xdj4hj31250h93zy.jpg

该示意图展示了微支付通道和 RSMC 如何工作。

  • 爱丽丝和鲍勃各出资 0.5 BTC 建立一个支付通道，该通道建立意味着，双方共同签名的资金交易广播上链（图中 on-chain 一侧）并且双方的第一笔链下交易（图中 off-chain 一侧 Alice 0.5 / Bob 0.5 ）已经确认。
  • 随后双方可以通过该通道链下确认相互之间的一系列交易重新分配资金交易金额而不用把交易广播至链上确认。一笔新的交易会事实上作废前一笔历史交易，因为交易机制会导致提交历史交易的一方损失资金，结果是只有最新的一笔交易才是有效的。
Figure 3: 新交易详细示意图

Figure 3: 新交易详细示意图

  • 一次新交易，双方会拥有该次交易各自的版本，如最近的一笔交易，爱丽丝拥有 Cna 和 RDna 交易而鲍勃有自己相应的版本 Cnb 和 RDnb（如上图）。交易 Cnb 中，交易输出 0 的意思是爱丽丝可花费该输出 0.8 BTC，交易输出 1 是一个带有RSMC的 2-of-2 签名输出，鲍勃持有子交易 RDnb 以 RSMC 合约约定的方式花费该输出。交易 RDnb 是交易Cnb的子交易，其输入来自 Cnb 1 RSMC 输出，并带有值为 1000 的时间锁，这意味着，该交易只有在父交易 Cnb 上链确认后，还需要等待 1000 个比特币区块链以后才能被确认。这就是对方实施违规惩罚的窗口期。
Figure 4: 老交易详细示意图

Figure 4: 老交易详细示意图

  • 伴随新交易的产生，老旧交易事实上被作废，作废的方式是产生一个相应的称之为违规补偿的交易，例如，老旧交易 C3a 的子交易 BR3a，以及 C3b 的子交易 BR3b。以鲍勃持有的交易 C3b 为列，交易 BR3b 没有时间锁，允许爱丽丝立即花费交易 C3b 1. RSMC 0.7 BTC 输出，这事实上撤销了交易 RD3b， 因为 RD3b 具有时间锁，需要在父交易上链确认后再等待 1000 个比特币区块链以后才能被确认。

3.1.2 净额清算和惩罚

在微支付通道建立并存继期间，双方可以链下确认多笔交易直到通道关闭，有三种情形导致清算并关闭通道。

  • 双方合作上链清算 - 双方可能不再有业务来往和交易的必要并希望能够赎回各自的资金，双方可以通过创建另外一次交易，该交易不带RSMC输出，直接按最后一次交易的份额分配交易输出并交换签名。任意一方广播上链最后这笔交易即可完成最后净额清算。
  • 单方面提交最后一次交易 - 例如爱丽丝想赎回资金而由于联系不上鲍勃等原因，无法合作关闭通道，爱丽丝可以单方面上链自己拥有的最后一次交易而关闭通道，在该情形下，鲍勃可以立即获得最后一次交易中自己的份额，而爱丽丝必须等待如 RDna 交易指定的时间锁到期后才可以赎回自己的份额。
  • 任意一方违规提交老旧历史交易 - 这种情形事实上并不会发生，但一旦发生，对方可以提交违规补偿交易以实施惩罚。例如，鲍勃提交了对自己有利的历史交易 C3b，那么，按照鲍勃拥有的 RD3b 交易来看，他需要在 C3b 被广播上链确认后，RD3b 仍需要等待 1000 个比特币区块后才能够被上链确认。在此期间，爱丽丝发现鲍勃违规提交老旧历史交易，她可以通过广播 BR3b 交易，该交易没有时间锁，可以立即上链确认并花费 C3b 1. RSMC 0.7 BTC输出，考虑到 C3b 0 号输出的 0.3 BTC 本就归属爱丽丝，这样一来，相当于通道所有资金均归爱丽丝所有。当然了，广播违规补偿交易是爱丽丝的责任，如果爱丽丝在惩罚窗口期没有上链违规补偿交易，则鲍勃到期可以花费 C3b 1 号输出的 0.7 BTC。这就是闪电网络的惩罚机制。

3.2 闪电网络和 HTLC

通过 HTLC 可以在闪电网络任意节点之间安全转移价值而无需信任中介节点。

Figure 5: 闪电网络HTLC工作示意图

Figure 5: 闪电网络HTLC工作示意图

该示意图展示了 Alice 如何使用 HTLC 通过闪电网络转账给 Dave 一笔资金，假设 Alice 和 Dave 之间并未建立一个微支付通道但可以通过闪电网络建立起一条 Alice 和 Dave 之间的临时支付路由通道。

  1. 首先双方通过其他通道（绿色线条所示），Alice 告知 Dave 要转 0.01 BTC 给 Dave，Dave 产生一个随机像原R，以及R的散列H，Dave 保留 R 并把散列H传递给 Alice。
  2. Alice 和 Bob 之间有已经建立的微支付通道，Alice 可以产生一个 HTLC 合约并连同 H 送给 Bob (红色虚线所示)，该合约的意思是：如果 Bob 能够在合约过期（三天）内提供一个 H 值对应的像原 R 值，则合约规定的 0.01 BTC 就归 Bob 所有，如果合约过期，则返回合约金额给 Alice。同理，Bob 和 Carol，Carol 和 Dave 之间也可以建立类似的 HTLC 合约，区别在于合约过期时间是递减的。至此，红色虚线所示的 Alice 到 Dave 之间支付路由通道就建立了。
  3. 履行 HTLC 合约的过程也相当简明，由于 Dave 持有 H 的像原 R，就可以在 HTLC 合约（Carol 和 Dave 间的合约）过期前，通过把 R 传递给 Carol 以得到 HTLC 合约的资金。同理，Carol 通过把得到的 R 传递给 Bob 已从 Bob 哪里得到资金，最后，Bob 把得到的 R 传递给 Alice 以得到资金。至此，整个 HTLC 交易完成并关闭。

3.3 闪电网络相关名词

  • RSMC (Revocable Sequence Maturity Contract / 可撤销序列成熟度合约) - 一个交易合约，允许带有该合约的交易（父交易）输出只能在该交易确认后推迟指定时间（由子交易序列确定）花费，可以通过创建一个特殊的子交易来取代其他子交易并立即花费父交易输出。
  • HTLC (Hashed Time Lock Contract / 散列安全时间锁合约) - 一个比特币脚本，允许受托方提供一个指定散列的原始密文来花费合约资金，也允许委托人在时间锁过期后赎回资金。
  • 资金交易 (Fund Transaction) - 一个 2-of-2 多重签名交易，用于创建最初的支付通道资金池。
  • 可撤销承诺交易 (Revocable Commitment Transaction) * 资金交易的子交易，可以花费资金交易的输出，通过创建新交易并撤销老旧交易在交易通道双方重新分配资金额。
  • 支付交易 (Delivery Transaction) - 一旦承诺交易广播上链，该交易能立即从承诺交易赎回资金。
  • 可撤销支付交易 (Revocable Delivery Transaction) - 带有时间锁的支付交易，可延迟收回承诺交易资金。
  • 违规补偿交易 (Breach Remedy Transaction) - 用于对不合作节点实施惩罚的交易。

3.4 相关比特币改善提案 (BIPs)

3.4.1 BIP65: CHECKLOCKTIMEVERIFY

该BIP为比特币脚本系统引入一个新操作码 (OPCHECKLOCKTIMEVERIFY) ，使用比特币交易域nLockTime指定交易锁定时间，从而允许交易输出推迟至指定时间以后才能花费。闪电网络可以使用该机制创建微支付通道，但不便之处在于到期后需要清算并关闭通道。

3.4.2 BIP68: 基于交易序列号的相对时间锁

通过在比特币交易记录中引入交易序列号 (nSequence) 实现相对时间锁 (RLT)，确保签名交易的输入在其相应的前序交易确认后的指定时间内（现对于前序交易确认时点）保持无效。闪电网络使用 nSequence，但修改其原有的语意以实现 RSMC，好处是可以保持支付通道一直开启。

3.4.3 BIP199: 散列安全时间锁合约交易

一个散列安全时间锁合约（HTLC）是一个脚本，它允许受委托者通过提供一个散列的原始密文来花费合约资金，也允许委托人在时间锁过期后赎回资金。该比特币改善提案实现HTLC。

4 闪电网络引入的问题

4.1 流动性问题

闪电网络要求在支付通道内锁定资金，这可能会导致流动性问题，同时由于闪电网络具有大幅度降低交易上链的需求，可能会导致和矿工之间的竞争。

  • 网络流动性 (Network Liquidity) - 保持通道开放可用
  • 通道流动性 (Channel Liquidity) - 锁定部分资金以为通道提供可用的资金池

4.2 系统性攻击

闪电网络包含百万级别的支付通道，通道内锁定了大量的资金，特别是大的中介人通道容易成为系统性攻击的目标，并且隔离措施将不再起作用。系统性攻击看起来可能性不大，但一旦发生则会导致灾难性后果。

  • 支付通道相互链接并锁定大量的资金，系统性攻击会使所有通道参与方损失资金。
  • 支付通道特别是中介人通道包含大量历史链下交易（未广播交易），通过并发广播历史链下交易，攻击者可能得到更多的资金。
  • 系统行攻击可能导致很多交易上链，并带来高昂的交易费用

5 闪电网络的启示

闪电网络给我们最大的启示莫过于再一次证明创新的利用比特币脚本能够产生颠覆性革新应用。当然了，闪电网络的思想也不仅仅适用于比特币。

  • 创新利用比特币脚本能够产生颠覆行革新。
  • 闪电网络思想不仅仅可用于改善比特币网络，它同样适用于类似的数字货币，实际上，以太坊就有自己的闪电网络。
  • HTLC的思想也不仅仅限于比特币内部，它可以扩展为一个跨链技术以在不同账本之间交换价值。

6 参考文献

  1. Satoshi Nakamoto（中本聪），”Bitcoin: A Peer-to-Peer Electronic Cash System”, http://www.bitcoin.org/en/bitcoin-paper, 2009.
  2. Bryan Bishop, “Review of Bitcoin Scaling Proposals”, http://diyhpl.us/~bryan/irc/bitcoin/scalingbitcoin-review.pdf, 2015.
  3. Joseph Poon, Thaddeus Dryja, “The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments”, https://lightning.network/lightning-network-paper.pdf, Version 0.5.9.1 2016.
  4. Joseph Poon, “Time and Bitcoin”, https://lightning.network/lightning-network-presentation-time-2015-07-06.pdf, 2015.
  5. “SF Bitcoin Social”, https://lightning.network/lightning-network-presentation-sfbitcoinsocial-2015-05-26.pdf, 2015.
  6. BIP65 “OPCHECKLOCKTIMEVERIFY”, https://github.com/bitcoin/bips/blob/master/bip-0065.mediawiki, 2014.
  7. BIP68 “Relative lock-time using consensus-enforced sequence numbers”, https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki, 2015.
  8. BIP199 “Hashed Time-Locked Contract Transactions”, https://github.com/bitcoin/bips/blob/master/bip-0199.mediawiki, 2017.

本作品采用知识共享署名 4.0 国际许可协议进行许可。