Un canal Lightning possède deux soldes dont la somme est limitée par sa capacité. Le solde local utilisable constitue la liquidité sortante ; le solde distant utilisable, la liquidité entrante. Les réserves, les frais de transaction commitment, les HTLC en attente, les règles des canaux et la capacité utilisable de chaque saut déterminent si un montant donné peut réellement parcourir une route.
La capacité du canal est le bitcoin immobilisé dans la sortie de financement. La liquidité n’est que la part actuellement utilisable dans une direction ; un canal d’une capacité de 1 000 000 sats peut donc détenir presque tout d’un côté et ne pas transporter un paiement important dans l’autre sens. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
La liquidité sortante est le montant que le nœud local peut envoyer par un canal après déduction des réserves du protocole, des obligations de frais de transaction commitment et des HTLC en attente. Elle diminue lors d’un paiement ou d’un transfert sortant et augmente quand la valeur arrive du pair. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
La liquidité entrante est le montant que le pair peut envoyer vers le nœud local. Elle est nécessaire pour recevoir par ce canal, mais modifier une demande de paiement ne la crée pas : elle doit exister dans le solde distant ou provenir d’une opération de gestion de liquidité. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
Un paiement routé ne réussit que si chaque saut choisi dispose d’assez de liquidité utilisable dans le bon sens et accepte le HTLC selon ses règles de frais, ses montants minimum et maximum et sa limite temporelle CLTV. Un canal épuisé peut bloquer une route par ailleurs bien connectée. [BOLT #2 — Peer Protocol for Channel Management] [BOLT #7 — P2P Node and Channel Discovery]
channel_reserve_satoshis, les frais de transaction commitment, anchor outputs, les règles de dust, max_htlc_value_in_flight_msat, max_accepted_htlcs et les HTLC déjà en attente peuvent réduire le montant disponible pour un nouveau paiement. Solde du portefeuille, capacité du canal et montant immédiatement routable sont donc trois nombres différents. [BOLT #2 — Peer Protocol for Channel Management]
BOLT #7 permet d’annoncer un canal et ses règles de transfert. Sa capacité peut être déterminée à partir de la sortie de financement identifiée dans la chaîne ; cela ne révèle pas la répartition privée des soldes. L’émetteur estime une route à partir de ses propres informations, des résultats passés et des tentatives de paiement. Un explorateur public ne peut confirmer qu’une route choisie transportera maintenant un montant précis. [BOLT #7 — P2P Node and Channel Discovery]
Un paiement réglé déplace le solde dans chaque canal utilisé : la liquidité sortante baisse et l’entrante augmente du côté émetteur, avec le changement inverse à l’autre extrémité. Le paiement redistribue la capacité existante sans augmenter la capacité totale. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
Un nœud de transfert a besoin de liquidité entrante dans un canal et sortante dans le suivant pour le même HTLC. Un total élevé de sats ne suffit pas s’ils se trouvent dans les mauvais canaux ou du mauvais côté. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity]
Les paiements reçus, le rééquilibrage circulaire, l’ouverture ou la fermeture de canaux, les swaps et le splicing peuvent déplacer la liquidité. Ils diffèrent par leurs frais, leurs traces dans la chaîne, leur durée, la confiance envers la contrepartie et le risque d’échec ; aucune méthode ne crée de liquidité gratuite. Un paiement en plusieurs parties peut combiner des routes, mais exige toujours une capacité directionnelle cumulée suffisante. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Managing Liquidity]
Sur votre propre nœud, contrôlez les soldes locaux et distants de chaque canal, les réserves, les HTLC en attente et la marge pour les frais, puis testez le montant prévu. Notez direction, montant, moment et implémentation : la liquidité change après chaque paiement et n’est pas un score permanent de tout le réseau. [BOLT #2 — Peer Protocol for Channel Management] [Lightning Labs — Understanding Liquidity] [Lightning Labs — Managing Liquidity]
Pour une vision complète, lisez aussi Lightning Network, Payment Channel, Lightning Routing, Inbound Liquidity, Bitcoin, HTLC. Cette entrée est également citée par Payment Channel, Lightning Routing, Volatilité, Capitalisation boursière.