Lightning: Wie aus Payment-Channels ein Netzwerk entsteht

Endlich kommen wir zum zweiten Teil der Erklärung des Lightning-Netzwerks: Wie wird aus Payment-Channels ein Netzwerk? Wie kann jemand Bitcoins an jemanden anderen senden, ohne direkt einen Channel mit ihm zu unterhalten? Warum braucht man dafür kein Vetrauen? Und wie finden die Lightning-Nodes eine Route durch das Netzwerk? Lest es selbst!

Wie schon im ersten Teil der Lightning-Erklärung muss ich ankündigen, dass die Sache nicht ganz unkompliziert wird. Wenn ihr es endlich geschafft habt, eingermaßen zu verstehen, wie Bitcoin funktioniert, und nun einen neuen Stock sucht, um den ihr eure Hirnlappen herumknoten könnt — dann ist das Lightning-Netzwerk genau das richtige Hobby für euch.

Beginnen wir zum Verständnis nochmal mit den Grundlagen: Das Lightning-Netzwerk soll ein Netzwerk von offchain-Transaktionen werden, also von Transaktionen, die nicht auf der Bitcoin-Blockchain sind, aber dennoch ebenso gültig. Dies hat den Vorteil, dass man nicht warten muss, bis die Miner die Transaktion bestätigen, und, vor allem: dass die Transaktionen nicht von jedem Knoten im Netzwerk geprüft und gespeichert werden müssen.

Sprich: Transaktionen sind schneller und eine ganze Menge der Probleme, die die Skalierung von Bitcoin derzeit so kontrovers machen, fallen weg. Klingt gut, oder?

Payment Channels

Die Grundlage von Lightning sind sogenannte Payment-Channels. Man kann sich diese so vorstellen, als würden wir einen Überweisungszettel ständig umschreiben, anstatt ihn einzuwerfen.

Anstatt Ihnen Geld zu überweisen, gebe ich Ihnen einen Zettel, und den können Sie einwerfen, wie Sie wollen, um die Überweisung klar zu machen. Wir beide können den Zettel aber auch wieder und wieder umschreiben, um zwischen uns beiden Transaktionen zu verrechnen. So können wir unendlich viele Transaktionen vollziehen, ohne dass es zu einer SEPA-Überweisung kommt.

Bei Bitcoin nutzen die Payment-Channels eine Multisig-Adresse, in die beide Parteien eines Channels Geld einzahlen – sagen wir, jeder 0,1 Bitcoin – und diese Adresse bildet dann die Balance eines Channels. Stellen Sie sich vor, wir beide überweisen Geld auf ein Treuhandkonto, vom dem nur Geld überwiesen werden darf, wenn wir beide unterschreiben.

Diese Balance eines Bitcoin Payment-Channels ändern wir mit einer Transaktion, die von beiden Parteien signiert, aber nicht an die Blockchain gesendet wird. Wenn Sie mir etwa 0,01 Bitcoin geben, bilden wir eine Transaktion, die aus der Multisig-Adresse 0,09 Bitcoin an Sie und 0,11 Bitcoin an mich auszahlt. Ich kann die Transaktion nun an die Miner senden, oder warten, bis Sie mir weitere 0,01 Bitcoin senden, wodurch die neue Transaktion 0,08 Bitcoin an Sie und 0,12 Bitcoin an mich auszahlt. Und so weiter.

Es ist theoretisch zwar auch möglich, dass man einen Channel ohne Guthaben aufbaut, aber in der Regel wird man zu Beginn ein wenig Geld hineinlegen, um damit sowohl senden als auch empfangen zu können.

Der Trick beim Payment-Channel ist, dafür zu sorgen, dass das ganze funktioniert, ohne dass wir uns vertrauen müssen. Also ohne dass die eine Partei die andere dadurch erpressen kann, dass sie ihre Signatur verweigert (und damit das Geld beider Parteien einfriert), und ohne dass eine Partei eine Transaktion ungeschehen machen kann, indem sie eine vergangne Transaktion an die Blockchain sendet. Eine clevere Kombination von Smart Contracts sorgt dafür, dass Payment-Channels ohne Vertrauen auskommen. Zumindest solange, wie euer Knoten online ist. Wie es genau geht, könnt ihr in meinem Artikel lesen. Oder gleich im Whitepaper.

