Bekanntgabe von c-lightning 0.6
Lightning Network

Bekanntgabe von c-lightning 0.6

Christian Decker
Christian Decker, Rusty Russell

Das lange Warten hat ein Ende: Wir, das c-lightning Team geben mit Freude die Herausgabe von c-lightning Version 0.6 bekannt, ein Meilenstein für das Projekt. Diese komplett neugeschriebene Implementation ist die erste voll spezifizierungs-konforme Veröffentlichung von c-lightning. Es bewegt sich weg von dem Protokoll das benutzt wurde als die Spezifikation konzipiert wurde und hin zu einer neuen Architektur die modular und erweiterbar ist, um sich besser Ihren Bedürfnissen und Ihrer Infrastruktur anzupassen.

Lightning Netzwerk Wachstumsstatistiken

Heute ist auch ein besonderer Tag für dasWachstum und die Entwicklung des Lightning Netzwerks: Alle drei Lightning Implementationen (Eclair, lnd und c-lightning) sind nun in Beta! Seit der Einführung des Blockstream Shops im Januar ist das Lightning Netzwerk gewaltig gewachsen. Zur Zeit der Bekanntgabe des Blockstream Shops hatte das Lightning Netzwerk insgesamt 46 offene Kanäle und 0.682 BTC Kapazität. Heute sind es ungefähr 7.800 offene Kanäle mit 26 BTC Kapazität. Das ist eine Steigerung von 16.856% in Kanälen und eine Steigerung von 4.084% in Kapazität in 6 Monaten!

Neue Features

Während es viele neue Features in der 0.6 Veröffentlichungsliste gibt, sind die folgenden die Interessantesten und Eindrucksvollsten:

  • Leichtgewichtige Nodes: Vorherige Veröffentlichungen machten es nötig eine volle Bitcoind Node neben c-lightning laufen zu lassen um Zugang zum Bitcoin Netzwerk zu bekommen. Diese Veröffentlichung benötigt immer noch das Bitcoin-cli Dienstprogramm, aber es kann nun auch mit entfernten Nodes kommunizieren, inklusive einigen Leichtgewicht Nodes wie spruned. Dies macht es möglich, c-lightning auf einem Raspberry Pi oder anderen schwachen Geräten laufen zu lassen.
  • Das Gossip Protokoll wurde um einen Bandbreite-sparsamen Mechanismus aktualisiert, der spezifische Informationen nachfragt anstatt die volle Netzwerk-Sicht auszutauschen. Dies ist besonders wichtig für schwache und mobile Geräte die anderweitig viel Bandbreite und Energie aufwenden müssten, um Informationen herunterzuladen und zu verifizieren die sie bereits besitzen.
  • API Stabilität: Die c-lightning JSON-RPC Nahtstelle und unterstützende Programmbibliotheken wurden neu entworfen um Änderungen in neuen Veröffentlichungen zu minimieren. Diese API Stabilität sollte es anderen Projekten einfach machen, auf c-lightning aufzubauen, da wir diese Version der API in der absehbaren Zukunft unterstützen werden und Rückwärtskompatibilität beibehalten, sollten wir Änderungen durchführen.
  • Wallet und Synchronisierung: C-lightning inkludiert nun eine vollwertige Wallet die sowohl on-chain als auch off-chain Mittel verwaltet. Es gibt keine Handhabung roher Transaktionen mehr! Alle Mittel werden automatisch verfolgt und so schnell wie möglich in die interne Wallet zurückgesandt, ohne dass der Nutzer eingreifen muss. Zusätzlich enthält die Blockchain Verfolgung nun eine interne Sicht auf die Blockchain, was lange Blockchain Neu-Durchsuchungen unnötig macht.
  • TOR Unterstuetzung: C-lightning unterstützt nun Nodes über das TOR Netzwerk zu verbinden, das automatische Registrieren als Hidden Service und das Akzeptieren von eingehenden Verbindungen über TOR.
  • Die Zahlungslogik wurde grundüberholt um automatische Neuversuche von Routingversagen zu unterstützen, zufällige Routenselektion und bessere Rückmeldung über den aktuellen Stand einer Zahlung.
  • Und wie immer: Leistung, Leistung, Leistung

Flexibility durch Modularität

