Lightning Network avancé : routage, splicing, BOLT 12

Lightning Network en 2026 n'est plus l'infrastructure expérimentale de 2019. La capacité publique a dépassé 6 000 BTC, des dizaines de milliers de nœuds tournent en production, et l'écosystème wallet a maturé. Les wallets mobiles encaissent et paient en deux secondes, BTCPay Server l'intègre nativement côté commerçant, des protocoles d'application bâtissent leur couche au-dessus (Nostr Zaps, Fedimint, Cashu).

Cette maturation a apporté trois changements techniques majeurs en 2023-2024 que la documentation grand public n'a pas encore digérés. Le splicing permet d'agrandir ou de réduire un canal ouvert sans le fermer, ce qui change la gestion de liquidité. Les offers BOLT 12 remplacent les factures jetables par des points de paiement statiques réutilisables et signables. Trampoline payments déchargent les wallets mobiles du calcul de route en déléguant à un nœud de confiance.

Cet article entre dans la mécanique de ces évolutions, et couvre aussi le routage multi-path atomique, les channel factories, la gestion fine de la liquidité entrante, l'écosystème watchtower, et l'attaque par jamming qui reste un problème ouvert. Lecture pour qui veut comprendre Lightning au-delà du fait de cliquer Send.

Routage atomique multi-path : MPP et AMP

Le routage Lightning des débuts envoyait un paiement par une route unique. Si l'un des canaux du chemin n'avait pas assez de capacité, le paiement échouait, à recommencer manuellement avec un autre wallet ou en attendant que la liquidité change. C'était la principale source d'échec de paiement entre 2018 et 2020, et l'excuse régulièrement donnée pour ne pas utiliser Lightning.

Multi-Part Payments (MPP, déployé en 2020) découpe un paiement en plusieurs morceaux qui empruntent des routes différentes en parallèle. Envoyer 500 000 sats peut passer en cinq morceaux de 100 000 sats par cinq chemins distincts. Côté destinataire, les morceaux se reconstituent. Chaque morceau utilise le même preimage hash, donc le paiement est atomique : soit tous les morceaux arrivent et le destinataire encaisse, soit l'opération échoue et chaque morceau est rendu à son expéditeur. Ce mécanisme a divisé les taux d'échec par dix sur les paiements supérieurs à 100 000 sats.

Atomic Multi-Path Payments (AMP, 2021) va plus loin en générant un preimage différent pour chaque morceau, ce qui permet à plusieurs paiements indépendants d'un même payeur vers un même destinataire de coexister sans collision de hash. AMP est nécessaire pour le streaming de paiements (un sat par seconde), les abonnements récurrents, et les offers BOLT 12. En 2026, MPP et AMP sont tous deux activés par défaut dans LND, CLN et Eclair. Quand un wallet annonce un taux de réussite de 95 %, c'est très majoritairement grâce à eux.

Splicing : redimensionner sans fermer

Avant 2024, un canal Lightning avait une capacité fixée à l'ouverture. Pour ajouter de la liquidité, il fallait fermer le canal (transaction on-chain, frais, attente de confirmations), récupérer les fonds, puis rouvrir un canal plus grand (nouvelle transaction on-chain, nouveaux frais, nouvelle attente). Pour les routing nodes, c'était une opération régulière coûteuse en frais on-chain et en uptime. Pour les utilisateurs, c'était une friction qui poussait à surdimensionner ou à fermer trop souvent.

Le splicing, déployé courant 2024 dans CLN puis dans Eclair et LND, permet de modifier la capacité d'un canal sans le fermer. Concrètement, on construit une transaction de splice qui consomme l'UTXO de funding actuel et en crée un nouveau avec un montant différent, pendant que le canal continue de fonctionner. Splice-in ajoute des fonds (un nouveau UTXO source les apporte), splice-out en retire (un nouveau UTXO sortant les récupère vers un wallet on-chain). L'opération coûte une seule transaction on-chain au lieu de deux, et le canal n'est pas indisponible pendant la fenêtre.

Conséquences opérationnelles. Première, un routing node peut maintenir ses canaux ouverts pendant des années en réajustant la capacité au fil de l'eau, ce qui améliore les statistiques de réputation et les chemins préférés. Deuxième, un utilisateur mobile peut payer un montant supérieur à sa balance Lightning en splittant on-chain un partie de ses sats vers le canal pendant le paiement (Phoenix l'a démocratisé dès fin 2024). Troisième, le splicing permet aussi de changer le type de canal (passage Taproot par exemple) sans rupture. C'est probablement le changement Lightning le plus important de la période 2024-2026.

