Dans Lightning Network, l’expéditeur construit généralement la route. À partir du graphe gossip public, des données du destinataire et de ses propres résultats, il estime un chemin; il calcule à rebours montant, frais et CLTV de chaque saut, place les instructions dans un paquet onion et essaie une autre route après un échec. Le graphe ne montrant pas la répartition actuelle des soldes, le routage est une décision probabiliste fondée sur des informations incomplètes et changeantes.
Le routing commence chez le payeur: son wallet ou node choisit un chemin candidat et indique le canal suivant à chaque intermédiaire. Le destinataire fournit identité, features et parfois route hints ou blinded paths; l’expéditeur calcule normalement la partie publique.
BOLT #7 diffuse annonces et channel updates directionnels avec frais de base, frais proportionnels, delta CLTV, minimum, maximum et disponibilité. Ils décrivent politique et topologie annoncées, sans prouver que le peer est en ligne ni que la liquidité suffit.
Le gossip public ne révèle pas la répartition du solde. Le routeur combine liquidité locale connue, capacité, succès, échecs, pénalités et scoring propre. Le chemin théorique le moins cher n’est pas forcément le plus probable.
Montants et expirations se construisent du payee vers le payer. Chaque hop reçoit le montant suivant plus ses frais et un CLTV supérieur de son delta; davantage de sauts augmentent frais totaux et marge temporelle.
BOLT #4 emploie onion routing: le payeur crée un paquet Sphinx avec un payload chiffré par saut. Un intermédiaire connaît ses voisins et son instruction, pas le chemin complet, sa longueur ou sa position; analyse du trafic et collusion restent possibles.
Échec temporaire, frais insuffisants, CLTV incorrect ou next peer inconnu renvoient un signal limité. L’implémentation peut pénaliser, recalculer et réessayer; un résultat ne décrit pas durablement le canal.
Chaque saut doit accepter le HTLC et disposer de liquidité utile dans le bon sens après réserves, HTLC pending et limites min/max. Une forte capacité globale ou de nombreux liens n’éliminent pas un canal déséquilibré.
Avec basic MPP, le payeur répartit total_msat entre plusieurs chemins que le destinataire règle ensemble. MPP exploite une liquidité dispersée mais ajoute HTLC, essais et frais sans créer de capacité.
Les route hints BOLT 11 montrent des derniers sauts privés; BOLT 12 et route blinding fournissent une fin chiffrée via un introduction point. Le payeur doit toujours atteindre ce point et respecter frais et CLTV agrégés.
Notez implémentation, version, montant, plafonds de frais et CLTV, tentatives, chemins, durée et erreur exacte. Comparez la même paire de nodes à des moments proches: le succès appartient à un paiement et un état précis. Sources: BOLT #4 — Onion Routing Protocol; BOLT #7 — P2P Node and Channel Discovery; BOLT #11 — Lightning Payment Encoding; Lightning Labs — Pathfinding; LDK — Routing and Route Parameters.
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.