Ca y est !: L’équipe de c-lightning, est heureuse d’annoncer la sortie de la version 0.6 de c-lightning, un jalon important du projet. Il s’agit d’une réécriture complète de l’implémentation précédente, la première version de c-lightning totalement conforme aux spécifications. Cette nouvelle version s’éloigne du protocole utilisé pendant la définition des spécifications et évolue vers une nouvelle architecture modulaire et extensible, afin de s’adapter à vos besoins et vos infrastructures.
Statistiques sur la croissance du Lightning Network
Aujourd’hui est aussi un jour important pour la croissance et le développement du Lightning Network : les trois implémentations de Lightning (Eclair, lnd, et c-lightning) sont désormais toutes en version beta ! Depuis la présentation du Blockstream Store en janvier, le réseau Lightning a énormément grandi. Au moment où le Blockstream Store a été annoncé, le réseau Lightning était composé de 46 canaux de paiement ouverts représentant une capacité totale de 0.682 BTC. Aujourd’hui, il y a environ 7 800 canaux de paiement ouverts avec 26 BTC de capacité. Cela représente une augmentation de 16 856% du nombre de canaux et de 4 084% de la capacité en 6 mois !
Nouvelles fonctionnalités
Même si les nouvelles fonctionnalités de la version 0.6 sont trop nombreuses pour être détaillées ici, les fonctionnalités suivantes sont les plus intéressantes et celles qui ont le plus d’impact :
- Nœuds légers : les versions précédentes nécessitaient un nœud bitcoind en plus de c-lightning afin de fournir l’accès au réseau Bitcoin. Cette version nécessite toujours l’utilitaire bitcoin-cli, mais il peut désormais communiquer avec des nœuds à distance, y compris des nœuds légers comme spruned. Cela permet d’exécuter un nœud c-lightning sur un Raspberry Pi ou d’autres appareils à faible consommation d’énergie.
- Le protocole de gossip (ndt : échange entre nœuds des informations relatives au reste du réseau) a été amélioré pour rendre le mécanisme moins gourmand en bande-passante et demander des informations précises au lieu d’échanger des vues exhaustives du réseau comme le faisait la version précédente. Cela est particulièrement important pour les appareils à faible consommation d’énergie et les appareils mobiles, qui consommeraient autrement beaucoup d’énergie et de bande-passante pour télécharger et vérifier des informations dont ils disposent déjà.
- Stabilité de l’API : l’interface JSON-RPC de c-lightning et les bibliothèques logicielles ont été repensées afin de minimiser les changements dans les futures versions. Cette stabilité de l'API devrait permettre à d'autres projets de s'appuyer sur c-lightning, car nous la maintiendrons dans un avenir prévisible, et serons attentif à la rétrocompatibilité si elle devait évoluer.
- Portefeuille et synchronisation : c-lightning inclut désormais un portefeuille complet pour gérer à la fois les fonds on-chain et off-chain. Il n’est désormais plus nécessaire de manipuler des transactions brutes ! Tous les fonds sont suivis automatiquement et renvoyés dans le portefeuille interne aussitôt que possible, sans requérir d’intervention de l’utilisateur. En plus de ça, le suivi de la blockchain génère une vue interne de la blockchain, il n’est donc plus nécessaire d’effectuer de longs rescans.
- Support de TOR : c-lightning permet désormais de se connecter à d’autres nœuds sur le réseau TOR, en s’enregistrant automatiquement comme un hidden service, et d’accepter des connexions entrantes sur TOR.
- La logique de paiement a subi un remaniement majeur, et effectue automatiquement de nouvelles tentatives en cas d’échec de routage, elle choisit aléatoirement sa route, et fournit davantage d’informations sur l’état actuel d’un paiement.
- Et comme toujours : performances, performances, performances.
Flexibilité par la modularité
L’architecture de c-lightning est basée sur un certain nombre de processus indépendants qui communiquent entre eux, chacun avec ses propres responsabilités. Cela permet une meilleure intégration dans votre infrastructure et une meilleure adaptation à vos besoins. Deux daemons utilisés pour tous les canaux, gossipd et hsmd, se distinguent par leur design modulaire.
Gossipd gère la vue locale sur le réseau et est chargé de trouver une route depuis la source d’un paiement jusqu’à son destinataire. L’implémentation par défaut va tenter de trouver une route qui représente un compromis raisonnable entre les frais, les délais, et la stabilité. Elle va également brouiller la route suivie en sélectionnant aléatoirement un certain nombre d'itinéraires candidats
et en modifiant légèrement les montants et les délais afin de dissimuler la destination du paiement. Cette implémentation par défaut peut facilement être désactivée si vous avez des besoins particuliers en matière de routage ou souhaitez appliquer une politique de routage spécifique, comme sélectionner la route avec les délais ou les frais les plus bas.
Hsmd gère toutes les opérations qui concernent les matériaux cryptographiques et contrôlent les fonds dans les canaux. C’est le seul sous-système qui a accès à la clé privée du noeud. Cela signifie que les autres sous-systèmes ne détiennent aucune information privée et doivent communiquer avec le daemon hsmd pour signer ou déchiffrer quoi que ce soit. Centraliser les opérations cryptographiques de la sorte réduit la surface à sécuriser et offre des possibilités d’applications intéressantes. Tandis que l’implémentation par défaut de hsmd fournit déjà une bonne sécurité en séparant les processus et permet de le sécuriser encore davantage au niveau de l’OS, par exemple SELinux et AppArmor, elle peut être facilement remplacée par une implémentation qui communique avec un HSM physique. Remplacer l’implémentation hsmd permet d’effectuer des opérations en l’absence d’interface graphique, par exemple d’exécuter un noeud c-lightning chez soi, et d’y coupler une application mobile pour gérer les clés privées et initialiser les paiements ou générer les factures.
Cette séparation des fonctionnalités de c-lightning entre plusieurs daemons n’est pas seulement plus flexible, mais est aussi une grosse amélioration de la sécurité d’un noeud, car elle garantit qu’un attaquant ne pourra pas interagir directement avec la gestion des clés privées. Chaque sous-système vérifie indépendamment la cohérence des états internes, et déconnecte un pair ou met fin à un processus s’il détecte un fonctionnement anormal. L’architecture multi-daemon permet aussi l’utilisation de Docker, SELinux et AppArmor afin de verrouiller les informations accessibles à chaque daemon et les actions qu’ils peuvent effectuer.
Et ensuite ?
Notre travail sur c-lightning est loin d’être terminé, nous travaillons constamment sur des fonctionnalités et des améliorations, ainsi qu’à l’optimisation des performances, de la stabilité et de l’utilisabilité. Vous n’avez pas trouvé votre fonctionnalité favorite ? Vous avez quelques remarques que vous pensez utiles ? Pourquoi ne pas ouvrir un ticket sur Github, nous laisser un mot sur la mailing list, ou nous contacter sur IRC ?
Parallèlement, nous contribuons également à l’avancement des spécifications Lightning, et nous recherchons activement à quoi la prochaine itération de protocole pourrait ressembler à travers des initiatives comme la proposition eltoo et des propositions faites sur Bitcoin comme SIGHASH_NOINPUT.
Nous souhaitons remercier les nombreux contributeurs qui n’ont pas seulement écrit du code pour c-lightning, mais ont aussi été suffisamment #reckless pour le tester et nous fournir un feedback sur ce qui marche et ce qui pouvait être améliorer. Enfin, nous voudrions remercier les autres équipes Lightning Network, ACINQ et Lightning Labs, ainsi que tous les contributeurs individuels qui ont mis du leur pour faire de la communauté Lightning Network un environnement si plaisant, collaboratif et ouvert !