Scaling LN With Hosted Channels
TL/DR
Hosted channels (HC) is an extention to LN protocol which allows two LN nodes to establish a new type of channel between them which is intentionally not backed on chain.
One side of such channel is called a Host because it’s a side where the actual money is stored, the other side is called a Client and it’s the one which trusts Host (amount of trust can be measured as HC capacity).
HCs are not enforceable on chain but still preserve Client privacy and Host’s balance obligations are cryptographically provable at all times so the only type of scam a Host can viably perform is an exit scam.
Established HC can be announced to Lightning network: doing so increases overall network liquidity and makes it more capital-efficient since other LN nodes can now use public HCs for routing without added trust assumptions on their side.
The Problem
Lightning has an existential liquidity issue. It manifests itself as a failed payment which happens because there turns out to be no route with enough liquidity in a given direction to get a payment through.
One viable solution is adding more channels but currently this invariably requires coins to be put into each new channel and then be kept there for a long time. At some point an LN node operator may not have enough funds to afford another chain-backed channel and fulfill a routing demand.
The Solution
If LN node owner trusts another node to a certain degree or herself runs many LN nodes then she may open HCs between these nodes which would address liquidity issues in 3 specific ways:
1 Augmented routing graph
Node owners may broadcast an established HC avilability to Lightning network. Other HC-enabled nodes collect this gossip and include public HCs into their local routing graphs. This gives them an ability to construct payment routes which contain both chain-backed and Hosted channels as hops, thus increasing existing routes' throughput and enabling new routes which did not exist previously.
It is safe for other nodes to use mixed channel routes as long as their local channels are chain-backed: whatever happens further down the route both payment sender and receiver can always either take a payment back on chain or get it successfully delivered.
2 Non-strict forwarding
Imagine that some routing node has two channels leading to payment recipient. Channel #1 is empty from routing node’s side while channel #2 is full and can be used to deliver a payment.
Now imagine an incoming routed payment which instructs node to route it specifically through empty channel #1: this is an impossible task but routing node is free to use channel #2 instead without sender knowing. This is not a violation of any kind but just a mechanism which any routing node can leverage.
Channel #2 may very well be an HC which routing node may utilize as a fallback mechanism to still route otherwise hopless payments. Non-strict forwarding is also a way for HC-disabled payer nodes to still benefit from HCs without even knowing they exist.
3 Private routing
HCs and private routing are additive technologies: they work better together. A routing-enabled mobile node is free to open private HCs and use them to trampoline-route 3rd party payments.
Status
As of 2021-12-30:
A total of 4 network nodes are known to have public hosted channels and also can work as Host side for private channels:
A total of 1 user-facing wallet supports private hosted channels: