Was sind HTLC im Lightning Netzwerk und wozu werden sie benötigt

Wer eine eigene Lightning Node betreibt, und Ride the Lightning als GUI Management verwendet, der ist sicher schonmal auf den Begriff HTLC gestossen, in diesem Beitrag schauen wir uns an wofür sie im Netzwerk sind und wozu sie benötigt werden. HTLC steht für "Hashed Time-Locked Contracts" und ist ein wesentlicher Bestandteil des Lightning-Netzwerks, einem Layer-2-Protokoll über der Bitcoin-Blockchain.

Wofür sind HTLCs?

• Sicherer und schneller Transfer von Zahlungen: HTLCs ermöglichen es, Zahlungen über mehrere Kanäle im Lightning-Netzwerk zu senden, ohne dass die Blockchain für jede einzelne Transaktion aktualisiert werden muss. Das macht Transaktionen schneller und effizienter.
• Vertrauensfreie Transaktionen: Sie erlauben Transaktionen zwischen Parteien, die sich gegenseitig nicht vertrauen müssen. Die Sicherheit wird durch den Mechanismus des HTLCs gewährleistet, nicht durch das Vertrauen in die Gegenpartei.

Wofür werden sie benötigt?

1. Routing von Zahlungen: Im Lightning-Netzwerk werden Zahlungen oft über mehrere Knoten (Nodes) geleitet. HTLCs helfen dabei, dass diese Zahlungen sicher und verlässlich von einem Ende zum anderen gelangen.
2. Verhinderung von Betrug: Durch die Zeitbindung in HTLCs (der "Time-Lock") wird sichergestellt, dass eine Zahlung entweder vollständig durchgeführt oder nach Ablauf der Frist automatisch rückgängig gemacht wird. Das verhindert, dass jemand das Geld nimmt und sich weigert, die Transaktion abzuschließen.

Praktisches Beispiel

Um zu verstehen, wie ein HTLC beim Routing im Lightning-Netzwerk entsteht schauen wir uns ein Beispiel an. Stellt Euch vor, Alice möchte Bob über das Lightning-Netzwerk eine Zahlung senden, aber sie haben keinen direkten Zahlungskanal zueinander. Stattdessen nutzen sie Carol als Zwischenknoten. Hier ist, wie das funktioniert. Wichtig dabei ist, das nur Bob die Zahlung auslösen kann, und kein Knoten dazwischen.

Ausgangssituation

• Alice möchte 1 Bitcoin (BTC) an Bob senden.
• Alice hat einen Zahlungskanal mit Carol, und Carol hat einen mit Bob.

Erstellung des Zahlungsgeheimnisses

• Bob generiert ein Geheimnis und daraus einen Hashwert.
• Bob sendet den Hashwert an Alice, ohne das Geheimnis preiszugeben.

HTLC von Alice zu Carol

• Alice richtet ein HTLC auf ihrem Kanal mit Carol ein.
• Sie sagt: "Carol, ich sende dir 1 BTC, aber du bekommst ihn nur, wenn du mir das Geheimnis zu diesem Hashwert innerhalb eines bestimmten Zeitraums liefern kannst."
• Dieses HTLC ist nun auf der Blockchain gesperrt, aber noch nicht an Carol ausgezahlt.

HTLC von Carol zu Bob

• Carol wiederholt den Prozess mit Bob.
• Sie richtet ein HTLC ein und sagt: "Bob, ich sende dir 1 BTC, aber nur, wenn du mir das Geheimnis zu diesem Hashwert innerhalb eines kürzeren Zeitraums als Alice mir gibt, liefern kannst."

Bob löst das HTLC aus

• Bob kennt das Geheimnis und gibt es an Carol weiter, um den 1 BTC von ihrem HTLC zu erhalten.
• Indem er das Geheimnis offenbart, erlaubt er Carol, das gleiche zu tun, um den 1 BTC von Alice zu erhalten.

