学习闪电网络-1：技术原理和进展

May 22nd, 2022

Why this network could be democratic...
Numismatic...
Cryptographic!
Why it could be released Lightning!
(Release Lightning!)

（闪电网络 spec —— BOLT 中的主题歌）

1. 闪电网络现状

Layer2 一直是行业关注的热点，特别是今年 zkRollup 等项目。也可能是因为 Rollup 的叙事以及与以太坊生态的应用开发结合等，Rollup 可能已经成为了 Layer2 的代名词。

然而 OG 级别的 Layer2 解决方案——闪电网络的在很多时候可能被忽视了。从去年开始，包括技术底层和应用生态方面，都已经有了不错的发展，特别是在推特通过集成 Cash App 来支持闪电网络之后。

闪电网络的目前通道累积的比特币容量约为 3792 个，从去年 4 月的 1000 个 BTC 左右的容量规模有了较快增长。

闪电网络自去年有了较快增长，其中红色为通道中全部的 BTC 数量（来源 Bitcoin Visuals；4月25日的抖动经查证应该只是显示数据错误）

不过如果对比以太坊上各类“锚定”的比特币，闪电网络的规模距离 WBTC（28万个）、 hBTC（3万8千个）、renBTC（6千6百个）等仍有不小差距。

但从用户数量上，闪电网络的发展可能还会比较让人值得期待。根据 Arcane Research 的统计和预估，在 Cash App 等应用的帮助下，估计会有超过 8 千万的用户已开始使用闪电网络。

与之对应的，闪电网络作为一个快速的支付网络，交易量在 2021 年也有了快速增长。

2. 闪电网络的技术原理

闪电网络的思想和其他 Layer2 技术类似，也是将交易执行和结算分离，即把交易执行放在链外执行，以提高执行的效率；最终结算的时候，再将最终状态上链。

这个原理和状态通道（支付通道）类似，而闪电网络在技术上利用了 HTLC 和 RSMC 等技术来实现了支付通道的连接，来形成了支付网络。

如果将上述各种技术以迭代的关系来展开，闪电网络的技术可以有以下递进的关系：

支付通道（单向）：2-2 多签、时间锁
支付通道（双向）：在之前基础上，增加 RSMC
支付网络（闪电网络）：在之前基础上，增加 HTLC（哈希时间锁合约）

单向支付通道

单向支付通道的实现非常简单。只需要付款方（例如 Alice 付给 Bob）存入到一个 Alice 和 Bob 共同持有的 2-2 多签地址即可。

（来源：MIT Course: Cryptocurrency Engineering and Design）

准备退款合约

但在此之前， Bob 需要先给 Alice 签署一份退款合约（没有发布上链的交易信息），从链下传递消息给 Alice 持有（此时 Alice 未签名，即只有 Bob 的签名）。

这个退款合约约定了退款的日期，即此日期后，Alice 可以解锁 Alice 存在双签地址中的全部存款。这样保护了 Alice，防止 Bob 不配合后续流程而导致 Alice 资金被锁死。

存款上链

拿到 Bob 的退款合约后， Alice 此时可放心的将资金转入到双方的多签地址中，发布在比特币主网上。待主网交易确认后，即可进行下一步操作。

支付通道中付款

此时 Alice 可多次通过支付通道，以不断更新通道内双方余额的方式向 Bob 付款。

具体的付款方式是，Alice 从链下将存款合约发送给 Bob（只需要 Alice 签名信息即可，因为 Bob 在需要时可自行添加自己的签名来解锁多签交易）；而这个合约的输出内容，即 UTXO 的输出信息，则是 Alice 和 Bob 在该笔交易后分别的通道内余额。

Alice 通过不断签署新的合约，来完成通道的内付款（状态更新）。

通道关闭/结算

整个通道是有时限的，因为 Alice 持有了一个退款合约。在到期后，Alice 可发布到主网上取走通道内的全部资金。所以，Bob 必须在 Alice 发布前将包含最新的通道状态的合约，发布上链，完成整个的结算。

