Ich versuche, die Technologie hinter LN und ähnlichen Konzepten zu verstehen.
So wie ich es verstehe, ist LN ein Netzwerk bidirektionaler Kanäle, die mit einer begrenzten Kapazität erstellt werden, innerhalb derer der Kanal betrieben werden kann. Wir können also Alice 3 Münzen in den Kanal und Bob 20 Münzen in den Kanal stecken lassen und dieses Verhältnis von 3:20 kann sich dann mit jeder Off-Chain-Zahlung zeitlich ändern, bis es schließlich den Punkt erreicht, an dem Alice und Bob wollen Schließen Sie den Kanal bei einem endgültigen Gleichgewichtsverhältnis - sagen wir 13:10.
Dieses bidirektionale Konzept hat einige Merkmale (oder Nachteile), z. B. die Notwendigkeit, den Kanal auszugleichen (oder einen neuen zu erstellen), wenn Zahlungen in eine Richtung häufiger sind. Außerdem benötigt jeder dieser Kanäle, der zwei Parteien verbindet, zwei On-Chain-Transaktionen.
Fragen: Warum verwenden wir Kanäle nur zwischen 2 Parteien? Wäre es nicht möglich, einen Kanal zu haben, der zB von 4 Parteien gebildet wird, zB Alice mit 3 Münzen, Bob mit 4 Münzen, Cecil mit 5 Münzen und Daniel mit 6 Münzen? Es sollte Alice ermöglichen, z. B. 2 Münzen an Bob zu senden, wodurch der Status des Kanals von "A3:B4:C5:D6" auf "A1:B6:C5:D6" usw. geändert wird.
Wenn dies möglich wäre, könnten wir 2 On-Chain-Transaktionen haben, um 4 (oder mehr) Entitäten miteinander zu verbinden, also scheint es effektiver zu sein als ein bidirektionaler Ansatz. Es scheint mir auch, dass es etwas einfacher wäre, den Kanal im Gleichgewicht zu halten, als im Fall eines bidirektionalen Falls.
Offensichtlich wäre für jede Off-Chain-Transaktion innerhalb des Kanals mehr Kommunikation erforderlich (wahrscheinlich müssten alle Parteien beteiligt sein).
Gibt es also ein grundlegendes Problem mit mehr als 2 Entitäten in einem Kanal? Oder ist es nur so, dass die Vorteile, sie zu haben, die zusätzliche Komplexität nicht aufwiegen würden?
Es gibt keinen grundsätzlichen Grund, warum Sie keine nicht-bidirektionale Verbindung verwenden könnten. Das Onion-Routing-Protokoll von Lightning kennt den Kanal zwischen zwei Knoten nicht. Wenn zwei Blitzknoten direkt nebeneinander lägen, könnten Sie hypothetisch anstelle eines Blitzkanals Roboterarme ein paar Cent hin- und herleiten lassen.
Würde ein Lightning-Channel ohne Zwei-Parteien funktionieren, oder würde ein Channel-Teilnehmer einen anderen betrügen?
Normales Lightning funktioniert so: Bevor Alice und Bob einen Kanal erstellen, signiert Alice Bobs Rückerstattungstransaktion und Bob signiert Alices Rückerstattungstransaktion. Alices Rückerstattungstransaktion sagt:
Output 0: 1 BTC can be claimed by Alice, only after 48 hours, OR
can be claimed by Bob, if Bob knows P, where hash(P) = x
Output 1: 1 BTC can be claimed by Bob
Wenn Alice entscheidet, dass sie den Kanal verlassen möchte, veröffentlicht sie die obige Transaktion, wartet 48 Stunden und fordert ihr Geld. Jetzt, da wir eine Möglichkeit haben, den Kanal zu beenden, zahlen Alice und Bob gemeinsam in eine Transaktion ein, die von den Rückerstattungstransaktionen ausgegeben werden kann, oder in jede Transaktion, die Alice und Bob gemeinsam unterzeichnen.
Das ist großartig, aber wie bewegt man Geld? Zunächst erstellen Alice und Bob neue Rückerstattungstransaktionen, um den neuen Status des Kanals widerzuspiegeln. Dann teilt Alice Bob P mit, dass der Wert darüber zu x gehasht wird. Wenn Alice jetzt versuchen würde, diese Transaktion an das Bitcoin-Netzwerk zu senden, würde Bob antworten, indem er das gesamte Geld im Kanal nimmt.
Hier treffen wir auf unsere erste Straßensperre. Wenn es drei Parteien mit Geld im Kanal gibt und Alice betrügt, ist es Charlie gegenüber offensichtlich unfair, dass Bob das gesamte verbleibende Geld nimmt. Wie beheben wir das?
Wenn Alice ihre Rückerstattungstransaktion verwendet, fallen wir in eine Zwei-Parteien-Version des Lightning-Protokolls. Wir tun dies unabhängig davon, ob Alice mit einer alten Rückerstattungstransaktion betrügt oder nicht. Alices Rückerstattung sieht nun so aus:
Output 0: 0.33 BTC can be claimed by Alice, only after 48 hours, OR
can be claimed by Bob and Charlie, if they know P, where hash(P) = x
Output 1: 0.67 BTC can be claimed by Bob and Charlie
Wir sind aber noch nicht fertig. Wenn Alice ihre Rückerstattungstransaktion verwendet, ist Charlie möglicherweise offline. (Tatsächlich könnte das der Grund sein, warum Alice den Blitzkanal verlässt.) Daher müssen Bob und Charlie jeweils eine Unterrückerstattungstransaktion erstellen, bevor sie den Kanal finanzieren. Bob unterzeichnet Charlies Transaktion und umgekehrt. Bobs Transaktion sieht so aus:
Output 0: 0.33 BTC can be claimed by Bob, only after 48 hours, OR
can be claimed by Charlie, if they know P, where hash(P) = x
Output 1: 0.34 BTC can be claimed by Charlie
Das Ergebnis ist, dass Sie bei n teilnehmenden Personen n Rückerstattungstransaktionen und n-1 Sub-Rückzahlungstransaktionen und n-2 Sub-Sub-Rückzahlungstransaktionen benötigen. Dies wächst faktoriell. Wenn Sie also 10 Teilnehmer haben, müssen Sie meiner Schätzung nach etwa 3,6 Millionen Transaktionen für jede Kanalaktualisierung signieren und widerrufen. Dies deckt jede mögliche Reihenfolge von Knoten ab, die den Kanal verlassen.
Wenn Sie bereit sind, etwas Sicherheit einzubüßen, könnten Sie 5 Lightning-Knoten ein 3-von-5-Multisignatur-Konto erstellen lassen und Abhebungen von diesem Konto nur zulassen, wenn 3 Knoten zustimmen, dass die Abhebung von einem Knoten mit genügend Guthaben durchgeführt wurde. Wenn Sie daran interessiert sind, schlage ich vor, sich Federated Peg anzusehen.
Murch