作者：Roy Sheinfeld，Breez 联合创始人兼首席执行官 翻译：善欧巴，金色财经

就像我这样的狂热支持者，没有人比我们更爱批评闪电网络。我也是Ben Carman一样的人。他在最近的一篇Stacker News文章中强调了流动性和离线支付如何阻碍闪电网络的用户体验，进而阻止人们进行自我托管。这似乎只是另一个抱怨，抱怨未来没有兑现它的承诺。我们曾被承诺会飞的汽车，最终却只得到了互联网奇迹。一切都令人惊叹，但没人满意。

然而，仔细观察，Ben说得有道理。多年来，我一直在谈论闪电网络的UX，包括离线支付的挑战。我们甚至在2019年就提出了离线支付问题的解决方案（我将在下面解释为什么我们从未实施它）。

我们可能觉得所承诺的未来永远遥不可及，但构建闪电网络就像攀登一座山。登山者只有站在山顶，才能真正看到山顶。他们甚至经常看不到下一个山脊。规划登山很重要，但大部分时间你只是专注于下一个落脚点。但这些步骤会累积起来。就像登顶后的景色是所有努力的回报一样，构建网络一步一步地，我们将迎来一个更加光明的金融未来。这就是闪电网络从一个想法发展成为一个功能性比特币支付网络的方式，这也是我们将到达目的地的方式。

由于离线支付是一个长期存在的用户体验挑战，让我回顾一下这个问题从何而来，目前有哪些技术可以解决这个问题，以及即将出现的情况。

问题

只体验过法定货币、链上比特币或托管钱包的人可能甚至不知道“离线支付”是一回事。法定货币和托管钱包通过控制用户的资金来解决这个问题。银行/托管人从其他用户的银行/托管人接收资金/欠条，并在用户要求时发送资金/欠条。如果用户从未真正保管过资金，那么他们是否在线并不重要。只有那些真正控制金钱的人才需要上网。对于链上比特币，发送者只需要接收者的地址。

自我托管闪电网络更具挑战性，因为交易双方需要同时在线。收件人需要向发件人发送发票，发件人需要发起付款，收件人必须签名。这种安排恢复了用户对自己资金的控制权，但也可能给用户体验带来痛苦。

过去：尝试与错误

在诺尔盖和希拉里最终成功之前，有记录的 11 次攀登珠穆朗玛峰的尝试。Breez 破解离线支付的第一次尝试称为“Connect to Pay”，它促使发送者在付款即将完成时通知接收者，以便接收者打开他们的闪电应用程序。基本的用户体验理念类似于电话：让双方同时忙于同一件事。但无需有意识的努力即可获得付款的能力实在是太根深蒂固了。这是我们都期望的用户体验，没有什么比这更好的了。（人们甚至不喜欢打电话。他们唱关于它的歌曲。）

我们的下一个想法，我们称之为Breez，更加复杂。这个想法是使用HODL 发票让发送者和接收者之间的路由节点拦截付款，直到接收者可用。因此，这很像宙斯的扎普洛克的想法。

尽管Breez有效，但我们从未将其投入生产，因为 HODL 发票无法针对路由节点进行扩展。他们占用资金。当路由节点持有一笔交易时，它基本上是向接收者提供无息贷款。流动性必须流动。通过在途中冻结异步支付来解决异步支付问题只会加剧流动性问题。

我们在正确的山上，但走错了路线。

现状：支持线下支付的现有手段

好消息是，技术已经发展到可以处理离线支付。现有的方法都不是完美的解决方案，因为它们都有权衡，但每种方法都有不同的用途。

LNURL-提款

第一个是LNURL-Withdraw。收件人可以扫描二维码或输入 URL，指示其应用程序向发件人请求资金。例如，想要从交易所提取资金的用户可以在方便时“提取”资金，而不是在离线时由交易所推送。

这种方法有两个主要缺点。首先，它要求发送者有一个在永久在线的服务器上运行的节点，因此它不适合非托管移动或 Web 客户端。其次，“拉动”模型仅适用于用户知道他们有资金可以兑换的非常具体的用例。例如，很难自发地给某人小费。

