使用 “分层通道”，在链下调整闪电网络通道容量

作者：jlspc
来源：https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-March/003886.html

太长不看：

需要动态管理闪电网络通道容量以支持高效的闪电网络（LN）付款
- 链上通道容量会带来延迟，增加成本并限制可扩展性
- 临时用户需要快捷低成本的通道容量调整方法来实现无需瞭望塔的闪电网络付款
- 通道工厂支持在链下调整通道容量，但是容量交换只能发生在工厂内部
分层通道支持灵活的链下通道容量调整
- 它们无需在有限的用户池内交换容量
- 它们还可以帮助无瞭望塔的临时用户避免通道容量滞留问题
分层通道之于通道容量如同，闪电网络之于比特币
无需改变底层比特币协议

概述

就确保闪电网络的高效运行而言，能否按需转移闪电网络通道容量起到举足轻重的作用。

事实上，有句话说得好，闪电网络常驻用户的“主要（可能也是唯一的）工作就是高效分配他们的流动性”[10]。

使用链上交易调整闪电网络通道容量会限制闪电网络的可扩展性，导致交易费上涨。

另外，在链上调整通道容量会产生较高的延迟。

事实上，如果有临时用户未启用瞭望塔，可能会出现长达几个月的延迟，造成资金滞留。因此，在当前环境下，这类用户无法在不启用瞭望塔的情况下运行节点 [10]。

一个现有链下通道容量调整方案是，创建一个通道工厂[1] 或 CoinPool [7] 并在同一个工厂/池子内的通道之间交换容量。但是，在所有闪电网络的支付通道中，属于同一个工厂或池子[8] 的只有很少一部分。因此，用户在容量不足与容量过剩的通道配对上十分受限。

本文利用分层闪电网络通道解决了两大问题。

第一，只要是在分层通道内创建的闪电网络通道，就有可能在链下即时灵活地调整它们的容量。

因此，分层通道之于通道容量就如同闪电网络之于比特币。事实上，这不仅仅是一个类比，因为通道容量就是在闪电网络上发生转移的。

第二，分层通道可由一个临时用户和一对常驻用户创建，临时用户无需启用瞭望塔即可发送并接收比特币，常驻用户可以使用所有通道容量路由付款，即使是当临时用户处于非活跃状态时。

如此一来，临时用户在运行节点时即使不启用瞭望塔，也不会导致任何资金滞留。

我们将在下文介绍分层通道是什么以及如何使用它们。如果你想查看更完整的介绍以及相关数据，可以阅读这篇文章 [6]。

分层通道

在分层通道中，参与方可以是单个用户，也可以是一群用户。

分层通道由两个参与方组成，生成两个主要输出（一方生成一个），另外还有 0 个及以上 HTLC 输出。

每个支付给多用户方的分层通道输出都是为另一个（可能同样是分层）通道提供资金。

因此，每个分层通道输出（包括解析后得到的 HTLC 输出）都可以被视为一个链下输出树的根，叶子为不同用户所有。

更新分层通道时，一方通过 HTLC 将资金提供给另一方。HTLC 提供方的一名用户被指定为 付款者，得到 HTLC 的一方的一名用户被指定为 收款者。

HTLC 的所有资金都由付款方提供。如果 HTLC 成功，大部分资金都会交给收款方（HTLC 收取方中除收款者之外的用户也会得到路由费）。

在通道状态更新为包含新的 HTLC 输出之前，通道中的所有用户会签署新的交易来花费新的通道状态的主要输出、已有 HTLC 输出以及新的 HTLC 输出。

接着，用户签署实现新的通道状态的交易（包括新的 HTLC 输出）并撤销之前的通道状态。

一旦 HTLC 被解决，通道状态将会更新，将 HTLC 的资金包含到接收方的主要输出中（如果 HTLC 成功的话），或提供方的主要输出中（如果 HTLC 失败的话）。

由于同一个分层通道内的两方可以使用 HTLC 来交换比特币，他们可以将自己的 HTLC 关联至其它（可能同样是分层）通道中的 HTLC，从而通过闪电网络进行付款。

需要强调的是，（可能是分层）通道中的各方都是闪电网络通道图中的一个节点，每个（可能是分层）通道则是一对连接通道内两方的单向边。

就像在当前的闪电网络中那样，付款包含一条路径：在上一跳中得到了 HTLC 的节点在下一跳中提供 HTLC（在上一跳中作为收款方的用户成为下一跳的付款方）。

如何在链下调整路由通道

提供路由服务的常驻用户可以使用分层通道在链下调整其闪电网络通道的大小。

假设常驻用户 A、B、C 和 D 之间创建了一个分层通道，其中 AB 为一方，CD 为另一方。此分层通道的主要输出为 AB 和 CD 所有的（非分层）通道提供资金。另外，假设 CD 方与（单用户）E 方之间另外有一个分层通道。

