Mehrparteien-Zahlungskanäle: Untersuchung der Kompromisse zwischen Zuverlässigkeit und On-Chain-Kosten

Rene Pickhardt hat kürzlich einen Thread eröffnet, in dem es um die Unterschiede zwischen Zweiparteien- und Mehrparteien-Zahlungskanälen (mehr als zwei Teilnehmer) geht

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.

Rene Pickhardt hat kürzlich einen Thread eröffnet, in dem er die Unterschiede zwischen Zweiparteien- und Mehrparteien-Zahlungskanälen (mehr als zwei Teilnehmer) im Zusammenhang mit seiner Forschungsarbeit zur Zahlungszuverlässigkeit im Lightning Network erörtert. Er äußert eine wachsende Skepsis hinsichtlich der Realisierbarkeit dieser Entwicklungsrichtung.

The high level idea of why channel factories improve the payment reliability 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.

Die übergeordnete Idee, warum Channel-Fabriken die Zahlungszuverlässigkeit verbessern, beruht auf der Liquiditätsallokation. In einem Netzwerk aus nur zwei Parteienkanälen müssen Benutzer Nullsummenentscheidungen darüber treffen, wo sie ihre Liquidität verteilen. Dies wirkt sich systemisch auf die Gesamterfolgsrate von Zahlungen im gesamten Netzwerk aus. Wenn Menschen ihre Liquidität an einem Ort anlegen, an dem sie für die Zahlungsabwicklung nicht benötigt wird, und nicht dort, wo sie ist, scheitern Zahlungen, da die Liquidität an den von den Menschen benötigten Orten aufgebraucht ist ( bis es wieder ausgeglichen ist). Diese Dynamik ist einfach eine der Designbeschränkungen des Lightning Network, die von Anfang an bekannt sind, und warum Forschung wie die von Rene unglaublich wichtig ist, damit das Protokoll/Netzwerk langfristig funktioniert.

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.

In einem Modell von Mehrparteienkanälen können Benutzer Liquidität großen Gruppen zuteilen und sie einfach außerhalb der Kette „unterzuteilen“, wo immer es gerade sinnvoll ist. Das bedeutet, dass selbst wenn ein Knotenbetreiber eine schlechte Entscheidung darüber getroffen hat, welcher Person Liquidität zugewiesen werden soll, er die schlecht platzierte Liquidität von einer Person umverteilen kann, solange diese Person im selben Mehrparteienkanal mit Personen ist, die ein guter Peer wären zur anderen Off-Chain, ohne dass On-Chain-Kosten anfallen.

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.

Dies funktioniert, weil das Konzept eines Mehrparteienkanals im Wesentlichen darin besteht, dass jeder in der Gruppe herkömmliche Zweiparteienkanäle über den Mehrparteienkanal stapelt. Durch die Aktualisierung des Multiparty-Kanals im Stammverzeichnis können die beiden Party-Kanäle oben geändert, geöffnet, geschlossen usw. werden, während sie außerhalb der Kette bleiben. Das Problem, das Rene anspricht, sind die Kosten, die entstehen, wenn die Leute nicht kooperieren.

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.

Die gesamte Logik von Lightning basiert auf der Idee, dass Sie, wenn Ihr einzelner Kanal-Kontrahent nicht mehr kooperiert oder reagiert, einfach Transaktionen in der Kette einreichen können, um die Kontrolle über Ihre Gelder durchzusetzen. Wenn Sie einen Mehrparteienkanal haben, fügt jede „Ebene“ im Kanalstapel mehr Transaktionen hinzu, die an die Blockchain übermittelt werden müssen, um den aktuellen Status durchzusetzen, was bedeutet, dass Mehrparteienkanäle in einer Umgebung mit hohen Gebühren teurer sind als zwei Partykanäle zur Durchsetzung in der Kette.

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.

Dies sind die wichtigsten Kompromisse, die berücksichtigt werden müssen, wenn man diese Systeme miteinander vergleicht, aber ich denke, wenn man sich ausschließlich auf den On-Chain-Fußabdruck konzentriert, wird der wichtigere Punkt in Bezug auf Off-Chain-Systeme außer Acht gelassen: Es geht ihnen einzig und allein darum, den Teilnehmern einen Anreiz zu geben, nicht weiterzumachen -Kette.

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.

Durch die richtige Strukturierung eines Mehrparteienkanals, also durch die Art und Weise, wie Sie die übereinander gestapelten Kanäle organisieren, können Sie Gruppen von Personen in Unterabschnitte unterteilen, die für ihre hohe Zuverlässigkeit bekannt sind oder sich gegenseitig vertrauen. Dies würde es den Personen in diesen Untergruppen ermöglichen, die Liquidität innerhalb dieser Untergruppe auch dann noch neu zu organisieren, wenn Personen außerhalb dieser Untergruppe vorübergehend nicht reagieren oder aufgrund technischer Probleme offline gehen. Die On-Chain-Kosten für die Durchsetzung von Dingen sind zwar wichtig, stehen aber in gewisser Weise im Zusammenhang mit dem zentralen Designziel eines Off-Chain-Systems: Menschen einen Grund zu geben, außerhalb der Kette zu bleiben und zu kooperieren, und Gründe für Menschen zu beseitigen, nicht zu kooperieren und zu zwingen Dinge in der Kette.

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

Es ist wichtig, diesen zentralen Designaspekt dieser Systeme nicht aus den Augen zu verlieren, wenn man darüber nachdenkt, wie ihre Zukunft aussehen wird.