Das Lightning-Netzwerk

Was ist das Lightning-Netzwerk? In diesem Beitrag versuchen wir, allgemeinverständlich zu erklären, wie dieses Wunderwerk der Bitcoin-Skalierbarkeit funktioniert. Teil 1 dreht sich um Payment-Channels.

Vom Lightning-Netzwerk hört man nur das allerbeste. Dieses Konzept, wird gesagt, löst alle Skalierbarkeits-Probleme des Bitcoins lösen, verbessert die Privacy und ermöglicht sofortige Transaktion.

Ja. Das wird gesagt und das ist nicht falsch. Wenn euch jetzt aber jemand verspricht, das Lightning Netzwerk „ganz einfach“ zu erklären, könnt ihr sicher sein, einen Lügner vor euch zu haben. Denn das Lightning Netzwerk ist nicht einfach, sondern affenkompliziert. Ich habe mir bei der Recherche zu diesem Artikel einige Knoten ins Gehirn gedreht, und ich werde nicht darum herumkommen, diese Knoten an euch weiterzugeben. Aber ich versuche, es so einfach wie möglich zu machen.

Bei Bitcoin kocht sich jeder Knoten sein eigenes Süppchen

Um das Lightning-Netzwerk zu verstehen, müssen wir beim Bitcoin-Netzwerk anfangen. Nämlich bei der Tatsache, dass dieses ein Broadcast-Netzwerk ist, was bedeutet, dass jeder Knoten jede Transaktion empfangen, validieren und speichern muss. Das hat seinen Sinn, ist aber offenkundig fürchterlich ineffektiv.

Stellt euch vor, eine Reisegruppe von 250 Leuten fährt von Heilbronn nach Antwerpen und jeder benutzt sein eigenes Auto. Oder: eine Gruppe von Schülern muss zusammen 5 Mathe-Aufgaben lösen, und jeder rechnet alle fünf Aufgaben durch. Oder, noch eine letzte Analogie: Sieben Gäste laden sich bei Chefkoch dasselbe Rezept für dieselbe Spargelsuppe für acht Personen herunter, drucken es aus und kaufen beim selben Supermarkt die Zutaten. Dann gehen sie zum Gastgeber, wo sich jeder in einem Töpfchen sein eigenes Süppchen kocht, wofür er die Zutatenmenge durch acht teilt.

Ich könnte ewig so weitermachen. Aber ich glaube, ihr habt verstanden, wo das Problem liegt und weshalb manche Leute sagen: Bitcoin skaliert nicht.

Das Lightning-Netzwerk skaliert super

Das Lightning-Netzwerk, um das es im Folgenden geht, räumt nun mit genau diesem Problem auf. Es bildet nämlich ein Netzwerk von Payment-Channels, die eine Transaktion nur von dem, der sie sendet, zu dem schickt, der sie empfangen soll. Das heißt, wenn ich jetzt Geld an Martin überweise, muss das nicht auf jedem Knoten im Bitcoin-Netzwerk gespeichert werden, sondern prinzipiell nur auf meinem und Martins Knoten. Das beseitigt mit einen Streich einige gravierende Schwächen des Bitcoins:

• Privatsphäre: Beim Bitcoin notiert jeder, was jeder macht. Blockchain-Analysen sind möglich und beeinträchtigen die Privatsphäre massiv. Wenn jedoch jeder nur die Transaktionen liest und speichert, die für ihn wichtig sind, verrät die Blockchain nichts über das Geld anderer Leute.
• Skalierbarkeit: Ein Broadcast-Netzwerk wie der Bitcoin kann nicht skalieren bzw. ist sehr schlecht darin. Mehr Teilnehmer machen das Netzwerk nicht effektiver, sondern steigern nur die gesamte Datenlast. Darum ist es unwahrscheinlich, dass Bitcoin jemals ein solches Transaktionsvolumen stemmen kann, wie es Netzwerke wie VISA leisten. Mit Lightning ist dies problemlos möglich.
• Geschwindigkeit: Eine Bitcoin-Transaktion kann zwar fast augenblicklich gesehen werden, wird aber erst nach einigen Minuten bis einer Stunde bestätigt. Bis dahin ist es möglich, die Transaktion rückgängig zu machen. Mit dem Lightning-Netzwerk hingegen werden Transaktionen augenblicklich gültig.

Stark, oder? Die große Frage ist jetzt: Geht das überhaupt? Und wie soll das funktionieren?

