Voici une série de 12 vidéos de Fanis Michalakis pour comprendre Bitcoin et le Lightning network. Cette série est une véritable Masterclass, tout est très bien expliqué en français, avec des schémas clairs. A visionner absolument pour comprendre le fonctionnement du Ligthning Network.
Dans cet article, chaque vidéo est suivi d’un résumé.
Comment fonctionne un canal de paiement.
Introduction au Lightning Network
Le Lightning Network est un réseau de canaux de paiement. Avant de traiter l’aspect réseau, il faut comprendre ce qu’est un canal sur Lightning, comment il fonctionne et de quoi il est constitué.
Canaux de paiement
Un canal de paiement est une connexion entre deux nœuds du réseau (par exemple, Alice et Bob). Les fonds sont déposés dans ce canal. Par exemple, Alice peut avoir 100 000 satoshis de son côté du canal et Bob 30 000 satoshis de son côté, pour un total de 130 000 satoshis dans le canal.
Transactions sur le canal
Les transactions sur le canal modifient la répartition des fonds entre les deux côtés. Par exemple, si Alice envoie 40 000 satoshis à Bob, il restera 60 000 satoshis du côté d’Alice et il y aura 70 000 satoshis du côté de Bob. La capacité totale du canal (130 000 satoshis dans cet exemple) reste constante.
Limitations des transactions
Une transaction ne peut pas envoyer plus de fonds qu’il n’y en a du côté de l’expéditeur. Par exemple, si Bob a 70 000 satoshis de son côté du canal, il ne peut pas envoyer 80 000 satoshis à Alice.
Représentation du « curseur »
Une autre façon de représenter la répartition des fonds dans un canal est d’utiliser un « curseur ». Si Alice a plus de fonds de son côté, le curseur est plus proche d’Alice. Si Bob a plus de fonds de son côté, le curseur est plus proche de Bob.
Capacité du canal
La capacité d’un canal est fixe et définie lors de l’ouverture du canal. Elle représente le montant maximum qui peut être envoyé en une seule transaction si toute la liquidité est du même côté. Cependant, ce n’est pas une limite sur le volume total de bitcoins qui peut être transigé dans le canal.
Adresses, UTXOs et transactions
Adresses Bitcoin
Une adresse Bitcoin est un nombre souvent représenté en format hexadécimal, dérivé d’une clé publique, qui elle-même est calculée à partir d’une clé privée. La clé privée est un élément secret qui ne doit pas être partagé, tandis que la clé publique et l’adresse peuvent être partagées.
Transactions Bitcoin
Une transaction Bitcoin est un envoi de bitcoins d’une adresse à une autre. Pour effectuer une transaction, il faut signer avec la clé privée correspondant à l’adresse de départ. Les fonds sur une adresse sont bloqués par un script qui ne permet de dépenser ces fonds que si certaines conditions sont remplies. En général, le script demande de fournir une signature avec la clé privée correspondant à l’adresse d’où l’on envoie les fonds.
UTXO (Unspent Transaction Outputs)
Les UTXO sont les paquets de bitcoins que l’on échange. Chaque fois qu’on fait une transaction, les fonds qui reçoivent un nouveau script sont en fait un UTXO. Les scripts bloquent les UTXO et pour dépenser un UTXO, il faut satisfaire la condition du script.
Adresses multi-signatures
Il est possible de créer une adresse à partir de plusieurs clés publiques, appelée adresse multi-signatures. Dans le contexte du réseau Lightning, on utilise des adresses multi-signatures générées à partir de deux clés publiques, où les deux clés privées doivent être utilisées pour effectuer une transaction.
Comment ouvrir un canal de paiement
Communication pair à pair
Avant d’ouvrir un canal, les deux parties (Alice et Bob dans cet exemple) commencent par échanger des messages. Alice, qui souhaite ouvrir le canal, envoie un message à Bob pour lui proposer d’ouvrir un canal avec une certaine capacité (130 000 satoshis dans cet exemple). Bob répond en acceptant l’offre et en fournissant sa clé publique.
Création d’une adresse multi-signature
Alice utilise sa clé publique et celle de Bob pour créer une adresse multi-signature. Cette adresse est utilisée pour ouvrir le canal.
Construction de la transaction de dépôt
Alice construit une transaction Bitcoin qui envoie des fonds de l’une de ses adresses à l’adresse multi-signature. Cette transaction n’est pas encore publiée.
Construction de la transaction de retrait
Avant de publier la transaction de dépôt, Alice construit une autre transaction qui dépense les fonds de la transaction précédente vers une de ses adresses. Cette transaction de retrait lui permet de récupérer ses fonds si elle ne souhaite plus avoir de canal avec Bob.
Signature de la transaction de retrait
Alice envoie la transaction de retrait à Bob pour qu’il la signe. Une fois qu’elle a la signature de Bob, elle sait qu’elle pourra récupérer ses fonds sans l’aide de Bob.
Publication de la transaction de dépôt
Une fois qu’Alice a la signature de Bob pour la transaction de retrait, elle publie la transaction de dépôt. Une fois que cette transaction est confirmée dans un bloc, le canal est considéré comme ouvert.
Il faut retenir qu’il n’y a pas besoin de faire confiance à l’autre partie lors de l’ouverture d’un canal, car la personne qui ouvre le canal s’assure de pouvoir récupérer ses fonds si nécessaire.
Transactions Lightning
Transactions Lightning
Une transaction Lightning est un transfert de fonds d’un côté à l’autre d’un canal. Les transactions Lightning reposent sur des transactions Bitcoin qui sont construites mais non publiées, à moins que le canal ne soit fermé.
Transaction d’engagement
Une transaction d’engagement est une transaction Bitcoin qui représente l’état actuel du canal, c’est-à-dire la répartition des fonds entre les deux côtés du canal. Chaque fois qu’une transaction Lightning est effectuée, une nouvelle transaction d’engagement est créée pour refléter le nouvel état du canal.
Création d’une transaction d’engagement
Pour créer une nouvelle transaction d’engagement, les deux parties du canal (par exemple, Alice et Bob) construisent indépendamment la même transaction Bitcoin, puis échangent leurs signatures respectives pour cette transaction. En échangeant leurs signatures, ils s’engagent sur le nouvel état du canal.
Publication d’une transaction d’engagement
Une transaction d’engagement n’est pas publiée tant que le canal est ouvert. Cependant, si l’une des parties le souhaite, elle peut publier la transaction à tout moment, ce qui entraîne la fermeture du canal. Chaque partie récupère alors les fonds qui lui sont dus sur la blockchain Bitcoin.
Possibilité de tricherie
Une des partie du canal pourrait théoriquement tricher en publiant une ancienne transaction d’engagement, cela lui permettrait de récupérer plus de fonds qu’elle ne devrait. Par exemple, si Alice a 60 000 satoshis de son côté du canal et Bob a 70 000 satoshis, Alice pourrait publier une ancienne transaction d’engagement où elle avait 100 000 satoshis, lui permettant de récupérer ces 100 000 satoshis et de voler 40 000 satoshis à Bob.
Sécurisation des transactions d’engagement
Pour éviter ce type de tricherie, les transactions d’engagement sont sécurisées en ajoutant des détails supplémentaires. En particulier, chaque transaction d’engagement peut être dépensée de deux manières.
- Soit par la partie à qui les fonds sont destinés après un certain nombre de blocs (grâce à un mécanisme appelé « time lock »).
- Soit par n’importe qui qui possède une clé de révocation spécifique à cette transaction.
Échange de secrets
Avant de passer à une nouvelle transaction d’engagement, les deux parties s’échangent leurs secrets respectifs pour la transaction d’engagement précédente. Cela leur permet de générer la clé de révocation pour cette transaction.
Punition des tentatives de tricherie
Si une partie tente de tricher en publiant une ancienne transaction d’engagement, l’autre partie peut utiliser la clé de révocation pour dépenser les fonds de la transaction avant que la partie tricheuse ne puisse le faire (grâce au « time lock »). Cela permet à la partie honnête de récupérer tous les fonds du canal, punissant ainsi la partie tricheuse.
Ces mécanismes de sécurité permettent de garantir que personne ne peut tricher sur le Lightning Network.
Fermeture d’un canal Lightning
Fermeture coopérative
C’est la méthode préférée pour fermer un canal. Alice et Bob (les deux parties du canal) s’accordent pour fermer le canal. Ils négocient les frais de transaction pour la fermeture et construisent ensemble une nouvelle transaction de fermeture. Cette transaction est différente de la dernière transaction d’engagement et ne contient pas de « time lock ». Alice signe la transaction et la publie, ce qui ferme le canal. Cette méthode est rapide et les frais sont contrôlés.
Fermeture forcée
Cette méthode est utilisée lorsque l’une des parties ne répond pas à la demande de fermeture du canal. Dans ce cas, la partie qui veut fermer le canal (Alice, par exemple) publie la dernière transaction d’engagement. Cette transaction a été construite et signée par Alice et Bob lors de la dernière transaction Lightning sur le canal. Cette méthode est plus lente en raison du « time lock » et les frais de transaction peuvent être inadaptés car ils ont été estimés lors de la construction de la transaction d’engagement.
Fermeture avec tricherie
Dans ce cas, une partie (Alice, par exemple) tente de tricher en publiant une ancienne transaction d’engagement qui lui donne plus de fonds qu’elle ne devrait. L’autre partie (Bob) peut surveiller la blockchain et le « mempool » (l’ensemble des transactions en attente d’être ajoutées à la blockchain) pour détecter cette tentative de tricherie. Si Bob détecte la tricherie, il peut utiliser la clé de révocation pour récupérer tous les fonds du canal, punissant ainsi Alice pour sa tentative de tricherie.
Ce qu’il faut retenir : la fermeture coopérative est toujours préférable car elle est plus rapide et les frais sont mieux contrôlés. Cependant, les autres méthodes sont disponibles en cas de besoin.
Fonctionnement du réseau de canaux
Comment les paiements sont acheminés de leur source jusqu’à leur destination.
Fonctionnement des HTLC
Fonctionnement des HTLC
Les HTLC sont des types de paiements sur le Lightning Network qui sont conditionnels et expirent dans le temps. Ils sont utilisés pour garantir que les paiements passent par des nœuds intermédiaires sans avoir à leur faire confiance.
Prenons un exemple avec trois nœuds : Alice, Susie et Bob. Alice veut envoyer 40 000 satoshis à Bob, mais elle n’a pas de canal direct avec lui. Elle décide donc de passer par Susie. Alice envoie 40 000 satoshis à Susie, qui les envoie ensuite à Bob. Pour s’assurer que Susie transmet le paiement, Alice utilise un HTLC.
HTLC et secrets
Pour récupérer les fonds de l’HTLC, Susie doit fournir un secret qui vérifie une certaine propriété. Ce secret est généré par Bob et son empreinte (hash) est incluse dans la facture qu’il envoie à Alice. Si Susie ne fournit pas le secret dans le temps imparti, l’HTLC expire et les fonds reviennent à Alice.
HTLC et transactions d’engagement
Les HTLC sont représentés dans les transactions d’engagement par une sortie qui leur est propre. Si le canal est fermé alors qu’un HTLC est en cours, les fonds de l’HTLC peuvent être récupérés sur la blockchain Bitcoin par la personne qui aurait reçu les fonds sur le Lightning Network si le canal était resté ouvert.
Expiration des HTLC
Les HTLC expirent dans un ordre spécifique, en commençant par le destinataire du paiement et en remontant jusqu’à la source. Cela garantit que personne ne peut être trompé si un HTLC expire avant qu’un autre ne soit résolu.
HTLC et fermeture du canal
La présence d’HTLC en cours dans un canal peut augmenter les frais de transaction sur Bitcoin en cas de fermeture forcée du canal. C’est pourquoi il est toujours préférable d’effectuer une fermeture coopérative du canal lorsque cela est possible.
Comment trouver une route au sein du réseau
Le nœud qui initie le paiement doit entretenir une topologie, c’est-à-dire une carte assez précise du réseau, qui est mise à jour au fur et à mesure du temps. Cependant, cette carte est incomplète et ne donne pas d’information sur la répartition de la liquidité dans les canaux à un instant donné.
Les nœuds entretiennent leur carte du réseau en échangeant régulièrement des messages dans le protocole Lightning, en annonçant la création de nouveaux canaux, en mettant à jour les frais de transaction au sein des canaux, et en écoutant la blockchain Bitcoin pour détecter la fermeture d’un canal.
Lorsqu’un nœud cherche à router un paiement, il utilise un algorithme qui prend en compte plusieurs critères, tels que la probabilité de réussite du paiement, les frais de transaction liés à chaque canal, les délais d’expiration, le nombre de nœuds intermédiaires, et parfois un élément d’aléatoire.
Si le premier essai de routage échoue, l’algorithme essaie avec la route suivante, et ainsi de suite jusqu’à ce que le paiement aboutisse ou échoue.
Le nœud destinataire du paiement peut aider le nœud émetteur en lui fournissant des informations supplémentaires, comme la présence de canaux privés ou la répartition des fonds dans les canaux dont il fait partie. Ces informations peuvent grandement aider le nœud émetteur à trouver la meilleure route pour le paiement.
Invoice, LNURL, Keysend
Invoice
Une invoice est une demande de paiement sur le réseau Lightning. L’invoice se compose d’une chaîne de caractères qui peut être divisée en deux parties : une partie lisible par l’homme (qui indique le réseau Lightning, la blockchain utilisée et le montant du paiement) et une partie destinée à être lue par la machine (qui contient des informations nécessaires pour le portefeuille pour envoyer le paiement).
LNURL
LNURL est un protocole qui simplifie l’expérience utilisateur lors de l’envoi et de la réception de paiements sur le réseau Lightning. Par exemple, lorsqu’un utilisateur veut retirer des fonds d’un service en ligne, le site affiche un QR code que l’utilisateur peut simplement scanner avec son portefeuille Lightning pour initier le retrait.
Keysend
Keysend est une méthode qui permet d’envoyer des paiements sur le réseau Lightning sans avoir à générer une invoice au préalable. L’utilisateur qui envoie le paiement génère une pré-image aléatoire, l’ajoute à la partie des données du paiement, et envoie le paiement à l’identifiant du destinataire. Le destinataire peut alors utiliser cette pré-image pour débloquer le paiement.
Comment gérer la liquidité de son canal
Types de profils d’utilisateurs
Il y a trois types principaux d’utilisateurs dans le Lightning Network : les payeurs, les vendeurs et les intermédiaires. Les payeurs ont besoin de liquidités de leur côté dans un canal pour effectuer des paiements. Les vendeurs ont besoin de liquidités du côté de l’autre nœud dans un canal pour recevoir des paiements. Les intermédiaires, qui aident à acheminer les paiements, ont besoin de liquidités des deux côtés.
Obtenir de la liquidité
Pour obtenir de la liquidité, un utilisateur peut ouvrir des canaux, faire des paiements pour déplacer la liquidité vers l’autre côté, ou acheter ou louer un canal de paiement auprès d’un service spécialisé.
Maintenir la liquidité
Maintenir la liquidité peut être plus difficile que de l’obtenir initialement. Les utilisateurs peuvent utiliser des services comme Loop pour déplacer la liquidité d’un côté à l’autre du canal. Ils peuvent également fermer et ouvrir de nouveaux canaux pour rééquilibrer la liquidité.
Services pour gérer la liquidité
Plusieurs services peuvent aider à gérer la liquidité dans le Lightning Network. ln2me ou dizzy sont des services qui permettent d’acheter, de louer, ou d’échanger de la liquidité.
Gestion de la liquidité pour les vendeurs
Les vendeurs, comme les boutiques en ligne, peuvent avoir besoin de gérer la liquidité de manière différente. Ils peuvent utiliser des services comme Loop Out pour déplacer la liquidité vers l’autre côté du canal et récupérer les fonds sur la blockchain Bitcoin. Ils peuvent également attendre que les nœuds de routage réorganisent leur liquidité.
Conclusion