Rene Pickhardt not too long ago kicked off a thread discussing the variations between two get together and multiparty (greater than two individuals) cost channels because it pertains to his analysis work round cost reliability on the Lightning Community. He voices a rising skepticism of the viability of that path for growth.
The excessive stage concept of why channel factories enhance the reliability of funds comes all the way down to liquidity allocation. In a community of solely two get together channels, customers must make zero sum selections on the place to allocate their liquidity. This has a systemic impact on the general success fee of funds throughout the community, if folks put their liquidity someplace it isn’t wanted to course of funds as an alternative of the place it’s, funds will fail because the liquidity in locations folks want is used up (till it’s rebalanced). This dynamic is just one of many design constraints of the Lightning Community identified from the very starting, and why analysis like Rene’s is extremely essential for making the protocol/community work in the long term.
In a mannequin of multiparty channels, customers can allocate liquidity into massive teams and easily “sub-allocate” it off-chain wherever it is sensible to within the second. Which means that even when a node operator has made a poor determination through which individual to allocate liquidity to, so long as that individual is in the identical multiparty channel with folks that might be a superb peer, they’ll reallocate that poorly positioned liquidity from one to the opposite off-chain with out incurring on-chain prices.
This works as a result of the idea of a multiparty channel is actually simply everybody within the group stacking standard two get together channels on prime of the multiparty one. By updating the multiparty channel on the root, the 2 get together channels on prime may be modified, opened, closed, and so forth. whereas staying off-chain. The issue Rene is elevating is the price of going on-chain when folks don’t cooperate.
The whole logic of Lightning is predicated round the concept in case your single channel counterparty stops cooperating or responding, you possibly can merely submit transactions on chain to implement management over your funds. When you’ve a multiparty channel, every “stage” within the stack of channels provides extra transactions that have to be submitted to the blockchain so as to implement the present state, which means that in a excessive charge atmosphere multiparty channels can be costlier than two get together channels to implement on-chain.
These are core trade-offs to think about when these techniques in contrast to one another, however I feel focusing solely on the on-chain footprint ignores the extra essential level concerning off-chain techniques: they’re all about incentivizing individuals to not go on-chain.
Correctly structuring a multiparty channel, i.e. the way you set up the channels stacked on prime, can mean you can pack teams of individuals into subsections which have a fame for prime reliability, or who belief one another. This is able to enable folks in these subgroups to nonetheless reorganize liquidity inside that subgroup even when folks outdoors of it aren’t responsive quickly, or go offline on account of technical points. The on-chain price of imposing issues, whereas essential, is sort of tangential to the core design purpose of an off-chain system: giving folks a cause to remain off-chain and cooperate, and eradicating causes for folks to not cooperate and power issues onc-chain.
It’s essential to not lose sight of that core design side of those techniques when contemplating what their future will appear like.
