locktime : Lightning : pourquoi avons-nous besoin de décrémenter les timelocks dans les paiements multi-hop ?
J’utilise le scénario suivant pour les deux questions : Alice veut payer 1 BTC à Dave via la route : Alice -> Bob -> Carol -> Dave
Pourquoi avons-nous besoin de timelocks ?
Supposons que la voie de paiement vient d’être établie. Signification : chaque saut de la route (A, B, C, D) a un HTLC avec son ou ses sauts voisins. Cependant, les HTLC n’auraient pas de timelocks. Maintenant, Dave envoie le R secret à Carol qui à son tour envoie R à Bob. Cependant, Bob ne répond pas (par exemple parce que son nœud s’est écrasé). Malheureusement, Alice n’a aucune idée de la raison pour laquelle Bob ne lui envoie pas R. Elle doit donc attendre que Bob redevienne réactif. Maintenant, cela pourrait prendre une heure, quelques jours, quelques semaines ou peut-être qu’il ne répondra plus jamais. Le problème pour Alice est que le HTLC entre elle et Bob est valide indéfiniment. Ainsi, sans timelock, l’argent engagé dans ce HTLC peut être bloqué pour un très long article et Alice ne peut rien y faire.
Quel est l’avantage de décrémenter les timelocks ?
Les timelocks de décrémentation sont utiles pour les sauts intermédiaires (tous les sauts autres que le premier et le dernier). Dans notre exemple, la route est :
A -> B -> C -> D
Donc B et C sont les sauts intermédiaires. Désormais, selon les HTLC, un saut intermédiaire peut réclamer de l’argent au saut précédent et doit payer de l’argent au saut suivant. Par exemple : Carol peut réclamer de l’argent à Bob et doit verser de l’argent à Dave.
D’une manière générale, cela signifie : un saut « HOP » doit s’assurer qu’après que le prochain saut « NEXT » a réclamé l’argent de HOP, HOP pourra réclamer l’argent du saut précédent « PREV » avant le HTLC entre PREV et HOP est invalidé (expiré). Et un moyen simple de le faire est de s’assurer que le verrouillage horaire HTLC entre HOP et NEXT est (significativement) inférieur à celui entre HOP et PREV.
Voici un exemple de ce qui pourrait arriver si tous les HTLC avaient le même timelock. Pour cet exemple, nous supposons que le timelock est „T+10 blocs“ (T = un numéro de bloc fixe). Ainsi, lorsque la hauteur de bloc est à T + 10 blocs ou plus tard, tous les HTLC ont « expiré » et :
- Bob peut récupérer son argent engagé auprès du HTLC avec Carol
- Carol peut récupérer son argent engagé auprès du HTLC avec Dave
Maintenant, une fois la voie de paiement établie, voici ce qui se passe :
Après un délai (à T + 8 blocs), Dave envoie le R secret à Carol. Ce faisant, il a prouvé à Carol qu’il pouvait (légitimement) réclamer l’argent de leur HTLC. Comme les deux parties ne veulent pas encore fermer leur chaîne, elles mettent à jour l’état de la chaîne en conséquence. En faisant cela, Carol vient de verser irrévocablement de l’argent à Dave.
Cependant, Carol n’a pas encore reçu d’argent de Bob. Alors elle envoie R à Bob. Mais Bob ne répond pas ! C’est dommage pour Alice car en 2 blocs (~ 20 minutes) Bob peut récupérer son argent ! Pour éviter cela, Carol doit immédiatement fermer le canal avec Bob en diffusant la transaction d’engagement qui contient le HTLC. En même temps, elle doit également envoyer une autre « transaction de livraison » qui (a l’intention de) transférer l’argent du HTLC (entre elle et Bob) à elle-même. Cependant, il n’y a malheureusement aucune garantie que les deux transactions soient effectivement incluses dans le bloc suivant (T+9). Mais si seul le HTLC est inclus dans le bloc T + 9, Bob peut diffuser sa propre « transaction de livraison » qui (a l’intention de) transférer de l’argent du HTLC maintenant confirmé (via le « chemin de temporisation » de la sortie) à lui-même. Il y a donc maintenant deux « transactions de livraison » dans le mempool qui utilisent la même sortie HTLC. Comme nous le savons, les doubles dépenses ne sont pas autorisées. Ainsi, une seule de ces transactions sera incluse dans un bloc ultérieur. Et si la transaction de Bob sera incluse, Alice perdra son argent.
Cela dit, je pense que techniquement, il serait également possible d’effectuer des paiements multi-sauts sans confiance sans décrémenter les timelocks. Mais ce concept est probablement beaucoup plus facile à mettre en œuvre et à maintenir.
