闪电网络流动性管理方案科普

作者：RGB++ Fans；来源：字节元 CKB

在之前的科普文章中，我们已经就支付通道、多跳路由、HTLC 等闪电网络相关的核心概念进行了简要科普。

我们提到，要在闪电网络中进行转账，往往要经由多个中间人节点搭建路径，而中间节点的可转余额往往有限，最终会影响到支付的成功率。为了确保路径中的节点有足够资金，增强用户体验，要通过一些流动性管理方案来进行调节。但要深入理解流动性管理问题，我们要先引入几个基本概念，比如本地余额和远端余额（Local and Remote Balance）、入账容量和出账容量（Inbound and Outbound Capacity）等。

过去我们曾提到，闪电网络的基本组成单位是节点和通道，后者是基于比特币网络搭建的链下 1 对 1 转账设施。在通道初始化时，双方会转入一些钱作为初始余额，在你这边的余额，叫 “ 本地余额 ”，你对手方那边的余额，叫 “远端余额 ”。本地余额决定了你能向对手方转多少钱，限制了你的支付能力即“出账容量”，远端余额决定了对手方能转给你多少钱，限制了你的“入账容量”即收款能力。

虽然参与双方各自的余额在通道关闭前可以频繁变更，但二者加总后的通道总容量无法改变，除非你整个重启通道或者用 “通道拼接” 注入资金。

（这张图展示了你和 Robert 各自的余额，你的本地余额为 5，远端余额为 3，通道的整体容量为 8）

理解了上面几个基础概念后，我们再来看闪电网络中的流动性管理到底是要解决什么问题。下图中展示了一个简化的节点连接图示，我们不难看到，你（左下角）只连接到了 LNTop 一个节点，由于你的远端余额为 3，最多能收到 3 美元的转账。而如果 Sophie 要给你转账 1 美元，则会因中间节点对 LNTop 的可转余额不足而失败（红框处，该节点对 LNTop 的出账容量为 0）。

可以说，通道容量是闪电网络在早期阶段遇到的严重问题之一。如果流动性在整个网络中的分布更充分，此类问题将有效减轻，对此的解决方案往往被统称为 “流动性管理”，比如通过租赁市场（Lighting Pool）让客户端连接到多个流动性充沛的节点、根据需要打开/关闭新通道，或是引入通道拼接、再平衡（Channel Rebalancing）等方法，在链上或链下对通道中的余额进行调控。

现在一些钱包客户端还提供自动化的通道管理功能，根据用户的支付行为和网络状况对通道进行智能管理，确保有足够的流动性进行转账。新用户在刚连入闪电网络时还可以采用 “单向注资” 的模式，就是只让通道对手方注资，自己不在通道初始化时注资，这样就能够减轻用户的经济成本，但代价是初始时没有对外支付的能力/出账容量。

下面我们将对闪电网络中流动性管理方案的常用手法进行更细致的科普。首先让我们了解下通道租赁，该方案主要解决节点的 “入账容量” 问题，就是当其他人想要向你转账时，你要保证能让对方成功搭建起支付路径，这就要对路径中包含的每个节点都提出要求，比如必须有充足的可转余额/出账容量。前面我们提到的路径失败的场景，根源在于某些中间节点与其他节点建立的通道中流动性不足。

构建通道是有代价的，因为参与方往往要锁定一部分资金，会产生机会成本。而所谓的通道租赁，其思路是通过市场化的手段让节点运行者们直接进行交易，通过 “租赁” 制让资金富余的节点主动为其他节点搭建通道。比如你是一个商户，需要随时接收其他人转来的钱，对额度有很高要求，一天内的“收款能力”要超过 200 枚 BTC。

于是你通过 Lighting Pool 与 4 个大型节点达成协议，这 4 个节点都与你搭建为期 24 小时的通道，各锁入 50 枚 BTC，分别为你提供 50 BTC 的远端余额，这样在每条通道中你的收款能力都会达到 50 BTC。如果有人向你转账，可以把这 4 个节点中任意 1 个作为中间人来搭建支付路径。

