SHINOBI: OFF-CHAIN ​​PROTOCOLS WILL ALWAYS BE A BALANCING ACT

Rene Pickhardt recently released a discussion on 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 in the Lightning Network. He expresses growing skepticism about the viability of this direction of development.

The high-level idea of ​​why channel factories improve payment reliability comes down to liquidity allocation. In a network of only two party channels, users must make zero-sum choices about where to allocate their liquidity. This has a systemic effect on the overall success rate of payments in the network, if people put their liquidity somewhere there is no need to process payments instead of where it is, payments will fail as liquidity in the places people need it is depleted (until it is rebalanced). This dynamic is simply one of the design constraints of the Lightning network known from the start, and why research like Rene’s is incredibly important to the long-term viability of the protocol/network.

In a multi-party channel model, users can allocate liquidity in large pools and simply “sub-allocate” it off-chain, wherever it makes sense at the time. This means that even if a node operator made a bad decision about who to allocate liquidity to, as long as that person is in the same multiparty channel with people who would be a good peer, they can reallocate that misplaced liquidity from one. to the other off-chain without incurring on-chain costs.

This works because the multi-party channel concept is essentially just everyone in the group stacking conventional two-party channels on top of a multi-party one. By updating the multiparty channel at the root, the top two party channels can be changed, opened, closed, etc., while remaining off-chain. The issue Rene raises is the cost of entering the 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 simply send transactions up the chain to enforce 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 apply in the chain.

These are basic trade-offs to consider when comparing these systems against each other, but I think focusing exclusively on the on-chain footprint ignores the bigger point about off-chain systems: they’re all about incentivizing participants to not go in the chain.

Properly structuring a multi-party channel, that is, how you organize the channels stacked on top of each other, can allow you to package groups of people into subsections that have a reputation for high reliability or trust each other. This would allow people in these subgroups to continue to reorganize liquidity within that subgroup, even if people outside of it become temporarily unresponsive or disconnect due to technical issues. The on-chain cost of enforcing things, while important, is somewhat tangential to the central design goal of an off-chain system: giving people a reason to stay off-chain and cooperate, and removing the reasons why people don’t cooperate and force . chain things.

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