什么是闪电网络 (Lightning Network)

闪电网路是比特币最具讨论度的 Layer 2 扩容方案之一，其背后的主要思想是设计一种支付协议，可用于比特币所面临可扩展性问题的链下解决方案。究竟比特币面对的问题是什么？闪电网路又要解决什么问题?这边用一个轻鬆的例子，简单介绍。

以比特币的交易速度来说，每秒只能处理2~7笔交易，想像一下用比特币进行支付，就像需要去银行排队转帐一样，一但交易量暴增，岂不是要在银行等到白了头？这种支付方式明显难以接受。

而闪电网路就像行动支付，你可以把一部分的钱存到行动支付，与任何支援的商家或个人快速地进行转帐。某一天夜深人静，阿平跟阿菜两人无聊，决定比赛，用行动支付互相转帐，每笔只转一块钱，看谁转的比较多。如果是传统的银行模式，两人可能排队排一夜只能玩个几次，还需要花手续费，根本没办法玩。透过行动支付一个晚上下来可以转上千次，最终结果是阿菜比阿平手速快，一块险胜。

而结算时行动支付会替他们去银行排队，然后跟柜台说 : 「阿平帐户余额 -1，阿菜帐户余额 +1」。读到这就能大致了解闪电网路解决方案的基本逻辑了。

重点来了，「闪电网路」要如何运作才能保证资产能够在无信任的前提之下进行交易，并保障交易能够安全的回到比特币主链上确认呢？以下就来介绍几项闪电网路的关键技术的概念。

单向支付渠道 (One-Directional Payment Channel)

在闪电网络出现之前，单向支付渠道的概念已经存在了一段时间了，但应用有限。Alice向Bob开啟了一个单向支付渠道，在这渠道中Alice有10BTC，Alice可以向Bob支付链下交易，但这个渠道是单向的，也就是说Bob不能通过相同的渠道支付给Alice。

假如Bob在接收到1颗比特币后:

• 可以选择关闭渠道，将交易广播至主链，让矿工做确认，即可从Alice那获得1颗比特币。

• 或者，Bob知道日后Alice会继续支付比特币给他，选择让通道继续开着。

问题来了，Bob拥有最后的签名与广播权，如果Bob是个无赖，让通道一直开着，Alice就永远没办法结算，10BTC就会被被绑架在这个支付渠道中。所以一般而言，支付渠道都会搭配一个配套措施「时间锁」。

时间锁 CheckSequenceVerify（CSV）

所谓的时间锁就是，在创建通道时会先约定好一个时间，时间一到，通道就必须强制关闭，有两人签名的交易将会上链做交易确认，没有签名的余额，会被返回给原持有人。

Alice和Bob在创建时，约定好在1000个区块后，通道必须关闭。所以Bob必须要在时间到之前，签名并广播交易，才能拿到Alice给他的1颗比特币。如果Bob迟迟不签名广播，一但约定时间到，Bob将一毛钱也拿不到。

双向支付渠道 (Bi-Directional Payment Channel)

单向支付渠道之所以简单，是因为交易是单向的，只允许两个人中的其中一个人发送交易，另一个人广播交易，不会有信任问题，但应用场景相对有限。

有鑑于单向渠道在应用上的不足，闪电网路想要打造的是无信任的双向支付渠道，让渠道的双方能够自由进行交易。那么闪电网路要如何避免交易双方产生信任问题，实现双向支付渠道呢？

所谓的信任问题包括:

• 双向支付渠道代表双方都必须有部分资金在渠道，那资产会不会被捲款?

• 如何保证最终结算不会有误?

• 支付渠道是P2P网路，没有验证机制，谁来保护帐本?

RSMC 可撤销顺序成熟度合约 (Revocable Sequence Maturity Contract)

RSMC 其实就是资金池，打开支付渠道时，双方将资产放入这个资金池中，封起来各自用一把钥匙锁上，交易时不会真的动用到该笔资金，而是用合约的方式纪录两人在资金池裡的剩余资产，等到关闭通道时，才会打开这个资金池做结算。

双向支付通道如何运作？

从头到尾，涉及的双方只需要与比特币区块链进行两次互动。一次打开支付渠道而另一次是关闭渠道，在这之间发生的所有其他交易都不直接与主链接触，这意味着，只有在双方都同意并签名的状态下，交易才会被确认。

假设 Alice 和 Bob 打算频繁进行交易，双方同意开闢双向支付通道，并约定好在 1000 个区块后强制结算。Alice 和 Bob 必须先在链上开啟一个多重签名钱包，才能开闢双向支付通道。

此时双方会各自生成一组 Secret Key (钥匙) 以及 Hash (锁头)，Hash 会交给对方，Secret Key 自行保管。在开闢双向支付渠道后，Alice 和 Bob 每次支付都像签一次合约，在签新合约之前会废弃掉旧合约，要注意的是当旧合约作废的同时彼此将取得对方旧合约的 Secret Key，而合约的内容就是关于如何重新分配资金池的资产。

