Rene Pickhardt recently kicked off one wire discussing the differences between two-party and multi-party (more than two participants) payment channels in relation to his research work on the reliability of payments on the Lightning Network. He expresses growing skepticism about the feasibility of that development direction.
The high-level idea of why channel factories improve payment reliability comes down to liquidity allocation. In a network of channels with only two parties, users must make zero-sum choices about where to allocate their liquidity. This has a systemic effect on the overall success rate of payments over the network. If people put their liquidity where there is no need to process payments instead of where it is, payments will fail because the liquidity in places that people need is used up (until it balances out again). This dynamic is simply one of the design limitations of the Lightning Network that was known from the very beginning, and why research like Rene’s is incredibly important to making the protocol/network work in the long term.
In a multi-party channel model, users can divide liquidity into large groups and easily “sub-allocate” it off-chain where it makes sense at the time. This means that even if a node operator makes 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, he can redistribute that poorly placed liquidity from one node. to the other off-chain without incurring on-chain costs.
This works because the concept of a multi-party channel essentially involves everyone in the group stacking conventional two-party channels on top of the multi-party channel. By updating the multi-party channel at the root, the two party channels at the top can be changed, opened, closed, etc. while remaining off-chain. The problem that Rene raises is the costs of working in the chain if people do not cooperate.
The entire logic of Lightning is based on the idea that if your counterparty in one channel becomes uncooperative or unresponsive, you can simply submit transactions up the chain to enforce control of your funds. If 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. This means that in a high-fee environment, multi-party channels will be more expensive than two. party channels to enforce on-chain.
These are important considerations to take into account when comparing these systems, but I think focusing solely on the on-chain footprint ignores the more important point about off-chain systems: it’s all about encouraging participants to not get chained.
By properly structuring a multi-party channel, that is, how you organize the stacked channels, you can divide groups of people into subsections that have a reputation for being highly trustworthy, or that trust each other. This would still allow people in these subgroups to reorganize liquidity within that subgroup, even if people outside of it temporarily become unresponsive or go offline due to technical issues. The on-chain costs of enforcing things, while important, go some way to the core design goal of an off-chain system: giving people a reason to stay off-chain and collaborate, and removing reasons for people not to participate to work and force. things onc chain.
It’s important not to lose sight of that core design aspect of these systems when considering what their future will look like.