（在 1ml.com 上，我们可以看到多个知名的闪电网络节点运营商，这些节点拥有较富余的资金，与其他节点建立了多条通道，可以通过租赁流动性来获取收益）

除了上面说的租赁池以外，还有流动性广告（Liquidity Advertisement），流动性提供方可以用闪电节点的 gossip 消息来播报自己的要价以及通道持续时间，接受要价的节点可以与之开启通道。此类基于租赁制的方案都会结合保证金制度，防止一方突然违约。

目前 Lighting Labs 等闪电网络开发商和 Fiber 都在尝试对单向注资下的流动性租赁场景进行优化，比如 Fiber 计划在 CKB 智能合约功能的基础上引入流动性代付制，会有指定的 LSP 服务商节点与用户搭建通道，并在一段时间内为用户免费提供入账容量，满足其收款需求。等用户收到一些钱后，合约再自动从中抽回成本，与此类场景相关的流动性质押机制也在讨论之中。

大体来看，通道租赁往往用于解决节点间建立连接、获取入账流动性的问题，而下面的通道拼接（Splicing）方案会通过链上操作进行注资/提现，直接变更通道中双方的总余额。正常情况下通道的开启和关闭都会用到 2/2 签名，由参与双方对共同拥有的链上资产进行再分配，而在早期的闪电网络方案中通道一旦开启，除非将其关闭后再重启，否则无法改变通道中的总体余额。

而通道拼接是后来提出的新方案，可以不关闭既有通道，在参与方的协作下，直接在链上对通道双方共同支配的 UTXO 进行重组更新，比如在既有资产基础上增添新的资产让参与方共同控制，进而改变通道中的总体余额。下图简单概述了这个思路，其中左侧是旧通道对应的链上资产 （UTXO1），由 Alice 和 Bob 多签控制，之后双方发起通道拼接，把另一笔资产（UTXO2）也加进来共同管理，最终通道双方可共同支配的资产（UTXO3）数额增多，容量增加。

通道拼接也可以用于减少通道中的过剩资金，把暂时处于闲置的资产转移出通道，提高资金利用效率。相比于传统的关闭/重启通道时需要两次链上交互，通道拼接只需要单次链上操作，可以显著降低成本。尽管通道拼接具有明显优势，由于历史原因该方案没有彻底成熟落地，其大范围采用仍需时日。

在了解了通道拼接后，我们继续介绍通道再平衡（Channel Rebalancing）的思想，这同样是一种在不关闭通道、不改变通道内总容量的前提下（忽略手续费），对不同通道内的链下余额进行调节的手段。假设你运行了一个闪电网络客户端，与其他节点之间建立了共计三个支付通道：

• 通道 1：与节点 X 建立，总容量为 1 个 BTC

• 通道 2：与节点 Y 建立，总容量为 0.5 个 BTC

• 通道 3：与节点 Z 建立，总容量为 0.5 个 BTC

每个通道的资金分布如下：

• 通道 1：你的本地余额：0.9 BTC 远端余额：0.1 BTC

• 通道 2：你的本地余额：0.1 BTC 远端余额：0.4 BTC

• 通道 3：你的本地余额：0.1 BTC 远端余额：0.4 BTC

现在的问题是，在通道 2 和通道 3中你的出账容量不足，最多能转给对手方 0.1 BTC，无法满足大额转账的需求。与此同时，通道 1 的出账容量过剩，达到 0.9 BTC，但你短期内根本用不了这么多。显然最好的办法是把通道1中富余的资金挪到另两条通道中。于是你打算从通道 1 的本地余额中转移 0.4 枚 BTC 到通道 2，转移 0.4 枚 BTC 到通道 3。而要达成这样的效果，你需要完成两笔环路支付（circular payment）。

具体的操作方法如上图所示，你可以直接转 0.8 枚 BTC 给节点 X，后者再向 Y 和 Z 各自转 0.4 枚 BTC，然后 Y 和 Z 分别在通道 2 和通道 3 中向你转 0.4 枚 BTC，增加你的本地余额，这样你就有了充沛的可转资金，满足未来的大额转账需求。