Abschluss des Prozesses

• Carol verwendet nun das Geheimnis, um das HTLC mit Alice zu lösen und ihren 1 BTC zu erhalten.
• Alle HTLCs werden abgerechnet, und die Zahlung von Alice an Bob über Carol ist abgeschlossen.

Wichtig zu merken

• Zeitliche Begrenzung: Die HTLCs haben eine Zeitbegrenzung. Wenn das Geheimnis nicht rechtzeitig geliefert wird, wird die Transaktion automatisch abgebrochen, und das Geld kehrt zu seinem ursprünglichen Besitzer zurück.
• Sicherheit: Durch die Verwendung von HTLCs muss Carol das Geheimnis von Bob erfahren, um ihr Geld zu erhalten. Das bedeutet, dass sie die Zahlung nicht einbehalten kann, ohne Bob zu bezahlen.
• Netzwerkeffizienz: Dieser Prozess ermöglicht es dem Lightning-Netzwerk, effizient Zahlungen über mehrere Kanäle zu leiten, ohne dass jeder Knoten ein direktes Vertrauensverhältnis haben muss.

In diesem Beispiel erleichtern die HTLCs eine sichere und effiziente Übertragung von Werten über indirekte Wege, ohne dass alle Beteiligten sich gegenseitig vertrauen müssen. Sie sind der Schlüssel für das Routing und die Skalierbarkeit des Lightning-Netzwerks.

Warum Time-locked Contracts?

Rückerstattung – Verhinderung von Fehlern

Beim Routing einer Zahlung können Probleme auftreten: Einer der Peers auf dem Weg kann offline gehen und unerreichbar werden, während die HTLCs weitergeleitet werden. Auch kann nicht ausgeschlossen werden, dass ein Knoten auf dem Weg böswillig handelt. Was wenn Carol sich weigert, das Geheimnis an den vorherigen Peer weiterzugeben und das HTLC so lange zurückhält, bis das Opfer Lösegeld zahlt?

Es muss eine Möglichkeit geben, zu garantieren, dass das Geld nicht für immer eingefroren wird, falls etwas schiefgeht. Wir müssen eine Rückerstattungsklausel in den Vertrag aufnehmen:

"Wenn Carol, also der Zwischenknoten das Geheimnis nicht innerhalb von 24 Stunden preisgibt, kann Alice die Mittel zurückfordern."

Diese zeitlich begrenzte Rückerstattungsklausel hilft auch, die Vollständigkeit zu erreichen. Man muss sich keine Sorgen über einen teilweisen Zahlungszustand machen. Im Falle eines Fehlers kann jeder Teilnehmer entweder mit seinem Kanalpartner zusammenarbeiten, um das HTLC rückgängig zu machen, oder er kann individuell die zeitlich begrenzte Rückerstattungstransaktion auf die Blockchain setzen, um seine Mittel zurückzuerhalten.

Bestimmte Funktionen erlauben eine bestimmte Blockhöhe oder einen Zeitstempel in der Zukunft anzugeben, wann die Transaktion der Blockchain hinzugefügt werden kann und gültig wird. Bis dahin bleibt die Transaktion unbestätigt und kann nicht zur Blockchain hinzugefügt werden. Im Kontext von HTLCs wird dieser Opcode mit Blockhöhen verwendet. Daher muss der Sender, um die Rückerstattungsklausel nutzen zu können, warten, bis der Block im Sperrskript erreicht ist, und eine gültige Signatur zu seinem oder ihrem öffentlichen Schlüssel vorlegen.

Welche weiteren Möglichkeiten gibt es Betrug auszuschliessen

Ein wichtiges Detail in Lightning-Netzwerkkanälen ist die Möglichkeit, Betrug zu verhindern. Wenn man einen Kanal mit einem Peer öffnet, ist es üblich, über die Lebensdauer des Kanals mehrere Transaktionen durchzuführen und den Kanalsaldo kontinuierlich zu aktualisieren, anstatt nach der ersten Zahlung das HTLC in die Blockchain zu schreiben.

