Bitcoin ne permet pas à ses transactions de devenir définitives en quelques millisecondes. Elles se disputent un espace de bloc limité, et un nouveau bloc n’est miné qu’environ toutes les dix minutes en moyenne. Alors comment un paiement Lightning peut-il parvenir à une boutique à l’autre bout du monde presque instantanément, pour des frais très faibles ?

La réponse n’est pas une blockchain plus rapide. Les paiements Lightning ne sont pas du tout inscrits sur la blockchain Bitcoin, du moins pour la grande majorité d’entre eux.

À la place, les utilisateurs de Lightning verrouillent des bitcoins dans ce qu’on appelle des canaux de paiement et échangent des mises à jour signées qui modifient qui peut dépenser ces fonds. Ces canaux forment un réseau, ce qui permet à un paiement de traverser plusieurs participants même lorsque l’expéditeur et le destinataire n’ont pas de connexion directe.

Beaucoup de personnes ont déjà utilisé le réseau Lightning, mais peu comprennent comment il fonctionne réellement. Décomposons-le, étape par étape.

Pourquoi avons-nous besoin de Lightning ?

Chaque transaction Bitcoin classique doit être diffusée à l’ensemble du réseau, vérifiée par des nœuds, incluse dans un bloc et stockée dans la blockchain pour toujours. C’est ce qui rend Bitcoin vérifiable de manière indépendante : n’importe qui peut exécuter un nœud et vérifier l’historique complet sans demander la permission d’une banque ou d’un processeur de paiement.

Cette propriété s’accompagne d’une contrainte volontaire. L’espace de bloc est limité, ce qui signifie que tout le monde ne peut pas acheter son café du matin avec une transaction Bitcoin classique. Il n’y a tout simplement pas assez de place. Augmenter la taille des blocs sans limite ferait monter les exigences en bande passante, en calcul et en stockage pour faire tourner un nœud, rendant la vérification indépendante de plus en plus difficile.

Lightning adopte donc une autre approche. Les transactions Bitcoin restent la couche de règlement, tandis que les paiements répétés ont lieu sur une deuxième couche. Plutôt que de demander à l’ensemble du réseau Bitcoin d’enregistrer chaque achat de café, deux participants peuvent régler de nombreux paiements entre eux et ne publier que le résultat lorsque c’est nécessaire.

Un point important à garder en tête est le suivant : Lightning, c’est du Bitcoin. Il reste étroitement lié au réseau Bitcoin et n’est pas « une nouvelle monnaie ». Les paiements Lightning sont des paiements Bitcoin ; ils utilisent simplement l’espace de bloc limité de façon plus efficace et moins fréquente.

Un canal de paiement commence sur Bitcoin

Imaginons qu’Alice veuille utiliser 0.001 BTC, soit 100 000 satoshis, pour des paiements Lightning. Elle ouvre un canal avec Bob en créant une transaction Bitcoin qui verrouille ces fonds dans un portefeuille contrôlé par les deux participants du canal. Vous pouvez voir cela comme un portefeuille multisig spécial 2-sur-2, où Alice et Bob détiennent chacun une clé et ne peuvent dépenser les fonds qu’ensemble.

Comme nous le verrons plus tard, ce portefeuille multisig doit remplir certaines propriétés importantes pour que le canal de paiement fonctionne de manière sûre et sans avoir à se faire confiance. Mais pour l’instant, ces détails ne sont pas importants.

La transaction de financement est enregistrée sur la blockchain Bitcoin. Une fois qu’elle a suffisamment de confirmations, le canal peut être utilisé pour des paiements.

Au départ, le canal peut ressembler à ceci, avec tout le solde du côté d’Alice, puisqu’elle a envoyé la transaction d’ouverture :

  • Alice: 100 000 sats
  • Bob: 0 sat
  • Capacité totale: 100 000 sats