Damit wären wir bei den Gehirnwindungen, die ich euch versprochen habe. Beginnen wir mit dem ersten Teil:

Die Payment Channels

Was ist ein Payment-Channel? Die Antwort ist nicht ganz einfach, weshalb ich euch bitten muss, mir einige Sätze Konzentration zu schenken. Sie werden es verstehen, das verspreche ich.

Um einen Payment-Channel zu eröffnen, überweisen Sie und ich einen Betrag – sagen wir jeweils 0,1 Bitcoin oder 40 Euro – auf eine 2-von-2 Multi-Sig-Adresse. 2-von-2 bedeutet folgendes: Sobald die Bitcoins auf dieser Adresse liegen, müssen sowohl Sie als auch ich eine Transaktion signieren, um sie auszuzahlen. Wie bei einem Mietkautionskonto.

Nachdem wir also die Bitcoins auf diese Adresse überwiesen haben, bilden wir eine Auszahlung – 0,1 Bitcoin für mich, 0,1 Bitcoin für Sie – und signieren diese. Wir senden sie aber nicht an die anderen Bitcoin-Knoten, sondern nur an uns. Anschließend modifizieren wir die Bitcoin-Transaktion immer wieder.

Sie können sich den Payment-Channel so vorstellen, als würde ich Ihnen einen ausgefüllten Überweisungsschein geben, den Sie jederzeit bei Ihrer Bank einwerfen können. Anstatt ihn einzulösen, ändern wir diesen Überweisungsschein aber stetig. Wenn ich eine Rechnung bei Ihnen bezahle, weise ich nicht die Bank an, Ihnen Geld zu überweisen, sondern sende Ihnen einen neuen Überweisungsschein, auf dem ich den Betrag erhöht habe. Und so weiter.

Stellen Sie sich vor, Sie und ich haben den erwähnten Payment-Channel, in den wir beide 0,1 Bitcoin eingezahlt haben. Wenn Sie mir nun 0,0001 Bitcoin spenden wollen, schreiben und signieren Sie eine Transaktion, die 0,0999 an Sie und 0,1001 an mich auszahlt. Wenn ich die Transaktion nun einlöse, schließe ich den Payment-Channel. Ich kann ihn aber offenlassen, und Sie können mir ein Jahr lang jeden Tag 0,0001 Bitcoin spenden. Am Ende des Jahres kann ich den Payment-Channel schließen, und Sie erhalten 0,0535 und ich 0,1365 Bitcoin. Sie haben 365 Überweisungen gemacht, aber nur eine einzige landet auf der Blockchain.

Solche Payment-Channel mögen praktisch sein, wenn dieselben zwei Parteien immer wieder Transaktionen machen. Um wirklich in der Masse brauchbar zu sein, müssen wir sie aber zu einem Netzwerk verbinden – zum Lightning-Netzwerk. Dieses erlaubt es, dass ich eine Spende von 5 Euro, die in meinem Payment-Channel eingetrudelt ist, an einen andere Payment-Channel route, um beispielsweise mein Konto bei Bitcoin.de aufzuladen.

Das ist die Idee. Bevor wir dazu kommen, wie sich die Payment-Channels verbinden, müssen wir noch einige Herausforderungen bei der Einrichtung der Payment-Channels erklären. Denn durch diese versteht man (einigermaßen), weshalb die verwirrenden neuen Skripte von Core Version 0.12.1 notwendig sind – und weshalb der Aufbau von Payment-Channels relativ kompliziert ist, aber funktioniert, ohne dass man jemandem vertrauen muss.

Denn alles andere wäre nicht mehr Bitcoin.

Wo ist das Problem?

Es gibt zwei große Probleme, warum ein Payment-Channel nicht so einfach funktioniert, wie ich es eben dargestellt habe. Im Whitepaper des Lightning-Netzwerkes erklären Joseph Poon und Taddeus Dryvja diese Probleme und deren Lösungen intensiv.

Das Geiselnahme-Probleme

Erstens: Stellen Sie sich bitte vor, Sie und ich eröffnen einen Payment-Channe. Jeder von uns überweist einen Bitcoin auf die 2-von-2 Multisig-Adresse. Noch bevor Sie aber dazu kommen, mir eine kleine Spende zu senden, zeige ich mein wahres Gesicht und sage: Hei, ich werde den Channel niemals schließen, Ihr Bitcoin ist für immer darauf eingesperrt, es sei denn, Sie überweisen mir einen halben Bitcoin an diese oder jene Adresse. Die Einzahlung jeder Partei in einem Payment-Channel kann von der anderen Partei zur Geisel genommen werden.

