Improving Payment Latency by Fast Forwards

Summary:

The Lightning Network protocol for forwarding payments currently requires 1.5 round trips before the next node can safely forward the payment, which creates greater latency for payments even with the current network at a nascent stage. Remote route lookups are likely to increase the route length, causing more payment latency. To improve payment latency, it is necessary to consider ways to optimize the system.In the current protocol, Alice and Bob need to revoke their previous commitment transaction before Bob can safely forward to Carol. This process requires 1.5 round trips, which creates additional latency on top of communication latency. The Poon-Dryja commitment transaction improves this by having each commitment transaction with at least two outputs: "to-local" output and "to-remote" output. The "to-local" output is encumbered by a CSV and is revocable. The "to-remote" output pays directly to a P2WPKH. At the 2018 Lightning Developer Summit, it was decided that the "to-remote" output will also be encumbered by a CSV to reduce communication latencies when forwarding payments. Additionally, the author proposes using fast forwards to say that an HTLC is "irrevocably committed" using only a single message from Alice to Bob. The author defines a new message called `fastforward_add_htlc`, which creates a pair of transactions, the fast-forward HTLC transactions, on top of the latest commitment transactions of both nodes. Fast forwards imply higher risk for nodes that accept fast forwards and which then themselves forward immediately. Fast failures are common due to incomplete information. Channels offering low-latency fast forwards need to charge higher off-chain fees to offset the risk that they need to pay on-chain fees. To determine the truth of the fast forward, nodes could make known-failing payments continuously in the background.Decker-Russell-Osuntokun does not need fast forwards if the link-level protocol is designed properly. Each update message includes the signature needed for the next update transaction and the next state transaction, that immediately has the new state. Upon receiving an "add HTLC", one can now construct the full next update transaction/next state transaction, and the existence of this update transaction is enough to invalidate any previous update transaction. So it is safe to forward the "add HTLC" to the next hop immediately as soon as the node can update its local database. The Lightning Network has a payment latency issue due to the need for commitment transaction synchronization. A proposed solution is the "fast forward" technique, which reuses the revocation path to root a new transaction in order to propagate failed payments via 'update_fail_htlc'. This is possible because the HTLC construction used by Lightning is revocable. The difference with fast-failed HTLCs is that they do not immediately contribute back to the "main" output as only when failure of the HTLCs has been put in a new commitment transaction can their value be reused for adding new HTLCs. However, this increases the risk of unilateral close after fast-forward or fast-fail and additional transactions need to be put on-chain, beyond just the commitment transactions, which require fees.There is an issue of conflicting 'next update' messages, which can be resolved by coordinating with the counterparty.

Updated on: 2023-06-02T18:32:24.784554+00:00