Lightning Netzwerk

Was ist das Lightning Netzwerk?

Das Lightning Network ist ein Second-Layer-Protokoll für Bitcoin. Es erweitert das Bitcoin-Netzwerk um eine zusätzliche Zahlungsebene, auf der Transaktionen nahezu in Echtzeit und mit sehr geringen Gebühren durchgeführt werden können.

Anstatt jede einzelne Zahlung direkt in der Blockchain zu speichern, werden viele Zahlungen zunächst außerhalb der Blockchain innerhalb von Zahlungskanälen abgewickelt. Erst das endgültige Ergebnis wird später wieder auf der Bitcoin-Blockchain festgehalten.

Dadurch können zwei Teilnehmer beliebig viele Zahlungen austauschen, obwohl dafür in der Regel nur zwei On-Chain-Transaktionen erforderlich sind: eine zum Öffnen und eine zum Schließen des Kanals.

Ein einzelner Zahlungskanal verbindet jedoch nur zwei Teilnehmer. Das eigentliche Lightning Network entsteht dadurch, dass tausende dieser Kanäle miteinander verbunden sind. Zahlungen können dadurch über mehrere Lightning-Nodes zu ihrem Ziel weitergeleitet werden, auch wenn Sender und Empfänger keinen direkten Kanal besitzen.

Das Lightning Network verändert weder die Konsensregeln von Bitcoin noch die maximale Geldmenge. Es nutzt ausschließlich Bitcoin-Transaktionen und erweitert das Netzwerk um eine zweite Ebene für schnelle und kostengünstige Zahlungen.

Warum braucht Bitcoin Lightning?

Bitcoin ist darauf ausgelegt, Transaktionen dezentral, nachvollziehbar und möglichst endgültig abzurechnen. Diese Sicherheit entsteht jedoch dadurch, dass jede On-Chain-Transaktion von den Nodes überprüft und dauerhaft in der Blockchain gespeichert wird.

Der verfügbare Blockplatz ist begrenzt. Werden viele Transaktionen gleichzeitig gesendet, konkurrieren sie um die Aufnahme in einen Block. Dadurch können die Transaktionsgebühren steigen und Zahlungen müssen möglicherweise auf eine Bestätigung warten.

Für größere oder seltene Zahlungen ist diese Abwicklung sinnvoll. Für alltägliche Kleinstzahlungen wäre es jedoch ineffizient, jede einzelne Zahlung dauerhaft in der Blockchain zu speichern.

Lightning verlagert deshalb häufige Zahlungen in Zahlungskanäle. Innerhalb eines Zahlungskanals können die Teilnehmer ihre Guthaben mehrfach aktualisieren, ohne jede Änderung als neue On-Chain-Transaktion zu veröffentlichen.

Durch die Verbindung vieler Zahlungskanäle können Zahlungen außerdem über mehrere Lightning-Nodes weitergeleitet werden. Sender und Empfänger benötigen daher keinen direkten gemeinsamen Kanal.

Lightning ersetzt Bitcoin nicht. Es reduziert lediglich die Anzahl der Zahlungen, die unmittelbar on-chain gespeichert werden müssen. Die Blockchain bleibt die Abrechnungs- und Sicherheitsschicht, während Lightning für schnelle und kostengünstige Zahlungen genutzt werden kann.

Zahlungskanäle

Das Lightning Network basiert auf Zahlungskanälen. Ein Zahlungskanal verbindet zwei Teilnehmer und ermöglicht es ihnen, Bitcoin-Guthaben beliebig oft untereinander zu verschieben, ohne jede einzelne Zahlung in der Blockchain zu speichern.

Zu Beginn eröffnen beide Teilnehmer gemeinsam einen Zahlungskanal. Dazu wird eine Bitcoin-Transaktion in der Blockchain veröffentlicht, welche die Bitcoin des Kanals sperrt und seine maximale Kapazität festlegt.

Innerhalb des geöffneten Zahlungskanals können die Teilnehmer ihre Guthaben anschließend beliebig oft aktualisieren. Dabei verändert sich lediglich die Verteilung der Bitcoin innerhalb des Kanals. Die Gesamtkapazität bleibt stets unverändert.

Erst wenn der Zahlungskanal geschlossen wird, wird der zuletzt vereinbarte Guthabenstand als Bitcoin-Transaktion in der Blockchain abgerechnet.

Die einzelnen Aktualisierungen eines Zahlungskanals werden nicht an die Bitcoin-Blockchain übertragen. Stattdessen speichern beide Teilnehmer stets den aktuellen Kanalzustand. Dadurch können beliebig viele Zahlungen stattfinden, obwohl nur das Öffnen und Schließen des Zahlungskanals on-chain veröffentlicht wird.

Wie ein Zahlungskanal technisch aufgebaut ist und wie die Kanalzustände gegenseitig abgesichert werden, wird auf der Seite Zahlungskanäle ausführlich erklärt.

HTLCs