Wie verhindert man das? Poon und Dryvja haben eine clevere Lösung dafür gefunden. Es hört sich komplizierter an, als es ist, und wenn Sie es einmal verstanden haben, ist es ganz einfach: Wir bilden zuerst die Transaktion, um den Payment-Channel zu eröffnen, senden sie aber weder ins Netzwerk noch signieren wir sie. Das heißt, jeder weiß, was passieren soll, aber keiner hat die notwendigen Signaturen, um die Aktion auszulösen. Der Payment-Channel existiert bisher nur als Idee.

Danach bildet jeder von uns, ausgehend von dieser Transaktion, die theoretisch vorliegt, die Transaktion, die den Payment-Channel schließen wird. Also die Transaktion, mit der jeder von uns seinen Anteil wieder auszahlt. Wenn wir beide 1 Bitcoin einzahlen wollen, bilden wir nun die Transaktion, um an jeden von uns 1 Bitcoin auszuzahlen. Diese Transaktion wird signiert und ausgetauscht, aber noch nicht abgesendet. Jeder ist also in der Lage, diese Transaktion abzusenden.

Erst wenn jeder von uns die Transaktion (bzw. die beiden Signaturen) besitzt, mit der der Channel geschlossen werden kann, signieren beide Parteien die Transaktion, die den Channel öffnet, und senden diese ans Netzwerk. Damit kann der Channel also jederzeit von jedem geschlossen werden.

Ergebnis: Die Bitcoins im Channel können nicht als Geisel genommen werden, da jede Partei sie jederzeit befreien kann. Noch ist dieses Modell nicht möglich, da man die ID der vorhergegangenen Transaktion braucht, um eine Folge-Transaktion zu signieren. Aber indem mit einer Softfork der Skript-Befehl OP_Signohash eingeführt wird, wird dies möglich sein.

Das löst aber noch nicht das zweite Problem.

Das Problem alter Commitment-Transaktionen

Stellen Sie sich diesmal vor, Sie spenden mir 200 Tage lang Bitcoins und verschieben damit die Bilanz unseres Payment-Channels von 0,5:0,5 zu 0,3:0,7. An Tag 201 beschließen Sie nun, den Payment-Channel zu schließen. Anstatt der aktuellsten Transaktion nehmen Sie dazu aber die erste Transaktion, die von uns beiden signiert wurde. Das Ergebnis wäre, dass jeder von uns 0,5 Bitcoin erhält und es so ist, als hätten Sie mir niemals etwas gespendet.

Poon und Dryvja haben auch dieses Problem (theoretisch) gelöst. Leider wird das jetzt eine Hausnummer komplizierter. Aber vertrauen Sie mir, Sie werden auch das verstehen.

Kurz zu den Begrifflichkeiten: Poon und Dryvja nennen die Transaktion, die den Payment-Channel eröffnet – also die Bitcoin auf die Multi-Sig-Adresse überweist – Funding-Transaktion, und die, die den Payment-Channel schließt, Commitment Transaktion. Um das Guthaben im Payment-Channel zu ändern, schreiben und signieren wir neue Commitment-Transaktionen.

Sobald wir also unsere Guthaben im Payment-Channel ändern, existieren mehrere Commitment-Transaktionen gleichzeitig, von denen jede mit demselben Recht auf die Blockchain kann. Wie kann man dieses Problem lösen? Wie sorgt man dafür, dass nur die neueste Commitment-Transaktion auf die Blockchain geht?

Poon und Dryvja haben hierfür ein Transaktionsmodell entwickelt, dass denjenigen, der eine ältere Commitment-Transaktion ausstrahlt, damit bestraft, dass er das gesamte Guthaben im Payment-Channel verliert. Dieses Modell besteht aus zwei Teilen.

Zum einen muss man erkennen, wer die falsche (veraltete) Transaktion gesendet hat. Dies ist relativ simpel: Man muss lediglich zwei unterscheidbare, aber faktisch identische Commitment-Transaktionen bildet. Das kryptographische Gerüst des Bitcoins macht dies möglich, indem jede Partei Inputs signiert und diese der anderen Partei gibt, die die gesamte Transaktion signiert. Stellen Sie sich vor, ich unterschreibe einen Zettel, den Sie in einen Brief stecken, auf den Sie wiederum Ihre Unterschrift setzen, und umgekehrt. Sie müssen die Details nicht kennen, sondern nur das folgende wissen: Es entstehen zwei verschiedene Transaktionen, die dasselbe machen. Das wird etwas später wichtig.