共同签名钱包裡的钱只能在三个条件下解锁：

1. 锁定时间到了

2. 任何一方通过对方的 Secret Key 从他们设置的多重签名钱包中解锁资金

3. 合约有双方签名，且其中一方广播

要注意的是，如果一方决定关闭支付渠道并广播交易，广播的那一方将不得不等待到交易签名时设置的预定时间到，才能收到他那部分的资金。

会不会有人作恶？

例如：闪电网路中的其中一位参与者广播对于自己有利的旧合约来进一步图利，而非依照正常程序广播最新的合约。

此时，上述的两个值得注意的点就派上用场

• 当旧合约作废的同时彼此将取得对方旧合约的Secret Key

• 如果一方决定关闭支付渠道并广播交易，广播的那一方将不得不等待到交易签名时设置的预定时间才能收到他那部分的资金

假如 Alice 企图广播旧合约恶意结算关闭通道，依照上述闪电网路的机制，Bob 与 Alice 都拥有对方旧合约的 secret key，且 Alice 必须等到预定的时间到，才能拿到旧合约中Alice 的那份 BTC，所以 Alice 只要广播旧合约，Bob 即可在 Alice 等待的时间中使用旧合约的 secret key 将 Alice 的那份 BTC 取走，这样一来 Alice 不但没有成功广播对他有利的旧合约，还为他的恶意行为付出代价。

读到这边，我们就把双向支付通道的运作方式全都说完了。接下来要介绍的是，双向支付通道如何编织成为支付网路。

支付网路

现在，除了 Alice 和 Bob 之间有支付通道之外，Bob 也和 Carol 开了支付通道。Alice 如果要向 Carol 支付 1 颗比特币，该怎么做呢?

Alice 可以选择直接跟 Carol，建立一个支付渠道，但是这样做对 Alice 跟 Carol 来说，必须在主链上建立多重签名钱包还要打币，不仅麻烦而且又需要额外成本。相信大家都想到解决方法了，Alice 只要透过现有的支付通道，先把 1 BTC 打给 Bob，Bob 在将 1 BTC 打给 Carol，这样就可以在不用负担额外成本的情况下完成交易了。但是，这同时也存在几个信任问题。

1. Bob 不老实，拿了 Alice 的 BTC 之后私吞，不交给 Carol。

2. Carol 拿了钱，却跟 Alice 说他没拿到钱。

如何解决这部分的信任问题，就要仰赖闪电网路的另一项核心技术「HTLCs」。

HTLCs 哈希时间锁合约 (Hash Time-Locked Contracts)

要解决上述的信任问题就必须做到两点:

1. Alice 要确定 Carol 本人确实有收到比特币

2. 必须确定 Bob 不会拿走这笔比特币

还记得我们之前介绍过的公钥与私钥吧，HTLCs 就是用同样的概念下去延伸，我们把钥匙想成私钥，锁头就是公钥。假设 Alice 需要付给 Carol 1 个 BTC，收款方 Carol 会创建一个Value (钥匙) 和对应的哈希值 (锁头)，然后把锁头交给 Alice。

这裡就是这个技术的精华。

” 只要拿得出钥匙就代表他是 Carol “

” 只有 Carol 拥有钥匙，换言之，只有 Carol 能够打开锁头 “

在这个前提下，Alice 和 Bob 提出一份合约，如果 Bob 在 3 天内（Lock time = 3 day），提供哈希值对应的 Value，Alice 就给 Bob 1.0001 BTC，超过 3 天，BTC 原路返回给 Alice。

Carol 也同样跟 Bob 签订一个合约，只要 Carol 提供哈希值对应的 Value，就必须给 Carel 1 BTC。

于是，Carol 向 Bob 提供 Value，从 Bob 那获得了 1 BTC。Bob 将这个 Value 交给 Alice，从 Alice 那获得了 1.0001 BTC，这当中的价差 0.0001 BTC 就给 Bob 作为手续费。

闪电网路的优势

闪电网路致力于比特币可扩展性问题的链下解决方案。如果成功，可能会大幅减少比特币区块链的负载，增加比特币的实际应用可能。

通过使用双向支付渠道，闪电网路可以实现近乎即时且极低成本的交易。

闪电网路的侷限性

与链上交易不同，如果接收方处于离线状态，没办法做交易确认，无法进行支付。

网路的参与者可能需要定期监控支付渠道，以保证他们的资金安全。

闪电网路较难支援大额付款。闪电网路交易时有时需要仰赖中间人，举个例子，闪电网路中存在 Alice、Bob 和 Carol 三人，Alice 要发送 1 BTC 的交易给 Carol ，这中间需要经过 Bob，如果 Bob 的余额不足 1 BTC ，这笔交易便无法顺利完成，因此交易金额会受限于中间人的资产余额。

闪电网路的实用性取决于网路大小，若使用人数不足，闪电网路便难以发挥其价值。越多的人加入，闪电网路才会更加健全且完善，流动性也才能随之提升。