Qu'est-ce qu'un HTLC ?

HTLC ou Hash Time Locked Contract sont un type de contrats intelligents ou de contrats intelligents utilisés pour créer des canaux de paiement.

UL'une des technologies les plus puissantes du langage de programmation de Script Bitcoin sont les connus Contrat HTLC ou Hash Time Locked. Ce sont un type de contrats intelligents ou contrat intelligent dont la principale capacité est de créer canaux de paiement ou canaux de paiement. De cette façon, les HTLC permettent la construction de technologies telles que Réseau Lightning (LN) à la fois en Bitcoin et dans d'autres crypto-monnaies compatibles avec cette capacité. Cela signifie que les HTLC permettent de créer des protocoles de deuxième couche capables d'accélérer considérablement l'évolutivité de Bitcoin. Tout cela sans renoncer à la sécurité de cette blockchain.

Cependant, les HTLC sont bien plus qu'un simple contrat intelligent. Ils sont l'union de plusieurs autres technologies qui au final permettent une fonctionnalité beaucoup plus complexe et selon les besoins de croissance de Bitcoin.

Dans cet article de Bit2Me Academy, vous en apprendrez plus sur les tenants et aboutissants et le potentiel de cet algorithme blockchain.

Origine du HTLC

L'origine des HTLC remonte à la nécessité de créer des mécanismes qui permettent une plus grande évolutivité dans Bitcoin. Curieusement, les premières idées qui ont conduit au HTLC sont assez originales, curieuses et même problématiques dans certains cas comme vous pouvez le voir ci-dessous :

Chaîne nSequence de Satoshi Nakamoto

La première idée qui a conduit au HTLC est venue du très Satoshi Nakamoto, avec ce qu'on appelle nCanaux de séquence. Ces types de canaux de paiement sont créés à l'aide du OP_CODE nSéquence et nLockTime. De cette manière, un système pourrait être créé dans lequel l'utilisateur pourrait envoyer une transaction avec une valeur de nLockTime (un verrouillage temporel) et une nSequence (une valeur qui permet le remplacement de la transaction par une autre). De cette manière, l'utilisateur peut effectuer un certain nombre d'achats et de paiements "instantanés".

Ils seraient ensuite ajoutés à une transaction finale qui remplacerait la transaction initiale avant que le nLockTime et la nSequence initiaux ne soient finalement fermés. De cette façon, la nouvelle transaction paierait tous les frais des achats effectués dans la même opération.

Ceci est possible car :

1. Les nSequences ont été conçues pour permettre de remplacer les transactions dans le mempool, si cette valeur n'était pas marquée avec la valeur hexadécimale 0xFFFFFFFF, car si elle était marquée avec cette valeur, le TX ne pourrait pas être remplacé. En fait, cette petite conception a été ce qui a conduit à la création du Remplacer par des frais ou RBF. L'idée derrière son utilisation dans les canaux nSequence était d'ajouter des opérations de paiement dans un TX et de le remplacer dans le mempool, jusqu'à ce que finalement ledit TX soit considéré comme une transaction finale (en le marquant avec 0xFFFFFFFF dans sa nSequence).
2. Avec nLockTime, une limite de temps serait fixée pour que les mineurs puissent enfin prendre le TX et le confirmer. Curieusement, nLockTime ne fonctionne que si nSequence est différent de 0xFFFFFFFF, donc cette valeur sert efficacement à garantir que les canaux nSequence sont trompés, garantissant le paiement au vendeur après un certain temps, même si le canal n'a pas été fermé par nSequence.

