Nach drei Monaten und 418 Commits von 36 Mitwirkenden freuen wir uns, die Veröffentlichung von Core Lightning v24.02 bekannt zu geben. Obwohl es sich hauptsächlich um eine Wartungsversion handelt, gibt es zahlreiche kleinere Änderungen, die Nodebetreiber schätzen werden, sowie einige Verbesserungen unter der Haube, die es für Benutzer einfacher und kostengünstiger machen, CLN zu betreiben.
Im Folgenden geben wir einen kurzen Überblick über Dual Funding, das endlich den Vorschlagsstatus verlassen hat und nun Teil der Spezifikation ist. Anschließend werden wir kurz die größten Funktionen und Optimierungen in dieser Version vorstellen.
Hinweis: Diese Version enthält einen Fix für einen Absturzfehler, der im Testnet auftreten kann. Wenn Sie CLN im Testnet verwenden, aktualisieren Sie bitte so schnell wie möglich.
Dual Funding ist nun weit verbreitet verfügbar
Lisa Neigut veröffentlichte den ersten Entwurf für Dual Funding bereits im Jahr 2017 (einer turbulenten Zeit), und seitdem hat es mehrere Iterationen durchlaufen. Nach Jahren der Feinabstimmung und Sicherung gegen Missbrauch wurde der Vorschlag schließlich in die Lightning-Spezifikation aufgenommen.
Dies ist ein unglaublicher Fortschritt für das Netzwerk insgesamt und für CLN und Eclair, die beide nun Dual Funding unterstützen. Dual Funding ermöglicht es Nodes, ihre Liquidität besser zu nutzen, ohne dass ein zweiter Kanal geöffnet werden muss, um Mittel zu einem Kanal hinzuzufügen. Es ist auch viel robuster gegen fehlverhaltende Teilnehmer als andere Protokolle zum Öffnen von ausgeglichenen Kanälen: Andere Protokolle erlauben oft einer Partei, mit den Geldern zu entkommen. Im Gegensatz dazu führen bei Dual Funding alle Parteien, die Mittel beitragen, ein Coinjoin-Protokoll durch, bei dem die Finanzierungstransaktion gemeinsam erstellt wird, ohne dass das Eigentum auch nur vorübergehend delegiert wird. Dies bedeutet, dass jede Partei die volle und ausschließliche Kontrolle über ihre Mittel behält, bis der Kanal vollständig erstellt ist, wodurch die Vertrauensanforderungen anderer Protokolle entfallen.
How Does the Lightning Spec Work?
An dieser Stelle möchten wir unseren Freunden bei ACINQ dafür danken, dass sie mit uns an dem Vorschlag gearbeitet und die zweite Implementierung des Vorschlags bereitgestellt haben, was uns letztendlich den Fortschritt ermöglichte. Zur Erinnerung: Die Anforderung von zwei Implementierungen soll sicherstellen, dass der Spezifikationsvorschlag alle notwendigen Informationen zur Implementierung enthält und dass der Vorschlag für mehr als eine Implementierung funktioniert. Angesichts der sehr unterschiedlichen Benutzerbasis, die CLN und ACINQs Produkte haben, war es eine sehr schöne Bestätigung, dass der Vorschlag Probleme für eine Reihe von Anwendungsfällen löst.
Aber die Reise ist noch nicht ganz vorbei. Teil der Dual-Funding-Spezifikation ist auch das interactive-tx-Subprotokoll, das zufällig auch die aktivierende Funktion für Splicing ist. Bleiben Sie also dran für weitere spannende Features, die in Kürze kommen.
Neues Wiederherstellungs-Plugin
Softwarefehler und Hardwareprobleme sind in der realen Welt unvermeidlich, daher ist es uns wichtig, die negativen Folgen so weit wie möglich abzumildern. Mit den Echtzeit-Backup-Funktionen, die wir vor ein paar Jahren eingeführt haben, haben wir ein System, das es ermöglicht, einen Knoten ohne betriebliche Auswirkungen außer einer kurzen Ausfallzeit wiederherzustellen. Die Echtzeit-Backups können jedoch etwas umständlich einzurichten sein, da sie normalerweise einen sekundären Speicherort zum Schreiben und eine regelmäßige Kompression der Backups erfordern.
Aditya Sharma setzte seine frühere Arbeit fort und baute ein Notfall-Wiederherstellungssystem, ähnlich wie die statischen Kanal-Backups (SCB) in anderen Implementierungen. Das statische Kanal-Backup und unser Notfall-Wiederherstellungssystem bestehen beide aus einer kleinen Datei, die Metadaten über die geöffneten Kanäle enthält. Im Falle eines Datenverlusts können wir diese Datei nehmen, in Kanal-Stubs expandieren und beginnen, uns mit Peers zu verbinden, in der Hoffnung, sie zu bitten, in unserem Namen zu schließen, damit wir dann die Mittel aus dem Abschluss auffangen können. Dies kann entweder als Ergänzung zu den Echtzeit-Backups oder als letzter Ausweg verwendet werden, falls Sie das Backup nicht konfiguriert haben.
Das neue Release fügt das Wiederherstellungs-Plugin hinzu. Wo Sie zuvor den Wiederherstellungsprozess verstehen und manuell durchlaufen mussten, übernimmt das neue Plugin die meisten Schritte des Prozesses. Dies bedeutet, dass die Wiederherstellung jetzt viel zuverlässiger geworden ist. Unterschätzen Sie nicht, wie wichtig Zuverlässigkeit und Benutzerfreundlichkeit in diesem Fall sind, besonders in einer Situation, in der Ihr System gerade abgestürzt ist und Sie versuchen, Ihre Mittel wiederherzustellen.
Leistungs- und Stabilitätsverbesserungen
Wie bei jeder Veröffentlichung enthält auch diese eine große Anzahl von Optimierungen, und obwohl wir nicht jede einzelne hervorheben können, gibt es einige allgemeine Themen, die wir hier erwähnen möchten.
Zum Beispiel wurde die Geschwindigkeit, mit der wir Blöcke verarbeiten, dank einiger Optimierungen im Bearbeitungscode um über 50 % erhöht. Dies bedeutet, dass es weniger Zeit dauert, bis Ihr Knoten nach einem Shutdown mit der Blockchain wieder aufgeholt hat.
Eine umfangreiche Überarbeitung der Art und Weise, wie Gossip behandelt wird, führte dazu, dass der Gossip in öffentliche und private unterteilt wurde und der private Gossip nicht mehr im Gossip-Store gespeichert wird. Dies bedeutet, dass die Gossip-Store-Datei nun zwischen mehreren Knoten geteilt werden kann und Sie auch eine bereitstellen können, wenn Sie einen neuen Knoten starten, was die erneute Verifizierung vermeidet und es Ihnen ermöglicht, Knoten viel schneller bereitzustellen.
Upgrade auf die neueste CLN-Version
Unter all den oben erwähnten Änderungen, Funktionen und Optimierungen enthält diese Version auch eine Lösung für ein Problem im Testnet. Das Problem tritt auf, weil libwally versucht, einige Relay-Richtlinien durchzusetzen, wenn ein Block geprüft wird, der diese Richtlinien nicht einhalten muss. Eine größere als erlaubte Transaktion im Block 2578284 führte dazu, dass libwally die Transaktion und dann den Block fälschlicherweise ablehnte. Wenn Sie CLN im Testnet verwenden, aktualisieren Sie bitte so schnell wie möglich auf v24.02. Bitcoin Mainnet ist nicht betroffen.
Zusätzlich zum Testnet-Fix gibt es auch einen kleinen Fix in elementsd und in Bezug auf Liquid-Unterstützung, bei dem wir möglicherweise einen Peg-In nicht korrekt analysieren konnten, was dazu führte, dass der Knoten beim Versuch, die Transaktion zu analysieren, stecken blieb.
Um auf die neueste Version von CLN zu aktualisieren, besuchen Sie die Release-Seite, oder wenn Sie sich für die Feinheiten interessieren, schauen Sie sich das Änderungsprotokoll an und sagen Sie uns, was Ihnen gefällt oder was wir verbessern könnten.
Und wie immer ein großes Dankeschön an die vielen Mitwirkenden und Freiwilligen, die uns weiterhin helfen, CLN im Laufe der Zeit zu verbessern. Wir sind dankbar für Ihre Beiträge und freuen uns darauf, weiterhin mit Ihnen zusammenzuarbeiten, um Lightning zu entwickeln.