Het wachten is voorbij: wij, het team van c-lightning, hebben eindelijk c-lightning 0.6 uitgebracht. Dit is een belangrijke mijlpaal voor het project. De vorige implementatie is geheel herschreven, en dit is de eerste release van c-lightning die de specificatie volledig volgt. Deze implementatie migreert weg van het huidige protocol, richting een nieuwe architectuur die modulair en uitbreidbaar is om het beter aan te kunnen passen op de benodigdheden en infrastructuur van de gebruiker.
Statistieken over de groei van het Lightning Network
Vandaag is tevens een belangrijke dag voor de groei en ontwikkeling van het Lightning Network: alle drie de Lightning-implementaties (Eclair, lnd, en c-lightning) zijn nu in de bètafase beland! Sinds de introductie van de Blockstream Shop in januari, is het Lightning Network flink gegroeid. Toen we de Blockstream Shop aankondigden, had het Lightning Network in totaal 46 open kanalen (channels) en 0,682 BTC aan capaciteit. Vandaag zijn er ruim 7800 open kanalen met 26 BTC aan capaciteit. Dat is een toename van 16.856% kanalen en 4084% capaciteit in 6 maanden!
Nieuwe functies
Hoewel er te veel nieuwe functies in versie 0.6 zitten om op te noemen, zijn de volgende functies zeker het benoemen waard:
● Lichtgewicht nodes: Voorgaande versies hadden naast c-lightning een bitcoind full node nodig om toegang tot het bitcoin-netwerk te verlenen. Deze release vereist nog steeds de bitcoin-cli utility, maar het kan nu ook op afstand met nodes communiceren, en dus ook met lichtgewicht nodes zoals spruned. Dit maakt het mogelijk om c-lightning te draaien op een Raspberry Pi en andere apparaten met laag energieverbruik.
● Het gossip-protocol is bijgewerkt en gebruikt nu een bandbreedtebesparend mechanisme dat om specifieke informatie vraagt, in plaats van te vragen om het overzicht van het hele netwerk zoals voorheen. Dit is vooral belangrijk voor (mobiele) apparaten met laag energieverbruik, die anders een hoop bandbreedte en energie zouden verbruiken om reeds beschikbare informatie te downloaden en verifiëren.
● API-stabiliteit: De c-lightning JSON-RPC-interface en bijbehorende libraries zijn opnieuw ontworpen om zo toekomstige veranderingen minimaal te houden. Deze API-stabiliteit moet het makkelijker maken voor projecten om c-lightning te gebruiken, want we gaan deze versie van de API een lange tijd ondersteunen en backwards compatible houden, zelfs als we veranderingen aanbrengen.
● Wallet en synchronisatie: c-lightning bevat nu een volledige wallet die de balans zowel on-chain als off-chain bijhoudt. Transacties hoeven dus niet meer los te worden verwerkt! De balans wordt automatisch bijgehouden en zo snel mogelijk teruggebracht naar de interne wallet, zonder dat de gebruiker daar iets voor hoeft te doen. Bovendien hebben we dankzij "blockchain tracking" nu een intern beeld van de blockchain, waardoor lange rescans niet meer nodig zijn.
● TOR-ondersteuning: het is nu mogelijk voor c-lightning om met nodes via het TOR-netwerk te verbinden, automatisch te registreren als hidden service, en binnenkomende verbindingen te accepteren via TOR.
● De betalingslogica is flink aangepakt en ondersteunt nu automatisch nieuwe pogingen als een route faalt, kiest nu willekeurige routes, en geeft betere feedback over de huidige voortgang van de betaling.
● En, zoals altijd: performance, performance, performance.
Flexibiliteit via modulariteit
De architectuur van c-lightning is gebaseerd op een aantal onafhankelijk communicerende processen die elk hun eigen verantwoordelijkheid hebben. Dit zorgt voor betere integratie in de infrastructuur van de gebruiker en maakt het makkelijker om het naar behoefte aan te passen. Twee daemons die globaal staan voor alle kanalen, gossipd en hsmd, zijn vooral opvallend modulair in opzet.
gossipd heeft een lokaal beeld van het netwerk en zoekt een pad van de bron van de betaling tot de bestemming. De standaard implementatie probeert een route te vinden met de juiste balans tussen kosten, timeouts, en stabiliteit. De route wordt ook verborgen door willekeurig te kiezen tussen een aantal routes en de kosten en timeouts te variëren om zo de doelbestemming van een betaling te verbergen. De standaard implementatie kan makkelijk worden vervangen als de gebruiker bepaalde routevereisten heeft of een specifiek routebeleid wil garanderen, zoals het altijd kiezen voor de route met de kortste timeouts of laagste kosten.
hsmd beheert alle operaties die te maken hebben met cryptografisch materiaal en beheert de balans van het kanaal. Het is het enige subsysteem dat toegang heeft tot de privé-sleutel van de node. Dit betekent dat andere subsystemen geen privé-informatie bevatten en met de hsmd daemon moeten communiceren om berichten te ondertekenen of ontsleutelen. Door de cryptografische operaties op deze manier bij elkaar te houden, is het makkelijker om te beveiligen en maakt het de weg vrij voor interessante toepassingen. Hoewel de standaard implementatie van hsmd al goede beveiliging biedt door processen gescheiden te houden en het te beveiligen op het niveau van het besturingssyteem, zoals met SELinux en AppArmor, kan het ook makkelijk worden vervangen met een implementatie die communiceert met een fysieke HSM. Het vervangen van de implementatie van de hsmd maakt het tevens mogelijk om "headless" te opereren, zoals door thuis een c-lightning-node te hebben en deze te verbinden met een mobiele app die de privé-sleutels beheert en betalingen initieert of invoices (facturen) creëert.
Deze scheiding van functionaliteit in c-lightning in meerdere daemons is niet alleen een flinke verbetering voor de flexibiliteit, maar ook een verbetering voor de beveiliging van de node, want een aanvaller kan zo niet direct communiceren met de bewaarplek van de privé-sleutels. Elk subsysteem verifieert op zichzelf de consistentie van de interne staat, en de verbinding met een peer wordt verbroken als er een inconsistentie optreedt. De architectuur van multi-daemons maakt het ook mogelijk om Docker, SELinux, en AppArmor te gebruiken en de informatie die elke daemon kan bereiken en welke acties ze kunnen uitvoeren, te beperken.
Wat volgt
Ons werk voor c-lightning is absoluut nog niet klaar. We zijn constant bezig met nieuwe functies en verbeteringen, en werken ook aan performance, stabiliteit, en gebruiksvriendelijkheid. Is je favoriete functie afwezig? Heb je feedback die ons misschien kan helpen? Plaats dan een bericht op Github, meld het via de mailing list, of neem contact op via IRC.
We zijn tegelijk ook bezig om bij te dragen aan de specificatie van Lightning, en zijn actief aan het onderzoeken hoe de volgende iteratie van het protocol eruit zou kunnen zien via voorstellen zoals eltoo en mogelijke veranderingen voor bitcoin zoals SIGHASH_NOINPUT.
We willen graag alle betrokkenen bedanken: niet alleen de mensen die code hebben bijgedragen aan c-lightning, maar ook iedereen die #reckless (roekeloos) genoeg was om het te testen en feedback te geven over wat werkt en wat verbeterd kan worden. En ten slotte willen we de Lightning Network-teams ACINQ en Lightning Labs bedanken, en alle contribuerende individuen die de community van het Lightning Network zo prettig, samenwerkend en open hebben gemaakt!