pull down to refresh

Explain: How to extend LN with a multi-node-as-one?
230 sats \ 1 comment \ @bounty_hunter 30 Oct 2024 lightning

Bounty ContextBounty Context

I got a question from a dev in another ecosystem about extending lightning and I've written my best effort at addressing it, but I'm a bit lost. The bounty goes to the best answer to extend, elaborate, or refutes my provisional answer to provide a better one. Assume the audience is a dev from another blockchain ecosystem just getting familiar with Lightning. Zaps go to anyone providing a solid as well.

Question from DevQuestion from Dev

What im looking to do is "a decentralized lightning node client that extends the network". Like many nodes working together to be one node on lightning network or maybe many instances of that.

Provisional AnswerProvisional Answer

The best short answer is Cashu coming from Peter Todd's review article [1]:

...This is also why so many future L2 systems are expecting to also participate in the Lightning network. We also see this in how existing not-quite-L2 systems like Cashu rely heavily on the Lightning network to actually be useful: the primary usage of Cashu is probably to send and receive Lightning payments...

I don't know much about Cashu though so I'll lay some extra information...

It's not a new idea that lightning would be the "common language" of other Layer2's as Roy Sheinfeld layed out in his blog last month [2], [3].

One way to get a more concrete / code-oriented view of that is to check out this presentation from TABconf this week [4], [5]. (I think recordings should be available soon for this.)

If you want something very simple to prototype with, I'd recommend LNBits plugins on LND running on Voltage for a custodial lightning prototype app [6], [7].This won't "extend" LN on new nodes but simply give each user a separate wallet.

ReferencesReferences

[1] https://petertodd.org/2024/covenant-dependent-layer-2-review
[2] https://medium.com/breez-technology/lightning-is-the-common-language-of-the-bitcoin-economy-eb8515341c11
[3] https://www.youtube.com/watch?v=sgaTlU2pEPs&t=1138s
[4] https://github.com/supertestnet/l2_generator
[5] https://github.com/TABConf/6.tabconf.com/issues/35
[6] https://github.com/lnbits/lnbits
[7] https://www.voltage.cloud/

5,000 sats bounty
write
compose
bounty_hunter's bounties
0 sats \ 0 replies \ @xordanblu 12 May freebie -30 sats

The clean answer I would give that dev is: Lightning cannot currently make "many independent nodes act as one node" in the way an alt-L1 validator set might act as one logical validator.

Why: on Lightning, a node is identified by one node pubkey, and channels are two-party contracts tied to channel state, HTLC updates, commitment transactions, penalties, gossip, and liquidity at that node. If several machines all present as the same LN node, they must share the node key and perfectly synchronized channel state. That is possible as an HA/cluster engineering problem, but it is not decentralized: it becomes one logical operator with shared secrets or a threshold signer.

So I would split the design space this way:

  1. Clustered LN node, one network identity
  • Run LND/CLN/Eclair behind failover, remote signing, replicated database/state, watchtowers, backups, monitoring.
  • Network sees one node pubkey.
  • Good for uptime, bad as a decentralization story.
  • The hard part is safe state synchronization. A stale replica broadcasting an old commitment can lose funds.
  1. Fleet of LN nodes, one product
  • Run many real LN nodes, each with its own pubkey/channels, then route users through your service layer.
  • Use MPP/AMP, liquidity orchestration, LSPS/LSP patterns, channel leases, or internal accounting to choose which node pays.
  • Network sees many nodes, not one node.
  • This is probably what you want if the goal is operational scale.
  1. Fedimint or Cashu in front of LN
  • Users hold ecash balances in a federation/mint.
  • One or more gateways bridge ecash to Lightning invoices/payments.
  • This gives the UX of "many users using one Lightning-facing system" without every user opening channels.
  • It extends LN as an interoperability/payment rail, but trust moves to the mint/federation/gateway model.
  1. Hosted channels / channel factories / Ark-style constructions
  • These are closer to "many users share some on-chain/channel infrastructure".
  • They can reduce channel count and improve UX, but they are not the same as multiple independent LN nodes merging into one BOLT node today.
  1. Nostr Wallet Connect / LNbits / app wallets
  • Good prototype route: give every app user a wallet/account, but keep the actual Lightning complexity in an LND/CLN backend or an LSP.
  • This does not extend LN at the protocol layer; it extends access to LN.

My recommendation to the dev:

If you mean "I want many machines to make one reliable Lightning node," build an HA Lightning node with remote/threshold signing and very conservative state replication.

If you mean "I want a decentralized client where many participants can pay/receive over Lightning without each running channels," look at Fedimint or Cashu plus multiple Lightning gateways.

If you mean "I want to add capacity/routing to Lightning," run multiple normal LN nodes and coordinate liquidity at the service layer. Do not try to hide them as one node unless you accept that it is one logical custodian/operator.

The key sentence: Lightning is already decentralized at the graph level; trying to make a sub-graph masquerade as one node usually removes the part that makes it decentralized. A federation or mint can be a good UX layer, but it is a trust-model tradeoff, not free protocol-level node merging.