Il s’agit d’un source routing à plusieurs niveaux : l’émetteur construit un trampoline onion interne avec destination, montant et budgets de frais et de CLTV, le transporte dans un onion ordinaire jusqu’au premier trampoline node, qui calcule le chemin intermédiaire concret vers le prochain trampoline hop ou le destinataire ; chaque nœud délégué ne connaît que sa partie.
Le source routing Lightning ordinaire suppose que l’émetteur connaît un graphe réseau utilisable et choisit chaque hop. Pour un téléphone souvent hors ligne, cela impose de télécharger et d’élaguer le channel gossip puis de calculer une route avant le paiement ; Trampoline Routing confie ce travail à plusieurs nœuds ayant une vue plus fraîche du réseau, et non la garde des clés ou des canaux. [6]
L’émetteur choisit le premier trampoline node, fixe le montant, la destination finale et les budgets de frais et de CLTV, puis crée un trampoline onion. Un payment onion ordinaire apporte ce petit onion au nœud ; celui-ci ne révèle que l’instruction du prochain trampoline hop, trouve un chemin concret via des nœuds ordinaires et réemballe l’onion restant pour le segment suivant. [1]
Des nœuds Lightning ordinaires peuvent se trouver entre deux trampoline nodes sans prendre en charge la proposition : ils traitent un onion et un HTLC standard selon BOLT #4. Le trampoline node comble le segment manquant, mais ne peut modifier le montant, les conditions temporelles ou le secret final sans faire échouer un contrôle ultérieur. [2]
La délégation n’est pas une garde. Un trampoline node ne reçoit ni seed, ni clé privée, ni droit unilatéral de dépenser depuis le canal ; il peut toutefois refuser ou retarder le paiement, choisir une route mauvaise ou coûteuse et observer les métadonnées de son segment. Le portefeuille doit imposer les budgets de frais et de CLTV, le payment secret, les erreurs chiffrées et les nouvelles tentatives. [1]
Au début d’octobre 2026, la proposition publique BOLTs #836 reste ouverte, tandis qu’Eclair et lightning-kmp mentionnent déjà l’implémentation du format proposé plus récent et la migration depuis l’ancien protocole expérimental. Cela prouve un déploiement réel, pas une interopérabilité achevée sur tout le réseau ; la configuration actuelle d’Eclair sépare aussi l’activation générale des paiements d’un prototype feature flag. [5]
BOLT #4 protège le contenu des couches et ne révèle à un hop que son prédécesseur et son successeur, sans masquer automatiquement toutes les métadonnées. Un fournisseur trampoline unique peut connaître le client émetteur et, lors d’un relais vers un destinataire non compatible, la destination ; plusieurs trampoline hops et un blinded path peuvent répartir cette connaissance, mais temps, montant et réutilisation restent corrélables. [2]
Route blinding se combine à trampoline en plaçant outgoing_node_id au lieu de outgoing_channel_id dans les données chiffrées. Le trampoline node ne déchiffre que le prochain nœud et calcule la route jusqu’à lui ; le destinataire peut masquer son segment tout en autorisant de nouveaux essais lors d’un manque temporaire de liquidité. [4]
Vérifier un portefeuille exige de contrôler s’il limite réellement le gossip, comment il choisit les trampoline nodes, quels feature bits et onion TLV il emploie, si le format est ancien ou proposé, comment il impose les budgets de frais et de CLTV, gère les erreurs et MPP, et si une destination non compatible révèle au nœud plus que l’utilisateur ne l’imagine. [3]
Pour une vision complète, lisez aussi Lightning Network, Lightning Routing, Lightning Service Provider, HTLC, Payment Channel, Confidentialité de Bitcoin.
01Un trampoline node peut-il voler un paiement Lightning ?+
La délégation de la recherche de route ne lui donne ni clés privées ni moyen de contourner les conditions du paiement. Il peut néanmoins refuser, retarder, essayer des routes coûteuses ou recueillir des métadonnées. Le portefeuille doit borner frais et CLTV, valider l’onion et le payment secret, et pouvoir choisir un autre nœud ou essai.
02Trampoline Routing est-il identique à un LSP ?+
Non. Un LSP est un rôle opérationnel pouvant fournir connexion, canal et liquidité ; un trampoline node calcule un segment délégué. Un même opérateur peut assurer les deux, mais les rôles diffèrent et leur concentration accroît la dépendance de disponibilité et de confidentialité.