观察上图，不难发现环路支付的本质是你向自己转账，把自己在不同通道中的余额转来转去，最后让整体的余额分配达到你的预期结果，但单凭这种方法无法凭空增加任意一个通道中双方的总余额，此外其实施需要依赖于以下假设：X 对 Y、Z 有充足的可转资金，换句话说，环路支付往往要求相关节点事先有一定的流动性储备。

环路支付是通道再平衡思想的一种实现思路，而再平衡方案在实践中还可以配合其他方法，比如潜水艇互换等。下面让我们介绍潜水艇互换（Submarine Swaps），该方案的核心思想是在不关闭通道的前提下，借助 HTLC 等方法对链上与链下资金进行互换。

最简单的潜水艇互换场景是在链上向通道中充值，假设 Alice 已经和 Bob 建立了 1 对 1 通道，但一段时间后，Alice 的本地余额基本耗尽，无法再向外支付。此时 Alice 要注入更多资金，需要把通道关闭后再重启，但这条通道是租赁来的，提前关掉不太划算，那么该怎么办？

如果通过潜水艇互换的话，过程会比较容易，但要借助 HTLC。首先 Alice 可以生成一个随机数 R，对其取哈希 H(R)。后面 Alice 可以在链上向 Bob 的地址发送 BTC，其解锁条件受到 HTLC 的限制。Bob 要在链上解锁这些比特币，必须知道 H(R) 对应的原像 R。

Bob 在链下通道中与 Alice 通过 HTLC 进行交易，但方向反过来：Alice 要出示 R，然后才能解锁 Bob 付的钱。只要 Alice 出示了 R 的数值，Bob 就可以用它解锁 Alice 在链上锁定的 BTC。之后，Alice 在通道中的本地余额增加了，在链上的资产余额等价减少（忽略手续费的话），基本是 1 比 1 的置换（上面为了便于说明原理，没有严格按照潜水艇互换的常规操作顺序来讲解，实际上大多数时候是一方先在链下创建 HTLC，另一方才在链上创建对称的 HTLC）。

上述场景主要用于链上资产置换链下余额，只要对 Alice 和 Bob 的操作方向进行调整，就可以调换为提现操作，把链下余额变现为链上资产。潜水艇互换是凭借 HTLC 与时间锁等组合功能来保证安全的，即便对方中途放鸽子拒绝配合你，你锁在 HTLC 里的钱也安全，因为对方不知道解锁 HTLC 的密钥，等时间锁过期后，你便可以拿回本金。

但要注意，上述场景中虽然你的本金不会被盗，但需要有一方在链上创建 HTLC 锁定资金，这就必然会产生手续费磨损，如果对方放鸽子必然会对你产生一定影响。为了解决这些问题，潜水艇互换往往有一些配合的辅助手段，比如预付金、声誉系统等惩罚手段。

我们再概括下，潜水艇互换的核心思想是让链上/链下资产实现灵活互换，如果顺着通道再平衡的思路，可以实现出更优的流动性调整措施。这里我们简单举个例子：

假设你运行了一个节点，开通了多个通道，某些通道的本地余额富余，其他通道的本地余额严重不足，影响了你的支付能力。你想在不关闭通道的情况下，平衡各通道的资金分布，潜水艇互换可以成为一种良好的解决方法，你可以选择本地余额过多的通道，通过潜水艇互换将资金转移到链上，然后再通过潜水艇互换把链上资产注入目标通道，整个过程中，不需要关闭任何通道。

不过，总结上述知识点，我们不难发现潜水艇互换和通道拼接、通道租赁等流动性调节操作均会在链上留下操作痕迹，进而产生手续费，如果频繁地进行此类操作，必然会在用户的经济成本和 UX 上产生压力。由于比特币闪电网络依赖于 BTC 主网，频繁的进行链上交互并不现实，而基于 CKB 的 Fiber 面临的此类压力相对较小，在流动性管理的体验上较为流畅。但无论如何，闪电网络和 Fiber 都在对更新颖的流动性解决方案进行深入研究，未来或将在与 Mercury Layer 等项目团队的积极合作下，摸索出更为合适的路径。