iX Special 2019
S. 132
Wirtschaft und Gesellschaft
Blockchain

Lightning-Network: Blitzschnelle Bitcoins für den Alltag

Leichtes Netz

Oliver Gugger, Daniel Kobras

Das Lightning-Network erweitert die herkömmliche Bitcoin-Infrastruktur um neue Transaktionskanäle, die besonders schnell und leichtgewichtig sind. Die Autoren haben das in einem konkreten Projekt ausprobiert.

Mal futuristisch, mal zwielichtig: Wann immer Einsatzszenarien für Kryptowährungen zur Sprache kommen, sind sie eines ganz bestimmt nicht: alltäglich. Das mag einerseits daran liegen, dass Pommesbude oder Billig-­Discounter der rechte Glanz fehlt für strahlende Zukunftsvisionen, hat andererseits aber ganz konkrete technische Gründe.

Die Blockchain à la Bitcoin stößt bei steigender Nutzung prinzipbedingt rasch an ihre Kapazitätsgrenze – sie skaliert schlecht und ist daher ungeeignet für Anwendungsfälle, die Klein- und Kleinsttransaktionen in hoher Zahl verarbeiten müssen. Mehr Kapazität für zusätzliche Transaktionen ließe sich nur zulasten von Speicherbedarf und Netzbandbreite jedes einzelnen Bitcoin-Knotens schaffen. Ganz abgesehen von der Frage, ob tatsächlich der Erwerb jeder Currywurst nachvollziehbar und revisionssicher in einer universellen Blockchain-Infrastruktur beglaubigt werden muss. Genau hier setzen Lösungen an, die das Skalierungsproblem beheben: Statt die Transaktionsgeschwindigkeit der Blockchain zu erhöhen, soll sie von unnötigen Transaktionen entlastet werden.

Dieser Grundidee folgt das erstmals 2015 vorgeschlagene Lightning-Network. Die Bitcoin-­Blockchain dient hier nur noch als Unterbau für Vertrauens­stellungen und Zahlungsmittel, während das Gros der Zahlungen selbst in eigenen Kanälen stattfindet. Die arbeiten ressourcenschonend und nahezu ohne Zeitverzögerung, sodass Lightning eine ernst zu nehmende, unabhängige Alternative zu den mobilen Bezahlsystemen kommerzieller Anbieter darstellt.

Gleichzeitig erbt Lightning aber auch die bedeutendsten Eigenschaften des 2008 als Reaktion auf die Finanzkrise und die Furcht vor politisch getriebener Geldentwertung ins Leben gerufenen Bitcoin – zuvorderst Unabhängigkeit von Zentralbanken und staatlicher Regulierung. Dazu kommen der Schutz der Privat­sphäre durch Pseudonyme, offener, dezentraler Aufbau und die einfache Integration in Onlinezahlungsprozesse, aber auch ­einige der Schattenseiten: etwa die historisch hohe Schwankungsbreite des Wechselkurses im Vergleich zu herkömmlichen Währungen und der hohe Ressourcenverbrauch für den Proof-of-­Work-Algorithmus, mit dem Bitcoin sich die Unabhängigkeit von zentralen Strukturen erkauft.

Zahlen in eine Richtung

Die grundlegende Debatte darüber, ob die Unabhängigkeit von staatlichen Institutionen den Ressourcenbedarf rechtfertigt oder nicht, wird auch Lightning nicht lösen können. Aber es zeigt einen Weg auf, das schwere Gerät Bitcoin-Blockchain gezielt nur an den Stellen einzusetzen, wo seine Eigenschaften tatsächlich Vorteile bringen (on-chain), überall sonst jedoch leichtgewichtigeres Werkzeug zu verwenden (off-chain).

Um Lightning verstehen zu können, muss man zuerst Zahlungskanäle verstehen. Das Konzept der Zahlungskanäle wurde schon sehr früh in der Geschichte von Bitcoin vorgeschlagen. In ihrer einfachsten Variante funktionieren diese so: Sollen mehrere Zahlungen in die gleiche Richtung fließen, öffnet ein Käufer einen Zahlungskanal zu einem Verkäufer und befüllt den Kanal mit einem Teil seines verfügbaren Bitcoin-Vermögens. Dabei fließt noch kein Geld, der Vorgang wird aber als Smart Contract in der Bitcoin-Blockchain hinterlegt, die so die Vertrauensstellung zwischen beiden Parteien herstellt und die Zahlungsfähigkeit des Käufers verbürgt.

Mit dieser sogenannten Funding-Transaktion ist der On-Chain-Teil zunächst beendet. Der eigentliche Kaufvorgang findet off-chain statt. Der Käufer sendet dem Verkäufer über einen privaten Kommunikationskanal dazu eine signierte Transaktion über den geforderten Betrag. Der Verkäufer kann die Zahlung unmittelbar selbst validieren und hat nun die Wahl, ob er die Transaktion sofort einlöst oder den Kanal offen hält, um weitere Zahlungen entgegenzunehmen.

