La liquidité Lightning est la possibilité d’envoyer ou de recevoir de l’argent par un canal de paiement. Un canal de paiement commence par des fonds verrouillés dans Bitcoin. Ses participants peuvent ensuite modifier leur répartition sans inscrire chaque paiement individuel sur la chaîne. La liquidité sortante provient des fonds utilisables de ton côté ; la liquidité entrante, de ceux de ton partenaire. La capacité totale comprend les deux côtés : elle ne suffit donc pas à déterminer le montant qui peut passer dans un sens précis.
Anna et Pavel ont un canal d’une capacité de 1 000 000 sat : un million de satoshis, les plus petites unités sur la chaîne Bitcoin. Imaginons une situation simplifiée où Anna possède 800 000 sat et Pavel 200 000 sat. Pour comprendre le mécanisme, laissons de côté les réserves, les frais et les paiements en attente. Anna peut envoyer de l’argent à Pavel depuis son côté ; elle ne peut en recevoir de lui que depuis le sien. Pavel ne peut donc pas lui envoyer 300 000 sat par ce canal, malgré sa capacité totale d’un million. Aucun argent n’a disparu. Sa répartition ne permet simplement pas ce paiement. [1] [3]
La liquidité sortante est le montant utilisable pour un paiement qui part de chez toi. Dans notre exemple, elle repose sur les 800 000 sat d’Anna, mais le maximum réel est généralement inférieur à cause des réserves, des frais et des paiements en attente. Si Anna paie une autre personne que Pavel, la première étape passe toujours par l’un de ses canaux. Un nœud est le logiciel qui gère les canaux et traite les paiements Lightning. Les nœuds suivants doivent disposer de leurs propres fonds pour les étapes suivantes. Des bitcoins détenus hors des canaux n’augmentent pas automatiquement sa liquidité sortante : le portefeuille doit employer un mécanisme adapté pour transférer cette valeur vers Lightning. [1] [3]
La liquidité entrante est le montant que ton partenaire peut t’envoyer. Si Anna ouvre un canal dont elle possède presque tous les fonds, elle peut facilement envoyer, mais dispose de peu de marge pour recevoir. Créer une nouvelle demande de paiement ne change pas cette répartition. Il lui faut un canal dont l’autre participant détient un solde utilisable. Certains portefeuilles l’obtiennent auprès d’un prestataire et masquent cette complexité à l’utilisateur, souvent contre des frais. La capacité entrante n’est pas de l’argent supplémentaire qu’Anna possède déjà : c’est la possibilité de recevoir un paiement futur. [1] [3] [5]
Anna paie maintenant 100 000 sat à Pavel. Dans notre exemple simplifié, les soldes passent à 700 000 sat pour Anna et 300 000 sat pour Pavel. La capacité reste de 1 000 000 sat. Anna peut moins envoyer, mais davantage recevoir en retour ; pour Pavel, c’est l’inverse. Lorsqu’un portefeuille utilise plusieurs canaux, seuls ceux empruntés par le paiement changent. Le sens compte donc toujours. Une mesure de liquidité prise le matin ne décrit pas forcément ce qui pourra être envoyé le soir. [1] [3]
Un paiement vers un destinataire éloigné traverse plusieurs canaux. Chacun doit disposer d’une liquidité utilisable suffisante dans le bon sens, y compris pour les frais des étapes suivantes. Si une étape ne peut pas laisser passer le paiement, cette route échoue même si les autres canaux ont une grande capacité. Le portefeuille peut essayer une autre route ou répartir un paiement compatible en plusieurs parties. Cela ne crée pas les fonds manquants. Le montant n’est pas la seule contrainte : les délais comptent aussi. Un HTLC est un paiement conditionnel qui peut être réglé en prouvant la connaissance d’un secret précis. Les règles liées à CLTV fixent des échéances en blocs ; les écarts entre elles laissent aux intermédiaires le temps de régler le paiement sur la chaîne Bitcoin si la transmission se bloque. [1] [2]
Un intermédiaire doit pouvoir recevoir par un canal et envoyer le paiement lié par un autre. Un total élevé de soldes ne suffit pas. Si ses fonds se trouvent de son côté du mauvais canal, il risque de ne pas pouvoir les utiliser sur la route choisie. Il lui faut de la liquidité entrante dans le premier canal, puis sortante dans le second. Les conditions HTLC relient ces étapes : ces paiements dépendent de la connaissance d’un secret précis et de règles temporelles. L’intermédiaire ne se contente donc pas de la promesse que le participant précédent le paiera plus tard. [1] [3]
Les paiements reçus et envoyés modifient naturellement la liquidité. L’opérateur de plusieurs canaux peut aussi effectuer un rééquilibrage circulaire : envoyer un paiement par une route et le recevoir en retour par une autre pour déplacer les soldes entre ses propres canaux. Un swap échange des fonds sur la chaîne contre des fonds Lightning, ou l’inverse. Splicing permet de modifier le financement d’un canal compatible sans la procédure habituelle de fermeture et de réouverture. Ouvrir un autre canal est également possible. Ces méthodes diffèrent par leurs frais, leur durée, leurs traces sur la chaîne, la confiance requise et leur risque d’échec. Aucune ne crée d’argent : choisis selon ton besoin d’envoyer, de recevoir, ou des deux. [1] [4]
Commence par distinguer envoi et réception, puis vérifie que le portefeuille et le nœud partenaire sont en ligne. Sur ton propre nœud, compare les soldes local et distant de chaque canal, les réserves, les paiements en attente et les frais. Avec un portefeuille géré par un prestataire, vérifie ce que signifie réellement son montant disponible. Un échec ne prouve pas à lui seul une perte d’argent : une étape peut manquer de liquidité, une limite peut s’appliquer ou une panne temporaire survenir. Un petit paiement d’essai ne vérifie que ce montant à cet instant ; il ne garantit pas le passage de tous les paiements suivants. [1] [3] [4]
Les opérateurs doivent distinguer plusieurs limites. Une sortie de transaction indique un montant et les conditions permettant de le dépenser. channel_reserve_satoshis désigne les fonds qui doivent rester en réserve. Une partie peut être engagée dans des HTLC en attente, des paiements conditionnels non terminés. Les limites suivantes concernent les HTLC proposés par l’autre participant. max_htlc_value_in_flight_msat limite leur valeur totale et max_accepted_htlcs leur nombre ; le msat est un millième de satoshi utilisé dans les calculs Lightning. Selon le type de canal interviennent aussi les frais de la commitment transaction permettant de le fermer, et éventuellement des anchor outputs : des sorties spéciales permettant d’ajouter une transaction pour augmenter les frais de l’ensemble. Les règles Dust déterminent quelles sorties sont trop petites pour figurer dans cette transaction. Calcule donc le maximum disponible selon l’implémentation et le type de canal, sans soustraire une réserve supposée universelle. [1] [6]
BOLT #7 décrit les annonces de canaux et les règles de transmission des paiements. Pour un canal annoncé, on peut retrouver sur la chaîne sa sortie de financement et sa capacité. Cela ne révèle pas la répartition actuelle entre ses participants. L’expéditeur choisit sa route à partir de ses informations, des résultats précédents et de tentatives de paiement, pas d’une liste publique exhaustive de soldes en temps réel. Un explorateur peut donc afficher un grand canal sans prouver que ton montant peut le traverser maintenant dans le bon sens. [2]
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.