Glossaire / Lightning et couche 2
Delta d'expiration CLTV
- Qu'est-ce qu'un delta d'expiration CLTV ?
- Un delta d'expiration CLTV est le nombre de blocs qu'un nœud Lightning soustrait au timelock d'un paiement entrant avant de le transmettre, valeur annoncée par sens de canal dans le gossip.
Chaque nœud de transfert sur une route Lightning facture deux prix, des frais en millisatoshi et un délai en blocs, et le delta d'expiration CLTV est ce délai. Le BOLT 7 le transporte sous forme de champ de 16 bits dans le message channel_update, aux côtés de fee_base_msat, et chaque côté d'un canal publie sa propre valeur indépendamment. Si un paiement se bloque, cette pile de blocs représente la durée pendant laquelle votre argent reste gelé.
Comment cela fonctionne
Un delta d'expiration CLTV est choisi par le nœud qui effectuera le transfert, et il ne régit que le sens sortant de ce nœud.
La formulation de la spécification est exacte : un nœud doit régler le champ sur le nombre de blocs qu'il soustraira au cltv_expiry d'un HTLC entrant. Le delta n'est donc pas une échéance, c'est un écart. Le nœud accepte un paiement verrouillé jusqu'à une hauteur de bloc absolue, garde le delta pour lui et propose au saut suivant un paiement verrouillé jusqu'à cette hauteur moins le delta. Cet écart est la marge de sécurité du nœud : si le saut en aval règle au dernier moment possible, il reste autant de blocs pour réclamer en amont.
Chaque canal public porte deux de ces nombres, un par sens, chacun signé par le nœud qui l'a fixé. Ils circulent dans channel_update, type de message 258, à côté de htlc_minimum_msat et des deux champs de frais. Seules comptent les mises à jour annoncées par les nœuds qui transféreront : sur une route A vers B vers C vers D, le payeur utilise la mise à jour de B pour B vers C et celle de C pour C vers D, et aucune des siennes.
Les routes sont donc construites à rebours. Le payeur part de la destination avec l'expiration finale minimale demandée par la facture, remonte en ajoutant le delta annoncé de chaque saut, et le total courant devient le timelock du HTLC qu'il remet à son premier pair. Quand un nœud révise ses prix, le BOLT 7 lui demande de continuer à accepter les paramètres précédents pendant 10 minutes, car le gossip n'atteint pas tous les payeurs en même temps.
Où cela se voit
Les deltas d'expiration CLTV déterminent combien de temps un paiement Lightning bloqué immobilise votre solde, et l'exemple de routage du BOLT 7 chiffre deux routes par ailleurs identiques.
Quatre nœuds forment un losange : A, B, C et D, annonçant 10, 20, 30 et 40 blocs, C demandant un delta d'expiration final de 18, que la spécification appelle la valeur par défaut. A envoie 4 999 999 millisatoshi à C. Routé via B, A remet à son pair 5 010 198 millisatoshi, dont 10 199 de frais pour B, et le premier HTLC expire à la hauteur de bloc actuelle plus 80 : 20 blocs pour le saut de B, 18 pour C, et 42 de marge en plus. Routé via D, le même paiement coûte 5 020 398 millisatoshi et expire à la hauteur actuelle plus 100. Même expéditeur, même destinataire, même montant, et 20 blocs d'exposition en plus.
Ces 42 ne sont pas une marge arbitraire. Le BOLT 7 avertit qu'une route construite en additionnant honnêtement les deltas permet à un nœud intermédiaire de calculer sa propre position, et de là de deviner qui est payé, si bien qu'il est conseillé au payeur d'ajouter un décalage aléatoire, obtenu en parcourant le graphe vers l'extérieur depuis le destinataire et en additionnant les deltas rencontrés. La spécification appelle le résultat une extension de route fantôme.
Rien de tout cela ne relève de vous, à moins d'exploiter le nœud de transfert. Phoenix, que notre avis présente comme un véritable nœud Lightning autonome sur le téléphone, publie son prix d'envoi à 0,4 % plus 4 sat, et ce tableau chiffre l'argent, pas les blocs.
Delta d'expiration CLTV vs OP_CHECKLOCKTIMEVERIFY
Un delta d'expiration CLTV est une donnée de politique de routage publiée dans le gossip, tandis qu'OP_CHECKLOCKTIMEVERIFY est l'opcode de script bitcoin qui impose une échéance absolue on-chain.
Ils partagent trois lettres et peu d'autre chose. Un delta est relatif et vit entièrement off-chain : il n'apparaît dans aucun script, aucun nœud complet ne le valide, et le nœud qui l'a fixé le révise avec un nouveau channel_update. OP_CHECKLOCKTIMEVERIFY est inscrit dans les bitcoins eux-mêmes, vérifié par chaque nœud complet, et ne peut plus être modifié une fois ces bitcoins créés.