Aller au contenu
Financial Context Wiki

Contrat à verrouillage par hachage et délai (HTLC)

Un HTLC rend un paiement réclamable avec une préimage avant l'échéance et remboursable par une autre voie après. Découvrez son rôle dans les canaux de paiement et swaps atomiques, ainsi que ses risques.

Mis à jour

À des fins éducatives uniquement ; ceci ne constitue aucun conseil financier, juridique ou de sécurité. La sûreté d’un HTLC dépend des scripts ou contrats exacts, des règles des chaînes, de la politique de confirmation, des frais, de la surveillance et d’une action rapide.

Réponse directe

Un contrat à verrouillage par hachage et délai (HTLC) est un paiement conditionnel doté de deux voies de dépense concurrentes. Avant l’échéance, le bénéficiaire peut réclamer les fonds en révélant une valeur x dont le hachage correspond à la valeur engagée h = H(x) et en satisfaisant les signatures ou autorisations requises. Après, le payeur peut emprunter la voie de remboursement. L’ordre exact à la limite relève de la chaîne et du contrat, pas du mot « avant ».

Le verrou de hachage relie les actions : apprendre la même préimage après un paiement sortant peut permettre de régler un paiement entrant associé. Le verrou temporel borne la durée conditionnelle. Les canaux de paiement s’en servent pour relayer des paiements et les swaps atomiques pour coordonner des transferts sur des systèmes distincts.

Un HTLC n’est pas automatiquement sans confiance, atomique, privé ni auto-exécutant. Il faut aussi du code correct, des encodages compatibles, des échéances décalées, des hypothèses de finalité, des frais disponibles, une surveillance et une confirmation à temps. Le HTLC de Lightning est une conception Bitcoin spécifiée ; un autre contrat peut avoir une sémantique différente.

  • Branche de hachage : révéler la préimage et satisfaire l’autorisation de succès tant que la voie est valide.
  • Branche temporelle : satisfaire l’autorisation de remboursement après maturation du verrou absolu ou relatif.

Fonctionnement

Pour un paiement, Bob choisit une préimage neuve et imprévisible x, calcule h = H(x) et remet h à Alice. Alice verrouille les fonds selon des règles qui engagent h, nomment les parties autorisées et fixent l’échéance T.

  • Alice vérifie algorithme, encodage, montant, actif, bénéficiaire, destination de remboursement, chaîne et échéance avant financement.
  • Bob vérifie la sortie réellement financée ou le contrat déployé, et non un brouillon ou l’interface.
  • Pour réclamer par la branche de succès, Bob fournit x ; la logique vérifie H(x) = h et l’autorisation.
  • La publication ou transmission de x peut permettre à Alice ou à un intermédiaire de régler un autre HTLC portant le même hachage.
  • Sans succès à temps, le remboursement devient admissible à T ; cela ne le diffuse ni ne le confirme.
  • Il faut encore préparer ou conserver la transaction, payer des frais suffisants, l’envoyer, surveiller remplacements et conflits et obtenir les confirmations.
  • Après divulgation de x à une contrepartie ou chaîne publique, il faut le considérer public et ne pas le réutiliser ailleurs.

Bitcoin distingue les verrous absolus et relatifs. OP_CHECKLOCKTIMEVERIFY du BIP 65 bloque la dépense jusqu’à la hauteur ou l’heure de bloc encodée par le locktime ; OP_CHECKSEQUENCEVERIFY du BIP 112 attend l’âge relatif requis de l’entrée. Les champs de transaction doivent aussi être compatibles. Un verrou temporel est une règle de validation, pas un planificateur.

Dans Lightning, update_add_htlc transporte montant, payment_hash et cltv_expiry. Chaque relais propose un HTLC sortant expirant avant l’entrant correspondant, afin de réclamer en amont après réception de la préimage. BOLT 3 définit sorties d’engagement, voies HTLC-success et HTLC-timeout, signatures, révocation, suppression dust et délais ; deux branches ne constituent pas un canal complet.

Exemple

