Lightning Network : les canaux de paiement en démo

L’idée en une phrase

Le Lightning Network permet à deux personnes de se payer autant qu'elles veulent en réécrivant entre elles un solde partagé, et de n'en inscrire que le résultat final sur Bitcoin.

Ce solde partagé s'appelle un canal de paiement. Les fonds y sont bloqués sur la chaîne, dans une adresse à deux signatures. Chaque paiement remplace simplement le partage précédent par un nouveau, signé par les deux parties. Relié à d'autres canaux, cela forme un réseau qui route les paiements de proche en proche.

La démo

Exemple sans JavaScript : Alice paie 30 000 sat à Carol via Bob, avec une commission de 31 sat (1 sat de base plus 0,1 %, un barème choisi pour l'exemple). Le canal 1 passe à Alice 69 969 sat et Bob 80 031 sat. Le canal 2 passe à Bob 50 000 sat et Carol 50 000 sat. Aucune transaction n'a touché la chaîne et le total reste de 250 000 sat.

Pourquoi ça compte

Une transaction Bitcoin normale occupe de la place dans un bloc et prend environ 10 minutes pour sa première confirmation. Pour payer un café, tu devrais donc attendre, et payer des frais qui ne dépendent pas de la valeur du café. Comme les blocs sont limités, le réseau ne peut traiter qu'un nombre réduit de transactions à la seconde, et il restera ainsi par conception.

Lightning déplace le problème. Dans un canal, un paiement prend quelques instants, car il suffit d'échanger des signatures entre deux machines. Le coût ne dépend plus d'un bloc. Le prix à payer, c'est une gestion plus exigeante : il faut rester en ligne, surveiller ses canaux et gérer la liquidité. La démo te montre ces contraintes aussi.

Le code

Ce code rejoue un paiement sur une route de trois sauts, avec un vrai SHA-256. Change montant ou ajoute un nœud dans route : les commissions et les délais s'empilent. La dernière ligne montre un verrou qui refuse un faux secret.

Clique sur Lancer pour exécuter ce code dans ton navigateur.

Ce qui se passe vraiment

Chaque barre représente un canal. Sa longueur totale, la capacité, est fixée à l'ouverture par la transaction sur la chaîne. La partie colorée montre la part de celui qui est à gauche. Le paiement déplace la frontière dans la barre, et ne crée ni ne détruit aucun satoshi. Le compteur « total dans les canaux » le prouve : il ne bouge jamais pendant un paiement.

Lance un paiement et lis le journal ligne par ligne. Alice n'a pas de canal avec Carol. Elle passe par Bob, sans lui faire confiance, grâce à un contrat appelé HTLC (Hashed Timelock Contract). Carol tire un secret au hasard et donne à Alice uniquement son hash. Alice verrouille les fonds vers Bob avec cette condition : Bob les prend s'il présente le secret de ce hash avant la fin d'un délai, sinon ils reviennent à Alice. Bob pose le même verrou vers Carol.

Pour toucher son paiement, Carol doit révéler le secret à Bob. Ce faisant, elle lui donne exactement ce qu'il lui faut pour encaisser auprès d'Alice. Tout se fait donc, ou rien ne se fait. Bob ne peut pas garder l'argent : tant qu'il ne transmet pas, Carol ne révèle rien et le délai rend les fonds. Le délai de 40 blocs de Bob est plus court que les 80 d'Alice, pour lui laisser le temps de réagir s'il doit agir sur la chaîne. La valeur de ces délais est illustrative.

Règle ensuite le montant sur 60 000 sat et relance après ce premier paiement. Alice a de quoi payer, mais l'envoi échoue : Bob n'a plus que 50 000 sat vers Carol, alors que le canal 2 a une capacité de 100 000 sat. C'est la vraie limite de Lightning : la liquidité est orientée. Un canal de 100 000 sat ne permet pas d'envoyer 100 000 sat dans les deux sens. Passe le sens sur « Carol paie Alice » : la frontière revient en arrière et la liquidité se reconstitue.

Clique enfin sur « Publier un ancien état » après un paiement. Chaque mise à jour du canal annule la précédente par l'échange d'une clé de révocation. Si quelqu'un publie une version périmée, plus avantageuse pour lui, l'autre dispose d'un délai pour le prouver et rafler toute la capacité. La tricherie reste techniquement possible, mais elle est conçue pour coûter plus qu'elle ne rapporte.

La démo simplifie. Elle n'a que trois nœuds, un seul itinéraire, et elle ne montre ni signatures, ni routage en oignon, ni frais de la chaîne pour ouvrir et fermer.

Dans la vraie vie

Un canal repose sur une transaction d'ouverture vers une adresse 2-sur-2. Chacun garde en permanence une transaction de sortie signée, dite d'engagement, qui peut être publiée sans l'accord de l'autre. Tu ne dépends donc pas de ton partenaire pour récupérer tes fonds : au pire, tu forces la fermeture, avec un délai et des frais. Sans les deux signatures numériques, personne ne peut déplacer seul les fonds autrement que par cette sortie prévue.

Le routage utilise des paquets en oignon : chaque nœud ne voit que le précédent et le suivant, ce qui protège mieux l'expéditeur qu'une transaction publique. Les commissions de routage sont fixées par chaque nœud. Les montants internes sont exprimés en millisatoshis, ce qui permet des paiements inférieurs au satoshi dans le canal.

Lightning a été proposé en 2015 par Joseph Poon et Thaddeus Dryja, puis spécifié dans les documents BOLT. Il dépend de la chaîne de base pour la sécurité : la chaîne sert de tribunal. Cette logique de calcul déporté rappelle les layer 2 d'Ethereum, avec une différence : Lightning ne publie pas les paiements, seulement l'ouverture et la fermeture.

Pour l'utilisateur, un wallet Lightning ressemble à un wallet ordinaire, mais il faut distinguer deux types. Un wallet où tu gardes tes clés te laisse la responsabilité de surveiller les canaux. Un wallet où un service les garde est plus simple, mais ce service détient alors tes fonds.

Ce qui peut mal tourner

• Rester hors ligne trop longtemps. Si ton partenaire publie un ancien état pendant ton absence et que le délai expire, tu perds la différence. Les tours de garde (watchtowers) surveillent la chaîne pour toi.
• Perdre l'état de ton canal. Restaurer une vieille sauvegarde peut te faire publier un état périmé, et donc te faire punir. Les sauvegardes de canal statiques servent à demander une fermeture, pas à reprendre l'ancien état.
• Prendre la capacité pour de la liquidité. Sans solde entrant, tu ne peux pas recevoir. Sans solde sortant, tu ne peux pas payer. Un paiement échoue souvent pour cette raison, sans perte de fonds.
• Sous-estimer la fermeture forcée. Elle est publiée sur la chaîne, au tarif du moment, avec une attente de plusieurs blocs, souvent des jours, avant de récupérer tes fonds.
• Le blocage de canal. Un attaquant peut envoyer des paiements qu'il ne règle jamais et occuper la liquidité des nœuds pendant la durée du délai, sans payer de commission.
• Confier ses fonds à un wallet sans le savoir. Beaucoup d'applications simples sont en réalité des comptes chez un tiers. Vérifie qui contrôle les clés, comme expliqué dans wallet chaud, wallet froid.

Teste-toi