作者：Anony
在本篇中，我们将介绍让节点获得入账流动性（收款额度）的方案，并介绍这些方案在闪电网络终端用户所用的实现上的演化。
早在本系列第一篇中，我们就提到，出于 “通道（共有资金）” 的特性，“收款额度” 的概念是无法逃避的。而每个用户都有可能遇上想要收款却没有额度的情形。
这个问题因为闪电网络早期实现的一个设计而变得更加严峻 —— 单向注资。
单向注资
虽然在我们之前使用的例子中，都把通道双方都有余额作为通道的初始状态，但实际上，最早实现的通道注资方法是 “单向注资” —— 在参与通道的双方中，仅有一方为通道提供资金。如此一来，在一开始，双方得到的都是不平衡的通道：一方仅有支付能力（而无收款能力），而另一方又仅有收款能力（没有支付能力）。
这种设计有一些优点：易于实现、安全性检查更加简单（双向注资所需的额外安全性检查可见 1）；尤为重要的是，它更适合网络的启动。在一个新节点要加入网络时，它可能会选择跟一个已知的老节点开设通道，然而，对后者来说，却难以决定要不要在其中锁入流动性：如果这个新节点只是尝试一下，很少在线，那么，锁入其中的资金就无法获得收益。而单向注资使得该节点根本不必有此担忧：新节点会自己锁入资金，而不要求老节点提供任何初始资金。
但是，这也意味着，收款额度的获取成了所有新节点的难题 —— 不论你想做一个转发节点，还是将闪电网络用于日常使用。
截至本文撰写之时（2024 年 2 月），已经有两个闪电网络客户端（Core Lightning 和 Eclair）实现了 “双向注资（dual funding）”，也即在创建通道时，双方都可以为通道提供资金。在一些条件下，这可以节约一个节点要创建平衡的通道的步骤。
“双向注资” 的详细介绍可见这个页面 2。
接下来我们要介绍的是获得入账流动性的方案。概要来说，这样的方案可以分成两大类：一类的原理是向外支付；另一类的原理是请求他人向自己开设不平衡的通道。
潜水艇互换
“潜水艇互换（submarine swap）” 是第一类方案的代表。其想法是，需要入账流动性的节点将自己在闪电通道中的资金通过 HTLC 置换成链上资金；在向外支付的同时，该节点也就获得了入账流动性。
用户在闪电网络中给互换服务商支付，互换服务商在链上给用户支付，这就是潜水艇互换；而 HTLC 可以保证互换的免信任性。不过，由于这个过程涉及链上支付，它在实现中会遇到一些难题，从而一定程度上需要一些信任。我们用详细的互换流程来分析：
- 用户向服务商请求互换；服务商提供自身的闪电网络位置；
- 用户生成一个原像及其哈希值，使用该哈希值构造用于闪电支付的 HTLC；当支付转发消息到达服务商时，服务商使用相同的哈希值，在链上创建一个 HTLC 输出；
- 用户发现该链上 HTLC 输出得到确认之后，就使用哈希原像申领其中的资金；该原像也就暴露给了服务商；
- 服务商使用原像领取闪电网络中的 HTLC。
从第二步开始，服务商需要信任用户，因为 TA 需要创建一个链上输出。如果这时候用户突然反悔，或本来就有意作恶，不在链上释放原像，那么服务商就亏掉了为创建这个链上输出而需支付的手续费。也正因此，在一些服务中，服务商会要求用户预付一定的费用，在完成互换之后退款，但从原理上说，这又变成了用户需要信任服务商。
潜水艇互换在实践中的另一个困难是，它需要用户的钱包也有相应的支持。用于给用户支付的 HTLC 并不是常见的单签名输出，用户的钱包必须能够理解 HTLC 的脚本、懂得为其构造见证数据（witness），才能花费其中的资金。当前，将自身定位为 “比特币钱包” 的钱包软件几乎都无法提供这种支持，但一些 “闪电钱包” 则可以做到。未来，这需要依靠 Miniscript 这样的技术来提供更好的互通性 3。
潜水艇互换可能是最早出现的入账流动性获取方案，也启发了许多后来者。其中一种是 “PeerSwap”，直接跟你的通道对手实施潜水艇互换 4。还有一种叫 “环路支付（circular payment）”，就是规划出一条环状的路径，将自己在 A 通道中的余额转移到 B 通道 5。
潜水艇互换还有一种有趣的用法：你可以用闪电网络中的资金给他人支付链上比特币。此外，它也可以反向运行：将链上的比特币 “充值” 到自己的闪电通道中，以增加支付能力，无需 关闭通道-重新打开通道。
当前，如果你使用 LND 客户端来运行闪电节点，你可以使用搭配的 Loop 客户端来使用潜水艇互换功能。
通道租赁
获得入账流动性的另一种办法是租赁通道：请求他人用自己的资金与你开设一条通道（当然，你需要支付一些费用）。对方投入的资金即是你立即获得的收款额度。
请注意 —— 你并没有借他的钱，钱依然在他手上，只不过形式从链上资金变成了链下（某一条通道中的）资金；当你在这条通道中收到支付时，他必定在另一条通道中得到了 相同数额+转发费用 的支付。
显然，这种通道租赁需要让通道保持一段时间，否则出租方就可以收钱不办事 —— 在收到租金之后立即关闭通道。但是前面介绍的闪电通道构造似乎并没有对通道存续时间的保证。难道又只能引入信任了？
事实上，如果你了解比特币的脚本，你会发现，有一种很简单的办法可以保证出租方会让通道持续一段时间。假设租赁方 Alice 要求出租方 Bob 与自己开设一条通道，那么，Alice 可以在自己签名的承诺交易中，为所有给 Bob 支付的输出（包括普通的输出和 HTLC 输出的相应花费分支）都加入绝对时间锁，时间锁的过期时间是双方约定的合约结束时间。也即，即使 Bob 拿着最新的承诺交易退出通道，如果未过合约期限，这些资金也会一直锁定、无法动用。这就完全打消了 Bob 提前关闭通道的激励 —— 资金放在通道中还有可能产生收益，但关闭通道会导致字面意义上的 “冷藏”。早在 2018 年，就有开发者提出了这样的想法 6。
通道租赁的想法简单又直接。甚至移动端的自主保管钱包 Breez 也在 App 中提供了向著名的服务商租赁通道的入口。
最初，提供此类服务的都是著名的公司，而且流程中很可能需要信任。于是，人们想出了更多方法来降低参与的门槛、增加市场的竞争。
Lightning Pool
Lightning Pool 是 Lightning Labs 推出的一种通道租赁拍卖市场。用户可以使用 LND 客户端和搭配的 Pool 客户端来参与。其基本特性是：
- 市场需要一个中介（或者说拍卖行），来保证各方诚信行事。
- 流动性的需方和供方，都要各自与拍卖行创建一个 “账户”，并把钱存进去。这样的账户在比特币链上是一个输出，它有两个花费分支：一是户主与拍卖行的 2-of-2 多签名；二是户主单签名 + 绝对时间锁。
- 这样的输出保证了：拍卖行无法独自转移户主的资金，而且资金的所有行动都要经过户主的同意，并且，在一段时间之后，户主总能单方面转移其中的资金。所以，这样的账户是免信任的。并且，当户主提出自己的订单要求时，拍卖行可通过要求户主的签名，来保证这样的 出价/要价 是诚实的。
- 拍卖是供方和需方各自叫价、但叫价仅向拍卖行公开的盲拍。拍卖行会在确保供需匹配之后，以区块为时间间隔清算市场；并且，在同一区块中成交的所有订单，每一单位的资金将收到相同的租赁价格。
- 拍卖行在链上会用一笔交易，批量处理该区块内所有成交的订单。
- 订单成交之后，供需双方创建闪电通道，并且，将使用上文所述的技巧来保证通道会在合约期内持续存在。
Lightning Pool 是一种有趣的尝试。它用一个半公开的市场解决了流动性供需匹配的问题，还为比特币资金提供了一种按区块计量的利息率（当然，所有的通道租赁解决方案都有这个效果）。
Lightning Pool 的技术详述可见他们的论文 7。
Liquidity Advertisement
“流动性广告（Liquidity Advertisement）” 是 Blockstream 提出的一种技术，其核心是让流动性的供方可以用闪电节点的 gossip 消息（本来用于宣布新通道、新节点的消息，相当于整个闪电网络的公开频道）来播报自己的要价以及通道的持续时间。接受这个价格的闪电节点可以与之用双向注资方法开启通道、获得入账流动性。租赁方为通道提供的输入会立即用来支付租赁费。
当前，仅有 Core Lightning 客户端为 Liquidity Advertisement 提供了实验性支持。
零确认通道
上述两种方案，显然更适合于网络中的转发节点，以及有经验有技能的用户，却不适合于移动设备的用户（可以操作的界面更为有限），更不适合刚解除闪电网络、对技术了解不多的用户。因此，我们要专门一些适合刚入门用户的方案（并且假设他们会使用移动端 App，而不是电脑软件）。
“零确认通道（Zero-conf channel）”（也称 “零配置通道”、“涡轮通道”）的想法是，通过引入有限的信任，一举解决入门用户的两大问题：（1）创建通道需要等待；（2）新建通道没有入账额度。
办法如下：用户将比特币资金发送给服务商，服务商负责对用户开启通道（单向注资），并在通道内将扣除服务费之后的剩余资金转移给用户；并且，双方都视这条通道为立即可用，而无需等待通道注资交易得到区块确认。
显然，这个过程需要用户信任服务商：假定用户将资金转移给服务商之后，服务商拒绝执行后续步骤，那么用户并没有什么办法（只能到社交媒体上哭诉）；其次，在通道注资交易获得区块确认之前，用户在通道内获得的支付都是不可靠的，因为服务商可以重复花费注资交易的输入。
但是，它解决了刚进入闪电通道的用户的一些痛点：首先，常规的闪电通道，在创建时需要让注资交易获得 3 次区块确认，用户才能开始支付，而零确认通道可以让用户立即开始闪电支付（用户的闪电支付，只要能获得收据，是可靠的）；其次，这种通道由服务商创建（可能还加入了服务商自己的资金），所以用户从一开始就可以获得收款额度。因此，还是可以给用户带来显著的便利的。
而且，一旦零确认通道的注资交易获得区块确认，它就会逐渐转变成常规的闪电通道：用户拥有承诺交易所提供的保护，不再需要信任服务商。
显然，要求用户先将资金交给服务商，是双向注资技术缺位之时的无奈之举。有了双向注资之后，我们就可以优化它，让服务商和用户直接执行双向注资程序。这并不能缩减用户创建闪电钱包的时延，只是降低了所需的信任。至于 “零确认” 这段时间所要求的信任，则是无法消除的 —— 但我们都知道，这个环节所要求的信任，是有限的。
更富细节的描述可见此篇 8。
许多移动端的闪电钱包都实现过零确认通道。不过现在，它已逐渐让位于一种更精致的零确认通道 —— JIT 通道。
JIT 通道与闪电网络服务商（LSP）
“JIT 通道”，顾名思义，是一种 “按需开设的通道”，它在零确认通道的基础上更进一步，但又可以说更加简单。
其思想是：仅当用户要接收支付、现有的收款额度又不够时，由服务商向用户开设新的通道，用户在新的通道里领取支付；并且，这条新通道也是 “零确认通道”，可以立即使用。
其技术实现也非常直接：当一个 HTLC 即将经由服务商到达用户，而用户的收款额度不够时；服务商就跟用户创建一个新通道，并用这个新通道内的资金来创建所需的 HTLC；此外，服务商还可以要求用户在某一条通道中创建一个使用相同哈希值的 HTLC，以支付服务费。一旦用户在新通道中用原像领取支付，服务商就不仅能获得该笔支付的转发费（像常规的闪电通道一样），还能获得用户支付的服务费。
相比于原本的零确认通道，JIT 通道的流程大大减少，但又保留了零确认通道对服务商的好处：甄别用户。因为需要在通道中锁定资金、为用户提供收款额度，服务商最担心的就是遇上试水的、不真实的用户。或者说，服务商需要甄别用户，以决定自己锁定的流动性的数量。而用户预先付出的资金数量、即将收取的资金数量，都为服务商提供了重要的参考。
除去 “零确认” 过程中的信任，JIT 通道也未完全消除信任需要，但它跟潜水艇互换一样，更偏向要求服务商信任用户：服务商必须垫付创建通道的区块确认费，但如果这笔支付是虚假的、用户不会放出原像，服务商就面临亏损。
在业内，有一个 “闪电网络服务商（LSP）” 的概念。其意思是，当用户与这样的服务商建立通道时，服务商可以自动地帮助用户管理通道（包括备份）和流动性，无需用户为之烦恼；此外，由于 LSP 时刻在线，也能为用户异步接收支付提供帮助 9 。即使这个概念不是由 JIT 通道激发的，JIT 通道也必定极大地完善了这个概念。
当前，许多自主保管钱包都提供了 LSP，包括 Phoenix 钱包和 Breez 钱包。其中，Phoenix 钱包还有专门的一个页面，让用户自己配置为接收一笔支付而愿意支付的服务费上限。当开设通道所需的实际费用超过这个限度时，LSP 将不会行动。
现如今，人们已经在讨论为 LSP 制定一套技术规范 10，从而允许人们使用相同的软件来获取不同 LSP 的服务，以强化 LSP 的市场竞争、保证用户的体验。
结语
目前，大部分移动端闪电网络用户的选择依然是托管钱包 —— 用户不掌握私钥，资金也得不到真实通道的保护，但无需关心收款额度、定期在线要求以及通道资料备份等所有事情的，闪电支付服务。显然，自主保管钱包的体验还没有说服足够多的人。但是，我们有理由相信它会继续进步。上一篇文章所述的收款码的进化是一个例子。本篇所述的零确认通道的进化也是一个例子。
在下一篇文章，我们将介绍让用户能够更自由地应对支付和收款需要，不必关心资金形式的技术。它们改善了用户的支付能力，并且直观地展现了形式不同、本质相同的资金的深层一致性 —— 只有一种比特币。
（未完）
脚注
1. https://bitcoinops.org/zh/newsletters/2024/02/07/#txid-segwit ↩
2. https://bitcoinops.org/en/topics/dual-funding/ ↩
3. https://www.btcstudy.org/2022/06/26/hidden-power-of-bitcoin/ ↩
4. https://www.btcstudy.org/2022/04/27/peerswap-a-p2p-btc-ln-balancing-protocol/ ↩
5. https://www.btcstudy.org/2022/06/14/rebalancing-in-the-lightning-network-circular-payments-fee-management-and-splices/ ↩
6. https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001555.html ↩
7. https://github.com/lightninglabs/pool-paper/blob/main/liquidity.pdf ↩
8. https://www.btcstudy.org/2022/08/25/what-are-turbo-channels/ ↩
9. https://www.btcstudy.org/2024/02/02/the-past-present-and-future-of-offline-payments/ ↩
10. https://www.btcstudy.org/2023/12/01/lightnings-future-a-new-era-of-interoperability-with-lsp-specs/ ↩