作者：Nadav Kohen
来源：https://suredbits.com/payment-points-part-2-stuckless-payments/
在我们的上一篇文章中，我们讲到了，使用原像和哈希值来做闪电网络的原子化支付，可能导致路由支付的关联曝光以及遭遇虫洞攻击。我们也讨论了，使用标量和点来替代原像和哈希值，可以隐去支付之间的关联，并解决哈希支付面临的问题。在本文中，我们将讨论基于点支付，闪电网络上可以出现的一些新功能！
点支付合约系列
Payment Points Part 1: Replacing HTLCsPayment Points Part 2: “Stuckless” Payments
Payment Points Part 3: Escrow Contracts
Payment Points Part 4: Selling Signatures
在当前的闪电网络中，即使已经过了启动阶段，支付也是可以 “卡住” 的。所以资金可能会锁在哈希时间锁合约（HTLC）中，等时间锁过期后才能解锁（可能要等待很长一段时间）。支付卡住可能因为很多原因。应当注意的是，一个恶意节点也可以扣住你的支付，而不必付出任何个人代价（只不过得不到 TA 本可以获得的手续费）。即使有办法可以在启动期间解除支付，结算也有可能卡住（较不严重）。在这种情况下，接收方可以收到资金，但支付方得不到支付凭证（Proof of Payment，PoP）。
几个月前，Hiroki Gondo 曾经在 lightning-dev 邮件组中提出过一个无滞支付的提议，通过在启动阶段和结算阶段之间增加一轮叫做 “更新” 的通信，来解决这两个问题。
（译者注：下面这一段需参考前一篇文章，才能了解其区别。）
假设 Alice 要给 Carol 支付，如图所示。在 “启动” 阶段，在 Alice 把随机数的和通过洋葱网络发给 Carol 之前（注意，这个和是要用在这次路由支付的 “结算” 阶段的），Carol 在自己收到点时间锁合约（表明支付在 “启动” 阶段并没有卡住）后，先发送一个 ACK 给 Alice。收到 ACK 之后，启动阶段才算完成；这时候 “更新” 阶段开始，Alice 把随机数的和发给 Carol，然后 Carol 回复以支付凭证（因为从功能上来说，支付已经完成了）。最后，“结算” 阶段如往常一样进行。
这就解决了支付在结算阶段卡住的问题，因为 Alice 在结算阶段开始前就已经收到了支付凭证。
但它如何解决支付在启动阶段卡住的问题呢？答案是：现在卡住的交易可以安全地重发了。
Alice 不仅可以重新尝试以新路径给 Carol 支付，她甚至可以并行尝试两笔支付！因为 Alice 没有给 Carol 用来结算支付的信息，要到更新阶段才给，所以 Alice 可以安全地跟 Carol 启动多个路径，Carol 也知道只有其中一个路径会被使用。这是因为只有 Alice 可以启动更新阶段，Carol 无法径直结算 Alice 启动的所有支付（而在当前的闪电网络中 Carol 是可以这么做的）。因此，Alice 尝试创建的支付中只有一个会成功启动，只有这个会成功，其它的都会失败。
注意，Bob 在这里要做的与普通的闪电支付没有什么不同。所以，这个方案不需要所有闪电节点都使用，只需每笔支付的终点节点使用就可以了（可能还要加上路由 ACK 和更新信息的所有节点）。
另一个重要提醒是，虽然一种类似的方案可以使用哈希值和原像来实现，但它会要求 Alice 一开始就知道哈希值的原像，所以还是得不到支付凭证。支付凭证是非常重要的，不仅因为应用层的代码依赖于它，还因为它可以用来搭配使支付与其它操作原子化，例如信息解密。
这种 “无滞” 支付提议是许多依赖于点支付方案的闪电网络提议之一。在我的下一篇文章中，我们会继续这个系统，讲解另一个应用：闪电网络上的托管合约！
（完）