Rene Beckhardt recently started a string Discuss the differences between two-party and multi-party payment channels as they relate to his research work on payment reliability on the Lightning Network. Increasing doubts were expressed about the feasibility of this trend for development.
The high-level idea as to why channel factories improve the reliability of payments goes back to liquidity allocation. In a network of only two party channels, users have to make zero-sum choices about where to allocate their liquidity. This has a systemic impact on the overall success rate of payments across the network, if people put their liquidity where it is not needed to process payments instead of where it is, payments will fail as the liquidity is used where people need it (until rebalancing occurs). This dynamic is simply one of the limitations of accelerator network design that has been known from the beginning, and why research like Rene’s is so important to making the protocol/network work in the long term.
In an omnichannel model, users can allocate liquidity to large pools and simply “sub-allocate” it off-chain where it makes sense at the moment. This means that even if a node operator makes a bad decision about who to allocate liquidity to, as long as that person is in the same omnichannel with people who might be a good peer, they can reallocate that poor liquidity from someone. To the other party outside the chain without incurring on-chain costs.
This works because the omnichannel concept is essentially everyone in the group stacking traditional two-party channels on top of the multiparty channel. By updating the multiparty channel at the root, bipartisan channels at the top can be modified, opened, closed, etc. while remaining off-chain. The problem Rene raises is the cost of staying on the chain when people don’t cooperate.
The entire logic of Lightning is based on the idea that if a counterparty in a single channel stops cooperating or responding, you can simply send transactions on-chain to enforce control of your funds. When you have a multiparty channel, each “level” in the channel stack adds more transactions that must be sent to the blockchain in order to enforce the current state, which means that in a high-fee environment multiparty channels will be more expensive than two-party channels to enforce on-chain. .
These are the key trade-offs to consider when looking at these systems against each other, but I think focusing exclusively on the on-chain footprint misses the most important point about off-chain systems: they are all about incentivizing participants to no Go on the chain.
Properly organizing an omnichannel, i.e. how to organize the channels stacked at the top, can allow you to group groups of people into subsections that have a reputation for high reliability, or who trust each other. This would allow people in those subgroups to continue reorganizing liquidity within that subgroup even if people outside of it temporarily did not respond, or went offline due to technical issues. The cost of enforcing things on-chain, while significant, is kind of incidental to the primary design goal of an off-chain system: giving people a reason to stay off-chain and cooperate, and removing reasons for people not to cooperate and force things once on-chain.
It is important not to lose sight of the fundamental design aspect of these systems when thinking about what their future will look like.