Die c-lightning Architektur basiert auf einer Anzahl unabhängiger Kommunikationsprozesse, jede mit ihren eigenen Verantwortungen. Dies erlaubt bessere Integration in Ihre Infrastruktur und bessere Anpassung an Ihre Bedürfnisse. Zwei Dämonen die global für alle Kanäle sind, gossipd und hsmd, sind besonders durch ihre modulare Planung von Interesse.

Gossipd verwaltet die lokale Sicht auf das Netzwerk und ist damit beauftragt, einen Pfad von der Quelle einer Zahlung zu ihrem Ziel zu finden. Die Voreinstellung versucht eine Route mit einer vernünftigen Abwägung zwischen Gebühren, Auszeit und Stabilität zu finden. Sie verschleiert auch die Route indem sie willkürlich eine Anzahl Kandidaten auswählt und die Beiträge und Auszeiten leicht verändert um die Endpunkte der Zahlung zu verbergen. Die Voreinstellung kann leicht ausgewechselt werden sollten Sie bestimmte Routing Bedürfnisse haben oder eine bestimmte Routing Strategie verfolgen, beispielsweise immer die Route wählen die die geringsten Auszeiten und Gebühren hat.

Hsmd verwaltet alle Operationen, die kryptographisches Material berührt und kontrolliert die Mittel im Kanal. Es ist das einzige Subsystem, das Zugang zum privaten Schlüssel einer Node hat. Dies bedeutet, dass andere Subsysteme keine privaten Informationen halten und mit dem hsmd Dämon kommunizieren müssen um etwas zu signieren oder zu entschlüsseln. Die kryptographischen Arbeitsabläufe so zu zentralisieren reduziert die Oberfläche die geschützt werden muss und öffnet eine Anzahl interessanter Anwendungen. Während die voreingestellte hsmd Implementation bereits gute Sicherheit durch Systemtrennung bereitet sowie die Möglichkeit bietet, sich weiter über das Betriebssystem, z.B. SELinux und AppArmour abzusichern, kann es einfach mit einer Implementation ersetzt werden die mit einer physischen HSM kommuniziert.

Die hsmd Implementation weiter zu ersetzen erlaubt den Betrieb in ‘headlesss’ Modus, z.B. den Betrieb einer c-lightning Node zu Hause mit einer gekuppelten Mobilen App welche die privaten Schlüssel verwaltet und Zahlungen initiiert oder Rechnungen stellt.

Die Aufteilung der c-lightning Funktionalität in mehrere Dämonen ist nicht nur eine große Verbesserung für Flexibilität sondern auch eine solide Verbesserung der Node Sicherheit, da sie gewährleistet, dass ein Angreifer nicht direkt mit etwas interagieren kann was private Schlüssel berührt. Jedes Subsystem verifiziert unabhängig voneinander die Konsistenz seines internen Status und entkoppelt sich von einem Prozess sollte eine Inkonsistenz gefunden werden. Die Multi-Dämonen Architektur erlaubt auch die Nutzung von Docker, SELinux und AppArmor und verschließt auf welche Informationen jeder Dämon zugreifen kann und welche Aktionen er ausführen kann.

Was kommt als nächstes?

Unsere Arbeit mit c-lightning ist noch lange nicht beendet. Wir arbeiten konstant an Features und Verbesserungen ebenso wie Fortschritte in Leistung, Stabilität und Benutzbarkeit. Sie haben Ihr Lieblings Feature nicht gefunden? Legen Sie doch ein Issue bei Github an, schreiben Sie uns auf unserer Mailing Liste oder kontaktieren Sie uns über IRC.

Parallel dazu wirken wir auch am Fortschritt der Lightning Spezifizierung selbst bei und forschen aktiv wie der nächste Schritt des Protokolls aussehen könnte, wie durch Initiativen wie unseren eltoo Vorschlag und vorgelagerte Bitcoin Vorschläge wie SIGHASH_NOINPUT.

Wir möchten den vielen Beitragenden danken, nicht nur denen die Kode zu c-lightning beigetragen haben, sondern auch all denen, die #Reckless genug waren zu testen und Rückmeldung zu geben darüber was funktioniert und was verbessert werden könnte. Abschließend möchten wir den anderen Lightning Netzwerk Teams, ACIQ und Lightning Labs als auch allen individuellen Beitragenden danken die eingesprungen sind um die Lightning Netzwerk Gemeinschaft in eine angenehme, kollaborative und offene Umwelt zu verwandeln!

If you have specific preferences, please, mark the topic(s) you would like to read: