Lightning Rod 介绍

即时闪电支付为按需文化服务

见证Lightning Rod的力量！总有一天我们会用完闪电梗的库存，但今天还不是那一天！【双关】（来源：TheWhizzer）

视频点播，允许观众异步观看广播，已经有超过 25 年的历史。电话答录机（即严格基于硬件的语音邮件），允许人们在不同的地方进行异步对话，已经有超过 80 年的历史。支票，允许付款人和收款人在不同的地方、不同的时间进行异步支付，甚至可能是2300 年前发明的。

按需一直是一个非常长久的未来趋势。它正逐渐成为现实。而用户体验也在不断提高。我们甚至不再录制电视节目；我们直接流媒体播放。我们不再留语音消息；我们使用即时通讯应用。我们不再写支票；我们用 Venmo 发送款项。我们期望产品和服务在我们需要的时候随时可用。

闪电网络需要迎头赶上。

传统闪电支付重温

首先，让我们回顾一下传统闪电支付的运作方式。（如果你已经熟悉该协议，请直接跳到下一节。如果你想了解更多细节，请查看这里或这里，待你对Alice、Bob和Carol有深刻的情感了解后再回来。）

第一步：

在传统的闪电支付中，Carol（即收款人）通过向Alice（即付款人）开具发票来启动流程。Carol 的发票包含她创建的预映像的哈希值。

第二步：

Alice 发送给 Bob（即路由节点）一笔带有 Carol 预图像哈希值锁定的 HTLC 支付。

第三步：

Bob 向 Carol 发送一笔 HTLC 支付，Carol 可以用她最初发送的预图像哈希值来解锁。

第四步：

一旦 Carol 从 Bob 那里收到 HTLC 支付，她也可以将预图像分享给他，这让他可以解锁 Alice 的 HTLC。一旦他收到 Carol 的预图像，他会将预图像转发给 Alice 并完成 HTLC 支付循环。

第五步：

一旦 Alice 收到来自 Bob 的预图像，最后一步是通过用承诺交易替换 HTLC 交易来重新启动该过程，从而使支付通道保持打开状态。

问题：同时性

托管钱包很简单。它们只是将用户与他们的资金分离，并在远程的服务器上管理一切——就像比特币不过是 Candy Crush 代币一样。

非托管客户端严肃对待用户，让用户控制自己的资金，但这在用户体验上是有代价的。要在非托管客户端完成传统的闪电支付，双方——付款人和收款人——必须同时打开他们的客户端。除非双方同时在前台运行他们的移动应用，否则无法发起支付。

双方可以在不同的地方，但必须在同时为对方提供服务——就像电话一样。在按需时代，要求用户等待服务或彼此等待是倒退的。法币在异步支付方面做得更好，而超越法币是我们来这的目的。

我们目前用于解决客户端在支付两端同时在线问题的变通方法称为“连接即付”。它允许一方通过消息发送链接给另一方，当第二个用户点击它时，她那一端的支付会话就会开启。当然，这比二维码要好，但仍不理想。连接即付与打电话一样方便——它克服了空间距离，但没有消除同时性要求。对于快速通知，谁更喜欢打电话而不是发短信呢？

电话是给警察和电话推销员的。这是我们想要追求的用户体验吗？（来源：dopl3r）

通过短信，你可以传达相同的信息，接收者可以在方便时查看，而且它通过单一媒介发送，不需要同时性的要求。这就是我们要去的地方。

Lightning Rod——新标准

Lightning Rod使异步支付成为用户可完成的操作。换句话说，用户可以在他们想要的时候反应，而不是在客户端要求他们的时候。我们在这里提供了一个简化的描绘，但你也可以查看我们的 GitHub 以获取完整细节。

有时可视化会有所帮助，所以这就是棒。（来源：badgreeb RECORDS）

Lightning Rod如何运作

使用Lightning Rod，付款人（Alice）启动流程。并且没有 Bob。取而代之的是一个运行协议的节点。让我们叫这个节点“Rod”。

第一步：

Alice 发送一个秘密给 Carol。然后她可以离线去享受生活了。

第二步：

Carol 生成一个预图像，并将 Alice 的秘密哈希值与预图像哈希值（即付款发票）发送给 Rod。这实际上将 Alice → Carol 的支付拆分为两个支付：Alice → Rod 和 Rod → Carol。

现在 Carol 也可以离线去享受生活了。

第三步：

Rod 发送给 Alice 一个秘密的哈希值以及包含他从 Carol 那里接收到的预图像哈希值的 HODL 发票。（简而言之，HODL 发票允许接收方在 HTLC 的限制之外延迟或取消支付，但发送方仍然有义务付款。）

通过秘密的哈希值，Alice 可以验证支付来源，这意味着 Alice 可以验证 Carol 发起的付款请求。而多亏了 HODL 发票，她无需立即与 Rod 进行结算。

第四步：

一旦 Alice 验证了支付，她就会发送一笔 HTLC 给 Rod，后者随后发送一笔 HTLC 给 Carol，并继续从上述传统流程中的第二步开始的步骤。

换句话说，一旦付款人启动该流程，收款人可以在她闲暇时发送发票，而付款人可以按她的意愿付款。Rod 最终做了大部分等待，不过这没关系。这颗老心已为你守候多时了。

有几个关键特性需要注意。

• 与传统的闪电支付不同，在第一步 Alice 发送初始密文时存在与 Carol 的直接沟通。她可以通过自己选择的安全消息应用程序发送这个密文。

• 交易仍然是无需信任的。初始密文仅用于向 Alice 证明 Rod 的信誉（即“别担心。Carol 派我来的。”）。但如果没有 Carol 的预映像，Rod 无法使用 Alice 的资金。

• 虽然有两个独立的发票，但单个预映像实际上将它们绑定在一个支付程序中。

• 当付款人和收款人使用同一Lightning Rod时，它将了解到交易的来源、目的地和金额。用户可以通过使用多个随机选择的Lightning Rod来提高隐私，这与使用弹跳路由节点类似。协议支持在同一个支付中使用多个Lightning Rod，例如 Carol 将信息发送给 Rod B，而 Rod B 与 Rod A 交互，因此 Rod A 不知道 Carol（Alice → Rod A → Rod B → Carol）。

顺便说，我最近在柏林的一次闪电会议上解释了这个过程。（如果想看我的完整演示，请点击这里。）

为何如此？

我们正在努力推广比特币， 这意味着我们必须胜过法币，既要比现金更硬，又要像 Venmo 一样方便。但是光说这些是不够的。我们实际上需要创新---构建一个更好的捕鼠器，并不断改进它。

Lightning Rod是我们最新的创新。它使我们更近了实现闪电经济主流化的目标。它为我们一直缺乏的功能——异步支付——提供了基础设施，并且以一种尊重比特币价值和底层技术的方式来实现。

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