Hier kommen wir dazu, wie aus einem Payment-Channel ein Netzwerk wird. Denn solche Payment-Channels sind zwar eine entzückende Technologie, aber, ehrlich gesagt, so richtig nützlich sind sie im Alltag nur in Ausnahmefällen. Sowohl 21.co als auch SatoshiPay haben Payment-Channels gebaut, ohne dass diese wirklich zum Verkaufsschlager geworden sind. Daher ist die Frage, wie man über sie hinauskommt.

Wie aus Channels ein Netzwerk wird

Kommen wir zu dem Teil, für den ich mir für euch einen Knoten ins Gehirn gedreht habe. Wie aus Channels ein Netzwerk wird – das Lightning Netzwerk.

Stellt euch mal vor, zwei meiner Leser, Jens und Sven, haben jeweils einen Payment-Channel mit mir. Nun versucht Jens über diese Channels einen Bitcoin an Sven zu senden. Wie ist das möglich?

Der Kern der Sache ist recht einfach: Jens schickt mir einen Bitcoin (bzw. die Transaktion für einen Bitcoin) und ich schicke einen Bitcoin (bzw. eine Transaktion) an Sven.

Mir fällt kein besserer Vergleich ein als das beliebte Brettspiel Risiko. In diesem darf jeder Spieler, nachdem er seine Schlachten geführt hat, jede Armee um ein einziges Land verschieben. Nun kann man etwa eine Armee von Brasilien nach Nordwestafrika ziehen. Da die Armee, die bisher in Nordwestafrika stand, sich aber noch nicht bewegt hat, kann man sie nach Ägypten ziehen. Und so weiter. Ein wenig wie bei den Postboten früher, die bei den Stationen das Pferd gewechselt haben, um im Eiltempo durch ganz Deutschland zu reiten.

Im Prinzip haben wir damit schon die grundlegende Topographie des Lightning-Netzwerks dargestellt. Die Zahlungen flitzen durch die Channels. Wenn Sven etwa noch einen Channel mit Tony hat und Tony mit Jan, dann kann Jens über die Route Christoph-Sven-Tony eine Transaktion an Jan senden. Und so weiter.

Was sich für ein Netzwerk daraus bildet, steht noch in den Sternen. Es könnte sein, dass es komplett dezentral bleibt und jeder User zwei, drei, vier Channels betreibt und sich die Zahlungen dadurch ihren Weg suchen. Es wäre gleichsam aber auch möglich, dass sich große Hubs bilden, die viel Kapital in vielen Channels einsperren, um die Verbindungen innerhalb des Netzwerkes zu vereinfachen. Sie werden wohl dadurch Geld verdienen, dass sie Daten über die Zahlungsgewohnheiten ihrer Channel-Partner sammeln und / oder Gebühren verlangen.

Wie schon bei den Payment-Channels lautet die goldene, große Frage nun: Wie kann das Ganze ohne Vertrauen funktionieren? Also, wenn Jens eine Transaktion an Christoph schickt, damit der sie an Sven weiterleitet – wie kann Jens sicher gehen, dass Christoph sich nicht ins Fäustchen lacht und den Bitcoin einfach behält?

Die Antwort ist nicht ganz einfach zu verstehen. Aber wir versuchen es.

Hash Time-Locked Contracts

Um über Christoph Geld von Jens zu erhalten, generiert Sven einen zufällig Wert. Nennen wir ihn R. R ist einfach irgendeine Folge von Nummern oder Zeichen, wie ein Passwort. Daraus bildet er dann eine Hash. Das ist eine mathematische Einwegfunktion: Aus einer Zeichenfolge entsteht immer dieselbe Hash, aber es ist nicht möglich, aus der Hash die Zeichenfolge zu rekonstruieren. Mehr darüber in diesem Artikel.

Diese Hash schickt Sven dann zu Jens. Nehmen wir, der Anschauung wegen, an, es sei eine SHA 256 Hash wie diese:

0a8500781be5e73270e1c19ae7e7ab4ca321415734de17a48ec110fdf389a799