可以看到，支付通道只与主网发生了两笔交易，分别对应到通道的开始（存款）和关闭（结算）。中间的多次付款都不需要全局的共识和链上手续费，效率高、成本低。

但是，单向通道存在一些问题：

只能单向 Alice -> Bob。因为如果需要 Bob 付款，Bob 会选择性的把自己余额最大的那个合约信息广播上链，从而抵赖掉 Bob 的付款信息。
总时间有限。因为退款合约的时间锁限制，到期后就得通道关闭。

双向：RSMC

双向状态通道在单向支付通道的双签基础上，需要增加使用 RSMC，即 Revocable Sequence Maturity Contract

原理是：

双方各自产生 Revocation Key（Alice 和 Bob 的分别记作 AliceR、BobR）
双方通过不断互换合约来“刷新”状态
- “刷新”时，利用 Revocation Key 来“撤销”（作废）掉上一个状态
- 将 Revocation Key 交给对方（Alice 将 AliceR 交给 Bob）
- 双方同时需要新生成一个 Revocation Key （AliceR' 和 BobR'）

存款前

和单向支付通道在存款前类似，Alice 也需要先持有 Bob 的“退款合约”。但在基于 RSMC 的双向通道中，这个被称为是“提交”（commit）。

存款

Alice 和 Bob 双方互持 Revocation Key 之后，即可分别存入资金到 2-2 多签地址中，进行存款上链的交易。

与退款合约类似的，Bob 对该“提交”合约也已签名；不同之处在于，输出脚本解锁条件为，Alice 在若干区块后可解锁或者 Bob 在提供了 AliceR 的信息后解锁。

交易

具体的过程可由付款方先发给对方 Revocation Key（收款方没有动机去撤销掉收款的交易）

例如 state 1 -> state 2 是 Alice 付款给 Bob
那么 Alice 先出示 AliceR
Bob 再出示 BobR
双方可删除上一笔交易

闪电网络

RSMC 解决了两方间的双向支付通道问题。但如果涉及到多人，直接从双签（2-2多签）扩展到多签的方式并不具有大规模的可扩展性。但可以基于两方的支付通道上，增加更多技术来将多个支付通道连接起来，形成可支付的闪电网络。

（来源：A Technical Introduction to The Lightning Network）

最典型的实现支付通道连接的技术，是 HTLC（Hash Time Lock Contract）。

原理是在 RSMC 之上，收款人要新创建一个自己持有且待传递的 R。

1.收款人 Carol 根据 R 计算出 H。 H = Hash(R)，即 R 是 H 的原像

2.收款人 Carol 将 H 交给付款人 Alice，由付款人 Alice 增加在 UTXO 的输出解锁条件中

合约形式的解锁条件也变为下图的形式。下图的例子中，Bob 只要向 Alice 揭示 R 即可付款（更新通道内的状态）

3.正向的传播 H ，例如，从 Alice 和 Bob 的通道内先用 H 更新合约；然后 Bob 和 Carol 的状态通道也类似的使用 H 来更新。

但是在传递过程中，需要确保前一段付款人可收回退款的时间，要晚于后一段付款人的可收回退款时间。例如，下图例子中的 Alice 给 Bob 的付款可在 17:00 后收回，而 Bob 给 Carol 的付款可在 16:00 （早于17:00）收回。

4.反向的消除，例如收款人 Carol 通过揭示 R 来向 Bob 收款（Bob 验证 H=Hash(R) 之后，Bob 和 Carol 即可更新双方间的通道状态）

因此，闪电网络实际上是通过传递 R 来实现连接多个状态通道的收付款。同时也会利用 Tor 等技术来网络信息的隐匿，即中间人不知道实际的连接起点和终点。

3. BOLT