Im zweiten Fall sendet der Käufer über den Kanal eine weitere Transaktion, die den neuen Gesamtbetrag enthält. Eine „Vergiftung“, wie sie beim später vorgestellten bidirektionalen Zahlungskanal eingesetzt wird, ist hier nicht nötig. Denn der Verkäufer hat automatisch den Anreiz, nur die aktuellste Transaktion einzulösen, denn die enthält für ihn den höheren Betrag.

Auf diese Weise macht der unidirek­tionale Zahlungskanal die zuvor übermittelten Transaktionen zwar nicht formal, aber praktisch ungültig. Wartezeiten und Gebühren fallen erst beim Einlösen und Schließen des Zahlungskanals an. Das findet wieder on-chain statt. Öffentlich sichtbar wird dadurch nur die Summe aller ­Zahlungen, nicht jede einzelne Transaktion selbst. So kann man beispielsweise aus allen Käufen eines Monats jeweils die Zahlungen summieren, und nur diese Summe wird on-chain sichtbar.

Bidirektionales Zahlen

Zahlungspartner A und B zahlen in den Zahlungskanal ein (Abb. 1).
Gugger/Kobras

Ein genauerer Blick auf die einzelnen Datenpakete macht klar, wie Lightning auch dann noch funktioniert, wenn innerhalb eines Zahlungskanals Geld in beide Richtungen fließen soll. Die Funding-Transaktion für einen Kanal erstellt eine neue Bitcoin-Adresse (Multisig Account), die von beiden Zahlungs­partnern signiert ist und den Gesamtbetrag ihrer eingesetzten Bitcoins enthält (siehe Abbildung 1). Den zur Signatur gehörenden privaten Schlüssel behält jeder Zahlungspartner für sich. In diesem Zustand können beide Partner somit nur einvernehmlich über das Vermögen im Lightning-Kanal verfügen. Zusätzlich erstellen beide deshalb noch je eine Transaktion, die dem jeweiligen Partner die eingesetzte Summe aus dem Kanal wieder zurücküberweist (siehe Abbildung 2 und 3). Dazu muss jeder Zahlungspartner nur den eigenen privaten Schlüssel vorweisen.

Die gegensignierte Absicherungstransaktion, wie sie Teilnehmer A hält. Wird ein neuer Zustand ausgehandelt, übergibt Teilnehmer A seinen Schlüssel A1 an B, was ihn für den gesamten Betrag ermächtigt, sollte diese alte Transaktion jemals veröffentlicht werden (Abb. 2).
Gugger/Kobras

Für den Restbetrag des Gegenübers stecken in der Transak­tion jeweils zwei vorbereitete Alternativen: Der rechtmäßige Eigentümer erhält den Betrag entweder nach einer gewissen Warte­zeit von beispielsweise 1000 Bitcoin-Blöcken (10000 Minuten) zurück, oder der Zahlungspartner erhält sie mit dem privaten Schlüssel des ursprünglichen Eigentümers – den er zu diesem Zeitpunkt noch nicht kennt. Beide Parteien tauschen die entsprechend vorbereiteten Transaktionen aus und speichern sie bei sich ab. Der hier als Beispiel genannte Wert von 1000 Blöcken wird in der Praxis an die Größe des Betrags im Zahlungskanal angepasst. Je größer der Betrag, desto länger die Wartezeit.

Das symmetrische Gegenstück zur Transaktion aus Abbildung 2. Teilnehmer B hält diese Transaktion bei sich. Gibt es einen neuen Zustand, händigt Teilnehmer B seinen Schlüssel B1 aus und invalidiert somit diese Transaktion (Abb. 3).
Gugger/Kobras

Bei allen folgenden Zahlungsvorgängen geht es nun darum sicherzustellen, dass jede Partei im eigenen Interesse keine früheren Transaktionen veröffentlicht. Mit jeder neuen Transaktion erzeugen beide Partner dazu ein neues Schlüsselpaar, bauen damit wie oben beschrieben je eine Transaktion mit der aktuellen Zahlungsbilanz auf, tauschen sie aus und senden zusätzlich den privaten Schlüssel der vorherigen Transaktion an ihr Gegenüber (Abbildung 2, 3, 4). Das aktiviert die „Vergiftung“: Denn veröffentlicht eine Seite nun eine ältere Transaktion in der Blockchain, kennt nun auch die Gegenseite den passenden privaten Schlüssel und hat 1000 Blöcke Zeit, sich den gesamten im Kanal gespeicherten Betrag einzuverleiben. Das funktioniert in beide Richtungen. Egal wie sich die Balance im Lightning-Kanal im Verlauf der Zeit auch verschiebt, stets werden beide Seiten jeweils nur den letzten Zahlungsstand einlösen. Zudem hat jeder Partner jederzeit die Möglichkeit, den Kanal aufzulösen und damit den aktuellen Geldbetrag zurück ins reguläre Bitcoin-Netz zu überführen.

Kommentieren