Lightning Network : introduction technique
Cet article est dédié aux plus téméraires d’entre vous qui souhaitent comprendre le fonctionnement du réseau lightning sur Bitcoin.
Pour ceux qui cherchent une introduction non technique au Lightning Network, vous pouvez suivre le lien suivant :
Nous chercherons à comprendre les mécanismes permettant au Lightning Network d’exister sur bitcoin tout en garantissant un niveau de sécurité maximum aux utilisateurs
Qu’est ce qu’un canal de paiement ?
Comment fonctionnent les transactions sur Lightning Network ?
Comment est assurée la confidentialité sur le réseau ?
Autant de questions pour lesquelles vous trouverez ici des réponses.
Canaux de paiement et sécurité
La sécurité du réseau Bitcoin est assurée via un système de validation des transactions qui nécessite l’enregistrement de celles-ci sur la blockchain Bitcoin.
Au contraire, sur Lightning Network les transactions ne sont pas enregistrées immédiatement sur la blockchain Bitcoin, on parle alors de transactions off-chain.
Il est donc légitime de se demander si celles-ci sont aussi sécurisées que les transactions Bitcoin classiques.
La réponse est oui. Mais alors comment ?
Il est important de comprendre deux choses :
- Un canal de paiement est une transaction Bitcoin.
- Bitcoin possède un certain nombre de fonctionnalités intéressantes. En particulier, il est possible de configurer une adresse Bitcoin à partir de plusieurs adresses de telle sorte que les fonds qui y sont stockés ne puissent être dépensés qu’à une condition : il faut qu‘un certain nombre de signatures générées par un nombre plus grand ou égal d’adresses participantes soient apposées. C’est ce qu’on appelle une adresse multi-signature.
- Les canaux de paiement sont des adresses multi-signature avec uniquement deux parties prenantes; deux signataires sont nécessaires à la dépense des fonds.
- Le fait de déposer des fonds sur cette adresse multi-signature représente l’ouverture d’un canal de paiement, alors que le fait de les dépenser représente la fermeture du canal.
2. Une transaction off-chain dans un canal de paiement est une mise à jour de l’état des comptes qui prend la forme de transactions diffusables mais non diffusées sur la blockchain Bitcoin.
Voyons comment fonctionne un tel système.
- Un canal de paiement est créé en déposant des fonds sur une adresse multi-signature commune. Le montant total des BTCs envoyés à l’adresse multi-signature par les deux initiateurs du canal représente la valeur totale échangeable dans le canal de paiement.
- Chacun des deux initiateurs signe, sous la forme d’une transaction pouvant dépenser les fonds du canal, une transaction sortante représentant l’état initial du canal. Cependant, au lieu de diffuser cette transaction sur la blockchain Bitcoin, ces deux transactions sortantes vont être signées par leur émetteur et échangées entre les deux participants.
- A chaque nouvelle transaction à l’intérieur du canal, une nouvelle transaction sortante non diffusée est créée puis échangée entre les deux parties. Cette nouvelle version remplace la précédente. Puisque chaque participant détient une transaction sortante signée par l’autre partie, ils sont capable à tout moment d’apposer leur deuxième signature nécéssaire à la fermeture du canal et la récupération des fonds.
Mais alors comment s’assurer que ce soit bien la dernière version du canal qui soit diffusée sur la blockchain ?
Après tout, les deux parties ne se connaissent pas spécialement et n’ont pas forcément confiance l’une en l’autre. L’un des participants pourrait tout à fait diffuser une version préalable de l’échange qui l’arrange mieux que l’état actuel des comptes.
Deux systèmes sont utilisés pour régler ce problème :
- Le séquestre des fonds temporaire sur les transactions sortantes
Comme nous l’avons vu, ce “bilan comptable” existe en deux exemplaires pour chaque opération. Chaque exemplaire est rempli par l’un des parties et signé par celle-ci, puis donné à l’autre partie.
Afin d’assurer la sécurité du système, chaque exemplaire handicape son possesseur via un système ingénieux afin que celui-ci ne soit pas amené à tricher.
Pour cela, les bilans stipulent que le possesseur recevra ses bitcoins 1000 blocs après diffusion de la transaction sur la blockchain. L’autre partie les recevra immédiatement.
Grâce à ce système, si l’une des parties signe et diffuse une transaction, l’autre partie a 1000 blocs, soit plus ou moins une semaine, pour la pénaliser en cas de triche.
2. L’échange de “secrets” et de hashs permettant la libération des fonds séquestrés
A chaque nouvelle version du bilan, c’est à dire à chaque transaction off-chain, un secret est généré par chaque partie. Une fonction de hashage est alors appliquée à ce secret. Le hash résultant, qui peut être vu comme une empreinte numérique unique du secret, est donné à l’autre partie.
Le secret permet de débloquer et récupérer instantanément les bitcoins appartenant à l’autre partie et bloqués par le contrat. Il n’est pas donné à l’autre partie.
Lorsqu’une nouvelle transaction est executée off-chain, les secrets des bilans précédents sont échangés entre les parties. Cela veut dire que dans le futur, si l’un des parties cherche à diffuser un bilan antérieur sur la blockchain Bitcoin, l’autre partie sera capable de récupérer l’intégralité des bitcoins du canal avant que les 1000 blocs se soient écoulés.
Ainsi, chacun pourra décider du moment auquel il souhaite diffuser la transaction correspondant à la fermeture du canal sur la blockchain bitcoin tout en sachant qu’il dispose d’un bon temps de réaction si l’autre participant au canal cherche à tricher.
Si aucune des parties ne diffuse la transaction, alors le canal reste ouvert, alors que si la transaction est diffusée, le canal se ferme et les parties récupèrent leurs parts sur leurs adresses Bitcoin respectives. Le canal peut rester ouvert indéfiniment.
Voilà comment est assurée la sécurité des canaux de paiements.
Ci-dessous une illustration graphique de ces mécanismes :
A et B sont des utilisateurs
S est le nombre secret généré lors de chaque transaction d’engagement
H est le hash de ce secret
LIGHTNING NETWORK: UN RESEAU DE CANAUX DE PAIEMENT
Les canaux de paiement ne sont pas nouveaux. Leur fonctionnement basique a été décrit dès l’année 2011 par l’utilisateur hashcoin, puis retravaillé par différents acteurs de communauté Bitcoin depuis lors.
Cela dit, il aura fallu attendre le Lightning Network pour que soit proposé un système fonctionnel, sans tiers de confiance et décentralisé de mise en réseau de ces canaux.
En effet, un canal de paiement tel que décrit dans la première partie de l’article permet de sécuriser les paiements uniquement à l’intérieur d’un même canal.
Pour construire des paiements sécurisés avec des transactions qui passeront par de multiples canaux avant d’arriver à destination, un dernier élément est nécessaire : les Hashed TimeLocked Contracts.
Les HTLCs permettent de mettre en place des transactions spéciales grâce au système de séquestre des fonds et de secrets/hashs.
Voilà comment se passe une transaction Lightning Network, avec A et D qui souhaitent faire une transaction en passant par B et C:
- Le récepteur final D crée un secret. Il génère un hash ce secret (H) et le donne à A, le payeur. H est utilisé à chaque étape pour construire les HTLCs.
- A met en place un HTLC , une transaction spéciale qui présente les fonctionnalités suivantes : A paiera le montant total de la transaction à B si et seulement si B est capable de lui donner le secret du hash (H) dans un temps imparti. Si B n’en est pas capable, alors la transaction est annulée et A récupère le montant des fonds du contrat. A ne peut pas récupérer le montant du HTLC avant la fin du compte à rebours.
- Automatiquement, B met en place le même type de contrat avec C.
- C fait de même avec D. Seulement, comme D détient le secret, il est capable de le fournir à C et donc de déclencher le paiement de C. D récupère les fonds en donnant le secret à C. C connait maintenant le secret.
- C peut donc récupérer les fonds de B, et B récupère alors les fonds de A.
- Le paiement est complété.
Ainsi, à partir du moment où les HTLCs sont mis en place le long de la chaîne de paiement, chaque maillon est assuré de recevoir le paiement du maillon précédent. Le fait de devoir récupérer le hash afin de déclencher le paiement d’un maillon au suivant assure qu’en cas de non coopération, chaque maillon récupérera ses fonds une fois le temps du contrat HTLC expiré.
Il est important que le temps d’expiration des HTLCs diminue à chaque étape de la chaîne de paiement afin que chaque maillon soit assuré d’être payé ou de récupérer ses fonds.
Les maillons intermédiaires d’une chaîne de paiement peuvent éventuellement fixer des commissions afin d’être payés pour leurs services. Mais attention, ils ont intérêt à être très compétitifs car le payeur choisit le chemin qu’empruntera sa transaction.
IMPLEMENTATIONS ET INTEROPERABILITE
Différentes entreprises travaillent sur le Lightning Network et développent leur propres implémentations de la technologie. On retrouve notamment :
Il y a un peu plus d’un an, les différents groupes qui développent le Lightning Network, que ce soit des entreprises ou des projets Open Source, se sont réunis et ont mis en place un ensemble de normes d’intéropérabilité communes.
Ces normes portent le nom de BOLT (Basics of Lightning Technology).
Ils définissent comment les différentes implémentations vont intéropérer afin que les différents outils développés fonctionnent les uns avec les autres quelque soit l’implémentation choisie.
Une de ces normes communes est l’Onion Routing Protocol.
ONION ROUTING PROTOCOL ET CONFIDENTIALITE
L’Onion Routing Protocol, implémenté pour faire fonctionner le réseau Tor, permet d’assurer une confidentialité accrue sur les paiements lightning.
Ce nom a été donné car l’information relative au paiement est enveloppée en différentes couches, tel un oignon. A chaque étape de la chaîne, seul une couche est dévoilée au noeud qui route le paiement.
Ainsi, un noeud donné peut uniquement voir ses deux “voisins” dans la chaîne de paiement. Si l’on reprend le schéma donné plus haut, B ne voit que A et C, mais pas D.
L’information routée à l’intérieur de ce “paquet” va donner l’impression à chaque noeud qu’il reste 20 étapes sur la chaîne de paiement. C’est le nombre maximum de maillons possibles dans une chaîne de paiement lightning. Il est donc impossible pour un noeud de savoir quelle est la destination du paiement.
Lorsque le noeud ouvre ce paquet il trouve alors l’information de la prochaine étape de la chaîne. Seul le dernier noeud, en ouvrant le paquet, voit qu’il est la dernière étape.
Par ce processus, les noeuds n’ont aucun moyen de savoir combien de noeuds ont été utilisés avant eux et combien de noeuds vont être utilisés dans cette chaîne de paiement. Ils ne savent pas non plus où il se situent.
Seul le payeur et le receveur savent quelle est la taille de la chaîne et savent dans quelle position ils sont.
En conclusion, Lightning Network est une technologie astucieuse qui est discutée et développée depuis de nombreuses années.
En mars 2018, LN était enfin déployé sur le mainnet. C’était un travail de longue haleine: il a d’abord fallu implémenter l’amélioration de protocole SegWit afin que cela soit possible.
La mise en place d’un tel système montre les capacités que présente Bitcoin à évoluer et s’imposer à terme comme un système de transfert de valeur utilisé par les masses. Les champs d’applications sont nombreux.
Sources
- White Paper par Lighting Labs: https://lightning.network/lightning-network-paper.pdf
- Article de Bitconseil sur Lightning Network : https://bitconseil.fr/bitcoin-lightning-network-histoire-fonctionnement/
- Répertoire des LApps: https://dev.lightning.community/lapps/
- Vidéo d’Andreas Antanopoulos sur Lightning Network : https://www.youtube.com/watch?v=c4TjfaLgzj4&t=558s