Rappelez-vous que les bitcoins n’ont pas quitté la blockchain. Ils se trouvent simplement dans un autre portefeuille désormais. Ce qui change pendant la vie du canal, c’est l’accord valide sur la manière dont cet argent peut être dépensé. Voyons un exemple…

Les paiements sont des accords

Imaginez un contrat de location pour un appartement, dans lequel vous devez verser au propriétaire une caution de 1000 USD. Lorsque le contrat est résilié, le propriétaire doit vous rendre ces 1000 USD. Mais disons que vous souhaitez payer le propriétaire pour un meuble que vous avez abîmé. Vous pourriez simplement lui envoyer un virement bancaire classique ou lui remettre de l’argent liquide. Mais vous pourriez aussi tous les deux mettre à jour le contrat de location pour réduire la caution, par exemple à 900 USD. De cette façon, vous lui avez effectivement payé 100 USD sans déplacer d’argent, simplement en mettant à jour un contrat.

C’est exactement, ou presque, ainsi qu’un canal Lightning fonctionne. Les 1000 USD de cet exemple correspondent à la capacité du canal, et vous et le propriétaire pourriez vous « envoyer » de l’argent aussi souvent que vous le souhaitez en mettant simplement à jour le contrat. Puis, une fois le contrat terminé, vous réglez simplement le montant actuellement défini comme caution.

Le contrat dans Bitcoin

Dans Bitcoin, il ne s’agit évidemment pas de contrats de location, mais de transactions. Les deux concepts ne sont pourtant pas si éloignés, car signer une transaction Bitcoin revient conceptuellement presque à signer un contrat.

Revenons à notre canal de paiement : supposons qu’Alice paie Bob 20 000 sats. Ils ne créent pas et ne diffusent pas une transaction Bitcoin classique. À la place, leurs nœuds Lightning construisent et signent une nouvelle paire de transactions de règlement qui reflètent le solde mis à jour :

  • Alice: 80 000 sats
  • Bob: 20 000 sats

On les appelle des transactions d’engagement. Chaque participant détient une transaction valide qu’il peut publier pour fermer le canal et verser à tout moment le dernier solde convenu. Les deux versions diffèrent dans leurs détails, car chacune est conçue pour être publiée par l’un des deux côtés, mais elles représentent toutes les deux le même état du canal.

Si Bob renvoie plus tard 5 000 sats à Alice, les nœuds créent un autre état et un autre ensemble de transactions non publiées :

  • Alice: 85 000 sats
  • Bob: 15 000 sats

Là encore, rien n’a été diffusé sur le réseau Bitcoin. Alice et Bob ont simplement remplacé leur précédent accord de règlement par un plus récent. Ils peuvent répéter ce processus de nombreuses fois sans attendre un bloc ni payer de frais de transaction. Exactement comme avec la caution mise à jour dans le contrat de location.

Voici la première idée clé sur Lightning : un solde off-chain dans un canal Lightning n’est pas une entrée dans un registre global comme les transactions classiques. C’est le dernier ensemble de transactions Bitcoin que les participants du canal ont signé.

Voler le solde d’un canal

Vous pourriez maintenant vous demander pourquoi Alice, par exemple, ne diffuserait pas simplement un ancien accord de règlement sur le réseau Bitcoin. Après tout, les transactions Bitcoin signées restent valides, et ce faisant elle pourrait annuler les paiements qu’elle a faits à Bob, autrement dit lui voler ces fonds.

Dans notre exemple précédent du contrat de location, le système judiciaire, c’est-à-dire un juge au tribunal, pourrait trancher un litige entre le propriétaire et le locataire en respectant le contrat signé le plus récent. Dans Bitcoin, ce processus est plus compliqué. Nous avons besoin d’un mécanisme purement technique, puisqu’il n’existe aucun tiers de confiance sur lequel compter.

