如何在闪电网络中实现异步支付

作者：Lorenzo

来源：https://www.voltage.cloud/blog/how-async-payments-on-lightning-network-work

原文出版于 2023 年 10 月。BOLT12 规范已经于 2024 年 9 月合并到 BOLT 。

引言

闪电网络旨在成为一种扩大比特币交易吞吐量的解决方案。不过，随着我们更深地了解闪电网络的细节，我们就会发现依然需要加强的部分。其中一个显著的方面是 “异步支付” 的概念 —— 这个特性，如果能够交付，会极大地改善支付流程和用户体验。

传统的链上比特币支付之所以极为简单，就因为它有异步特性。我们用一个例子来解释：假设 Alice 想让 Bob 教自己弹吉他，要付钱；Alice 打开 Bob 的社交媒体个人主页，看到 Bob 附在个人介绍中的一个比特币地址；要发送支付给 Bob，Alice 只需复制这个地址、粘贴到自己的比特币钱包软件的收款方地址中，然后点击 “发送” 按钮，就可以了。这笔交易会在网络中排队，然后被比特币网络的区块链确认。当 Bob 打开自己的钱包软件时，就会发现多了一笔钱，来自 Alice 。

但是，如果 Alice 要通过闪电网络给 Bob 支付，用户体验就不同了。在支付的时候，发送方和接收方都必须在线、交换信息。

虽然不能说绝对完美，但这里的差别，为我们解释闪电网络中的同步支付和异步支付，打下了基础。

闪电网络支付概述

为了理解异步支付的概念，先理解支付在闪电网络中如何实现，是很有帮助的。

在闪电网络中，如果 Alice 要给 Bob 发送支付，她必须先跟 Bob 请求一张发票。这意味着 Bob 必须主动打开自己的闪电钱包、为 Alice 的支付生成一张发票。跟传统的比特币地址不同，闪电网络发票是一次性的。多次支付同一张发票可能会让发送者丢失资金。

（译者注：尽管比特币地址可以复用，但地址复用是个坏习惯，会损害地址主人的隐私性；重复支付发票会给发送者带来风险，是因为在一次支付完成后，确保该支付安全性的哈希原像就已暴露，不是收款方的中间节点也可能领取第二次支付；也正因此，复用发票对收款方来说也不安全。）

在获得 Bob 的发票之后，Alice 使用自己的闪电钱包，根据发票中的信息发送支付。在背后，她的支付穿越了一连串的闪电通道，直至到达 Bob 的节点（由 Bob 的闪电钱包控制）。收到支付后，Bob 的节点要回传一条收据。这条收据保证了每个中间节点都能得到手续费，并且 Alice 也能得到保证：支付已经成功。如果（在支付送达的时候） Bob 的节点离线了（没有回传收据），这笔支付就悬在半空、无法完成。虽然闪电网络协议保证了没有人会遭遇资金损失，但也带来一个用户体验挑战，因为要保证连续在线的状态，是很难做到的，尤其是在移动设备上。

总而言之，闪电网络支付面临两个同步性障碍：

接收方必须应邀生成发票；
在支付方发送支付时，接收方必须在线。

处理异步支付

异步支付的效果

在闪电网络内实现异步支付，意味着即使接收方不在线，支付也能发起。一个中间节点会安全地扣住支付，并仅在接收方重新连接到网络、能够接收支付时送达。

简单方法

乍看起来，让闪电支付变成异步，是很容易的。发票交互问题可以通过让 Bob 的节点提前生成许多发票、存放在第三方服务端、服务端响应请求交付发票来解决。而支付确认问题可以通过让支付转发路径的最后一个节点暂时扣住支付、等待 Bob 节点上线来解决。

然而，这些方法有许多问题。最明显的一个问题是，这会在一个设计目标是免信任的支付系统中引入信任。接收方必须信任自己的发票 “保管者” 会提供诚实的服务。另一个问题是，发票会过期。最后，因为支付悬在半空，整条支付转发路径上的所有节点，都必须锁住一部分的流动性，直到 Bob 回到线上或者发票过期。这是坏的效果，因为转发节点需要高效运营自己的流动性，而让自己的流动性锁定不确定的时间是低效的。

我们可以做得更好吗？

回到 2021 年，Matt Corallo 提出，一项妥协可以提升异步支付。这需要使用 “LNURL”，然后发送者和接收者都需要使用闪电网络服务商（LSP）。他建议使用 LNURL 以异步地生成发票。这些发票可以携带一个标签，来提醒发送者，接收者连接到了某个 LSP，但当前并不在线。然后，发送者发送一笔带有很长超时时间的支付指令给自己的 LSP，要求 TA 扣住支付，直至收到某一条信息。

这个收到支付的 LSP 并不立即转发支付，从而，为这笔未完成的支付而 “锁定” 的资金就只有发送者自己的资金。然后，发送者让接收者的 LSP 在接收方回到线上时，给自己的 LSP 发送消息。然后，发送者就可以安全地下线。当接收者回到线上，TA 的 LSP 就发送消息给支付方的 LSP，触发支付的转发。

使用这种策略，在任何时间都不需要第三方托管。这意味着资金不可能被盗；而且技术上来说，LSP 也不能被定义为监管意义上的托管商。而且，一旦 BOLT 12 规范完成，它就可以替代 LNURL 。这将使异步支付更少依赖于外部服务端（而 LNURL 会依赖）。

LNURL 方法的问题在于，用户依然需要信任第三方来提供发票。不能保证这些服务供应商不会复用发票，从而允许 LSP 盗窃资金。改善这一点的一种办法是使用 PTLC 。这样一来，发送者和 LNURL 服务商必须合谋，才能窃取资金。但发送者没有理由做这样的事。

虽然在信任关系上没有一种解决方案是完美的，但相比上面的简单方法，这些都是更好的处理方法。Matt 的建议依赖于对 LNURL 服务商的信任，而且支付已然过期，就像简单方法一样。

结论

在尝试让比特币支付更快捷、更高效的竞赛中，闪电网络已显现出自己是佼佼者。不过，虽然有此潜能，当前闪电支付的同步特性，彰显了用户体验上的差距。

传统的比特币支付简单又灵活，支付的发送方和接收方无需同时联网。相反，闪电支付需要双方同时在线，产生了潜在的使用障碍。

粗疏的解决方案，比如依赖第三方发票保管商和节点暂缓转发策略，会在一个致力于免信任性的系统中引入信任。Matt Corallo 在 2021 年提出的建议，利用了 LNURL 和闪电网络服务商，提供了一个有前景的基础。它尽可能减少了锁定的流动性、赶走了第三方托管商，而且有望跟即将到来的 BOLT12 规范相配合。不过，与 LNURL 有关的信任问题依然让人顾虑。PTLC 这样的创新会增加额外的安全性。

在闪电网络中实现异步支付的冒险已经开始，各种拟议的解决方案都让我们越加接近无缝而且免信任的支付体验。

（完）