Lightning Routing consiste à trouver et à utiliser un chemin pour payer à travers le réseau Lightning. Ce chemin est composé de canaux de paiement : leurs participants immobilisent ensemble des fonds en Bitcoin et actualisent la part qui appartient à chacun. Ces canaux sont gérés par des programmes appelés nœuds. L’expéditeur planifie généralement le chemin à partir d’informations publiques, de données du destinataire et de tentatives précédentes. Il ne connaît toutefois pas tous les soldes actuels : il doit donc estimer si le chemin fonctionnera et parfois en essayer un autre.
Anna veut payer un café, mais n’a pas de canal avec l’établissement. Elle en a un avec Pavel, qui possède à son tour un canal avec le café. Le paiement peut donc passer par lui : dans le premier canal, une partie du solde passe d’Anna à Pavel ; dans le second, de Pavel au café. Ce n’est pas la même pièce qui circule entre les canaux : leurs soldes changent par étapes liées entre elles. Pavel doit donc disposer de ses propres fonds utilisables du côté où il paie le café. Le portefeuille ou le nœud de l’expéditeur choisit un chemin jusqu’au destinataire et prépare les instructions de chaque étape. Le destinataire fournit les données nécessaires et les fonctions prises en charge, éventuellement avec des informations sur une fin de trajet privée. Les nœuds intermédiaires suivent ensuite ces instructions. Ces nœuds ne recherchent pas chacun de leur côté le chemin complet jusqu’au destinataire. [1] [4]
Gossip désigne la diffusion d’informations entre nœuds. BOLT #7 décrit les annonces de canaux et leurs mises à jour directionnelles : frais fixes et proportionnels, différence d’expiration CLTV, montants minimum et maximum et indicateur de disponibilité. Ces conditions annoncées ne prouvent ni que le voisin est connecté, ni qu’il dispose actuellement de fonds suffisants. Ici, CLTV désigne une échéance exprimée par une hauteur de bloc Bitcoin, c’est-à-dire sa position dans la chaîne, et non par une heure précise. L’écart entre les échéances laisse à l’intermédiaire le temps de réagir si le transfert se bloque. [2]
La capacité totale d’un canal ne révèle pas ce que chaque côté peut envoyer maintenant. L’expéditeur connaît ses propres canaux ; ailleurs, il utilise estimations et historique des réussites et des échecs. Le logiciel évalue donc les frais et la probabilité de réussite. Entre-temps, un autre paiement peut modifier la liquidité, c’est-à-dire les fonds qui peuvent être envoyés dans le sens voulu. [4] [5]
Les étapes sont liées par des HTLC, des paiements conditionnels dont l’achèvement exige de révéler le secret correspondant. Si un paiement n’aboutit pas, ses fonds peuvent être récupérés après l’échéance. Le calcul part du montant destiné au bénéficiaire et remonte le chemin. Chaque intermédiaire doit recevoir le montant pour le nœud suivant plus ses propres frais. Son HTLC entrant doit expirer suffisamment après le sortant, selon la différence CLTV requise. Un trajet plus long peut donc augmenter le coût et la durée d’immobilisation des fonds en cas de problème. [1] [2]
Onion routing dans BOLT #4 utilise la construction Sphinx : chaque étape reçoit des instructions chiffrées séparément. L’intermédiaire connaît ses voisins précédent et suivant ainsi que ses instructions. Le paquet seul ne révèle pas tout le chemin, sa longueur ou sa position exacte. L’analyse du trafic ou la coopération entre nœuds peuvent néanmoins réduire la confidentialité. [1]
Un canal peut échouer temporairement, les frais être trop faibles, le CLTV incorrect ou le voisin suivant indisponible ou inconnu. L’expéditeur reçoit une information limitée sur l’erreur. Son logiciel peut réduire la note d’un chemin, recalculer et réessayer. Ce n’est pas une amende versée au nœud, et un résultat ne constitue pas un jugement permanent de fiabilité. [1] [4]
Trouver des connexions ne suffit pas : chaque étape doit accepter le HTLC et disposer de fonds utilisables suffisants dans le sens voulu. Une partie du solde peut être conservée en réserve ou immobilisée dans des paiements en cours. Les champs techniques htlc_minimum_msat et htlc_maximum_msat fixent aussi les montants minimum et maximum d’un seul HTLC dans ce sens. L’unité msat représente un millième de satoshi ; le satoshi est la plus petite unité de valeur sur la chaîne Bitcoin. Même une limite annoncée élevée ne prouve pas que la liquidité nécessaire est disponible à cet instant. Un seul canal inadapté peut donc bloquer tout le chemin. [2]
Si le destinataire prend en charge basic MPP, c’est-à-dire un paiement divisé en plusieurs parties, l’expéditeur peut répartir le montant total, désigné par total_msat dans le protocole, entre plusieurs chemins. Le destinataire attend les parties nécessaires et les règle ensemble. Cela exploite la liquidité répartie entre canaux, mais MPP n’en crée pas. Le nombre de HTLC, de tentatives et éventuellement les frais augmentent. [1]
Les route hints de BOLT #11 peuvent fournir les détails des dernières étapes non annoncées. Route blinding, utilisé dans BOLT #12, propose plutôt une fin de trajet chiffrée via un nœud d’entrée, l’introduction point. L’expéditeur doit toujours trouver un chemin utilisable jusqu’à ce point et respecter les frais et CLTV cumulés. Une meilleure confidentialité ne garantit pas la livraison. [3] [6] [1]
Pour les paiements courants, le portefeuille se charge de chercher le chemin. Les détails suivants sont surtout utiles aux opérateurs de nœuds et pour comprendre des problèmes récurrents. Notez le logiciel et sa version, le montant, les plafonds de frais et de CLTV, le nombre d’essais, les chemins utilisés, le délai d’achèvement et la cause exacte de l’échec. Comparez la même paire de nœuds à des moments proches. La réussite décrit un paiement donné dans un état donné du réseau, pas une note globale permanente. [4] [5]
Pour une vision complète, lisez aussi Lightning Network, HTLC, Liquidité Lightning, Payment Channel, Bitcoin, Inbound Liquidity. Cette entrée est également citée par HTLC, Liquidité Lightning, BOLT 12, Inbound Liquidity.