Comme nous l’avons vu dans la première partie sur le Lightning Network, celui-ci pourrait permettre à l’avenir de résoudre le problème de scalabilité du bitcoin. Toutefois, il est important de savoir si ce changement ne représente pas un danger pour un autre point du trilemme de la blockchain : la sécurité. En effet, la sécurité du réseau et notamment des fonds fait partie des premières interrogations lorsque l’on s’intéresse au Lightning Network. Nous allons donc aujourd’hui aborder le Justice System du Lightning Network et son fonctionnement.
Comment ça marche ?
Comme nous l’avons vu précédemment la forme la plus commune de fermeture d’un canal est un accord réciproque. C’est-à-dire que le premier nœud engage la fermeture du canal alors que l’autre pair est en ligne. Dans ce cas, la transaction se fait via une multi-signature 2 of 2 et les fonds sont répartis correctement.
Toutefois, que se passe t-il lorsqu’un nœud cherche à fermer un canal sans l’accord de l’autre nœud ? Dans ce cas, plusieurs scénarios peuvent avoir lieu.
Le premier scénario a lieu lorsqu’un nœud opère une fermeture de canal sans communiquer avec l’autre nœud mais avec une absence de mauvaises intentions (Non-cooperative closure > Non-Breach).
Pour ce cas, deux transactions on-chain seront nécessaires. La première sera faite via une mutli-signature 2 of 2 comme dans le cas d’une fermeture classique avec deux destinataires. Dans un premier temps, le nœud n’ayant pas engagé la fermeture recevra les fonds selon la version du canal fournie par le noeud fermant (d’où la nécessité d’honnêteté). La seconde partie de la transaction sera transférée vers un second destinataire à partir duquel le nœud ayant engagé la fermeture pourra récupérer ses fonds via une seconde transaction.
Dans le second scénario, un nœud cherche à voler des fonds en engageant une fermeture du canal basée sur un état antérieur du nœud (ne comportant donc pas toutes les transactions). Il y aura alors Non-Justice si le deuxième nœud ne vérifie pas le réseau dans un délai défini appelé « locktime » (Non-cooperative closure > Breach > Non-Justice).
Ainsi, la procédure de fermeture sera la même que pour le scénario précédent, mais avec des informations erronées sur la répartition des fonds (basés sur la version du canal fourni par le nœud fermant celui-ci).
Le dernier scénario consiste en une tentative de vol par le nœud fermant le canal, mais avec une vérification du réseau par le second nœud (Non-cooperative closure > Breach > Justice). Dans ce cas, il y aura aussi deux transactions, mais c’est aussi le nœud « honnête » qui pourra récupérer les fonds déposés sur le deuxième destinataire de la transaction multi-signature 2 of 2.
Il serait donc possible d’éviter le Justice System ?
En effet, c’est ce que laisse paraître le second scénario dans lequel le second nœud ne vérifie pas le réseau dans le délais imparti. Toutefois, pour pallier ce scénario de Non-Justice, la fonctionnalité de Watchtowers (ou tours de guet en français) a été implémentée en Juin 2019 (LND 0.7.0). Une watchtower peut alors vérifier pour les nœuds auxquels elle est connectée s’il y a tentative d’escroquerie et engager une transaction de justice.
Un nœud peut être à la fois être un client et une watchtower. Notons aussi qu’il n’est pas nécessaire pour un nœud et une Watchtower d’avoir un canal les reliant puisque la watchtower ne fait que se connecter au nœud pour le monitorer. On pourrait donc imaginer que chaque noeud du réseau serait connecté à une ou plusieurs watchtower/noeud. Ainsi, ils seraient en mesure de vérifier réciproquement l’état des canaux l’un pour l’autre, ce qui empêcherait toute tentative de triche.
En fin de compte, la fonctionnalité de Watchtowers en complément au Justice System rend le risque de brèche impossible au sein du Lightning Network.
Et si un nœud perd des données ?
Le problème qui persiste vient alors si un noeud perd ses données ou les voit détruites. Dans ce cas, la solution la plus simple consisterait en la sauvegarde régulière de ces données pour avoir un point de restauration. En réalité, cette solution est très risquée puisque s’il y a modification du canal entre la sauvegarde et la restauration des données ce changement peut être vu comment une tentative de brèche et donc puni par le Justice System puisque la version du canal sera erronée.
Les Static Channel Backups implémentés en Avril 2019 (v0.6-beta) sont un bon pas pour résoudre ce problème. En effet, la sauvegarde est alors actualisée à chaque ouverture de canal et encryptée à partir d’une clé dérivé de la clé propre à l’utilisateur. Cela empêche notamment à un autre utilisateur de restaurer cette sauvegarde. Une fois les canaux restaurés, les pairs de ces canaux seront forcés à fermer le canal avec la dernière version du canal (le noeud ayant engagé la restauration paiera les frais de fermeture du canal). Les SBCs permettent alors de restaurer les fonds off-chain (sur le LN) en cas de perte partielle ou complète des données.
Sources :
- Le whitepaper du Lightning Network
- BitMex Research :
- Le repo GitHub Lightning Network Daemon
2 réponses sur “Lightning Network : le Justice System”