À titre pédagogique, Alice échange 1 BTC contre les 20 ETH de Bob. L’exemple illustre seulement l’ordre : la production exige du code audité pour chaque chaîne et ne doit pas recopier ces durées nominales.

  • Alice produit de nouveaux x et h = H(x), puis verrouille 1 BTC pour que Bob réclame avec la préimage et qu’Alice rembourse après 48 hours.
  • Après vérification de la transaction Bitcoin et de la politique de confirmation, Bob verrouille 20 ETH avec hachage et encodage compatibles ; la voie d’Alice finit après 24 hours, puis vient le remboursement de Bob.
  • Avant de révéler x pour réclamer 20 ETH, Alice vérifie ID Ethereum, bytecode, adresse, actif, montant, parties, h et les deux voies.
  • Bob apprend x par la réclamation ou le message convenu et tente la voie Bitcoin avant son échéance plus tardive.
  • Si l’échange s’arrête avant la divulgation, chaque remboursement ne devient valable que selon sa chaîne et doit être envoyé puis confirmé.

L’écart entre 48 hours et 24 hours est une marge de réaction, pas une valeur universelle. Il faut modéliser réorganisations, temps de bloc, finalité, exécution, relais, mempool, frais, censure et latence sur les deux systèmes. Le second acteur ne doit pas avancer uniquement parce que l’interface indique « confirmé ».

Risques

  • Mauvais engagement : algorithme, longueur ou encodage diffèrent et le même x ne fonctionne pas des deux côtés.
  • Mauvais artefact : sortie, ID de chaîne, adresse, bytecode, actif, montant, bénéficiaire ou remboursement diffèrent de l’interface.
  • Ordre dangereux : échéances identiques ou trop proches empêchent de réclamer en amont après paiement en aval.
  • Erreur de limite : hauteur, heure de bloc, horodatage, âge relatif et comparaisons < et <= ne sont pas équivalents.
  • Aucun remboursement automatique : la maturité valide seulement la dépense ; portefeuille, nœud, utilisateur ou veilleur doit agir.
  • Frais et dust : une réclamation peut être non rentable, supprimée, bloquée ou impossible sans actif natif de frais.
  • Confirmation et réorganisation : voir transaction ou préimage ne signifie pas règlement irréversible.
  • Course et congestion : succès, timeout, remplacement, conflit ou retard hostile consomment la marge.
  • Implémentation : des défauts de script, contrat, portefeuille, signature, nonce, RPC ou client peuvent invalider les voies.
  • Surveillance : une partie hors ligne peut rater divulgation, échéance, fermeture forcée, remplacement ou dernier envoi utile.
  • Vie privée : hachages réutilisés, préimages, montants, horaires et événements peuvent corréler des transferts.
  • Option et blocage : une partie peut immobiliser la liquidité puis abandonner ; achèvement et compensation ne sont pas garantis.

Avant de risquer une valeur, tester succès et remboursement avec un montant négligeable, consigner artefacts et échéances, réserver les frais et attribuer surveillance et diffusion en cas de panne.

Idées reçues

  • « Les fonds reviennent automatiquement à l’échéance. » En général, seul le remboursement devient possible ; il faut le diffuser et le confirmer.
  • « Satisfaire H(x) = h constitue tout le contrat. » Signatures, branches, champs, règles, révocation et autorisation comptent aussi.
  • « La même échéance des deux côtés est équitable. » L’intermédiaire ou second acteur a besoin d’une marge en amont après avoir appris x.
  • « Une préimage visible garantit le temps de réclamer. » Confirmations, réorganisation, congestion, frais et censure peuvent l’épuiser.
  • « Atomique signifie que deux chaînes changent dans une transaction indivisible. » Des états séparés sont coordonnés ; abandon, remboursement et états unilatéraux temporaires subsistent.
  • « Les HTLC sont anonymes et éliminent toute confiance. » Ils divulguent des signaux et dépendent du code, des chaînes, des clés, de la surveillance et des opérations.

Sujets associés

Sources

Navigation

Rechercher dans le wiki...