闪电网络的核心技术原理还是相对比较简单的，但是如果要真正用在实际环境中，还需要考虑各种异常情况以设计和约定好相应的处理方法。

例如，上文提到的超时时间该如何设置？如何避免节点知晓全部路径以防止其与路径上的其他节点串通？中间付款失败时如何处理？以及是否有更优的技术实现来替代原像的传递等等。

在基于比特币脚本等有限的可编程能力的情况下，这些规范尤为重要。

BOLT 协议就是闪电网络对各种层面上通信和应用处理的一个全面的协议，用来解决上述问题。

和网络通信协议 TCP/IP 以及区块链 IBC 协议等等类似，BOLT 协议包括了各个层面上的多种子协议。包括：

网络连接层
消息层
P2P 层
路由层
支付层

其中的一些实现也可以替换，例如，Bolt 11 原定义的是通过 HTLC 的原像与哈希的方式来生成和传递 invoice，但也可以改用 PTLC（点时间锁合约）。

4. 一些比较重要的改进

PTLC

PTLCs（Point Time Locked Contracts，点时间锁合约）从 2018 年左右开始讨论用于改进 HTLC。为什么？HTLC 在应用到闪电网络中具有是需要将原像传递给发送方。

HTLC 用于闪电网络可能存在的问题

这样会存在一些问题，例如支付路径上的某两个不直接连接的节点相互串通，则可能会存在绕过中间节点，占用原本属于中间的手续费。

例如，下图中 Mallory 和 Mike 是两个串通好的恶意节点。Mike 在向通道支付了 1 BTC 并拿到原像后，直接交给了 Mallory；Mallory 则进一步用该原像向上游获取了 1.1 BTC（假设中间环节的所有手续费是 0.1 BTC）。至此，Mike 和 Mallory 相当于同谋用 1 BTC 的成本获取了 1.1 BTC 的收益，而他俩中间环节的节点手续费则被侵占，且通道资金处于锁定状态，要到超时后才能恢复正常。

（来源：Payment Points Part 1: Replacing HTLCs）

PTLC 原理

上述问题在于 HTLC 传递的原像在路径上唯一，因此解决的办法也可以针对性的进行设计。PTLC 采用了椭圆曲线的不可逆和可同态计算的特性，这样使得秘密在传递的每一段上都需要和前一段有关。

PTLC 流程

在 PTLC 下，以 Alice -> Bob -> Carol 的付款流为例：

Carol 生成一个秘密值 $z$ ，并把 $z * G$ 交给 Alice。
- 其中 $G$ 是椭圆曲线上的一个点
- Alice 不能通过 $z * G$ 来反推出 $z$
Alice 生产两个随机数 $x$ 和 $y$
Alice 生成一个付款合约给 Bob，解锁条件是 Bob 能揭示 $(x + z) * G$ 对应的“私钥”，即$(x + z)$ 。合约里的 $(x + z) * G$ 可通过$x * G + z * G$ 计算出来
Alice 把 $y$ 交给 Bob。
Bob 生成一个付款合约给 Carol，解锁条件是 Carol 能揭示 $(x + y + z) * G$ 的”私钥“， $(x + y + z)$。合约里的 $(x + y+ z) * G$ 可通过 $(x + z) * G + y * G$ 计算出来
Alice 把 $(x+y)$ 交给 Carol。即 Carol 知道$(x+y)$，但不知道 $x$ 或 $y$ 的具体值
Carol 通过 $(x+y)+z = (x+y+z)$ ，给 Bob 展示该值，解锁第 5 步 Bob 的付款
Bob 得知了 $(x+y+z)$ 之后，通过 $(x+y+z) - y$ 计算出 $(x + z)$ ，并向 Alice 展示，以解锁第 3 步的付款合约。
最后， Alice 通过计算 $(x + z) - x$ 得到 $z$，作为自己的支付证明。

也就是，通过同态运算和在付款流程中的每一个环节中增加随机数的方式，确保了每一个环节不可被绕过。