BOLT 12 : offers réutilisables

Une facture Lightning classique (BOLT 11) est jetable : elle encode un montant, un destinataire, un hash et une date d'expiration. Une fois payée, elle ne peut pas resservir. Pour qui veut recevoir des dons récurrents, exposer une adresse de pourboire ou facturer des abonnements, c'est lourd : il faut générer une nouvelle facture à chaque transaction, soit côté serveur dynamique, soit côté wallet à la main.

BOLT 12, conçu par Rusty Russell et déployé progressivement depuis 2022, introduit deux primitives : les offers et les invoices. Un offer est un message statique signé par le destinataire, qui décrit qui peut recevoir un paiement et selon quelles conditions (montant fixe ou laissé au payeur, description, expiration). Un offer peut être encodé dans un QR code, partagé sur Twitter, affiché en pied de blog, exactement comme une adresse Bitcoin on-chain. Le payeur scanne l'offer, son wallet contacte le destinataire qui génère à la volée une invoice spécifique au paiement.

L'adoption en 2026 est encore partielle. CLN supporte BOLT 12 nativement depuis 2023, LND depuis fin 2024 (avec des limites sur les offers complexes), Eclair depuis 2024. Côté wallets, Phoenix et Mutiny acceptent les offers, Wallet of Satoshi reste sur BOLT 11. Pour un blog ou un commerce, l'offer remplace la nécessité de tourner un serveur BTCPay capable de générer des invoices : un offer statique imprimé sur un sticker suffit. C'est le pas décisif pour des paiements Lightning vraiment passifs.

Trampoline : déléguer le calcul de route

Calculer une route Lightning demande de connaître le graphe du réseau (canaux, capacités, frais annoncés). Un nœud routing l'entretient en permanence : plusieurs centaines de Mo de données graphe, mises à jour en temps réel via gossip. Pour un wallet mobile sur smartphone qui sort du métro toutes les heures et perd la connexion, maintenir et synchroniser ce graphe est lourd, voire impossible sur les anciens téléphones.

Trampoline payments, conçu par l'équipe Eclair en 2019 et déployé dans Phoenix dès 2020, déplace le calcul de route. Le wallet mobile demande à un nœud trampoline (typiquement un nœud bien connecté que le wallet utilise par défaut) de trouver et d'emprunter la route. Le wallet ne connaît que son canal au trampoline et le destinataire final ; le trampoline s'occupe du reste. Cela permet à un wallet mobile de payer même quand il n'a pas le graphe à jour, ou quand il est connecté à un réseau lent.

Le compromis est une légère perte de privacy face au trampoline (qui voit le destinataire) et une dépendance opérationnelle (si le trampoline est down ou compromis, le paiement échoue). Cela reste acceptable pour des paiements grand public, et c'est ce qui rend Phoenix et Mutiny si fluides côté utilisateur. Les wallets non-custodial qui passent par Trampoline gardent les fonds chez l'utilisateur (la signature reste locale), mais déchargent le calcul de route. C'est un bon compromis entre Wallet of Satoshi (custodial, 100 % serveur) et un nœud LND complet sur Raspberry Pi (full sovereign, lourd).

Liquidité entrante : le vrai problème opérationnel

Recevoir un paiement Lightning demande de la liquidité entrante. Quand on ouvre un canal en y poussant 1 000 000 sats, on dispose de 1 000 000 sats sortants mais zéro entrant. Sans canal où des sats sont du côté distant, on ne peut rien recevoir. C'est le problème opérationnel numéro un de Lightning pour qui veut accepter des paiements, et la cause principale d'abandon pour un commerçant qui découvre Lightning sans accompagnement.

Trois grandes solutions coexistent en 2026. Les services de location de liquidité (Lightning Pool de LND, Magma de Amboss, Liquidity Ads de CLN) qui permettent d'acheter à des routing nodes professionnels une promesse de liquidité entrante pour quelques mois moyennant une commission. Les wallets mobiles modernes (Phoenix, Aqua) qui résolvent le problème automatiquement via splice-in à la première réception. Les LSP (Lightning Service Providers) comme Voltage ou River qui proposent des canaux pré-équilibrés moyennant abonnement.

