Rene Pickhardt recently started a series discussing the differences between two-party and multiparty (more than two participants) payment channels as they relate to his research work on payment reliability on the Lightning Network. He expresses growing doubts about the effectiveness of that approach to development.
A high-level view of why channel factories improve the reliability of payments comes down to the allocation of funds. In a two-party channel network only, users have to choose a zero sum of money where to allocate their money. This has a systemic impact on the success rate of payments across the network, if people put their money somewhere where payments don’t need to be processed instead of where it is, payments will fail as payments are being used in places where people need them (until rebalancing). This dynamic is just one of the Lightning Network’s known design constraints from the start, and why research like Rene’s is incredibly important to making the protocol/network work over time.
In a multi-party channel model, users can invest in large groups and simply “split” off-chain wherever 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 multi-party channel with good peers, they can re-allocate that misplaced money from another. in another off-chain without incurring on-chain costs.
This works because the concept of a multi-group channel is basically everyone in a group stacking two group channels on top of a multi-group channel. By updating the multi-group channel at the root, the two group channels at the top can be changed, turned on, off, etc. while not using a chain. The problem Rene raises is the cost of moving on-chain when people don’t cooperate.
The whole idea of Lightning is based on the idea that if one of your channels stops cooperating or responding, you can simply send transactions to 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 need to be sent to the blockchain to enforce the current state, meaning that in a high-cost environment multi-party channels will be more expensive than two. party channels for on-chain use.
This is an important trade-off to consider when looking at these programs versus others, but I think focusing exclusively on the on-chain footprint ignores a very important point about off-chain programs: it’s all about stakeholder motivation not go to the chain.
Properly organizing a multi-group channel, i.e. the way you organize stacked channels, can allow you to group groups of people into categories with a reputation for high credibility, or mutual trust. This will allow people in these subgroups to continue to reorganize money within that subgroup even if people outside of it are temporarily unresponsive, or go offline due to technical issues. The on-chain enforcement costs, while significant, kind of affect the main design goal of the off-chain system: to give people a reason to stay off-chain and cooperate, and remove reasons for people not to cooperate and enforce. things onc-chain.
It is important not to lose sight of that core design aspect of these systems when considering what their future will look like.