Rene Pickhardt recently kicked off a thread discussing the differences between two party and multiparty (more than two participants) payment channels as it relates to his research work around payment reliability on the Lightning Network. He voices a growing skepticism of the viability of that direction for development.

The high level idea of why channel factories improve the reliability of payments comes down to liquidity allocation. In a network of only two party channels, users have to make zero sum choices on 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 isn’t needed to process payments instead of where it is, payments will fail as the liquidity in places people need is used up (until it is rebalanced). This dynamic is simply one of the design constraints of the Lightning Network known from the very beginning, and why research like Rene’s is incredibly important for making the protocol/network work in the long run.

In a model of multiparty channels, users can allocate liquidity into large groups and simply “sub-allocate” it off-chain wherever it makes sense to in the moment. This means that even if a node operator has made a poor decision in which person to allocate liquidity to, as long as that person is in the same multiparty channel with people that would be a good peer, they can reallocate that poorly placed liquidity from one to the other off-chain without incurring on-chain costs.

This works because the concept of a multiparty channel is essentially just everyone in the group stacking conventional two party channels on top of the multiparty one. By updating the multiparty channel at the root, the two party channels on top can be modified, opened, closed, etc. while staying off-chain. The problem Rene is raising is the cost of going on-chain when people don’t cooperate.

The entire logic of Lightning is based around the idea that if your single channel counterparty stops cooperating or responding, you can simply submit transactions on chain to enforce control over your funds. When you have a multiparty channel, each “level” in the stack of channels adds more transactions that need to be submitted to the blockchain in order to enforce the current state, meaning that in a high fee environment multiparty channels will be more expensive than two party channels to enforce on-chain.

These are core trade-offs to consider when looking at these systems compared to each other, but I think focusing exclusively on the on-chain footprint ignores the more important point regarding off-chain systems: they are all about incentivizing participants to not go on-chain.

Properly structuring a multiparty channel, i.e. how you organize the channels stacked on top, can allow you to pack groups of people into subsections that have a reputation for high reliability, or who trust each other. This would allow people in these subgroups to still reorganize liquidity within that subgroup even if people outside of it are not responsive temporarily, or go offline due to technical issues. The on-chain cost of enforcing things, while important, is kind of tangential to the core design goal of an off-chain system: giving people a reason to stay off-chain and cooperate, and removing reasons for people to not cooperate and force things onc-chain.

It’s important to not lose sight of that core design aspect of these systems when considering what their future will look like.