Jens verspricht nun Christoph, dass er einen Bitcoin bekommt, wenn er den Wert liefert, der zu dieser Hash führt. Natürlich belässt Jens es nicht bei einem Versprechen, sondern bildet eine spezielle Transaktion: einen sogenannten Hash Contract.

Um das zu verstehen, solltet ihr wissen, dass jede Transaktion in ihrem Kern ein Script hat. Eine normale Transaktion sagt: „Du darfst mich ausgeben, wenn du eine Transaktion mit dem privaten Schlüssel signierst, der zu dieser oder jener Adresse passt.“ Ein Hash Contract sagt nun eben: „Du darfst mich ausgeben, wenn du mir die entsprechende Signatur UND den Wert lieferst, der zu dieser oder jener Hash führt.“

Jens schickt also eine solche Transaktion an Christoph. Damit Christoph die Bitcoins in der Transaktion erhalten kann, muss er Sven darum bitten, ihm den der Hash zugrunde liegenden Wert zu geben. Dies macht Sven im Austausch gegen einen Bitcoin. In unserem Fall wäre der Wert „bitcoinblog.de“, was ihr mit dem netten Hashgenerator von Henrik nachprüfen könnt.

Wie verhindern wir aber, dass Christoph einfach darauf pfeift, die Transaktion weiterzuleiten? Er könnte sich ja schadenfroh damit zufrieden geben, dass Jens einen Bitcoin weniger hat, ohne Sven bezahlt zu haben. Die Transaktion von Jens steckt im Nirwana, und weder Christoph noch Sven haben etwas bekommen. Ähnlich würde es ablaufen, wenn Sven die Herausgabe des „Passworts“ verweigert. Die verschiedenen Parteien der Transaktion könnten die anderen erpressen: Gib‘ mir 0,1 Bitcoin mehr, oder deine 1,0 Bitcoin Transaktion wird für immer feststecken.

Hier kommen die Time-Locked-Contracts ins Spiel. Denn eine Lightning-Transaktion kann auf zwei Arten ausgezahlt werden. Zum einen, wie oben beschrieben, wenn Christoph seine Signatur und den der Hash zugrundeliegenden Wert abliefert. Zum anderen – und das ist das Sicherheitsnetz – wenn der Sender der Transaktion – Jens – seine Signatur zeigt. Dies funktioniert aber erst nach Ablauf einer bestimmten Zeit, daher auch „Time-Locked.“ Wenn sich also eine Partei der Transaktionskette weigert, das Passwort rauszugeben, kann der Sender der Transaktion diese nach Ablauf einer bestimmten Zeit wieder auflösen. Das schlimmste, was passieren kann, ist, dass die Bitcoins für eine bestimmte Zeit eingefroren sind.

Es ist gar nicht so schwer, oder? Wir können das ganze auch darauf ausdehnen, dass die Zahlung von Sven über Tony zu Jan geht. In diesem Fall gibt Jens die Hash an Christoph, Christoph an Sven und Sven an Tony, während Jan die Lösung des Rätsels den Weg andersherum läuft, also an Tony, von Tony an Sven und vonn Sven an Christoph. Es ist im Prinzip derselbe Vorgang, außer, dass die „Time-Lock“ entsprechend eingestellt werden muss, damit die Channels kaskadierend einfallen.

Damit hätten wir die Frage, wie Lightning ohne Vertrauen funktioniert, einigermaßen beantwortet. Schwieriger ist hingegen die Frage, woher die einzelnen Teilnehmer des Netzwerkes wissen, wie ihre Transaktion den Weg von Sender zu Empfänger findet.

Flare, Sphinx, Onion Rounting

Um eine Lightning-Transaktion abzusenden, brauchen Sie im Idealfall nur eine Hash. Sven möchte Geld haben, also hinterlegt er öffentlich eine Hash, und jeder, der Sven etwas spenden will, schickt Geld an die Hash. Zumindest könnte eine Zahlung so ablaufen.

Die Kunst besteht nun darin, eine Möglichkeit zu finden, den Lightning-Knoten auf eine dezentrale Weise klar zu machen, auf welchem Weg eine Zahlung ihr Ziel erreicht. Dies wird noch dadurch verkompliziert, dass nicht alle Mittelsmänner gleich sind. Wenn etwa Jan einen Bitcoin über Christoph an Sven schicken will, aber Christoph in seinem Channel an Sven nur 0,1 Bitcoin hat, muss sich Jan einen anderen Mittelsmann mit mehr Geld im Channel suchen. Eine Route durch das Netzwerk muss also nicht nur einen Weg ans Ziel finden, sondern auch sicherstellen, dass die Mittelsmänner genügend Bitcoins in den Channels haben.