Breez SDK 方法：利用移动通知

移动通知是支持离线支付的另一种方式。在 iOS 或 Android 中触发移动通知甚至可以为客户端应用程序提供足够的 CPU 时间来接收付款。使用移动通知来处理收款不需要接收者的积极参与，并且为同时性问题提供了自然、非侵入性的解决方案。这就是为什么我们在 Breez SDK 中加入了一项新功能，以方便使用推送通知进行离线支付。对于 SDK 用户来说，这是一个重大的用户体验改进，只需要开发人员做一点工作。

Breez SDK 方法的工作原理如下：首先，开发人员创建一个 Webhook，LSP 可以在付款过程中调用该 Webhook。一旦付款到达作为收款人之前最后一跳的 LSP，LSP 就会通过 Webhook 调用通知传送服务 (NDS)，NDS 会向用户的手机发送带有说明的推送通知。开发人员需要以设置 NDS 的形式进行一些跑腿工作，但结果是更好的用户体验，因为用户不需要将应用程序保留在前台即可接收付款。它还使移动用户能够使用静态地址（例如闪电地址、LNURL-Pay 或 BOLT12）接收付款。

移动通知是一种改进，但不是万能药。显然，它们仅适用于移动设备，如果设备关闭或用户禁用了所需的通知，则这种方法将不起作用。此外，谷歌或苹果可能会通过改变操作系统处理通知的方式来抵消其有效性。这就是为什么我们需要一个内置于闪电协议中的解决方案。

未来：将异步支付构建到闪电网络中

下一阶段离线支付背后的想法很简单：使支付异步。由于同时性问题对自助移动和网络用户的影响最为严重，而且几乎所有此类用户都通过 LSP 连接到闪电网络，为什么不利用其始终在线的 LSP 在发送者或接收者离线时同步支付呢？

LSP可以通过拦截HTLC来及时分解支付流，从而消除了同时性问题，或者更确切地说，将其转移到LSP层面，这对LSP来说没有问题。这一切都始于发票中嵌入的一条消息，指示收件人离线但已连接到 LSP。发送方将付款连同消息一起发送到他们自己的 LSP，以将其保留较长的到期时间，以等待进一步的指示。然后，发件人向收件人的 LSP 发送消息，要求其在收件人重新上线时提醒自己的 LSP（仍持有付款）。此时，基本上由 LSP 决定。当接收者重新上线时，他们的 LSP 会向发送者的 LSP 发送信号以转发付款。

这种模型不会损害网络的整体流动性，因为唯一可以冻结资金的节点是发送者自己的 LSP，这是用户真正想要的。

虽然表面上看起来很简单，但要让这种方法达到最佳效果，就需要更多技术支持：静态发票、洋葱消息、盲路、中继跳跃支付（trampoline payments），最终还有支付通道状态更新 (PTLC)。这些技术确实复杂，但如果你想深入了解，可以观看我 2023 年在 Honeybadger 大会上的分享。目前一些闪电网络应用已经支持了部分功能，但要使其在整个网络实现互通，让所有用户都能享受最佳体验，还需要一段时间。

未来何时到来？

明天太阳当然会升起，但今天已经很灿烂了。我的观点是，我们已经有了不同的、功能性的方式来处理闪电网络上的离线支付而不放弃托管，每种方式都适合不同的用例。LNURL-Withdraw 已经适用于一些商业环境，新的 Breez SDK 功能可以实现移动设备的离线支付。

这很酷！我们并不总是这样，但现在我们有了。我们已经生活在昨天的未来。

基于协议的解决方案仍在进行中。许多实现，如 Eclair、LDK、lndk 和 Core Lightning（是的，我正在看你的 lnd）正在实现这一目标所需的功能方面取得进展。一旦实施，异步支付将带来巨大的用户体验改进。这是一个值得追求的未来。

当我们到达那里时，我确信还会有其他挑战需要我们的关注并考验我们的耐心，但我们永远不要忘记我们已经攀登了多高。