Wir alle wissen, die Bitcoin-Blockchain ist eine begrenzte Ressource (und das ist auch wichtig und notwendig zur Erhaltung der Dezentralität von Bitcoin). Um Bitcoin als Zahlungsmittel für den gesamten Planeten zu skalieren, ist daher eine Lösung auf Layer 2 zur Übertragung von Bitcoin unumgänglich.
Zum Glück haben wir ja bereits das Jahr 2023 und es hat sich schon Vieles getan. Wir haben mittlerweile Lightning produktiv auf dem Bitcoin Main Net. Die Technologie entwickelt sich rasant weiter - neue, coole Features kommen laufend hinzu (multipath payments, Hold-Invoices, LN-URL, Bolt12, etc.) und Lightning-Payments funktionieren mit dem Wachsen des Netzwerks mit jedem Tag reibungsloser und verlässlicher.
Aber es gibt natürlich immer Verbesserungspotential:
In der aktuellen Adoptionsphase von Lightning (so ehrlich muss man sein) kann man bei weitem noch nicht überall mit Lightning zahlen, wo bereits Bitcoin akzeptiert wird. Immer wieder kommt man in eine Situation, in der man dennoch On-Chain Bitcoin-Transaktionen durchführen muss (oder möchte).
Wenn man als User nun seine Bitcoin in einer Lightning Wallet aufbewahrt, ist es manchmal schwierig oder umständlich, mit dieser Wallet eine On-Chain Zahlung durchzuführen. Es gibt zwar mittlerweile Services wie Lightning Loop (oder entsprechende ähnliche Services, die von Wallet Anbietern bereitgestellt werden), die einen Atomic Swap zwischen Lightning und On-Chain ermöglichen. Das bedeutet einfach, man sendet einem Swap-Partner (Lightning Loop Betreiber oder Wallet-Anbieter) Bitcoin via Lightning und dieser sendet atomic (also gleichzeitig und unwiderruflich) eine Bitcoin-Transaktion On-Chain an das gewünschte Ziel.
Damit kann man zwar aus einer Lightning Wallet heraus On-Chain Zahlungen durchführen (die Phoenix-Wallet macht das zum Beispiel im Hintergrund so), aber man ist auf einen Peer angewiesen (auch wenn man diesem nicht vertrauen muss) und es fallen zumeist Gebühren für den Service an, sodass so eine Zahlung immer etwas teurer ist, als eine “normale” On-Chain Transaktion.
Diese gefühlte Trennung der Guthaben in einer Wallet zwischen On-Chain und Lighting ist daher immer noch eine große Hürde, die auch konzeptionell neuen Usern schwer vermittelbar ist.
Man stelle sich vor, man startet als Lightning Routing-Betreiber (dies geht ja mittlerweile dank Projekten wie Raspiblitz, Umbrel, myNode etc. immer einfacher). Man macht mit ein gewissem Guthaben ein paar Channels auf, etabliert sich als Routing Node, öffnet ein paar weitere Channels, wächst langsam rein, macht größere Channels auf, und plötzlich hat man ein paar alte Channels, die schon lange online sind, aber die im Laufe der Zeit zu “klein” geworden sind, weil vielleicht mittlerweile mehr Lightning-Routing-Traffic durch die eigene Node geht, oder man mehr Liquidität fürs Routing bereitstellen möchte.
Ja, natürlich kann man jetzt einfach einen zweiten zusätzlichen Channel zum selben Peer aufmachen. Aber man hat dann zwei Channels, die auch zwei separate closing transactions brauchen und so weiter. Ginge das nicht besser?
Kurz gesagt: Doch, das geht besser!
Splicing: engl. für “verbinden”, “kleben”, den Begriff kennt man auch in der Welt der Netzwerkverkabelung, das Verbinden zweier Glasfaser-Enden nennt man ebenfalls “splicing”).
Vereinfacht gesprochen ist ein einzelner Lightning Channel nichts anderes als eine 2-von-2 Multi-Sig Wallet-Adresse zwischen 2 Partnern, in der eine bestimmte Anzahl an BTC liegen. Diese Funds auf dieser Adresse sind auf der Blockchain sozusagen eingesperrt. Das ist die “funding transaction” (und diese Transaktion muss mindestens drei Bestätigungen auf der Blockchain haben).
Die beiden Peers erzeugen danach gemeinsam (weil ja 2-von-2 Multisig, deswegen müssen immer beide mit-signieren) immer wieder neue Child-Transaktionen, in denen sie einen bestimmten Teil des Guthabens an den einen Partner und den Rest an den anderen Partner auszahlen würden (falls es zu einer Closing-Transaktion käme).
Diese Transaktion landet aber vorerst nicht auf der Blockchain, sondern wird laufend ersetzt durch neuere Versionen, wo die Aufteilung der Funds (“welcher Teil gehört dem Einen und welcher dem Anderen”) entsprechend angepasst wird, wenn satoshis durch den Channel fließen. (Zum einfacheren Verständnis habe ich hier bewusst ein paar komplexere Details, wie zb. das Widerrufen alter Channel-States, weggelassen).
Am Ende des Lebenszyklus eines Channels wird einfach eine finale Transaktion auf der Blockchain gebroadcastet, die genau die Funds in der 2-von-2 Wallet entsprechend dem letzten “Aufteilungs-Stand” im Channel, an die beiden Partner sendet. Das ist die “closing transaction”.
Die Idee beim Channel Splicing ist nun – vereinfacht gesprochen – das Schließen eines bestehenden Channels und das Öffnen eines neuen Channels in einer einzelnen Transaktion durchzuführen, oder anders gesprochen: die “funding transaction” eines Channels durch eine neue Transaktion zu ersetzen.
Dadurch, dass die neue Transaktion auf der alten Funding-Transaktion aufbaut, könnte man dies auch so gestalten, dass man nicht 3 Bestätigungen abwarten muss. In diesem Fall ist das Vertrauen auf eine 0-conf Transaktion sicher, da gewährleistet ist, dass es keinen Double-Spend geben kann. Da die alte Funding-Transaktion eine 2-von-2 MultiSig Adresse ist, kann jeder der beiden Partner sicher sein, dass der jeweils Andere ohne Zutun des Partners keine Double-Spend-Transaktion erstellen kann. Und sollte die neue Transaktion nie oder erst sehr spät bestätigt werden, werden in der Zwischenzeit alle auflaufenden Routing HTLCs einfach auf beiden Funding-Transaktionen parallel aufgebaut.
Nun denn, wie man sieht sehr viel:
Diese Eigenschaften (keine Downtime des Channels, Entfernen oder Hinzufügen von Funds in einem Channel mit nur einer Transaktion) bieten eine Lösung für beide zu Beginn dargestellten Problemstellungen.
Aktuell ist Channel Splicing noch nicht im Protokoll (den sog. Lightning BOLTs) spezifiziert, das heißt im Moment ist Channel Splicing noch nicht möglich und in keiner Lightning-Implementierung vorhanden. Die oben genannte Phoenix-Wallet steht jedoch kurz vor einem entsprechenden Update.
Bereits 2018 wurden auf der Lightning-Dev Mailingliste erste Vorschläge diskutiert (siehe diesen Beitrag von Rusty Russel vom c-lightning Team und diesen Optimierungsvorschlag von René Pickhardt).
Allerdings wurde das Thema danach zugunsten anderer, damals ebenso noch nicht implementierter Themen (zb. Multipath Payments, flexiblere Datenstruktur im Onion Routing - Stichwort “TLV”, keysend, etc.) immer wieder zurückgestellt.
Im Frühjahr 2021 hat Rusty Russel allerdings einen konkreten Entwurf als Pull-request (Änderungsvorschlag) für die Spezifikation begonnen (siehe hier), der seitdem regelmäßig unter den Entwicklern der verschiedenen Lightning Implementierungen diskutiert wird.
Lightning ist großartig, aber wir dürfen nicht vergessen, dass es immer noch in den Kinderschuhen steckt. Auch wenn das Netzwerk laufend (und rasant) wächst, gibt es noch viele Ideen und technische Verbesserungen, die einfach aus Zeitmangel noch nicht umgesetzt sind.
Also wenn Lightning heute noch nicht perfekt ist, habt etwas Nachsicht und Zuversicht. Die Entwickler-Community arbeitet daran. Ideen gibt es genug in der Pipeline.
Let’s build the money of the future. :-)
Vielen Dank für's Lesen meines Beitrags zu diesem Thema und bis zum nächsten mal - euer Johnny.