À chaque fois qu’un canal passe à un nouvel état, les deux parties échangent des informations qui révoquent l’état précédent. Cela se fait cryptographiquement en révélant une certaine clé, que l’autre partie peut utiliser si vous essayez de tricher. Si Alice tente de diffuser une transaction d’engagement déjà révoquée, c’est-à-dire si elle essaie de tricher, son propre paiement est retardé. Pendant ce délai, Bob peut utiliser les informations de révocation pour prouver qu’Alice a publié un ancien état et réclamer l’intégralité des fonds qu’elle essayait de prendre.

Les scripts exacts utilisés dans ces transactions sont plus complexes, mais l’incitation est simple : tenter de régler un ancien solde peut coûter à la partie malhonnête l’ensemble des fonds de son canal. Et ce n’est pas tout : elle perd aussi en crédibilité économique dans le réseau, ce qui dissuade les autres d’ouvrir de nouveaux canaux avec elle.

Ce mécanisme de pénalité explique aussi pourquoi un nœud Lightning ne peut pas ignorer la blockchain indéfiniment. Bob doit détecter une fermeture obsolète du canal et réagir dans la fenêtre de contestation. Le nœud n’a pas besoin d’être en ligne à chaque seconde, mais il doit vérifier assez souvent, ou déléguer cette surveillance à quelqu’un d’autre — ce qu’on appelle une watchtower. C’est l’un des principaux compromis de sécurité de Lightning : vous devez garder un œil sur votre argent.

Les canaux forment un réseau

Vous l’avez sans doute deviné : le concept d’un seul canal de paiement, qui permet un nombre arbitraire de paiements entre deux participants, peut maintenant s’étendre à un réseau de canaux de paiement interconnectés, permettant un nombre arbitraire de paiements entre beaucoup plus de participants.

Un canal entre Alice et Bob est utile, mais ouvrir un canal séparé avec chaque personne ou chaque boutique irait à l’encontre de l’objectif. À la place, Bob peut avoir un autre canal ouvert avec Carol, qui à son tour a un canal ouvert avec David.

Cela permet maintenant à Alice de créer un paiement vers David, en acheminant le paiement à travers différents canaux :

Même si Alice n’a pas de canal direct avec David, on peut mettre à jour les trois canaux de sorte que de la valeur passe d’Alice à David :

  1. Alice envoie 1 000 sats à Bob.
  2. Bob envoie 1 000 sats à Carol.
  3. Carol envoie 1 000 sats à David.
  4. David a effectivement reçu 1 000 sats de la part d’Alice.

Bob et Carol transmettent le paiement en utilisant des bitcoins qu’ils ont déjà disponibles du bon côté de leurs propres canaux. Ils peuvent facturer de petits frais de routage pour fournir ce service, c’est-à-dire de la liquidité et le maintien de leurs nœuds en ligne. C’est pour cela que les paiements Lightning s’accompagnent tout de même de petits frais de transaction.

Malheureusement, l’histoire ne s’arrête pas là, car nous venons de créer un nouveau problème : Alice ne devrait pas payer Bob tant qu’elle n’a pas la certitude que David sera payé. Bob ne devrait pas payer Carol à moins que le paiement entrant d’Alice soit garanti. Et Carol ne devrait pas pouvoir prendre l’argent de Bob sans finaliser le paiement vers David.

Lightning résout ce problème avec des paiements conditionnels.

Le secret qui relie chaque saut

Lorsque David crée une facture Lightning classique, son portefeuille génère un secret aléatoire. Ce secret s’appelle une préimage — un terme un peu sophistiqué de cryptographie pour désigner « ce qui existait au départ ». Le portefeuille place ensuite l’empreinte de cette préimage, c’est-à-dire une valeur de hachage, dans la facture Lightning.

Alice utilise ce hash de paiement pour mettre en place une chaîne de Hashed Timelock Contracts, souvent abrégés en HTLCs. Chaque contrat dit, en termes simplifiés :

