Ark as a Channel Factory: Compressed Liquidity Management for Improved Payment Feasibility

I’ve been interested in this direction for a little under a year and have been doing exploratory work towards this recently.

My focus is under the assumption that routing nodes are already highly provisioned, but end-nodes such as mobile clients and related make LSP economics difficult at best due to inbound liquidity requirements, which could be highly optimized by layering it on Ark. Given my focus on LSP+mobile client style arrangements, this also lets me punt on the gossip/routing question for now.

This is essentially a Timeout Tree with the ability to “teleport” the end-channels between trees, at the cost of the additional wait at the leaf’s “forfeit” stage to ensure the ASP isn’t being double-spent (which imo is immaterial to user incentives).

With the hash-based Ark (hArk), I think this architecture becomes quite plausible with a lightly modified variant of today’s LN:

  1. Normal channel operation in a tree
  2. Client+LSP request refresh to new tree
  3. Tree with refreshed vtxo is generated / confirmed (can even be done predictively before 2!)
  4. Client+LSP quiesce old channel
  5. Client+LSP do new tree vtxo channel setup (clone channel)
  6. Client+LSP sign forfeit tx ← Old channel revoked, new channel can only be claimed if revoke spent
  7. ASP sends hash preimage ← new channel under control of Client+LSP
  8. Client-LSP unquiesce channel in new tree, continue operation

Note that with predictive tree generation and confirmation, this results in the client being able to refresh their channel nearly instantaneously, even if they only unlock their mobile phone once before old tree expiry.

Note that connector-based Ark would make the interactivity story significantly more daunting, or force significant channel downtime during round refreshes.

There are lots of details to sort out clearly, but I just wanted to sketch out what this could practically look like with no consensus or mempool changes, nor major BOLT rewrites.

Since Lightning already requires on-chain confirmations for such changes, Ark does not worsen latency from this perspective as ark rounds could eventually take place in every block

One UX consideration here is that with today’s LN, 0-conf channels allow the client to see the fully signed transaction right away, while if you were waiting for batching rounds, this is another step removed. The LSP is promising that that ASP will emit a transaction with the appropriate structure to generate a new channel vtxo.

7 Likes