Aber was, wenn ein Peer eine Transaktion mit einem alten Kanalzustand, der ihm zugutekommt, in die Blockchain schreibt, anstatt den neuesten Zustand zu verwenden? Es muss einen Weg geben, dieses Verhalten zu verhindern.

Man könnte eine weitere Klausel in den Vertrag aufnehmen:

"Wenn Bob versucht, von mir zu stehlen, habe ich 24 Stunden Zeit zu beweisen, dass er betrügt. Wenn ich das beweisen kann, darf ich das gesamte Geld, das wir unserem Kanal zugesichert haben, alleine behalten."

Wie beweisen wir, dass unser Peer betrogen hat?

Wenn jemand den Kanalzustand mit einem falschen State aktualisieren möchte, gibt er dem anderen Peer eine aktualisierte Commitment-Transaktion mit dem neuen Kanalsaldo. Der andere Peer antwortet mit einem "revocation-key", der als Beweis verwendet werden kann, dass der Kanalzustand nicht korrekt ist ist. Diese gegenseitige Überprüfung geschieht bei jeder Lightning-Transaktion, sodass bei 1000 Transaktionen 1000 Widerrufsschlüssel gespeichert werden müssen, bis der Lightning-Kanal geschlossen wird.

Es gibt mehrere Aktionen die ausgeführt werden können. Die erste ist die Straftransaktion: Sie ermöglicht es jedem, der den <Widerrufsöffentlicherschlüssel> signieren kann, und wird von der betrogenen Partei verwendet eine Aktion einzuleiten. Wenn Alice betrogen wird, kann sie den Widerrufsschlüssel, den Bob ihr gegeben hat, als sie ihren Kanalzustand aktualisiert haben, verwenden, um das gesamte Geld aus dem Kanal für sich zu beanspruchen. Der Zustand wird sofort in die Blockchain geschrieben und der Kanal mit dem Zustand von Alice auf die Blockchain geschrieben.

Die zweite Aktion verhindert es der Partei, die den HTLC hält und daher eine gültige Signatur für den <Local Delayed Public Key> hat, die Bitcoin auszugeben (Also damit ist Bob der Betrüger gemeint). Damit das nicht passiert gibt es eine Schutzfunktion: Der Ausgebende muss warten, bis die festgelegte Verzögerung abgelaufen ist. Die Verzögerung wird vor der Eröffnung des Kanals vereinbart und ist normalerweise umso größer, je mehr Geld dem Kanal zugesichert wird. So geben wir Alice Zeit zu beweisen, dass sie beraubt wird. Damit wird verhindert, sollte Alice kurz offline sein, oder Netzwerkprobleme haben, um Ihren echten Kanalzustand offen zu legen, ansonsten könnte das Bob schnell tun und den falschen Kanalzustand settlen und den Kanal closen.

Da die Bitcoin-Blockchain Nutzer vor Doppelausgaben schützt und die betrügerische Partei warten muss, um die Transaktion in der Blockchain zu bestätigen, kann die betrogene Partei die Straftransaktion veröffentlichen, sobald sie die Transaktion mit dem falschen Kanalsaldo im Mempool sieht, und sie schneller bestätigen lassen, als der Betrüger seine Transaktion bestätigen kann, da dieser ja eine Verzerzögerung gebunden ist

HTLCs sind also ein cleveres Instrument im Lightning-Netzwerk, das schnelle, kostengünstige und sichere Transaktionen ermöglicht, aber es erfordert auch einiges an Management und Verständnis, um sie effektiv zu nutzen. Ihr werdet aber als normer Node Betreiber, der ab und zu ein paar Zahlungen tätigten, eher weniger aktiv mit HTLCs zu tun haben, das übernimmt Eure Node automatisch im Hintergrund.