René Pichardt recently kicked off Thread Discussing the differences between two-party and multiparty (more than two participants) payment channels as it relates to their research work around payment reliability on the Lightning Network. He voices growing doubt over the feasibility of that direction for development.
A high-level idea of why channel factories improve payment reliability depends on liquidity allocation. In a network with only two party channels, users do not have to make any choices on where to allocate their liquidity. This has a systemic impact on the overall success rate of payments across the network, if people hold their liquidity elsewhere that does not need to be processed rather than where it is, payments will fail as people go to the required locations. Liquidity is used up (until it is rebalanced). This mobility is one of the design constraints of the Lightning Network known from the beginning, and why research like René’s is incredibly important to keep the protocol/network working long term.
In a model of multiparty channels, users can allocate liquidity into larger groups and “sub-allocate” it off-chain wherever it makes sense at the time. This means that even if a node operator made a poor decision about which person to allocate liquidity to, as long as that person is in the same multiparty channel with people who would be a good peer, they will receive that bad liquidity. Can reallocate from one to the other off-chain without incurring on-chain costs.
This works because the concept of a multiparty channel is essentially to put traditional two party channels on top of a multiparty channel for everyone in the group. By updating the multiparty channel at the root, the two party channels at the top can be modified, opened, closed, etc. while remaining 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 on the idea that if your single channel counterparty stops cooperating or responding, you can submit transactions on the 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 to enforce the current state, meaning multiparty channels in a higher fee environment. More than two will be expensive. To implement party channels on-chain.
These are the main trade-offs to consider when looking at these systems compared to each other, but I think focusing exclusively on the on-chain footprint misses the more important point in relation to off-chain systems. Ignored: They’re all about encouraging the participants No Go on-chain.
Structuring a multiparty channel appropriately, i.e. how you organize the channels placed at the top, can allow you to pack groups of people into sub-channels that have a reputation for high reliability, or which Trust each other. This will allow people in these subgroups to still 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 implementing things, although significant, is tangential to the basic design goal of an off-chain system: to give people a reason to stay off-chain and cooperate, and to force people not to cooperate. Removing the causes of things on-chain.
When considering what the future of these systems will look like, it is important not to overlook the core design aspects of these systems.