Vous pouvez réclamer ce paiement si vous révélez le secret correspondant à ce hash avant la date limite. Sinon, l’expéditeur récupère l’argent.

Alice propose un tel paiement conditionnel à Bob. Bob en propose un correspondant à Carol, et Carol en propose un à David. Les délais deviennent plus courts à mesure qu’on se rapproche du destinataire, de sorte que chaque nœud de routage ait le temps de récupérer son paiement entrant si une étape ultérieure doit être réglée on-chain.

David connaît le secret, il peut donc le révéler et réclamer le paiement final. Une fois que Carol apprend le secret, elle peut réclamer l’argent à Bob. Bob peut alors à son tour réclamer à Alice. La même preuve déverrouille le paiement à rebours sur toute la route.

Si la route échoue ou si David ne révèle jamais le secret, le HTLC expire et les modifications en attente sont annulées ou remboursées. Cela rend le paiement atomique : soit il aboutit sur toute la route, soit il échoue sans laisser quelqu’un dans la situation d’avoir payé l’étape suivante sans rien recevoir en retour.

En fonctionnement normal, tout cela se déroule par messages entre nœuds Lightning. Les transactions HTLC sont importantes, car chaque participant peut faire appliquer le résultat sur Bitcoin si la coopération échoue. Autrement dit, tous ces contrats sophistiqués, avec de la cryptographie pour garantir que personne ne puisse tricher, ne sont finalement, là encore, que des transactions Bitcoin signées. Si quelque chose tourne mal, la transaction peut être publiée sur la blockchain Bitcoin, et les fonds reviennent là où ils doivent être.

Comment un canal se ferme

Comme tout contrat de location, un canal Lightning ne restera pas ouvert pour toujours, et il existe deux grandes façons de le fermer.

  • Dans une fermeture coopérative, les deux participants s’accordent sur le solde final et signent une transaction de fermeture. C’est généralement l’issue la plus simple et la moins coûteuse. Une fois cette transaction confirmée, chaque participant contrôle à nouveau directement on-chain sa part. Pour reprendre notre analogie, le locataire et le propriétaire se sont simplement mis d’accord sur le montant final de la caution à reverser.
  • Dans une fermeture unilatérale, l’un des participants publie sa dernière transaction d’engagement sans la coopération de l’autre participant. On parle aussi parfois de force close. C’est une fonction de sécurité essentielle : aucun côté ne peut prendre les bitcoins de l’autre en otage en passant hors ligne ou en refusant de signer.

Une fermeture unilatérale est plus lente et peut être plus coûteuse. Les timelocks doivent expirer, et des HTLC non résolus peuvent nécessiter des transactions on-chain supplémentaires. Mais tant que l’utilisateur possède le dernier état valide du canal et surveille la blockchain lorsque c’est nécessaire, le protocole lui offre une sortie unilatérale appliquée par la blockchain Bitcoin.

C’est la base du modèle de sécurité de Lightning. Les participants coopèrent pour la rapidité, mais ils n’ont pas à se faire confiance pour la garde des fonds. Le réseau Bitcoin agit comme arbitre final lorsqu’ils ne sont pas d’accord, comme dans l’exemple du contrat de location.

Voilà. Nous avons décomposé les éléments clés d’un paiement sur le réseau Lightning. Bien sûr, il y aurait encore beaucoup à approfondir : comment un nœud trouve-t-il une route dans le réseau ? Existe-t-il différents mécanismes de pénalité, et comment se comparent-ils ? Comment contourner les contraintes de liquidité ? Mais pour l’instant, restons-en aux composants essentiels.

Quelle est la place d’un hardware wallet

Un hardware wallet et un portefeuille Lightning résolvent des problèmes entièrement différents.