如果 AB 想要减少其（非分层）通道的容量，可以通过闪电网络创建一笔付款，由 AB 方（用户 A 是付款方）支付给 A 方（用户），付款路径是 AB -> CD -> E -> F -> G -> A。

由于此付款来自 AB 方与 CD 方共有的分层通道中的 AB 方，由该分层通道支付给 AB 方的主要输出的值会随之减少。

由于 A 和 B 所有的（非分层）通道的资金来源于上述分层通道支付给 AB 方的主要输出，此付款缩减了 A 和 B 所有的通道的容量。

最后，由于此付款由 A（此付款第一跳中提供方 AB 的付款方）支付给 A 自己（此付款的终点），用户 A 的资金既没有增多，也没有减少（如果不考虑支付给用户 C、D、E、F 和 G 的路由费的话）。

此外，就像任何闪电网络付款那样，无论每个路由节点在上一跳中收到多少资金，到了下一跳都会在扣除路由费后，将剩余资金全部发送出去。因此，路由节点的余额大体不变（会因收取路由费而略有增加）。

此处的路由节点 E、F 和 G 跟当前闪电网络中的没有区别。但是，我们需要多加关注路由节点 CD，因为多用户节点是分层通道会为闪电网络带来的新特性。

就像其它路由节点那样，CD 方经由与 AB 方的分层通道收到了资金，并经由与 E 的分层通道将等量资金扣除路由费后发送给 E。

请注意，C 和 D 在闪电网络通道图中同样显示为节点。由 CD-AB 分层通道提供资金的 C-D 通道显示为 C 和 D 之间的一对单向边。由 CD-E 分层通道提供资金的 C-D 通道显示为 C 和 D 之间的一对单向边。

因此，C 和 D 之间两条通道的容量之和基本不变，会因路由费而略有增加。

由 AB 方支付给 A 的付款对闪电网络通道图局部的影响如下所示。

各参与方显示为方块，各通道显示为参与双方之间的一对有向边。

通道容量在有向边对之间显示，参与双方的余额在有向边对上方或下方显示。

                                                                  200
     PHYSICAL CHANNELS                                       +--+ ->  +--+
  BEFORE AB -> A PAYMENT                                     |C | 500 |D |
  OF 100 UNITS PLUS FEES                                     |  |  <- |  |
                                                             |  | 300 |  |
                                                             |  |     |  |
     800      800      400      200      500      500        |  | 700 |  |
+--+ ->  +--+ ->  +--+ ->  +--+ ->  +--+ ->  +--+ ->  +--+   |  | ->  |  |
|AB|1300 |CD|1000 |E |1000 |F | 400 |G | 700 |A | 800 |B |   |  | 800 |  |
+--+  <- +--+  <- +--+  <- +--+  <- +--+  <- +--+  <- +--+   +--+  <- +--+
     500      200      600      200      200      300             100

                                                                  308
     PHYSICAL CHANNELS                                       +--+ ->  +--+
   AFTER AB -> A PAYMENT                                     |C | 609 |D |
  OF 100 UNITS PLUS FEES                                     |  |  <- |  |
                                                             |  | 301 |  |
                                                             |  |     |  |
     691      694      296       98      400      391        |  | 594 |  |
+--+ ->  +--+ ->  +--+ ->  +--+ ->  +--+ ->  +--+ ->  +--+   |  | ->  |  |
|AB|1300 |CD|1000 |E |1000 |F | 400 |G | 700 |A | 691 |B |   |  | 694 |  |
+--+  <- +--+  <- +--+  <- +--+  <- +--+  <- +--+  <- +--+   +--+  <- +--+
     609      306      704      302      300      300             100

逻辑通道与物理通道

由于 C 和 D 之间存在两条通道（一条由 CD-AB 分层通道提供资金，另一条由 CD-E 分层通道提供资金），理所当然要用两对有向边来分别表示两条通道（如上方所示）。

但是，如果我们在逻辑上将 C 和 D 之间的两条物理通道合并成一条容量为两条物理通道容量之和的逻辑通道，会得到更好的启发。

事实上，只要在连接 C 和 D 的两条物理通道中使用并行 HTLC，就能在 C 和 D 之间路由大额付款。

此外，将逻辑（而非物理）通道公开给闪电网络对等节点有利于增加通道容量的稳定性，因为逻辑通道的所有方参与付款路由后基本不会改变通道容量（会因路由费而略有增加）。

以上述付款为例，A 和 B 之间的通道容量会因 AB 方支付给 A 的付款（另外还有路由费）而减少，而其它逻辑通道（包括 C 和 D 之间的逻辑通道）的容量基本不变（会因路由费而略有增加）。

     LOGICAL CHANNELS
  BEFORE AB -> A PAYMENT
  OF 100 UNITS PLUS FEES

     800      800      400      200      500      500             900
