In den vergangenen Tagen sind teilweise hitzige Debatten über das Bitcoin Lightning Netzwerk entstanden. Kern dieser sind oftmals kritischen Fragen über die Grenzen des Bezahlsystems. Obwohl ich einen kritischen und konstruktiven Austausch für absolut förderlich halte, mangelt es der aktuellen Debatte leider manchmal am Fundament. Ferner sind die angeführten Argumente nicht neu und werden teilweise seit vielen Jahren innerhalb der Community diskutiert. Deshalb räume ich nun mit den beiden Falschaussagen auf, die mir persönlich am häufigsten unterkommen…
Lese-Tipp: Das Lightning-Netzwerk einfach erklärt
Das Lightning Network sei kaputt, denn es skaliere nicht
Das wohl häufigste „Argument“ weshalb das Lightning Netzwerk ein Fehlschlag sein sollte, ist wohl, dass der Bitcoin Main-Layer gar nicht die Kapazität besäße, um tatsächlich allen Menschen dieser Welt einen eigenen Lightning Channel zu ermöglichen. Das Argument rührt daher, dass jeder Lightning Channel einen sogenannten “On-chain Footprint” hat, denn zum Öffnen und Schließen eines Zahlungskanals ist derzeit eine Transaktion auf dem Bitcoin Main-Layer notwendig. Das ist tatsächlich nicht wirklich eine bahnbrechende Erkenntnis, auch wenn manche Kritiker so tun, als wäre sie es. Besonders absurd wird es aber, wenn diese dann auch noch behaupten, dass Bitcoiner dies aktiv verheimlichen oder abstreiten würden. Wer sich wirklich mit der Materie auseinandergesetzt hat, der weiß, dass diese „Problematik“ bereits seit den Geburtsstunden des Lightning Netzwerks diskutiert wird. So heißt es im Whitepaper des Lightning Networks:
"Würden alle Transaktionen mit Bitcoin innerhalb eines Netzwerks von Mikro-Zahlungskanälen abgewickelt, um 7 Milliarden Menschen zwei Kanäle pro Jahr mit unbegrenzten Transaktionen innerhalb des Kanals zu ermöglichen, wären 133 MB Blöcke erforderlich (unter der Annahme von 500 Byte pro Transaktion und 52560 Blöcken pro Jahr)."
Bis heute ist diese Limitierung und passende Lösungen ein relevantes Gesprächsthema, weshalb sich über die letzten Jahre zahlreiche Whitepaper und Konzepte rund um mögliche Lösungsansätze gebildet haben.
Das Lightning Network skalieren durch Effizienz
Viele Lightning-Kritiker betrachten es als „Fakt“, dass die Öffnung eines Lightning Kanals heutzutage ungefähr 250 virtual Bytes (vB) an Blockspace benötigt. Das würde bedeuten, dass ein Block der Bitcoin Blockchain nur 4000 Kanalöffnungen fassen kann.
Nun gibt es aber durchaus Möglichkeiten den On-chain-Footprint einer Kanalöffnung drastisch zu reduzieren, wie z.B. das sogenannte “Batch-Opening”. Bei diesem Ansatz werden mehrere Kanäle mit einer einzelnen Transaktion eröffnet. Alex Bosworth eröffnete Anfang des Jahres 50 Lightning Zahlungskanäle in einer einzelnen Transaktion und reduzierte somit den On-chain Footprint einer einzelnen Öffnung von 250 vB auf ca. 45 vB.
Diese immense Steigerung der Effizienz ist keine Zukunftsmusik und bereits heute auf der Bitcoin Blockchain verfügbar. Aber wo wir gerade von Zukunftsmusik sprechen…
Das Lightning Network skalieren durch Technologie
Das Konstruieren von effizienten Transaktionen ist ein wichtiger Faktor für die Skalierbarkeit des Lightning Netzwerks, aber bei Weitem nicht der einzige. Des Weiteren gibt es eine Reihe von Ideen und Konzepten, um den On-chain Footprint des Lightning Networks weiter zu reduzieren. Einer dieser Ansätze sind die sogenannten Channel Factories, ein Konstrukt, welches eine Art Zwischen-Layer zwischen Lightning Kanälen und der Bitcoin Blockchain ermöglicht. Anstatt, dass zwei Entitäten eine 2-of-2 MultiSig Adresse als Basis für ihren Kanal nutzen, nutzt ein größerer Kreis aus n Personen eine n-of-n MultiSig Adresse, um auf dieser Basis eine Vielzahl an Kanälen zwischen einander zu eröffnen. Diese Kanäle sind dann nicht mehr direkt in der Bitcoin Blockchain verankert, sondern in der n-of-n MultiSig Adresse, die wiederum in der Blockchain verankert ist. Es benötigt also nur eine einzige Transaktion, um Kanäle für alle Teilnehmenden zu eröffnen.
Eine weitere Entwicklung ist das sogenannte Splicing. Heutzutage ist die Kapazität eines Zahlungskanals statisch. Sie wird bei der Eröffnung festgelegt und kann nicht verändert werden. Das bedeutet, wenn zwei Entitäten ihren Kanal vergrößern oder verkleinern möchten, müssen sie den alten Kanal schließen (1 TX) und einen neuen öffnen (1TX). Splicing ermöglicht es einem Teilnehmer sowohl Kapazität aus einem Lightning Kanal abzuziehen, oder sie hinzuzufügen. Natürlich benötigt auch dieser Vorgang eine Transaktion auf dem Main-Layer, aber eben nur eine, also 50% des ursprünglich benötigten Blockspaces.
Das Lightning Network gar nicht skalieren…
Den Abschnitt zur ersten Falschaussage abschließen möchte ich mit einem etwas kontroversen Thema: Lightning muss man vielleicht gar nicht unbedingt skalieren. Oder zumindest nicht zu einem Punkt von 16 Milliarden Lightning Channel Openings/Closings im Jahr. Die Aussage spielt darauf an, dass die Vorstellung jeder Mensch dieser Welt würde gerne einen eigenen Lightning Node mit einigen Kanälen betreiben, vielleicht auch etwas unrealistisch ist. Wenn man sich das derzeitige System anschaut, gibt es durchaus Menschen, die sehr glücklich sind, wenn ihnen jemand die Verantwortung abnimmt. Manche Menschen sind sogar darauf angewiesen. So könnte beispielsweise jeder Webseitenbetreiber seinen eigenen Webserver nutzen, aber dennoch nutzen die meisten hierfür Hosting Anbieter, obwohl das ein nicht unerhebliches Vertrauen erfordert und eine immense Abhängigkeit schafft.
Natürlich dürfen sich die Entwickler des Protokolls niemals auf dieser Annahme ausruhen. Das Ziel sollte immer ein maximaler Zugang für jeden sein. Aber es gibt durchaus Konstrukte die einer Vielzahl von Menschen Zugang zu Bitcoin und Lightning gewähren und dabei kaum on-chain footprint haben, da sie auf Vertrauen basieren.
Das naheliegendste Beispiel sind custodial Wallets, wie beispielsweise Wallet of Satoshi. Hier teilen sich Hunderte Menschen einen gemeinsamen Lightning Node und dessen Kanäle, der von einem Custodian betrieben wird. Ähnlich, aber dennoch fundamental anders funktioniert FediMint. FediMint oder Federated Chaumian Mints ermöglichen es kleinen Communities ihre eigenen Custodians, sozusagen „Mini-Community-Banken“, zu ernennen, die dann ein Substitut ausgeben, welches zu einem späteren Zeitpunkt wieder gegen Bitcoin getauscht werden kann. Natürlich beruht auch dieses Konzept auf Vertrauen, aber im Gegensatz zu einer normalen (custodial) Wallet vertraut man hier einer Person aus der eigenen Community. Federated Chaumian Mints sind ein wahnsinnig spannendes Thema, welches den Rahmen dieses Beitrags völlig sprengen würde. Ihr könnt hier mehr darüber erfahren.
Ein letztes Beispiel sind sogenannte "Hosted Channels", die wie ein regulärer Lightning Kanal funktionieren, dabei aber keine Öffnungs-Transaktion auf dem Main-Layer haben, sondern auf reinem Vertrauen zwischen den beiden Parteien basieren (oder sich auf off-protocol Zusicherungen wie Verträge oder Kautionen etc. verlassen).
Die Zahlungsflüsse sind unidirektional
Dass das Lightning Netzwerk auf bidirektionalen Zahlungskanälen besteht, ist unanfechtbar. Das bedeutet jedoch nicht, dass Zahlungen zwangsläufig in beide Richtungen fließen müssen. Betrachtet man einen theoretischen Kanal zwischen einem Arbeitgeber und einem Arbeitnehmer, dann fließen Zahlungen meistens nur in eine Richtung. Einige Lightning-Kritiker denken, dass sie an dieser Stelle ein fundamentales Problem des Netzwerks entdeckt haben, denn nach einer gewissen Zeit wäre ja die gesamte Liquidität auf einer Seite des Kanals und er könnte nicht mehr für Zahlungen in diese Richtung genutzt werden. Dasselbe gilt für Supermärkte und deren Kunden und generell alle Zahlungen, die eher nur in eine Richtung laufen. Sie stellen sich das Lightning Netzwerk ungefähr so vor:
Diese Annahme wird nachvollziehbar, wenn man bedenkt, dass viele dieser Kritiker nicht verstehen, wie die Dynamik des Netzwerks in Wirklichkeit aussieht. Denn während es jedem Arbeitgeber offen steht, direkte Kanäle zu seinen Mitarbeitern zu öffnen und zu pflegen, sieht eine realitätsnähere Darstellung des Netzwerks rund um den Anwendungsfall eher so aus:
In der Realität öffnen Teilnehmer nicht ausschließlich direkte Kanäle zueinander, sondern profitieren von einer zentralen Funktionalität des Lightning Netzwerks: Routing. Routing bedeutet, dass die Zahlung zwischen zwei Parteien nicht über einen direkten Kanal zwischen diesen abgewickelt wird, sondern über die Kanäle von einer Vielzahl von anderen Nodes die zwischen den beiden liegen. Routing erlaubt es LN Teilnehmern nicht nur jemanden zu erreichen, der nicht direkt mit ihnen verbunden ist, sondern ist auch relevant für die Verteilung der Liquidität im Netzwerk.
Nehmen wir als Beispiel einen Arbeitnehmer, der sein Gehalt von seinem Arbeitgeber erhält und einen Großteil davon über die Zeit in einem Supermarkt ausgibt. Würden für diese Transaktionen ausschließlich direkte Kanäle verwendet werden, würde sich die Liquidität tatsächlich immer auf einer Seite des Kanals sammeln. Aber in der Realität hat der Arbeitnehmer vielleicht lediglich einen Kanal mit einem lokalen Routing Node und dieser Node hat wiederum einen Kanal mit dem Arbeitgeber, dessen Kunden und dem Supermarkt. Über den einen Kanal des Arbeitgebers fließen nun also sowohl Einnahmen als aus Ausgaben und die Liquidität verteilt sich immer wieder und entspricht eher einem Kontostand, der sich am Anfang des Monats füllt und dann mit der Zeit weniger wird. Ähnlich sieht es für den Arbeitgeber aus. Auch dieser hat einen Kanal mit dem Routing Node, über den er das Gehalt an seinen Arbeitnehmer zahlt, aber auch Einnahmen aus Richtung des Kunden erhält. Wie man sieht, ist Routing also essenziell für die Verteilung von Liquidität und darf bei der Betrachtung der Zahlungsflüsse auf keinen Fall außer Acht gelassen werden.
Das LN ist nicht kaputt, aber auch noch nicht perfekt
Das Scheitern des LN als „Fakt“ oder „Tatsache“ darzustellen, wie es manche Kritiker tun, ist völlig unangebracht. Wie in den Abschnitten oben beschrieben ist die Zukunft des Lightning Netzwerks längst nicht so düster wie so mancher einer beschreibt. Das bedeutet aber nicht, dass das Projekt bereits abgeschlossen wäre. Es gibt viele Dinge, die weltweit hunderte Entwickler und Builder tagtäglich beschäftigen und selbstredend gibt es imaginäre Probleme, die sich unter Umständen in der Zukunft manifestieren könnten. Ich persönlich denke aber, und das hat auch die Erfindung und Implementierung von Lightning selbst gezeigt, dass wir Probleme am ehesten effektiv lösen, wenn sie tatsächlich existieren. Sich rechtzeitig Gedanken zu machen und nicht blind in die Zukunft zu gehen ist wichtig, aber mehr eben auch nicht. Der bekannte Entwickler John Carvalho hat vor Kurzem gesagt:
"Bitcoin Core sollte die Aufgabe haben, die Probleme zu lösen, die wir heute haben und nicht die Probleme, die wir uns ausmalen, und zwar auf eine Art und Weise, die keine Probleme für die bestehenden Nutzer schafft."
John Carvalho
Und während er sich dabei auf Bitcoin Core bezieht, bin ich der festen Überzeugung, dass dasselbe auch für das Lightning Netzwerk gilt.
Unser heutiger Gastautor "Egge" ist Gründer und CEO von Starbackr, einem sozialen Netzwerk, welches auf dem Lightning-Netzwerk basiert. Auch Blocktrainer.de ist natürlich bei Starbackr vertreten. Schaut dort gerne mal vorbei.