Le BitBox est conçu pour protéger vos clés privées sur le long terme, et les transactions doivent être confirmées et vérifiées manuellement sur son écran sécurisé. C’est excellent pour la sécurité, mais peu pratique pour Lightning : chaque fois qu’un paiement est envoyé ou reçu, de nouveaux états de canal doivent être signés en interaction avec d’autres nœuds Lightning. À moins de rester 24 heures sur 24 à côté de votre hardware wallet, prêt à confirmer un paiement entrant.

Pour beaucoup d’utilisateurs, la configuration pratique ressemble donc à un compte d’épargne et à un portefeuille physique : conservez les montants les plus importants en cold storage sur un hardware wallet, et ne transférez qu’un petit solde de dépenses vers un portefeuille Lightning non custodial. Cela limite le montant exposé si le téléphone, l’ordinateur ou le portefeuille Lightning est compromis, tout en conservant la commodité des paiements instantanés.

L’auto-garde reste importante sur Lightning. Avant de choisir un portefeuille, vérifiez si vous contrôlez vous-même les clés, comment fonctionne la récupération, qui gère les canaux et ce qui se passe si le fournisseur du portefeuille disparaît. « Portefeuille Lightning » décrit une technologie de paiement, pas un modèle de sécurité universel.

Nous travaillons encore activement à intégrer un portefeuille Lightning dans la BitBoxApp, afin d’offrir une expérience fluide entre ces deux philosophies de portefeuille. Le hardware wallet peut toutefois encore jouer un rôle, en dérivant les clés privées du portefeuille Lightning à partir de sa propre sauvegarde, afin d’éviter d’avoir à gérer une nouvelle sauvegarde pour le portefeuille Lightning.

Conclusion

Le Lightning Network n’est ni une partie séparée de bitcoin, ni un raccourci qui contourne les règles de Bitcoin. C’est un réseau de canaux de paiement soutenu par de vraies transactions Bitcoin.

Les participants des canaux mettent à jour des transactions signées au lieu de diffuser chaque paiement. Les mécanismes de révocation découragent chaque côté de tricher. Des scripts Bitcoin complexes relient plusieurs canaux pour qu’un paiement routé aboutisse d’un bout à l’autre ou échoue en toute sécurité.

C’est ainsi que Lightning peut donner une impression d’instantanéité sans dépendre d’un processeur de paiement central. Sa rapidité vient du déplacement de l’activité courante off-chain ; sa sécurité vient du fait qu’il conserve un chemin de retour vers Bitcoin. Le résultat convient bien aux paiements du quotidien, à condition que les utilisateurs comprennent les compromis liés à la liquidité, à la disponibilité, aux sauvegardes et au risque des hot wallets.

Pour l’épargne de long terme, le cold storage restera généralement le meilleur outil. Pour de petits paiements fréquents, Lightning offre un complément convaincant — et non un remplacement — à la couche principale de Bitcoin.

Vous n’avez pas encore de BitBox ?

Assurer la sécurité de vos cryptos n’a pas besoin d’être compliqué. Les hardware wallets BitBox stockent hors ligne les clés privées de vos cryptomonnaies. Vous pouvez ainsi gérer vos coins en toute sécurité.

Le BitBox02 Nova comme le BitBox02 existent aussi en édition Bitcoin-only, avec un firmware résolument ciblé : moins de code signifie moins de surface d’attaque, ce qui améliore encore votre sécurité lorsque vous ne stockez que du bitcoin.

Achetez le BitBox02 Nova ou procurez-vous un BitBox02 dans notre boutique !

Shift Crypto est une entreprise privée basée à Zurich, en Suisse. Notre équipe de contributeurs Bitcoin, d’experts crypto et d’ingénieurs en sécurité développe des produits qui permettent à nos clients d’avancer sereinement, du niveau débutant jusqu’à une maîtrise approfondie de la gestion des cryptomonnaies. Le BitBox02, notre hardware wallet de deuxième génération, permet aux utilisateurs de stocker, protéger et utiliser Bitcoin et d’autres cryptomonnaies en toute simplicité — avec son compagnon logiciel, la BitBoxApp !