Zum anderen muss man eine Möglichkeit finden, „falsche“ – also den Vertrag verletzende, betrügerische – Transaktionen rückgängig zu machen. Das Ziel muss es sein, dass nur die aktuellste Transaktion durchgeht, ohne widerrufen zu werden bzw. eine Strafe auszulösen.

Hier kommt ein Skript namens  OP_CHECKSEQUENCEVERIFY ins Spiel, kurz CSV. Dieses nutzt das Sequence-Field einer Transaktion, um deren Output quasi „einzufrieren“: Eine Transaktion muss eine bestimmte Anzahl an Bestätigungen erhalten, damit man ihren Inhalt ausgeben kann. Ich kann Ihnen beispielsweise einen Bitcoin senden, aber in die Transaktion reinschreiben, dass Sie diesen Bitcoin erst nutzen dürfen, wenn die Transaktion seit 1.000 Blöcken bestätigt ist. Man hängt also ein Zeitschloss an die Transaktion.

Im Detail ist es sehr kompliziert, aber mit OP_CSV kann man ein Transaktionsmodell bilden, das es erlaubt, Transaktionen unter bestimmten Bedingungen zu verändern: Jede Partei bildet eine Commitmit-Transaktion mit zwei Pfaden. Erstens wird das Geld, so wie im Payment-Channel vereinbart, an jede Partei ausgezahlt. Dieser Output wird „eingefroren“ und benötigt eine bestimmte Anzahl von Bestätigungen. Zweitens wird der gesamte Inhalt des Payment-Channels an die Gegenpartei ausgezahlt. Dieser Output kann nur von der Gegenseite ausgelöst werden und dies nur, nachdem die Transaktion bereits gesendet wurde – aber er kann sofort ausgezahlt werden.

Also: Wenn Sie unseren Payment-Channel mit einer veralteten Transaktion schließen, nach der Sie 0,5 und ich 0,5 Bitcoins erhalten, obwohl eigentlich ich 0,6 und Sie 0,4 bekommen sollten, wird der Output dieser Transaktion erst nach sagen wir 1000 Blöcken gültig. Sobald Sie diese Transaktion jedoch abgesendet haben, habe ich die Möglichkeit, das gesamte Guthaben des Payment-Channels sofort an mich auszuzahlen.

Dieser zweite Output macht dementsprechend eine Commitment-Transaktion ungültig. Wenn Sie mir im Payment-Channel also 0,1 Bitcoin überweisen, senden Sie mir nicht nur den signierten Input für eine neue Transaktion zu, sondern auch die Information, mit der ich die vorangegangene Transaktion im Falle ihrer Ausstrahlung so umbiegen kann, dass das gesamte Guthaben an mich geht.

Das bedeutet: solange wir beide den Payment-Channel beobachten, können wir jederzeit erkennen, wenn der andere eine veraltete Commitment-Transaktion absendet und ihn damit bestrafen, indem wir sämtliche Outputs der Transaktion auf uns umleiten. Dies macht es faktisch unmöglich, veraltete Commitments zu senden und stellt alleine den Versuch unter Strafe. Das einzige damit verbundene Problem ist, dass beide Parteien eines Payment-Channels gelegentlich online sein müssen, um zu beobachten, ob die Gegenseite risikiert, eine veraltete Commitment-Transaktion in die Blockchain zu bringen.

Ausblick

Das Lightning-Netzwerk ist also das Konzept von Payment-Channels, in denen wir der Gegenpartei nicht vertrauen müssen, um sicher zu sein, dass der aktuellste Transaktionsentwurf der einzige ist, der gültig sein wird.

Bislang ist dies jedoch nur in der Theorie möglich. Um zu funktionieren, benötigt man zum einem CSV – eingeführt in Core 0.12.1, aber noch nicht aktiviert – und zum anderen Segregated Witness – was die Transaction Malleability vollständig beseitigt.

Noch nicht geklärt ist das Problem des Routings – also die Frage, wie die Transaktionsentwürfe den Weg durch das Netz der Channels finden. Dazu kommen wir, hoffentlich, in einem Folgebeitrag.