Pour un commerce qui démarre, la voie pratique en 2026 est l'utilisation d'un wallet ou d'une intégration BTCPay qui appuie sur un LSP : Breez Technology, Blockstream Greenlight, Voltage. Le LSP ouvre et maintient les canaux à votre place, vous payez quelques sats de frais, vous oubliez la mécanique. Pour un node operator qui veut vraiment apprendre, ouvrir manuellement un canal vers Wallet of Satoshi, ACINQ ou River, puis demander un canal en retour, reste l'école qui apprend tout le reste. Compter quelques jours et 50 000 à 200 000 sats de frais pour stabiliser une configuration utile.

Watchtowers et channel factories

Un canal Lightning utilise des transactions de pénalité pour décourager une fermeture frauduleuse. Si la contrepartie tente de fermer le canal en publiant un état ancien (donc plus favorable pour elle), la victime peut publier la transaction de pénalité dans un délai donné (typiquement 144 blocs soit 24 heures), ce qui lui attribue tout le contenu du canal. Mais ce mécanisme suppose que la victime soit en ligne et regarde la blockchain.

Pour un nœud routing professionnel toujours en ligne, ce n'est pas un problème. Pour un utilisateur mobile dont le wallet ne tourne pas 24/7, c'est un risque réel. Les watchtowers résolvent ce problème : un tiers (gratuit ou payant) reçoit du wallet des hints chiffrés sur les états valides du canal, surveille la blockchain à sa place, et publie la transaction de pénalité si nécessaire. Le watchtower ne peut pas voler les fonds (il ne voit que des hints), il agit en gardien passif. LND, CLN et Eclair supportent tous des watchtowers depuis 2020 ; les wallets mobiles modernes en utilisent un par défaut.

Les channel factories, à l'état de recherche depuis 2018 et de premiers déploiements expérimentaux en 2025, vont plus loin. L'idée : une seule transaction on-chain ouvre une factory qui héberge plusieurs canaux Lightning entre plusieurs parties, ce qui mutualise le coût on-chain. Au sein de la factory, les canaux peuvent se réallouer la liquidité sans toucher la blockchain. C'est le pas suivant de la scalabilité Lightning, mais sa généralisation dépend de Taproot et probablement d'un soft-fork supplémentaire type CTV. À surveiller pour 2026-2028.

Jamming : le problème non résolu

Le jamming est l'attaque DoS résiduelle de Lightning. Principe : un attaquant initie un paiement vers lui-même via un long chemin, mais ne révèle jamais le preimage. Les HTLC restent bloqués sur chaque canal du chemin pendant le délai d'expiration (jusqu'à plusieurs heures), immobilisant la liquidité des nœuds intermédiaires. Si l'attaquant inonde le réseau, des nœuds entiers se retrouvent avec leur capacité gelée, sans pouvoir router le trafic légitime.

L'attaque coûte peu à l'attaquant (les paiements échouent, donc pas de frais payés) mais coûte cher aux victimes (opportunité perdue de routage, frais on-chain potentiels pour forcer la résolution). Plusieurs propositions ont émergé depuis 2020 : frais up-front non remboursables, hashed time-lock reverse, reputation scores entre nœuds. Aucune n'a fait consensus, partiellement parce que toutes ajoutent une complexité significative au protocole.

En 2026, deux directions dominent. La première est pragmatique : LND, CLN et Eclair ont ajouté des mécanismes de réputation locale (un nœud qui jamme régulièrement voit ses paiements de routing rejetés par les autres nœuds). La seconde est plus structurelle : des propositions BOLT en discussion (notamment celles autour de l'anti-DoS pricing) pourraient passer en 2027-2028 si elles atteignent consensus. Pour un opérateur, l'hygiène 2026 consiste à activer la réputation locale, limiter le nombre de HTLC simultanés par canal, et accepter que quelques % de capacité reste périodiquement bloquée par des paiements en transit.

Avertissement

Contenu éducatif et informatif uniquement : ni conseil en investissement, ni conseil fiscal ou juridique. Bitcoin comporte des risques importants, dont une forte volatilité et la perte possible du capital investi. Chaque lecteur reste responsable de ses décisions ; en cas de doute, consultez un professionnel qualifié dans votre juridiction.

Voir aussi

Pour les bases du Lightning Network, voir Lightning Network expliqué simplement et Choisir un wallet Lightning. Pour la mécanique des frais Bitcoin et du mempool, voir Frais Bitcoin et mempool. Pour la vue d'ensemble des sujets techniques avancés, voir le guide Approfondir Bitcoin.