René Pickhardt recently started a thread discusses the differences between two-party and multi-party payment channels (more than two participants) in relation to his research work on the reliability of payments on the Lightning Network. He expresses growing skepticism about the viability of that direction for development.
The high-level idea of why channel factories improve payment reliability comes down to liquidity allocation. In a channel network of only two parties, users have to make zero-sum decisions about where to allocate their liquidity. This has a systemic effect on the overall success rate of payments across the network; If people put their liquidity somewhere it's not needed to process payments instead of where it is, payments will fail as liquidity runs out in the places people need it (until it rebalances). This dynamic is simply one of the design limitations of the Lightning Network known from the beginning, and why research like René's is incredibly important to making the protocol/network work in the long term.
In a multi-party channel model, users can allocate liquidity in large pools and simply “sub-allocate” it off-chain where it makes sense at the time. This means that even if a node operator has made a bad decision about which person to allocate liquidity to, as long as that person is in the same multi-party channel with people who would be a good peer, they can reallocate that misplaced liquidity from one to the other outside. of the chain without incurring costs within the chain.
This works because the concept of a multi-party channel is essentially all members of the group stacking conventional two-party channels on top of the multi-party one. By updating the multi-party channel at the root, the top two channels can be modified, opened, closed, etc. while remaining off-chain. The problem that René raises is the cost of entering a chain when people do not cooperate.
Lightning's entire logic is based on the idea that if your single-channel counterparty stops cooperating or responding, you can simply send transactions on-chain to impose control over your funds. When you have a multi-party channel, each “level” in the channel stack adds more transactions that must be sent to the blockchain to enforce the current state, meaning that in a high fee environment multi-party channels will be more expensive than two. party channels to enforce the chain.
These are critical trade-offs to consider when comparing these systems to each other, but I think focusing exclusively on the on-chain footprint ignores the most important point regarding off-chain systems: it's about incentivizing participants to No go in chain
Properly structuring a multiparty channel, that is, how to organize channels stacked on top, can allow you to group groups of people into subsections that have a reputation for high trustworthiness or that trust each other. This would allow people in these subgroups to reorganize liquidity within that subgroup even if people outside of it are temporarily unresponsive or go offline due to technical issues. The on-chain cost of enforcing things, while important, is tangential to the central design goal of an off-chain system: to give people a reason to stay off-chain and cooperate, and to eliminate reasons for people not to cooperate and force. chain things.
It is important not to lose sight of that central aspect of the design of these systems when considering what their future will look like.