Taproot 支持 PTLC 的实现

Taproot 升级中的 Schnorr 签名也给 PTLC 带来了可能，通过使用 Schnorr 聚合签名的部分和适配器签名（partial and adaptor signatures）来实现。

重复使用收款码：Keysend

闪电网络根据 BOLT 11 必须要 invoice。在实际应用时，闪电网络有一个“痛点”在于：收款人要先展示一个一次性的“收款码”（invoice），付款人才能付款，而且每次收付款都必须更换。

这样对于商户希望能长期稳定的收款、线上用户希望能收到打赏来说太不方便了。

“Keysend” 希望实现的效果类似微信长期收款码：只需知道我的公钥，就可以给我无限次支付了，而无需每次生成一个 invoice。

Keysend 原理

Keysend 的实现原理是：支付者选出原像，然后使用洋葱消息封装它，然后路由给接收者。洋葱封装后的数据沿着一条路径转播，但完整的路径对路径上任一转发该支付的节点都是不可知的。因为，数据是在沿着这个路径达到最终目的地的过程中，被路径上的一个一个节点逐步解封的。

目前大多数闪电网络实现（包括 LND 和 c-lightning）都实现了 Keysend。

不只是支付

Keysend 还可以支持多种应用。Keysend 可以通过在封装支付信息的洋葱数据包中加入额外的信息，来支持聊天（例如 Sphinx Chat）和川流式支付应用（如 Podcasting 2.0、Breez）等。

稳定币等其他资产：Taro

闪电网络在支付的使用上仍然有一个没能很好回答的问题：为什么要用比特币来支付？如果一个 Bitcoin 长期支持者要用闪电网络，那么 TA 可能很难真的愿意用宝贵的比特币去支付；而对于闪电网络有极大希望去“破圈”的、unbanked 人群，比特币的高波动率可能也会比较难以接受。

Lightning Labs 在 2022 年 4 月宣布的 Taro 可能会解决这一问题。

“bitcoinize the dollar”。Taro 计划在比特币网络上利用 Taproot 技术来支持闪电网络使用稳定币来支付。

Taro 原理

Taro 的原理是，基于 Taproot，允许在现有的 UTXO 输出中嵌入任意类型的元数据。

Sparse Merkle Sum Tree

Taro 在记录账户状态数据时，使用了稀疏 Merkle 总和树（Sparse Merkle Sum Tree）。

首先看稀疏 Merkle 树（SMT）。这种二叉树结构和普通 Merkle 树的区别是将所有可能取值作为叶子节点。也就是通过这种方式，SMT 对所有可能的数据进行了“索引”，便于进行非存在性证明。

例如，key 的空间范围是 256 位 bit 的，即总共可能有 $2^{256}$ 个 key。如果用二叉树的左分支表示 0、右分支表示 1，也就是需要一个 256 层的二叉树在叶子节点上表示所有可能的 key。如果将这个树用作状态树，即叶子节点上的 key 都是所有可能的账户地址。
也因为这种形式，SMT 会非常“稀疏”，毕竟对于全部账户地址集合来说，有状态的账户属于极少数。

另外，SMT 也具有插入顺序无关等特性，因为数据元素已经固定好位置。

使用 Taproot，连接现有闪电网络

Taro 将稀疏 Merkle 总和树的树根做 Hash 后，作为 UTXO 的 Taproot 树的一个叶子节点。因此，Taro 可以利用 Taproot 交易对 Taro 资产的状态进行更新。

而这个交易只要在闪电网络的开始和结束这两个通道内完成即可。例如下图中，只需要 Alice 和 Bob 以及 Carol 和 Dave 之间通过 Taproot 方式维护了 Taro 的状态即可。开始和结束这两段可以使用 Taro 定义稳定币（L-USD）来结算，而中间的连接部分可以对应的将稳定币转换成闪电网络中对应的 BTC。