Contrats de verrouillage de temps hachés (HTLC) | de Jennifer Ezeobi | Coinmons | mai 2022

Aperçu
Le réseau Bitcoin tient un registre public des transactions. En raison de la limite de taille des blocs, la blockchain de couche 1 elle-même ne peut pas gérer un grand volume de transactions. Le Lightning Network résout ce problème d’évolutivité grâce à l’utilisation de « canaux de paiement ».

Les canaux de paiement sont établis entre deux parties de telle sorte qu’elles peuvent effectuer de nombreux paiements entre elles dans la limite de la capacité du canal (valeur du BTC utilisé pour financer le canal) sans être enregistrées sur la blockchain. Seules les transactions de financement et de clôture doivent être enregistrées en chaîne.

Étant donné que les canaux de paiement sont entre deux parties, il ne serait pas économique pour un utilisateur d’ouvrir un canal de paiement pour effectuer des transactions avec chaque entité différente qu’il souhaite payer. C’est là que nous pouvons utiliser la capacité d’acheminer en toute confiance les paiements sur plusieurs canaux sur le réseau Lightning, car il suffit de trouver un chemin de nœuds connectés (autres participants au réseau Lightning) pour acheminer les paiements jusqu’à votre destination. Cela permet aux nœuds déconnectés de se payer mutuellement.

Un exemple pratique pourrait être qu’Alice veut payer Eric pour la pizza qu’elle a achetée dans son magasin. Alice n’a pas de canal de paiement avec Eric mais en a un avec Bob. Bob à son tour a une chaîne avec Carol qui a une chaîne avec Diana qui à son tour a une chaîne avec Eric.
Alice peut ensuite acheminer le paiement via Bob, Carol et Diana vers Eric.

Pour acheminer les paiements en toute confiance, le réseau Lightning utilise des contrats de verrouillage de temps haché (HTLC)

Que sont les HTLC ?

Un contrat hashed timelock est un type de contrat intelligent qui est à la fois hashlocké et timelocké.
Le hashlock limite la dépense de fonds verrouillés sur un hachage jusqu’à ce qu’une preuve cryptographique soit fournie, tandis que le timelock limite la dépense de fonds jusqu’à un certain moment ou une certaine hauteur de bloc dans le futur.

« Les HTLC comportent deux clauses fondamentales : une clause de paiement sécurisée par un verrouillage de hachage et une clause de remboursement garantie par un verrouillage du temps. Pour ouvrir un verrou de hachage et réclamer un paiement, le destinataire doit révéler la préimage à un résumé de hachage encodé dans le contrat. Pour ouvrir une serrure horaire et recevoir un remboursement, le dépensier doit attendre après un certain temps encodé dans le contrat.

— Bitcoin Optech

Les HTLC sont utilisés dans différentes implémentations de paiement telles que les swaps atomiques – le commerce inter-chaînes entre les crypto-monnaies et les paiements contingents à connaissance nulle qui permettent un échange équitable des biens vendus et des paiements sur le réseau Bitcoin et le réseau Lightning, entre autres.
Pour cet article, je me concentrerais sur leur utilisation dans le réseau Lightning.

HTLC dans le Lightning Network

Les HTLC servent de protocole d’équité pour les paiements effectués sur le Lightning Network.
Le processus d’acheminement des paiements sur le réseau commence par une facture générée par le destinataire et envoyée à l’expéditeur. Cette facture contient des informations pertinentes telles que le hachage de paiement, le montant du paiement, les conseils de routage, etc.
Le hachage de paiement « H » est essentiellement un grand nombre aléatoire qui a été haché avant d’être envoyé à l’expéditeur. Lorsque l’expéditeur reçoit une offre du montant demandé de l’un de ses canaux, il proposera en retour la préimage (qui hache le hachage du paiement) qui permet à la fois de régler le paiement et qui sert de preuve que le destinataire a reçu les fonds car ils sont les seuls à connaître la préimage.

Voici le script Bitcoin qui exécute ceci :

Le script a deux chemins de dépenses possibles. Le premier chemin envoie des fonds à Bob si Bob peut produire `R`

OP IF
OP HASH160 <Hash160 (R)> OP EQUALVERIFY

Si ce chemin n’est pas satisfait, le deuxième chemin rachète les fonds à Alice après l’expiration du délai.

OP ELSE
2 <Alice1> <Bob1> OP CHECKMULTISIG
OP ENDIF 1> <Bob1> OP CHECKMULTISIG
OP ENDIF

Comme simulé précédemment, les HTLC peuvent faciliter le paiement d’Alice de 1 BTC à Eric pour la pizza qu’elle a achetée, comme indiqué ci-dessous :

1. Eric génère un secret (`R`), hache ce secret et l’envoie à Alice. Le secret n’est connu que d’Eric.
2. Le nœud d’Alice calcule le chemin de routage le plus court, calcule les frais (0,003 BTC) pour les nœuds intermédiaires avec le paiement d’Eric (1 BTC) et crée un HTLC pour payer Bob 1,03 BTC s’il peut fournir le secret (également appelé préimage) dans le 10 prochains blocs, sinon, les fonds seront remboursés à Alice.
3. Le HTLC d’Alice incite Bob à créer un HTLC pour payer Carol qui a un canal de paiement, 1.02BTC si elle peut fournir le secret (`R`) dans les 9 prochains blocs, sinon, les fonds lui seront remboursés.
4. Carol crée à son tour un HTLC pour payer Diana 1.01BTC si elle peut fournir le secret (`R`) dans les 8 prochains blocs, sinon, les fonds lui seront remboursés.
5. Diana crée ensuite un HTLC pour payer Eric 1BTC si elle peut fournir le secret (`R`) dans les 7 prochains blocs, sinon, les fonds lui seront remboursés (Diana).
6. À la réception du HTLC, Eric, en tant que destination finale et destinataire, fournit le secret (`R`) qu’il a généré et déverrouille le HTLC pour obtenir le paiement 1BTC.

Puisque Diana a maintenant le secret (`R`), elle fournit ce secret à Carol pour déverrouiller son HTLC et récupérer les fonds enfermés. Ce secret est rétropropagé également via Bob, puis vers Alice. Ceci est illustré dans l’illustration ci-dessus, étapes 6 à 9.
Tous les nœuds de ce chemin de routage peuvent réclamer les fonds verrouillés dans les HTLC et effectuer un routage de paiement réussi.

Limites

Étant donné que le même hachage de paiement est utilisé pour tous les HTLC tout au long d’un itinéraire de paiement, cela pourrait théoriquement entraîner certains problèmes :

1. La réutilisation des factures entraînerait une violation de la vie privée et permettrait aux nœuds qui ont déjà acheminé des paiements à l’aide de cette facture de pouvoir dépenser ce HTLC puisqu’ils ont déjà la préimage/le secret.
2. Susceptibilité à l’attaque par trou de ver : Interception de paiement et réclamation de fonds/frais.

Deux nœuds partageant des informations (par exemple, parce qu’ils appartiennent à la même personne) peuvent savoir s’ils sont ensemble sur une route en voyant qu’ils ont reçu des HTLC avec le même hachage. Cela leur donne non seulement des informations sur le routage auxquelles nous ne voulons pas qu’ils aient accès, mais cela leur permet également d’effectuer une «attaque par trou de ver» qui consiste à travailler ensemble pour voler les frais de tous les sauts intermédiaires entre eux.

-SuredBits