Manche sagen, ein solches „Routing“ wäre ohne zentrale Hubs nicht möglich, weshalb Lightning nicht, wie von vielen erhofft, besonders privat ist, sondern ganz im Gegenteil, ein Alptraum der Transparenz wird. Andere hingegen sagen, ein solches Routing ist nicht nur möglich, sondern bereits so gut wie entwickelt.

Genaueres kann ich hier nicht beurteilen. Ich kann mich nur auf die Lightning-Entwickler verlassen. Rusty Russel, Lightning-Entwickler für Blockstream, bloggt über das sogenannte Onion Routing im Dezember 2016: „Im Internet ist Routing einfach. Man wirft ein Paket raus, auf das eine Adresse gestempelt ist, und der Empfänger findet heraus, wie er es näher bringt. In der Regel funktioniert es. Wenn man aber Anonymität möchte, geht das jedoch nicht.“ Und Anonymität ist, so Russel, für jeden Blockstream-Mitarbeiter ein großes, wichtiges Thema. Daher haben „Christian Decker und Olaoluwa Osuntokun das zuvor publizierte Sphinx-Schema für Lightning implementiert.“

Sphinx ist ein Protokoll, entwickelt von George Danezis und Ian Goldberg. Es ist laut Whitepaper „ein kryptographisches Nachrichtenformat, das genutzt wird, um anonyme Nachrichten in einem Mix Netzwerk zu verbreiten. Es ist kompakter als andere vergleichbare Methoden, und bietet ein vollständiges Set an Sicherheit-Features: Es macht die Antworten ununterscheidbar, versteckt die Länge der Pfade sowie die Position der Sender und und bricht den Link zwischen den Gliedern der Reise einer Nachricht durch das Netzwerk.“

Für Lightning bedeutet die Anwendung von Sphinx, wie Rusty Russel erklärt, „dass kein Node sagen kann, wie viele Sprünge eine Transaktion bereits hinter sich hat, noch wie viele sie noch vor sich hat; lediglich, was der vergangene und was der nächste Sprung ist.“ Dies ermöglicht, wie Russel in einem anderen Post erläutert, ein „vernünftiges“ Maß an Privacy: Einzelne Knoten wissen, wie erwähnt, nur die letzte und die nächste Station einer Transaktion.

Allerdings können Nodes zusammenarbeiten, um Transaktionen zu identifizieren, und es ist möglich, mit Traffic-Analysen mehr herauszufinden. Laut Rusty gibt es jedoch bereits Ideen, wie man diese Probleme lösen kann, auch wenn die gegenwärtige Implementierung noch nicht in der Lage ist, auf ein übermäßig großes Netzwerk zu skalieren.

Eine Alternative zu Sphinx ist das Flare-Protokoll, das BitFury entwickelt hat. Die Firma hat darüber im Spätsommer 2016 ein Whitepaper geschrieben. Getestet wurde Flare von ACINQ, einem französischen Startup, das einen der ersten Lightning-Prototypen entwickelt hat. Laut BitFury konnte ACINQ mit 2.500 AWS-Knoten schnell und relativ zuverlässig Routen für Transaktionen finden. So wie ich es verstehe, hat Flare vor allem das Potenzial, gut zu skalieren:

„Das Design von Flare zielt darauf ab, zu gewährleisten, dass Routen im Lightning-Netzwerk so schnell wie möglich gefunden werden, während die Menge an Daten minimiert und die Dezentralität erhalten wird. Der Preis, um dies zu erreichen, ist, dass jeder Node proaktiv Informationen über die Topologie des Netzwerks sammelt, und reaktiv Informationen über die Topologie zusammenstellt, die er für eine Transaktion braucht … Wir haben Simulationen des Routing-Algorithmus durchgeführt und sind der Ansicht, dass sie bis zu 100.000 Knoten skalieren können.“

An sich steht dem Lightning-Netzwerk also nichts weiter im Wege.