Damit eine Zahlung über mehrere Lightning-Nodes weitergeleitet werden kann, müssen alle beteiligten Kanalaktualisierungen miteinander verknüpft sein. Entweder wird die gesamte Zahlung erfolgreich ausgeführt oder sie wird vollständig zurückgesetzt.

Dafür verwendet das Lightning Network sogenannte HTLCs. Die Abkürzung steht für Hashed Timelock Contract (deutsch: hashbasiertes Zeitvertragssystem oder wörtlich hashbasierter Zeitvertrag).

Ein HTLC verknüpft ein kryptographisches Geheimnis mit einer zeitlichen Frist. Legt der Empfänger das passende Geheimnis rechtzeitig offen, kann er die Zahlung einlösen. Andernfalls kann der Sender die gebundenen Satoshi nach Ablauf der Frist zurückfordern.

Der Empfänger erzeugt zunächst ein Geheimnis und übermittelt dem Sender nur dessen Hash. Anschließend wird entlang der Zahlungsroute in jedem beteiligten Zahlungskanal ein bedingtes Zahlungsversprechen eingerichtet.

Kennt der Empfänger das passende Geheimnis, kann er das letzte HTLC einlösen. Dabei wird das Geheimnis sichtbar und schrittweise rückwärts über die Route weitergegeben. Jeder weiterleitende Node kann damit wiederum das vorherige HTLC einlösen.

Kann die Zahlung nicht abgeschlossen werden, laufen die jeweiligen Zeitbedingungen ab. Die vorübergehend gebundenen Satoshi werden dann wieder freigegeben.

Die Funktionsweise von Hashlocks, Timelocks und den unterschiedlichen Ablaufzeiten entlang einer Zahlungsroute wird auf der Seite HTLCs ausführlich erklärt.

Routing

Ein Zahlungskanal verbindet immer nur zwei Teilnehmer. In der Praxis besitzen jedoch die wenigsten Nutzer einen direkten Zahlungskanal zu jedem Empfänger. Stattdessen werden Zahlungen über mehrere miteinander verbundene Lightning-Nodes weitergeleitet. Dieser Vorgang wird als Routing bezeichnet.

Jeder weiterleitende Node empfängt die Zahlung über einen Zahlungskanal und leitet sie über einen anderen Zahlungskanal an den nächsten Node weiter. Für diese Dienstleistung kann er eine kleine Routing-Gebühr verlangen.

Damit eine Zahlung erfolgreich zugestellt werden kann, sucht der Sender eine geeignete Route durch das Lightning Network. Dabei berücksichtigt die Wallet unter anderem die verfügbaren Zahlungskanäle, deren Kapazität und die anfallenden Routing-Gebühren.

Wie geeignete Zahlungsrouten gefunden werden, welche Informationen Nodes über das Netzwerk austauschen und wie Onion Routing die Privatsphäre schützt, wird auf der Seite Routing ausführlich erklärt.

Abrechnung des Kanals

Solange ein Zahlungskanal geöffnet ist, werden alle Zahlungen ausschließlich zwischen den beiden Teilnehmern ausgetauscht. Bitcoin kennt lediglich die Eröffnung des Kanals und erhält keine Informationen über die einzelnen Aktualisierungen des Kanalzustands.

Erst beim Schließen des Zahlungskanals wird der zuletzt gemeinsam bestätigte Kanalzustand in einer Bitcoin-Transaktion veröffentlicht. Diese verteilt die ursprünglich im Kanal gebundenen Bitcoin entsprechend der aktuellen Guthabenverteilung an die beiden Teilnehmer.

Dadurch können beliebig viele Lightning-Zahlungen stattfinden, obwohl nur zwei Bitcoin-Transaktionen dauerhaft in der Blockchain erscheinen: eine zum Öffnen und eine zum Schließen des Zahlungskanals.

Wie ein Zahlungskanal kooperativ oder einseitig geschlossen wird und wie der aktuelle Kanalzustand kryptographisch abgesichert ist, wird auf der Seite Zahlungskanäle ausführlich erklärt.

Weiterführende Ressourcen

Das Lightning Network wird nicht von einer einzelnen Organisation entwickelt. Stattdessen existiert eine gemeinsame Protokollspezifikation sowie mehrere unabhängige Implementierungen, die diese Spezifikation umsetzen.

Protokollspezifikation

• Lightning BOLTs (Basis of Lightning Technology)
• Beschreibung: Offizielle Spezifikation des Lightning-Protokolls.

Referenzimplementierungen

• LND (Lightning Labs)

• Beschreibung: Die weltweit am weitesten verbreitete Lightning-Implementierung in Go.

• Core Lightning (Blockstream)

• Beschreibung: Modulare Lightning-Implementierung von Blockstream, ursprünglich als c-lightning bekannt.

• Eclair (ACINQ)

• Beschreibung: Lightning-Implementierung in Scala mit Fokus auf mobile Anwendungen und Infrastruktur.