Inbound Liquidity

Petr tient un café et accepte les paiements sur Lightning Network. Son nœud, le logiciel chargé des paiements, affiche des fonds, pourtant un client n’arrive pas à payer. Le manque de liquidité entrante peut l’expliquer. Un canal de paiement est un accord entre deux nœuds sur la répartition des bitcoins déposés. La part de Petr est le local balance, celle de son partenaire le remote balance. Recevoir un paiement fait passer de la valeur du côté du partenaire vers Petr. Encore faut-il que ce côté ait des fonds à transférer. Le remote balance appartient toujours au partenaire : obtenir la capacité de recevoir n’est ni un don de bitcoin ni une recette déjà gagnée. [1] [6]

Prenons un canal d’une capacité de 1000000 sat. Sat abrège satoshi, une petite unité de bitcoin. Petr dispose d’un local balance de 800000 sat et son partenaire d’un remote balance de 200000 sat. La marge brute de réception est donc de 200000 sat. Si Petr reçoit 100000 sat, son côté passe à 900000 sat et il reste 100000 sat au partenaire. Petr a gagné ce paiement, mais sa marge pour les suivants a diminué. Pour rester clair, l’exemple écarte réserves, frais et paiements en attente appelés HTLC, expliqués plus bas. Si Petr finance seul un nouveau canal sans transfert initial au partenaire, il obtient surtout une capacité d’envoi. Confirmer l’ouverture n’inverse pas cette direction. [1] [2]

Au fil d’une bonne journée, l’argent s’accumule du côté de Petr tandis que la marge entrante des canaux utilisés diminue. Un solde plus élevé peut donc aller avec une moindre capacité à recevoir le paiement suivant. Avec sa propre infrastructure, il faut suivre les canaux utilisables, les montants attendus, les paiements en cours et le coût du réapprovisionnement en liquidité. Certains portefeuilles gèrent une partie de ce travail, sans supprimer le mécanisme. Petr peut même ignorer un échec : le paiement peut s’arrêter avant d’atteindre son nœud. Une facture émise ou une ancienne indication de capacité ne confirme pas un encaissement. [6]

Quand Petr paie un fournisseur par Lightning, le local balance des canaux utilisés diminue et leur remote balance augmente. Cela peut libérer de la marge pour de futurs encaissements. Loop Out fonctionne de façon similaire : au moyen d’un swap, un échange entre couches de paiement, il envoie de la valeur depuis Lightning et reçoit du bitcoin à une adresse sur la chaîne. Il n’a pas besoin de fermer les canaux. Loop In fait l’inverse et transforme des fonds sur la chaîne en solde Lightning dépensable. Aucune opération ne crée de bitcoin. Pour comparer le résultat, il faut compter les frais de routage, du service de swap et de la transaction sur la chaîne, puis vérifier l’achèvement de l’opération. [1] [4]

Un partenaire peut aussi financer un canal vers Petr. Celui-ci obtient alors de la marge entrante sans recevoir en cadeau les fonds du partenaire. La documentation de Lightning Pool décrit un marché de tels accords : bid est une demande de liquidité, ask une offre de fourniture. La location a une durée exprimée en blocs et comporte une prime ainsi que d’autres frais. Un bloc est un groupe de transactions ajouté à la blockchain, l’historique public des transactions Bitcoin. La durée dépend donc de l’arrivée des blocs, pas d’un nombre exact d’heures. Ce n’est pas l’achat de tout le solde distant. La durée convenue ne signifie pas non plus qu’un même montant restera disponible : les paiements modifient la répartition. La disponibilité permanente du canal après la fin de l’accord n’est pas acquise non plus. [1] [5]

Petr peut avoir plusieurs canaux et avoir besoin de marge entrante chez un autre partenaire. Le Circular rebalancing, ou rééquilibrage circulaire, envoie son paiement dans le réseau par un canal et le fait revenir par un autre de ses canaux. Le canal d’envoi gagne de la marge entrante ; celui d’arrivée en consomme. Des fonds passent entre ses côtés des canaux, sans création de capital, et le routage coûte des frais. Il faut un chemin utilisable. Si tous les côtés distants de ses canaux manquent de fonds, aucun ne peut accueillir le retour du paiement. Le rééquilibrage circulaire seul ne règle pas ce problème. [1]

Une partie des fonds doit rester en réserve pour le fonctionnement sûr du canal. D’autres fonds peuvent être temporairement engagés dans des HTLC, des engagements de paiement conditionnels. Le destinataire peut les réclamer en révélant une valeur secrète dont on calcule le hash de paiement convenu, une valeur servant à la vérification. En cas d’échec, la partie qui a envoyé le paiement dispose d’un moyen de récupérer les fonds après l’expiration du délai. BOLT 2, la spécification de gestion des canaux, limite aussi le montant minimal, le nombre de HTLC simultanés et leur valeur totale. Tout le remote balance n’est donc pas forcément disponible pour un autre paiement. Additionner les soldes distants puis retirer une réserve universelle ne suffit pas : chaque canal et son état comptent. [2]

Un paiement traverse généralement plusieurs nœuds. Même si Petr a de la marge, un tronçon précédent peut être hors ligne ou manquer de fonds. BOLT 7 décrit les messages channel_update qui annoncent les conditions de routage dans un sens d’un canal. Ils comprennent les frais et htlc_maximum_msat, la limite d’un paiement conditionnel individuel en msat, des millièmes de satoshi. Ils ne promettent pas un solde actuel sur l’ensemble du chemin. La somme de la marge entrante de Petr ne garantit donc pas de recevoir ce montant de chaque expéditeur. La liquidité du destinataire est une partie nécessaire de la solution, mais pas la seule. [3]