Nous vous proposons ici – avec l’autorisation de l’auteur – une synthèse d’une série de réflexions et de conseils postés originellement par Fabrice Drouin (cofondateur et CTO d’ACINQ), sur le Slack de CryptoFR. Ces messages portent sur la meilleure façon de faire tourner un nœud Lightning quand on n’est ni développeur ni expert de Linux, en utilisant de préférence un serveur VPS bon marché.
Mon intention à travers ce post c’est simplement de dire quelle est pour moi la meilleure façon de faire (et celle qui permet le mieux de se former). Je suis néanmoins conscient que, étant donnée la tendance Umbrel/Raspiblitz d’un côté et LN-as-a-service de l’autre, mon opinion est clairement minoritaire. Le message que j’essaie de faire passer, ce n’est pas qu’il faut nécessairement faire tourner des noeuds LN chez AWS plutôt que chez soi, mais plutôt que les gens prennent un peu de recul et se focalisent plus sur leur objectif :
- S’agit-il d’apprendre comment fonctionne LN ? Pas besoin de mainnet pour ça ;
- S’agit-il simplement d’utiliser le réseau ? Il serait plus simple alors d’utiliser un wallet mobile non-custodial ;
- Veut-on “aider le réseau” ? Le fonctionnement de LN est très différent de celui de Bitcoin et multiplier les noeuds n’aide pas, quand ils ne sont pas fiables, c’est même le contraire ;
- Espère-t-on gagner de l’argent avec LN ? “Vous allez au devant de grosses déconvenues” (TM).
Pour nous [chez ACINQ], l’objectif est clair : faire de LN un réseau capable de prendre une part significative des paiements online/mobile dans les années qui viennent, sans sacrifier les aspects “privacy” et “custody”, et ça passe avant tout par la fiabilité (un réseau de paiement qui n’est pas * très * fiable ne sert à rien), c’est pour ça que je ne suis pas fan des solutions clef-en-main d’aujourd’hui.
Il y a aussi un aspect non technique mais crucial : la gestion de la capacité de routage. Un nœud qui n’opère qu’une poignée de channels à $5 ne sert à rien pour le routage, et il faut analyser la façon dont les balances évoluent pour re-générer de la capacité entrante ou sortante.
Bref, on ne peut pas simplement « YOLO » et ignorer la maintenance (liquidité et erreurs/fermetures de channels), car un nœud mal géré sera au final blacklisté par ses peers.
Mes préconisations
Du point de vue d’un opérateur, un nœud LN c’est un service assez classique, avec des problématiques classiques : déployer / configurer / mettre à jour / sauvegarder / surveiller / debugger. Il y a aussi quelques points spécifiques : les sauvegardes sont un peu délicates à implémenter, et ça gère de l’argent.
Je conseille d’utiliser de préférence un VPS pas cher plutôt qu’une machine hébergée chez soi. C’est nettement meilleur en ce qui concerne la sécurité. Il faudra évidemment sécuriser ce VPS :
- configurer SSH en mode « clef publique seulement »,
- désactiver l’accès root, etc.
- installer et configurer ufw pour ne laisser que le port SSH ouvert,
- installer et configurer fail2ban.
Il existe de nombreux guides pour ça. Ceux qui sont rédigés par les cloud providers (digital ocean, ovh, linode…) font l’affaire. Selon le fournisseur et le VPS utilisé il faudra en option ajouter un disque pour stocker les données du nœud Bitcoin. Là encore ça dépend des fournisseurs mais c’est ce qui risque de coûter le plus cher (et ça permet aussi de comprendre pourquoi le modèle des « Watch Towers » aujourd’hui n’est pas viable économiquement).
Pour la suite, je conseille de commencer en mode testnet, et, quand on est content du setup, de basculer éventuellement vers le mainnet :
- installer et configurer un noeud bitcoin,
- faire l’IBD (rapide sur testnet),
- installer et configurer un noeud LN (c-lightning, lnd, eclair). Attention, selon l’implémentation retenue la configuration Bitcoin peut être différente.
Premier point très important : le stockage des données et le backup
Il faut sauvegarder :
- des données statiques (par exemple les seed qui servent à générer les clefs privées des noeuds et des channels, a priori ce sera un ou deux petits fichiers) ;
- les données des channels et les données de paiement/audit. Par ordre de priorité, choisir si possible de stocker les données dans Postgres, ou dans sqlite si n’est pas possible ;
- réfléchir à une solution de backup, qui dépend de la base utilisée, de l’implémentation et du provider.
Quand faire le backup ? Dans le protocole les données doivent être sauvées quand on signe. Certaines implémentations fournissent un « hook » pour pouvoir appeler un script custom à ce moment.
Comment faire le backup ? Le mieux (et probablement le plus cher) c’est d’utiliser une base postgres fournie par le cloud provider.
Deuxième point important : vérifier que les noeuds LN et bitcoin fonctionnent
Il y a plusieurs choix possibles:
- se reposer sur la gestion des services de l’OS pour démarrer et redémarrer automatiquement en cas de panne ;
- tout lancer à la main dans un tmux/screen qu’on retrouve quand on se re-connecte en SSH (par exemple un onglet pour Bitcoin Core, un onglet pour LN, etc…) ;
- configurer des alertes quand les noeuds bitcoin/LN ne fonctionnent pas. Là encore, ça dépend du provider. Avec AWS, par exemple, c’est très simple de lancer un script CRON qui fait un appel à une API (bitcoin, LN…) et envoie un email si ça ne marche pas. Et bien sûr on ne teste que les alertes qui fonctionnent.
Troisième point important : les logs
Archiver les logs est un énorme plus en termes de debug, et pouvoir les consulter sans se connecter sur la machine est un énorme plus en ce qui concerne la sécurité. Là encore il y a plein de possibilités que l’on peut combiner :
- configurer le noeud LN pour utiliser des logs tournants (un fichier/jour)
- envoyer les logs vers un espace de stockage (S3, …)
- utiliser une solution de logging type logentries/papertrail/…
Une fois qu’on a ça, faire un test réel :
- ouvrir un ou deux channels,
- simuler un crash complet du nœud,
- vérifier qu’on a les alertes et les logs, et voir comment restaurer.
Il y d’autres tests intéressants à faire :
- faire un force-close, regarder quelles transactions sont publiées et avec quelles fees,
- redémarrer avec de vieilles données et vérifier que dataloss-protect fonctionne correctement.
On peut aller plus loin :
- collecter et exporter des métriques (nombre de channels ouverts/fermés, paiement, balance du noeud bitcoin/LN, …)
- créer des alertes si des channels se ferment…
En ce qui concerne LN, il est intéressant de regarder le protocole et de comprendre comment les transactions on-chain sont gérées :
- Qui publie ?
- Qui paie les frais ?
- Qu’est-ce qui est publié en cas de mutual-close ou de force-close ?
- Qu’est-ce qui se passe quand il y a des paiements en cours ?
Il faut également comprendre les interactions avec la blockchain :
- Qu’est-ce qui doit être surveillé et qu’est-ce que ça implique ? (i.e pourquoi certaines implémentations demandent que les transactions soient indexées ? Quel est l’impact du pruning ?)
- Le wallet onchain est-il géré par le noeud bitcoin (eclair) ? Par le noeud LN (c-lightning et lnd) ?
- Quels sont les avantages/inconvénients de chacune de ces deux solutions ?
ll n’y a pas besoin d’être un développeur pour faire tout ça, mais il faut être un peu technique et vouloir se plonger un peu dans l’OS, les services offerts sur le cloud, et les implémentations. C’est, à mon avis, très instructif et pas juste pour l’aspect LN. Par ailleurs, ça ne vous empêchera pas de passer à une solution plus « clef en main » plus tard (sauf que vous vous rendrez compte que finalement vous n’en avez pas besoin).
Tout ce qui est décrit ci-dessus est assez générique et devrait pouvoir être implémenté avec c-lighning, eclair ou lnd.
