离线支付的过去、现在和未来

没有人比闪电网络最热情的支持者更挑剔了。像我这样的人。像 Ben Carman 这样的人。在最近的 Stacker News 帖子中，他强调了流动性和离线支付是阻碍用户体验和阻止自我托管的闪电网络方面。这可能看起来像是对未来未能兑现承诺的又一次抱怨。我们被承诺了飞行汽车，而我们得到的只是互联网的奇迹。一切都很棒，但没人感到快乐。

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

可能感觉好像承诺的未来永远遥不可及，但构建闪电网络很像爬山。登山者在站在山顶之前从未真正见过山顶。他们通常甚至看不到下一个山脊。计划攀登很重要，但大多数时候你只是专注于下一个立足点。但这些步骤会累积起来。就像从山顶看到的风景是对所有努力的回报一样，一个更光明的货币未来将是我们一点一点构建网络的回报。这就是闪电网络如何从一个想法发展成为一个功能性的比特币支付网络，以及我们将如何到达目的地。

和登山一样，我们谁也无法独自到达那里。（图片：Sylvain Mauroux）

由于离线支付是一项长期的用户体验挑战，让我回顾一下这个问题从何而来，目前有哪些技术可用于处理它，以及未来会怎样。（我将在接下来的文章中回顾 Ben 的另一个问题 - 渠道流动性。）

问题

那些只体验过法币、链上比特币或托管钱包的人可能甚至没有意识到“离线支付”这件事。法币和托管钱包通过控制用户的资金来解决问题。银行/托管人从其他用户的银行/托管人那里接收资金/IOU，并在用户要求时发送资金/IOU。如果用户从未实际托管资金，那么他们是否在线并不重要。只有那些实际控制资金的人才需要在线。对于链上比特币，发送者只需要接收者的地址。

自我托管的闪电网络更具挑战性，因为交易的双方需要同时在线。接收者需要向发送者发送发票，发送者需要发起付款，接收者必须对其进行签名。这种安排恢复了用户对其自身资金的控制，但它也可能是用户体验中的一个痛点。

过去：试验和错误

在 Norgay 和 Hillary 最终成功之前，有11 次有记录的尝试攀登珠穆朗玛峰。Breez 破解离线支付的第一次尝试被称为“连接以支付”，这促使发送者在付款即将通过时通知接收者，以便接收者打开他们的闪电网络应用程序。底层的用户体验理念类似于电话：只是让双方同时忙于同一件事。但是，毫不费力地接收付款的能力实在是太根深蒂固了。这是我们都期望的用户体验，没有其他方法可以做到。（人们甚至不喜欢打电话。他们唱歌来表达这一点。）

我们的下一个想法，我们称之为 Lightning Rod，更为复杂。这个想法是使用 HODL 发票 让发送者和接收者之间的路由节点拦截付款，直到接收者可用。因此，它很像 Zeus 的 Zaplocker 想法。

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

我们在正确的山上，但采取了错误的路线。

现在：支持离线支付的现有手段

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

LNURL-Withdraw

第一个是 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）接收付款。

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

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

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

LSP 可以通过拦截 HTLC 来及时分解支付流程，从而消除同时性问题，或者更确切地说，将其转移到 LSP 的级别，这对 LSP 来说不是问题。一切都始于嵌入在发票中的一条消息，指示接收者已离线但已连接到 LSP。发送者向他们自己的 LSP 发送付款，并附带一条消息，指示他们自己的 LSP 持有该付款，并设置一个较长的到期时间，等待进一步的指示。然后，发送者向接收者的 LSP 发送消息，要求其在接收者重新上线时提醒他们自己的 LSP（仍在持有付款）。此时，基本上取决于 LSP。当接收者重新上线时，他们的 LSP 会向发送者的 LSP 发出信号以转发付款。

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

听起来很简单，但这种方法需要更多的技术才能优化运行：静态发票、onion messages、盲路由、trampoline payments 以及最终的 PTLC。这很复杂，但那些想深入了解的人可以观看我在 Honeybadger 2023 上的会议。虽然一些闪电网络实现已经支持其中一些功能，但整个网络采用它们还需要一段时间，这对于互操作性至关重要。

未来何时到来？

当然，太阳明天会升起，但它今天已经在发光了。我的意思是我们已经拥有不同的、功能性的方法来处理闪电网络上的离线支付，而无需放弃托管，每种方法都适用于不同的用例。LNURL-Withdraw 已经适用于某些商业环境，而新的 Breez SDK 功能支持移动设备的离线支付。

太酷了！我们并非一直拥有这些，但现在我们有了。我们已经生活在昨天的未来。

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

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

• 原文链接： medium.com/breez-technol...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～