+--+ ->  +--+ ->  +--+ ->  +--+ ->  +--+ ->  +--+ ->  +--+   +--+ ->  +--+
|AB|1300 |CD|1000 |E |1000 |F | 400 |G | 700 |A | 800 |B |   |C |1300 |D |
+--+  <- +--+  <- +--+  <- +--+  <- +--+  <- +--+  <- +--+   +--+  <- +--+
     500      200      600      200      200      300             400

     LOGICAL CHANNELS
   AFTER AB -> A PAYMENT
  OF 100 UNITS PLUS FEES

     691      694      296       98      400      391             902
+--+ ->  +--+ ->  +--+ ->  +--+ ->  +--+ ->  +--+ ->  +--+   +--+ ->  +--+
|AB|1300 |CD|1000 |E |1000 |F | 400 |G | 700 |A | 691 |B |   |C |1303 |D |
+--+  <- +--+  <- +--+  <- +--+  <- +--+  <- +--+  <- +--+   +--+  <- +--+
     609      306      704      302      300      300             401

当然了，上述例子也可以被逆转（由 A 向 AB 方付款），在链下增加 A 和 B 之间的通道容量。

帮助临时用户解决容量滞留问题

分层通道还可以用来帮助无瞭望塔的临时用户解决容量滞留问题。

假设无瞭望塔的临时用户 A 与常驻用户 B 和 C 共同创建了一条分层通道，其中 A 是一方，BC 是另一方。

假设 A 想要付款给 G，BC 方与用户 D 之间另有一条分层通道，D 与 E 之间有一条通道，E 与 F 之间有一条通道，F 与 G 之间有一条通道。

在此场景下，A 可以通过包含路径 A -> BC -> D -> E -> F -> G 的闪电网络创建一笔付款。

当然了，上述例子也可以被逆转：由 G 向临时用户 A 付款。

重点是，只要是在 A 没有进行收付款的情况下，常驻用户 B 和 C 就可以使用通道内的所有容量来路由闪电网络付款。这里还要强调的一点是，只要 B 和 C 将他们的两条物理通道（一条由 BC-A 分层通道提供资金，另一条由 BC-D 分层通道提供资金）合并成一条逻辑通道对外公开，BC 在向为 A 提供付款路由服务时，此逻辑通道的容量基本不变（会因路由费而略有增加）。

分层通道协议

创建分层通道协议需要解决几个问题。

第一，来自分层通道的每个主要输出（或已解决的 HTLC 输出）必须要能够支付给交易树，由交易树通过叶子将输出的资金分配给用户个人。

为了解决该问题，我们可以要求分层通道中的用户在签署承诺交易之前互换签名，让交易树能够花费此承诺交易的每个输出。

第二，闪电网络通道目前通过 channel_announcement 消息公布。此消息引用了链上 UTXO 为通道提供资金。通道的容量是静态的。

这类 channel_announcement 消息不适用于由链下 UTXO 提供资金且拥有动态容量的分层通道。

Russell 关于 channel_update_v2 消息的提议 [9] 非常适用于分层通道，因为它不仅合并了通道公告和通道更新的概念，还包含了通道容量，因此支持动态容量。

此提议还支持链下充值通道，让用户在公布容量最多为链上 UTXO 值的固定倍数的通道时能够引用链上 UTXO。

第三，分层通道必须具备支持两名以上用户的能力。

当前的闪电网络通道协议只支持双用户通道，因为它对于欺诈行为的惩罚方式是：如果有一方试图将非最新承诺交易上链，另一方就可以拿走通道内的所有资金。

如果通道内有超过两名用户，且其中至少有两名用户作恶，上述方式就无法发挥作用。

在这种情况下，两名恶意用户可能会串谋：一方将承诺交易上链，另一方以“惩罚”的名义拿走通道内的所有资金，包括那些属于诚实用户的资金。即使恶意用户无法确保自己一定能够拿走通道内的资金，高收益预期也有可能诱使用户作恶。

相较之下，通道工厂协议旨在让两名以上用户能够在链下更新工厂状态，每个工厂状态都包含工厂内用户的资金归属情况。

因此，如果我们将分层通道状态定义为包含两个主要输出以及任何 HTLC 输出，就可以使用通道工厂协议在链下更新通道状态。

尤其值得一提的是，我们还可以使用 Invalidation Tree protocol（失效树协议）[2]、Tunable-Penalty Factory protocol（可调惩罚工厂协议）[5] 或 Single-Commitment Factory protocol（单一承诺工厂协议）[5]。

其中，Tunable-Penalty Factory protocol 看起来最具吸引力，因为它只需要花费 O(1) 时长和 O(1) 链上字节即可完成单边通道关闭。

最后，除了维护通道的当前输出集，每个 HTLC 输出都要根据对应 HTLC 的条款解决。

一种基于当前闪电网络协议的简单方法是让 HTLC 输出能够通过以下两种方式之一花费：