Certes c'est une solution très basique, à sens unique (seul le créateur du TX pouvait la gérer), avec une durée de vie limitée (l'utilisation de nLockTime et nSequence ne permet pas un fonctionnement infini) et sans règles de consensus sécurisées (tout se passe dans le mempool où rien n'est confirmé). Mais c'était quand même une idée révélatrice.

Et, voir Bitcoin comme un moyen de créer des canaux de paiement et de construire des systèmes alimentés par son OP_CODE a ouvert de nombreuses possibilités, ce que Nakamoto a montré avec grâce avec cette idée. Le meilleur? Cette idée était applicable depuis la version 0.1.0 de Bitcoin, elle fait donc partie du protocole depuis sa création.

Chaînes Spilman et CLTV

Deux autres formes bien connues de canaux de paiement sont Canaux Spilman et les chaînes CLTV. Le premier d'entre eux a été proposé par Jeremy Spilman, dans lequel les transactions multi-signatures sont combinées à l'utilisation de nLockTime pour éviter les pièges qui permettent le vol de fonds. Fondamentalement, un canal Spilman se compose de :

1. Créez une transaction multi-signatures 2 sur 2 où l'acheteur et le vendeur créent le canal de paiement. La transaction est seulement créée, mais pas transmise au réseau tant que l'opération n'est pas terminée. Cette première opération est appelée opération de financement.
2. Ensuite, une transaction est créée qui dépense la précédente en utilisant nLockTime qui garantit le paiement du TX multi-signature. Cette transaction est remise au vendeur, qui la signe et la retourne à l'acheteur.
3. Le premier TX est envoyé au réseau pour confirmation, et une fois confirmé, vous pouvez commencer à commander ce que vous voulez, puisque le canal de paiement a été ouvert.
4. Désormais, à chaque nouvelle transaction de paiement, un TX est créé qui dépense la transaction de financement (la première transaction créée). Cette opération envoie le paiement de ce que vous demandez au vendeur et renvoie la monnaie à l'acheteur. L'acheteur peut dépenser autant qu'il veut tant que son opération de financement le permet, s'il dépasse la limite, il ne pourra pas continuer à dépenser. Si vous avez fini de dépenser, en fermant le canal avec un changement, celui-ci ira automatiquement à l'acheteur.

Ce système peut également être créé à l'aide de l'OP_CODE, OP_CHECKLOCKTIMEVERIFY(CLTV). Dans ce cas, la CLTV permet uniquement l'inclusion de nouvelles conditions de fermeture du canal de paiement qui évitent certains pièges (comme le vendeur ne voulant pas fermer le canal de paiement lorsque vous souhaitez arrêter de consommer). De plus, l'utilisation de CLTV minimise les étapes en n'ayant pas besoin de créer la deuxième transaction du canal Spilman.

Ces deux premières expériences ont conduit à la création des HTLC, qui ont ensuite conduit à la création du Lightning Network. Ceci afin de mettre en œuvre une deuxième couche dans le réseau blockchain Bitcoin pour gérer les transactions en dehors de celui-ci via des canaux de paiement. Cela a été rendu possible grâce au travail de Joseph Poon et Tadge Dryja, qui ont proposé ce système en 2016.

Comment fonctionnent les HTLC ?

Le fonctionnement du HTLC repose sur deux parties très importantes. Le premier est sa capacité à effectuer des hashlocks, ou blocages par hachage des transactions qui sont effectuées. Et la seconde est la capacité d'effectuer timelock, ou les verrous horaires de ces mêmes transactions. Ces deux fonctions réunies permettent aux HTLC d'exécuter des transactions sous certaines conditions convenues lors de l'exécution du contrat. Mieux encore, ces transactions sont protégées au niveau du hachage et de l'heure. Cela les rend très sécurisés par rapport aux modèles de canaux de paiement initiaux, tels que le canal nSequence.

L'idée derrière est que lorsqu'un participant est intéressé à effectuer une transaction, il peut contacter une autre personne et parvenir à un accord. Cet accord vous permet à tous les deux d'effectuer des transactions dans des conditions que vous acceptez tous les deux. Ainsi, les deux parties peuvent être sûres qu'il n'y aura pas de tricherie dans leurs opérations. Cela donne l'assurance que les fonds ne peuvent pas être consultés par malveillance à l'avance. Et, en même temps, que les transactions effectuées soient correctement effectuées.

Pour ce faire, le HTLC crée un hachage unique de la clé privée de la transaction qui est délivrée à chacune des parties (ce qui est possible par le hashlock). De cette façon, chaque partie doit participer à la transaction à la fois pour ouvrir et fermer le canal de paiement. Sans les deux hachages, la transaction (une fois ouverte) ne peut pas être fermée pour réclamer le paiement. Cela force la communication entre les parties pour que la fin de la transaction soit signée ensemble.

Une deuxième protection supplémentaire est donnée par le timelock, avec lequel un délai raisonnable est spécifié afin que ceux qui participent à la transaction puissent effectuer les actions nécessaires pour que la transaction se déroule sans inconvénient. Si ce délai s'écoule et que la transaction ne se clôture pas, les conditions secondaires de ladite transaction sont exécutées, qui permettent de récupérer les fonds auprès de leurs propriétaires d'origine. Bien entendu, les conditions peuvent être différentes, mais le timelock a pour but de laisser le temps aux parties de fermer le canal dans le bon sens, sans recourir à des instructions secondaires.

Le modèle de contrat HTLC a été conçu en pensant au lancement du réseau Lightning de Bitcoin, un réseau de paiements instantanés hors chaîne qui en profite pour offrir la sécurité à ses utilisateurs.

Principales utilisations du HTLC

L'utilisation principale des HTLC est la création de canaux de paiement, comme décrit par Poon et Dryja dans leur travail sur le Lightning Network. En effet, grâce aux HTLC, ce type de système est sécurisé et permet une communication bidirectionnelle, à la fois entre les participants et les créateurs de la chaîne, ainsi qu'avec le réseau. chaîne latérale et la chaîne principale des crypto-monnaies où ledit HTLC est exécuté. En ce sens, les HTLC sont une méthode fiable pour créer ces types de fonctions de paiement avancées, comme LN l'a montré jusqu'à présent.

Une autre utilisation importante des HTLC est dans swaps atomiques ou swaps atomiques. Grâce à leur capacité hors chaîne, les HTLC peuvent intercommuniquer deux chaînes de blocs différentes et permettre à leurs utilisateurs d'effectuer des échanges atomiques instantanés qui peuvent ensuite aller de manière transparente à la chaîne principale.

Avantages et inconvénients de HTLC

L'un des plus grands avantages des HTLC est de faciliter les transactions sur les canaux de paiement P2P. De cette façon, il est facile de créer un réseau de nœuds qui gèrent tous ces canaux hors chaîne et d'acheminer ces paiements afin que les parties reçoivent les paiements en toute sécurité. Ainsi, sans avoir recours à des nœuds intermédiaires, il est possible de créer un réseau de paiement gigantesque, quasi instantané, sécurisé et à très faible coût.

Un autre point en faveur des HTLC est que les transactions de paiement peuvent être protégées avec des conditions bien définies. De cette façon, le vol de fonds ou les actions malveillantes par des parties au sein du système peuvent être évités.

De plus, les HTLC offrent au réseau Bitcoin une grande amélioration de son évolutivité et de sa capacité à effectuer des micropaiements. Tout en réduisant les goulots d'étranglement sur la chaîne, les commissions sont réduites et le réseau évolue pour servir de plus en plus de personnes.

Cependant, tout n'est pas positif. De nombreux experts du monde de la cryptographie ont trouvé des problèmes dans les HTLC. Il y a tout d'abord le point de traçabilité des opérations, ce qui signifie que les paiements effectués avec HTLC ne sont pas anonymes. Un autre inconvénient est que les HTLC peuvent entraîner des systèmes plus complexes et donc des logiciels avec des problèmes de sécurité non détectés.

Autres alternatives à HTLC

Malgré les avantages offerts par la mise en œuvre des HTLC, certains développeurs ont leur intérêt porté sur le développement de nouvelles alternatives à ces contrats intelligents. Les développeurs de l'écosystème Lightning Network unissent leurs forces pour apporter de profonds changements à ce réseau. Ceci dans le but d'utiliser PTLC dans l'exécution de transactions avec un niveau de confidentialité beaucoup plus élevé que ceux actuellement offerts par HTLC.

D'autres contrats intelligents qui émergent dans l'exécution de transactions multi-signatures telles que Racine pivotante. Tout cherche à atteindre une nouvelle ère de contrats intelligents dans le réseau Bitcoin qui offrent une plus grande confidentialité, polyvalence et sécurité aux transactions.