Un canal d’état est établi entre deux parties, par le biais d’une transaction qui verrouille un état partagé sur la chaîne de blocs. C’est ce qu’on appelle la transaction de financement ou transaction d’ancrage. Cette transaction unique doit être transmise au réseau et exploitée pour établir le canal. Dans l’exemple d’un canal de paiement, l’état bloqué est le solde initial (en devise) du canal.

Les deux parties échangent alors des transactions signées, appelées transactions d’engagement, qui modifient l’état initial. Ces transactions sont des transactions valides dans la mesure où elles pourraient être soumises pour règlement par l’une ou l’autre des parties, mais sont plutôt détenues hors chaîne par chaque partie en attendant la fermeture du canal. Les mises à jour d’état peuvent être créées aussi rapidement que chaque partie peut créer, signer et transmettre une transaction à l’autre partie. En pratique, cela signifie que des milliers de transactions par seconde peuvent être échangées.

Lors de l’échange de transactions d’engagement, les deux parties invalident également les états précédents, de sorte que la transaction d’engagement la plus récente est toujours la seule qui puisse être remboursée. Cela empêche l’une ou l’autre des parties de tricher en fermant unilatéralement le canal avec un état antérieur expiré qui lui est plus favorable que l’état actuel. Nous examinerons les différents mécanismes qui peuvent être utilisés pour invalider l’état antérieur dans la suite de ce chapitre.

Enfin, le canal peut être fermé soit de manière coopérative, en soumettant une transaction de règlement finale à la chaîne de blocs, soit unilatéralement, par l’une ou l’autre des parties soumettant la dernière transaction d’engagement à la chaîne de blocs. Une option de fermeture unilatérale est nécessaire au cas où l’une des parties se déconnecte de manière inattendue. La transaction de règlement représente l’état final du canal et est réglée sur la chaîne de blocs.

Pendant toute la durée de vie de la chaîne, seules deux transactions doivent être soumises pour minage sur la chaîne de blocs : les transactions de financement et de règlement. Entre ces deux états, les deux parties peuvent échanger un nombre illimité de transactions d’engagement qui ne sont jamais vues par personne d’autre, ni soumises à la chaîne de blocs.

Un canal de paiement entre Bob et Alice, montrant les transactions de financement, d’engagement et de règlement illustre un canal de paiement entre Bob et Alice, montrant les transactions de financement, d’engagement et de règlement.

Pour expliquer les canaux d’état, nous commençons par un exemple très simple. Nous démontrons un canal à sens unique, ce qui signifie que la valeur ne circule que dans une seule direction. Nous partirons également de l’hypothèse naïve que personne n’essaie de tricher, pour garder les choses simples. Une fois que nous aurons expliqué l’idée de base du canal, nous examinerons ce qu’il faut pour le rendre sans confiance afin qu’aucune des parties ne puisse tricher, même si elle essaie de le faire.

Pour cet exemple, nous supposerons deux participants : Emma et Fabian. Fabian propose un service de diffusion vidéo en continu facturé à la seconde via un canal de micropaiement. Fabian facture 0,01 millibit (0,00001 BTC) par seconde de vidéo, ce qui équivaut à 36 millibits (0,036 BTC) par heure de vidéo. Emma est une utilisatrice qui achète ce service de diffusion vidéo en continu auprès de Fabian. Emma achète la vidéo en continu de Fabian avec un canal de paiement, payant pour chaque seconde de vidéo montre Emma achetant le service de diffusion vidéo en continu de Fabian en utilisant un canal de paiement.

Dans cet exemple, Fabian et Emma utilisent un logiciel spécial qui gère à la fois le canal de paiement et la diffusion vidéo en continu. Emma exécute le logiciel dans son navigateur, Fabian l’exécute sur un serveur. Le logiciel inclut les fonctionnalités de base du portefeuille bitcoin et peut créer et signer des transactions bitcoin. Le concept et le terme "canal de paiement" sont complètement cachés aux utilisateurs. Ce qu’ils voient, c’est une vidéo payée à la seconde.

Pour mettre en place le canal de paiement, Emma et Fabian établissent une adresse multisignature 2 sur 2, chacun d’eux détenant l’une des clés. Du point de vue d’Emma, le logiciel de son navigateur présente un code QR avec une adresse P2SH (commençant par "3") et lui demande de soumettre un "dépôt" pour jusqu’à 1 heure de vidéo. L’adresse est alors financée par Emma. La transaction d’Emma, payant à l’adresse multisignature, est la transaction de financement ou d’ancrage pour le canal de paiement.

Pour cet exemple, disons qu’Emma finance la chaîne avec 36 millibits (0,036 BTC). Cela permettra à Emma de consommer jusqu’à 1 heure de diffusion vidéo en continu. La transaction de financement dans ce cas fixe le montant maximum qui peut être transmis dans ce canal, en définissant la capacité du canal.

La transaction de financement consomme une ou plusieurs entrées du portefeuille d’Emma, approvisionnant les fonds. Il crée une sortie d’une valeur de 36 millibits payée à l’adresse multisignature 2 sur 2 contrôlée conjointement entre Emma et Fabian. Il peut avoir des sorties supplémentaires pour revenir au portefeuille d’Emma.

Une fois la transaction de financement confirmée, Emma peut commencer à diffuser la vidéo. Le logiciel d’Emma crée et signe une transaction d’engagement qui modifie le solde du canal pour créditer 0,01 millibit à l’adresse de Fabian et rembourser 35,99 millibits à Emma. La transaction signée par Emma consomme la sortie de 36 millibits créée par la transaction de financement et crée deux sorties : une pour son remboursement, l’autre pour le paiement de Fabian. La transaction n’est que partiellement signée - elle nécessite deux signatures (2 sur 2), mais n’a que la signature d’Emma. Lorsque le serveur de Fabian reçoit cette transaction, il ajoute la deuxième signature (pour l’entrée 2 sur 2) et la renvoie à Emma avec 1 seconde de vidéo. Désormais, les deux parties ont une transaction d’engagement entièrement signée que l’une ou l’autre peut racheter, représentant le solde à jour correct du canal. Aucune des parties ne diffuse cette transaction sur le réseau.

Au tour suivant, le logiciel d’Emma crée et signe une autre transaction d’engagement (engagement #2) qui consomme la même sortie 2 sur 2 de la transaction de financement. La seconde transaction d’engagement alloue une sortie de 0,02 millibits à l’adresse de Fabian et une sortie de 35,98 millibits à l’adresse d’Emma. Cette nouvelle transaction est le paiement de deux secondes cumulées de vidéo. Le logiciel de Fabian signe et renvoie la deuxième transaction d’engagement, ainsi qu’une autre seconde de vidéo.

De cette manière, le logiciel d’Emma continue d’envoyer des transactions d’engagement au serveur de Fabian en échange de diffusion vidéo en continu. Le solde de la chaîne s’accumule progressivement en faveur de Fabian, car Emma consomme plus de secondes de vidéo. Disons qu’Emma regarde 600 secondes (10 minutes) de vidéo, créant et signant 600 transactions d’engagement. La dernière transaction d’engagement (#600) aura deux sorties, divisant le solde de la chaîne, 6 millibits pour Fabian et 30 millibits pour Emma.

Enfin, Emma sélectionne "Stop" pour arrêter le streaming vidéo. Fabian ou Emma peuvent maintenant transmettre la transaction d’état finale pour règlement. Cette dernière transaction est la transaction de règlement et paie Fabian pour toute la vidéo consommée par Emma, remboursant le reste de la transaction de financement à Emma.

Le canal de paiement d’Emma avec Fabian, montrant les transactions d’engagement qui mettent à jour le solde du canal montre le canal entre Emma et Fabian et les transactions d’engagement qui mettent à jour le solde du canal.

Au final, seules deux transactions sont enregistrées sur la chaîne de bocs : la transaction de financement qui établit le canal et une transaction de règlement qui répartit correctement le solde final entre les deux participants.

Le canal que nous venons de décrire fonctionne, mais seulement si les deux parties coopèrent, sans échec ni tentative de tricherie. Examinons certains des scénarios qui cassent ce canal et voyons ce qui est nécessaire pour les réparer :

Ces deux problèmes peuvent être résolus avec des verrous temporels. Voyons comment nous pourrions utiliser des verrous temporels au niveau des transactions (nLocktime).

Emma ne peut pas risquer de financer un multisig 2 sur 2 à moins qu’elle n’ait un remboursement garanti. Pour résoudre ce problème, Emma construit les transactions de financement et de remboursement en même temps. Elle signe la transaction de financement mais ne la transmet à personne. Emma transmet uniquement la transaction de remboursement à Fabian et obtient sa signature.

La transaction de remboursement agit comme la première transaction d’engagement et son verrou temporel établit la limite supérieure pour la durée de vie du canal. Dans ce cas, Emma pourrait définir le nLocktime sur 30 jours ou 4320 blocs dans le futur. Toutes les transactions d’engagement ultérieures doivent avoir un verrou temporel plus court, afin qu’elles puissent être remboursées avant la transaction de remboursement.

Maintenant qu’Emma a une transaction de remboursement entièrement signée, elle peut transmettre en toute confiance la transaction de financement signée en sachant qu’elle pourra éventuellement, après l’expiration du délai, racheter la transaction de remboursement même si Fabian disparaît.

Chaque transaction d’engagement que les parties échangent pendant la durée de vie du canal sera verrouillée dans le futur. Mais le délai sera légèrement plus court pour chaque engagement afin que l’engagement le plus récent puisse être remboursé avant l’engagement précédent qu’il invalide. En raison de nLockTime, aucune des parties ne peut propager avec succès l’une des transactions d’engagement jusqu’à l’expiration de leur verrouillage temporel. Si tout va bien, ils coopéreront et fermeront le canal gracieusement avec une transaction de règlement, rendant inutile la transmission d’une transaction d’engagement intermédiaire. Sinon, la transaction d’engagement la plus récente peut être propagée pour régler le compte et invalider toutes les transactions d’engagement précédentes.

Par exemple, si la transaction d’engagement #1 est verrouillée dans le temps sur 4320 blocs à l’avenir, alors la transaction d’engagement #2 est verrouillée dans le temps sur 4319 blocs dans le futur. La transaction d’engagement #600 peut être dépensée 600 blocs avant que la transaction d’engagement #1 ne devienne valide.

Chaque engagement fixe un délai plus court, ce qui lui permet d’être dépensé avant que les engagements précédents ne deviennent valides montre chaque transaction d’engagement définissant un verrou temporel plus court, lui permettant d’être dépensé avant que les engagements précédents ne deviennent valides.

Chaque transaction d’engagement ultérieure doit avoir un verrou temporel plus court afin qu’elle puisse être diffusée avant ses prédécesseurs et avant la transaction de remboursement. La possibilité de diffuser un engagement plus tôt garantit qu’il sera en mesure de dépenser la sortie de financement et d’empêcher toute autre transaction d’engagement d’être remboursée en dépensant la sortie. Les garanties offertes par la chaîne de blocs Bitcoin, empêchant les doubles dépenses et appliquant des verrous temporels, permettent effectivement à chaque transaction d’engagement d’invalider ses prédécesseurs.

Les canaux d’état utilisent des verrous temporels pour appliquer des contrats intelligents dans une dimension temporelle. Dans cet exemple, nous avons vu comment la dimension temporelle garantit que la transaction d’engagement la plus récente devient valide avant tout engagement antérieur. Ainsi, la transaction d’engagement la plus récente peut être transmise, dépensant les entrées et invalidant les transactions d’engagement précédentes. L’application de contrats intelligents avec des délais absolus protège contre la tricherie par l’une des parties. Cette implémentation n’a besoin de rien de plus que des verrous temporels absolus au niveau de la transaction (nLocktime). Ensuite, nous verrons comment les verrous temporels au niveau du script, CHECKLOCKTIMEVERIFY et CHECKSEQUENCEVERIFY, peuvent être utilisés pour construire des canaux d’état plus flexibles, utiles et sophistiqués.

La première forme de canal de paiement unidirectionnel a été présentée sous la forme d’un prototype d’application de streaming vidéo en 2015 par une équipe de développeurs argentins.

Les verrous temporels ne sont pas le seul moyen d’invalider les transactions d’engagement antérieures. Dans les sections suivantes, nous verrons comment une clé de révocation peut être utilisée pour obtenir le même résultat. Les verrous temporels sont efficaces mais ils ont deux inconvénients distincts. En établissant un verrou temporel maximal lors de la première ouverture du canal, ils limitent la durée de vie du canal. Pire, ils obligent les implémentations de canaux à trouver un équilibre entre autoriser des canaux à longue durée de vie et obliger l’un des participants à attendre très longtemps un remboursement en cas de fermeture prématurée. Par exemple, si vous autorisez le canal à rester ouvert pendant 30 jours, en réglant le délai de remboursement sur 30 jours, si l’une des parties disparaît immédiatement, l’autre partie doit attendre 30 jours pour un remboursement. Plus le point final est éloigné, plus le remboursement est éloigné.

Le deuxième problème est que puisque chaque transaction d’engagement ultérieure doit décrémenter le verrouillage temporel, il existe une limite explicite sur le nombre de transactions d’engagement qui peuvent être échangées entre les parties. Par exemple, un canal de 30 jours, définissant un verrouillage temporel de 4320 blocs dans le futur, ne peut accepter que 4320 transactions d’engagement intermédiaires avant de devoir être clôturé. Il y a un danger à définir l’intervalle de transaction d’engagement de verrouillage de temps à 1 bloc. En définissant l’intervalle de verrouillage entre les transactions d’engagement sur 1 bloc, un développeur crée une charge très lourde pour les participants au canal qui doivent être vigilants, rester en ligne et regarder, et être prêts à transmettre la bonne transaction d’engagement à tout moment.

Maintenant que nous comprenons comment les verrous temporels peuvent être utilisés pour invalider des engagements antérieurs, nous pouvons voir la différence entre fermer le canal de manière coopérative et le fermer unilatéralement en diffusant une transaction d’engagement. Toutes les transactions d’engagement sont verrouillées dans le temps, par conséquent, la diffusion d’une transaction d’engagement impliquera toujours d’attendre jusqu’à ce que le verrouillage ait expiré. Mais si les deux parties s’entendent sur le solde final et savent qu’elles détiennent toutes les deux des transactions d’engagement qui feront éventuellement de ce solde une réalité, elles peuvent construire une transaction de règlement sans verrou temporel représentant ce même solde. Dans une clôture coopérative, l’une ou l’autre des parties prend la transaction d’engagement la plus récente et construit une transaction de règlement qui est identique à tous points de vue, sauf qu’elle omet le verrou temporel. Les deux parties peuvent signer cette transaction de règlement en sachant qu’il n’y a aucun moyen de tricher et d’obtenir un solde plus favorable. En signant et en transmettant de manière coopérative la transaction de règlement, ils peuvent fermer le canal et racheter leur solde immédiatement. Dans le pire des cas, l’une des parties peut être mesquine, refuser de coopérer et forcer l’autre partie à conclure unilatéralement la transaction d’engagement la plus récente. Mais s’ils le font, ils doivent aussi attendre leurs fonds.

Une meilleure façon de gérer les états d’engagement antérieurs est de les révoquer explicitement. Cependant, ce n’est pas facile à réaliser. Une caractéristique clé du bitcoin est qu’une fois qu’une transaction est valide, elle reste valide et n’expire pas. La seule façon d’annuler une transaction est de doubler ses entrées avec une autre transaction avant qu’elle ne soit minée. C’est pourquoi nous avons utilisé des verrous temporels dans l’exemple de canal de paiement simple ci-dessus pour nous assurer que les engagements les plus récents pourraient être dépensés avant que les engagements plus anciens ne soient valides. Cependant, l’enchaînement des engagements dans le temps crée un certain nombre de contraintes qui rendent les canaux de paiement difficiles à utiliser.

Même si une transaction ne peut pas être annulée, elle peut être construite de manière à rendre son utilisation indésirable. Pour ce faire, nous donnons à chaque partie une clé de révocation qui peut être utilisée pour punir l’autre partie si elle essaie de tricher. Ce mécanisme de révocation des opérations d’engagement préalable a été initialement proposé dans le cadre du Lightning Network.

Pour expliquer les clés de révocation, nous allons construire un canal de paiement plus complexe entre deux échanges gérés par Hitesh et Irene. Hitesh et Irene gèrent respectivement des échanges de bitcoins en Inde et aux États-Unis. Les clients de l’échange indien d’Hitesh envoient souvent des paiements aux clients de l’échange américain d’Irene et vice versa. Actuellement, ces transactions se produisent sur la chaîne de blocs Bitcoin, mais cela signifie payer des frais et attendre plusieurs blocs pour les confirmations. La mise en place d’un canal de paiement entre les bourses réduira considérablement les coûts et accélérera le flux des transactions.

Hitesh et Irene démarrent le canal en construisant en collaboration une transaction de financement, chacun finançant la chaîne avec 5 bitcoins. Le solde initial est de 5 bitcoins pour Hitesh et de 5 bitcoins pour Irene. La transaction de financement verrouille l’état du canal dans un multisig 2 sur 2, comme dans l’exemple d’un canal simple.

La transaction de financement peut avoir une ou plusieurs entrées de Hitesh (ajoutant jusqu’à 5 bitcoins ou plus) et une ou plusieurs entrées d’Irene (ajoutant jusqu’à 5 bitcoins ou plus). Les entrées doivent légèrement dépasser la capacité du canal afin de couvrir les frais de transaction. La transaction a une sortie qui verrouille les 10 bitcoins au total sur une adresse multisig 2 sur 2 contrôlée à la fois par Hitesh et Irene. La transaction de financement peut également avoir une ou plusieurs sorties rendant la monnaie à Hitesh et Irene si leurs entrées ont dépassé leur contribution de canal prévue. Il s’agit d’une transaction unique avec des entrées offertes et signées par deux parties. Il doit être construit en collaboration et signé par chaque partie avant d’être transmis.

Maintenant, au lieu de créer une transaction d’engagement unique que les deux parties signent, Hitesh et Irene créent deux transactions d’engagement différentes qui sont asymétriques.

Hitesh a une transaction d’engagement avec deux sorties. La première sortie paie à Irene les 5 bitcoins qui lui sont dus immédiatement. La deuxième sortie paie à Hitesh les 5 bitcoins qui lui sont dus, mais seulement après un verrou temporel de 1000 blocs. Les sorties de transaction ressemblent à ceci :

Irène a une transaction d’engagement différente avec deux sorties. La première sortie paie à Hitesh les 5 bitcoins qui lui sont dus immédiatement. La deuxième sortie paie à Irene les 5 bitcoins qui lui sont dus mais seulement après un verrou temporel de 1000 blocs. La transaction d’engagement qu’Irene détient (signée par Hitesh) ressemble à ceci :

De cette façon, chaque partie a une transaction d’engagement, dépensant la sortie de financement 2 sur 2. Cette entrée est signée par l'autre partie. À tout moment, la partie détenant la transaction peut également signer (remplir le 2 sur 2) et diffuser. Cependant, s’ils diffusent la transaction d’engagement, il paie immédiatement l’autre partie alors qu’elle doit attendre l’expiration d’un verrou temporel. En imposant un délai au remboursement de l’une des sorties, nous désavantageons légèrement chaque partie lorsqu’elle choisit de diffuser unilatéralement une opération d’engagement. Mais un délai ne suffit pas à lui seul à encourager une conduite équitable.

Deux opérations d’engagement asymétriques avec paiement différé pour le titulaire de l’opération montre deux opérations d’engagement asymétriques, où la sortie payant le titulaire de l’engagement est retardée.

Nous introduisons maintenant le dernier élément de ce schéma : une clé de révocation qui empêche un tricheur de diffuser un engagement expiré. La clé de révocation permet à la partie lésée de sanctionner le tricheur en prélevant tout le solde de la chaîne.

La clé de révocation est composée de deux secrets, chacun généré indépendamment par chaque participant du canal. Il est similaire à un multisig 2 sur 2, mais construit à l’aide de l’arithmétique de la courbe elliptique, de sorte que les deux parties connaissent la clé publique de révocation mais que chaque partie ne connaît que la moitié de la clé secrète de révocation.

À chaque tour, les deux parties révèlent leur moitié du secret de révocation à l’autre partie, donnant ainsi à l’autre partie (qui a maintenant les deux moitiés) les moyens de réclamer la sortie de pénalité si cette transaction révoquée est jamais diffusée.

Chacune des transactions d’engagement a une sortie "retardée". Le script de rachat pour cette sortie permet à une partie de la racheter après 1000 blocs, ou à l’autre partie de la racheter si elle a une clé de révocation, pénalisant la transmission d’un engagement révoqué.

Ainsi, lorsque Hitesh crée une transaction d’engagement pour Irene à signer, il rend la deuxième sortie payable à lui-même après 1000 blocs, ou à la clé publique de révocation (dont il ne connaît que la moitié du secret). Hitesh construit cette transaction. Il ne révélera sa moitié du secret de révocation à Irène que lorsqu’il sera prêt à passer à un nouvel état de canal et qu’il voudra révoquer cet engagement.

Le script de la deuxième sortie ressemble à ceci :

Irène peut signer cette transaction en toute confiance, car si elle est transmise, elle lui paiera immédiatement ce qui lui est dû. Hitesh détient la transaction, mais sait que s’il la transmet dans une fermeture de canal unilatérale, il devra attendre 1000 blocs pour être payé.

Lorsque le canal passe à l’état suivant, Hitesh doit révoquer cette transaction d’engagement avant qu’Irene n’accepte de signer la prochaine transaction d’engagement. Pour cela, il lui suffit d’envoyer sa moitié de clé de révocation à Irène. Une fois qu’Irene a les deux moitiés de la clé secrète de révocation pour cet engagement, elle peut signer le prochain engagement en toute confiance. Elle sait que si Hitesh essaie de tricher en publiant l’engagement précédent, elle peut utiliser la clé de révocation pour racheter la sortie retardée de Hitesh. Si Hitesh triche, Irene obtient les DEUX sorties. Pendant ce temps, Hitesh n’a que la moitié du secret de révocation pour cette clé publique de révocation et ne peut pas racheter la sortie avant 1000 blocs. Irene pourra racheter la sortie et punir Hitesh avant que les 1000 blocs ne se soient écoulés.

Le protocole de révocation est bilatéral, ce qui signifie qu’à chaque tour, à mesure que l’état du canal est avancé, les deux parties échangent de nouveaux engagements, échangent des secrets de révocation pour les engagements précédents et signent les nouvelles transactions d’engagement de l’autre. Au fur et à mesure qu’ils acceptent un nouvel état, ils rendent l’état antérieur inutilisable, en se donnant mutuellement les secrets de révocation nécessaires pour sanctionner toute tricherie.

Regardons un exemple de la façon dont cela fonctionne. L’un des clients d’Irene souhaite envoyer 2 bitcoins à l’un des clients de Hitesh. Pour transmettre 2 bitcoins à travers le canal, Hitesh et Irene doivent faire avancer l’état du canal pour refléter le nouvel équilibre. Ils s’engageront dans un nouvel état (état numéro 2) où les 10 bitcoins de la chaîne sont divisés, 7 bitcoins pour Hitesh et 3 bitcoins pour Irene. Pour faire progresser l’état du canal, ils créeront chacun de nouvelles transactions d’engagement reflétant le nouveau solde du canal.

Comme auparavant, ces transactions d’engagement sont asymétriques de sorte que la transaction d’engagement que chaque partie détient les oblige à attendre si ils la remboursent. Surtout, avant de signer de nouvelles transactions d’engagement, ils doivent d’abord échanger des clés de révocation pour invalider l’engagement précédent. Dans ce cas particulier, les intérêts de Hitesh sont alignés sur l’état réel de la chaîne et il n’a donc aucune raison de diffuser un état antérieur. Cependant, pour Irene, l’état numéro 1 lui laisse un solde plus élevé que l’état 2. Quand Irene donne à Hitesh la clé de révocation pour sa transaction d’engagement précédente (état numéro 1), elle révoque effectivement sa capacité à tirer profit de la régression du canal vers un précédent. état parce qu’avec la clé de révocation, Hitesh peut racheter sans délai les deux sorties de la transaction d’engagement précédente. Cela signifie que si Irene diffuse l’état antérieur, Hitesh peut exercer son droit de prendre toutes les sorties.

Il est important de noter que la révocation ne se produit pas automatiquement. Alors que Hitesh a la capacité de punir Irene pour avoir triché, il doit surveiller la chaîne de blocs avec diligence pour détecter des signes de tricherie. S’il voit une diffusion d’une transaction d’engagement préalable, il dispose de 1000 blocs pour agir et utiliser la clé de révocation pour contrecarrer la tricherie d’Irène et la punir en prenant la totalité du solde, les 10 bitcoins.

Les engagements révocables asymétriques avec blocages temporels relatifs (CSV) sont une bien meilleure façon de mettre en œuvre les canaux de paiement et une innovation très importante dans cette technologie. Avec cette construction, le canal peut rester ouvert indéfiniment et peut avoir des milliards de transactions d’engagement intermédiaires. Dans les implémentations prototypes de Lightning Network, l’état d’engagement est identifié par un index de 48 bits, permettant plus de 281 000 milliards (2,8 x 10¹⁴) de transitions d’état dans n’importe quel canal !

Les canaux de paiement peuvent être encore étendus avec un type spécial de contrat intelligent qui permet aux participants d’engager des fonds dans un secret remboursable, avec un délai d’expiration. Cette fonctionnalité est appelée contrats de verrouillage du temps de hachage (Hash Time Lock Contract), ou HTLC, et est utilisée à la fois dans les canaux de paiement bidirectionnels et routés.

Expliquons d’abord la partie "hachage" du HTLC. Pour créer un HTLC, le destinataire prévu du paiement créera d’abord un R secret. Ils calculent ensuite le hash de ce secret H :

Cela produit un hachage H qui peut être inclus dans le script de verrouillage d’une sortie. Celui qui connaît le secret peut l’utiliser pour racheter la sortie. Le secret R est également appelé préimage pour la fonction de hachage. La préimage est simplement la donnée utilisée comme entrée dans une fonction de hachage.

La deuxième partie d’un HTLC est le composant "verrou temporel". Si le secret n’est pas révélé, le payeur du HTLC peut obtenir un "remboursement" après un certain temps. Ceci est réalisé avec un verrouillage temporel absolu à l’aide de CHECKLOCKTIMEVERIFY.

Le script implémentant un HTLC pourrait ressembler à ceci :

Toute personne connaissant le secret R, qui, lorsqu’il est haché, est égal à H, peut racheter cette sortie en exerçant la première clause du flux IF.

Si le secret n’est pas révélé et que le HTLC est réclamé, après un certain nombre de blocages, le payeur peut demander un remboursement en utilisant la deuxième clause du flux IF.

Il s’agit d’une implémentation de base d’un HTLC. Ce type de HTLC peut être échangé par toute personne qui a le secret R. Un HTLC peut prendre de nombreuses formes différentes avec de légères variations dans le script. Par exemple, l’ajout d’un opérateur CHECKSIG et d’une clé publique dans la première clause limite le rachat du hachage à un destinataire nommé, qui doit également connaître le secret R.

Voyons comment cela fonctionne.

Dans cet exemple, nous avons cinq participants : Alice, Bob, Carol, Diana et Eric. Ces cinq participants ont ouvert des canaux de paiement entre eux, par paires. Alice a un canal de paiement avec Bob. Bob est connecté à Carol, Carol à Diana et Diana à Eric. Pour simplifier, supposons que chaque chaîne est financée avec 2 bitcoins par chaque participant, pour une capacité totale de 4 bitcoins dans chaque chaîne.

Une série de canaux de paiement bidirectionnels liés pour former un réseau Lightning qui peut acheminer un paiement d’Alice à Eric montre cinq participants dans un Lightning Network, connectés par des canaux de paiement bidirectionnels qui peuvent être liés pour effectuer un paiement d’Alice à Eric (Canaux de paiement routés (Lightning Network)).

Alice veut payer Eric 1 bitcoin. Cependant, Alice n’est pas connectée à Eric par un canal de paiement. La création d’un canal de paiement nécessite une transaction de financement, qui doit être engagée dans la chaîne de blocs Bitcoin. Alice ne veut pas ouvrir un nouveau canal de paiement et engager davantage de ses fonds. Y a-t-il un moyen de payer Eric, indirectement ?

Acheminement des paiements étape par étape via un réseau Lightning montre le processus étape par étape d’acheminement d’un paiement d’Alice à Eric, à travers une série d’engagements HTLC sur les canaux de paiement reliant les participants.

Alice exécute un nœud Lightning Network (LN) qui assure le suivi de son canal de paiement vers Bob et a la capacité de découvrir des itinéraires entre les canaux de paiement. Le nœud LN d’Alice a également la capacité de se connecter via Internet au nœud LN d’Eric. Le nœud LN d’Eric crée un R secret à l’aide d’un générateur de nombres aléatoires. Le nœud d’Eric ne révèle ce secret à personne. Au lieu de cela, le nœud d’Eric calcule un hachage H du secret R et transmet ce hachage au nœud d’Alice (voir Acheminement des paiements étape par étape via un réseau Lightning étape 1).

Maintenant, le nœud LN d’Alice construit une route entre le nœud LN d’Alice et le nœud LN d’Eric. L’algorithme de routage utilisé sera examiné plus en détail plus tard, mais pour l’instant supposons que le nœud d’Alice puisse trouver une route efficace.

Le nœud d’Alice construit alors un HTLC, payable au hash H, avec un délai de remboursement de 10 blocs (bloc actuel + 10), pour un montant de 1,003 bitcoin (voir Acheminement des paiements étape par étape via un réseau Lightning étape 2). Le supplément de 0,003 sera utilisé pour compenser les nœuds intermédiaires pour leur participation à cette voie de paiement. Alice offre ce HTLC à Bob, déduisant 1,003 bitcoin de son solde de canal avec Bob et l’engageant sur le HTLC. Le HTLC a la signification suivante : "Alice engage 1,003 de son solde de canal à payer à Bob si Bob connaît le secret, ou remboursé sur le solde d’Alice si 10 blocs s’écoulent." Le solde de canal entre Alice et Bob est maintenant exprimé par des transactions d’engagement avec trois sorties : solde de 2 bitcoins à Bob, solde de 0,997 bitcoin à Alice, 1,003 bitcoin engagé dans le HTLC d’Alice. Le solde d’Alice est réduit du montant engagé dans le HTLC.

Bob s’est maintenant engagé à ce que s’il parvient à obtenir le secret ` R ` dans les 10 prochains blocs, il puisse réclamer les 1,003 verrouillés par Alice. Avec cet engagement en main, le nœud de Bob construit un HTLC sur son canal de paiement avec Carol. Le HTLC de Bob engage 1,002 bitcoin dans le hachage H pendant 9 blocs, que Carol peut échanger si elle a le secret R (voir Acheminement des paiements étape par étape via un réseau Lightning étape 3). Bob sait que si Carol peut réclamer son HTLC, elle doit produire R. Si Bob a ` R ` dans neuf blocs, il peut l’utiliser pour lui réclamer le HTLC d’Alice. Il gagne également 0,001 bitcoin pour avoir engagé le solde de son canal pendant neuf blocs. Si Carol n’est pas en mesure de réclamer son HTLC et qu’il ne peut pas réclamer le HTLC d’Alice, tout revient aux soldes de canal précédents et personne n’est à perte. L’équilibre des canaux entre Bob et Carol est maintenant : 2 pour Carol, 0,998 pour Bob, 1,002 commis par Bob pour le HTLC.

Carol s’est maintenant engagée à ce que si elle obtient R dans les neuf prochains blocs, elle puisse réclamer 1,002 bitcoin verrouillé par Bob. Elle peut désormais s’engager sur HTLC sur sa chaîne avec Diana. Elle engage un HTLC de 1.001 bitcoin au hachage H, pour huit blocs, que Diana peut racheter si elle a le secret R (voir Acheminement des paiements étape par étape via un réseau Lightning étape 4). Du point de vue de Carol, si cela fonctionne, elle est plus riche de 0,001 bitcoin et si ce n’est pas le cas, elle ne perd rien. Son HTLC à Diana n’est viable que si R est révélé, auquel cas elle peut réclamer le HTLC à Bob. L’équilibre des canaux entre Carol et Diana est désormais : 2 pour Diana, 0,999 pour Carol, 1,001 commis par Carol pour le HTLC.

Enfin, Diana peut proposer un HTLC à Eric, engageant 1 bitcoin pour sept blocs à hacher H (voir Acheminement des paiements étape par étape via un réseau Lightning étape 5). L’équilibre des canaux entre Diana et Eric est maintenant : 2 à Eric, 1 à Diana, 1 commis par Diana au HTLC.

Cependant, à ce saut dans la route, Eric a le secret R. Il peut donc prétendre au HTLC proposé par Diana. Il envoie R à Diana et réclame le 1 bitcoin, l’ajoutant au solde de son canal (voir Acheminement des paiements étape par étape via un réseau Lightning étape 6). L’équilibre des canaux est maintenant : 1 pour Diana, 3 pour Eric.

Maintenant, Diana a un R secret. Par conséquent, elle peut désormais réclamer le HTLC à Carol. Diana transmet R à Carol et ajoute le bitcoin 1.001 au solde de son canal (voir Acheminement des paiements étape par étape via un réseau Lightning étape 7). Maintenant, l’équilibre des canaux entre Carol et Diana est : 0,999 pour Carol, 3,001 pour Diana. Diana a "gagné" 0,001 pour sa participation à cette voie de paiement.

En revenant sur le parcours, le secret R permet à chaque participant de réclamer les HTLC restants. Carol réclame 1,002 à Bob, fixant le solde sur leur chaîne à : 0,998 à Bob, 3,002 à Carol (voir Acheminement des paiements étape par étape via un réseau Lightning étape 8). Enfin, Bob revendique le HTLC d’Alice (voir Acheminement des paiements étape par étape via un réseau Lightning étape 9). Leur solde de canaux est mis à jour comme suit : 0,997 pour Alice, 3,003 pour Bob.

Alice a payé Eric 1 bitcoin sans ouvrir de chaîne à Eric. Aucune des parties intermédiaires de la voie de paiement n’avait à se faire confiance. Pour l’engagement à court terme de leurs fonds dans le canal, ils peuvent gagner une petite commission, le seul risque étant un léger retard de remboursement si le canal était fermé ou si le paiement acheminé échouait.

Toutes les communications entre les nœuds LN sont cryptées point à point. De plus, les nœuds ont une clé publique à long terme qu’ils utilisent comme identifiant et pour s’authentifier les uns les autres.

Chaque fois qu’un nœud souhaite envoyer un paiement à un autre nœud, il doit d’abord construire un chemin à travers le réseau en connectant des canaux de paiement avec une capacité suffisante. Les nœuds annoncent les informations de routage, y compris les canaux qu’ils ont ouverts, la capacité de chaque canal et les frais qu’ils facturent pour acheminer les paiements. Les informations de routage peuvent être partagées de diverses manières et différents protocoles de routage sont susceptibles d’émerger à mesure que la technologie Lightning Network progresse. Certaines implémentations de Lightning Network utilisent le protocole IRC comme mécanisme pratique permettant aux nœuds d’annoncer les informations de routage. Une autre implémentation de la découverte de route utilise un modèle P2P où les nœuds propagent les annonces de canal à leurs pairs, dans un modèle d'"inondation", similaire à la façon dont bitcoin propage les transactions. Les plans futurs incluent une proposition appelée Flare, qui est un modèle de routage hybride avec des "quartiers" de nœuds locaux et des nœuds de balise à plus longue portée.

Dans notre exemple précédent, le nœud d’Alice utilise l’un de ces mécanismes de découverte de route pour trouver un ou plusieurs chemins reliant son nœud au nœud d’Eric. Une fois que le nœud d’Alice a construit un chemin, elle initialisera ce chemin à travers le réseau, en propageant une série d’instructions cryptées et imbriquées pour connecter chacun des canaux de paiement adjacents.

Il est important de noter que ce chemin n’est connu que du nœud d’Alice. Tous les autres participants de la route de paiement ne voient que les nœuds adjacents. Du point de vue de Carol, cela ressemble à un paiement de Bob à Diana. Carol ne sait pas que Bob transmet en fait un paiement d’Alice. Elle ne sait pas non plus que Diana transmettra un paiement à Eric.

Il s’agit d’une fonctionnalité essentielle du Lightning Network, car elle garantit la confidentialité des paiements et rend très difficile l’application de la surveillance, de la censure ou des listes noires. Mais comment Alice établit-elle ce chemin de paiement, sans rien révéler aux nœuds intermédiaires ?

Le Lightning Network implémente un protocole de routage en oignon basé sur un schéma appelé Sphinx. Ce protocole de routage garantit qu’un expéditeur de paiement peut construire et communiquer un chemin à travers le Lightning Network tel que :

En utilisant ce protocole routé en couches d’oignon, Alice enveloppe chaque élément du chemin dans une couche de cryptage, en commençant par la fin et en remontant. Elle crypte un message à Eric avec la clé publique d’Eric. Ce message est enveloppé dans un message crypté pour Diana, identifiant Eric comme le prochain destinataire. Le message à Diana est enveloppé dans un message crypté avec la clé publique de Carol et identifiant Diana comme le prochain destinataire. Le message à Carol est crypté avec la clé de Bob. Ainsi, Alice a construit cet "oignon" multicouche chiffré de messages. Elle l’envoie à Bob, qui ne peut que déchiffrer et déballer la couche externe. À l’intérieur, Bob trouve un message adressé à Carol qu’il peut transmettre à Carol mais ne peut pas se déchiffrer. En suivant le chemin, les messages sont transférés, décryptés, transférés, etc., jusqu’à Eric. Chaque participant ne connaît que le nœud précédent et suivant dans chaque saut.

Chaque élément du chemin contient des informations sur le HTLC qui doivent être étendues au saut suivant, le montant qui est envoyé, les frais à inclure et l’expiration du temps de verrouillage CLTV (en blocs) du HTLC. Au fur et à mesure que les informations de route se propagent, les nœuds effectuent des engagements HTLC jusqu’au saut suivant.

À ce stade, vous vous demandez peut-être comment il est possible que les nœuds ne connaissent pas la longueur du chemin et leur position dans ce chemin. Après tout, ils reçoivent un message et le transmettent au saut suivant. Ne devient-il pas plus court, leur permettant de déduire la taille du chemin et leur position ? Pour éviter cela, le chemin est toujours fixé à 20 sauts et rempli de données aléatoires. Chaque nœud voit le saut suivant et un message chiffré de longueur fixe à transmettre. Seul le destinataire final voit qu’il n’y a pas de saut suivant. Pour tout le monde, il semble qu’il y ait toujours 20 sauts de plus à faire.

Un Lightning Network est une technologie de routage de deuxième couche. Il peut être appliqué à toute chaîne de blocs prenant en charge certaines fonctionnalités de base, telles que les transactions multisignatures, les verrous temporels et les contrats intelligents de base.

Si un réseau Lightning est superposé au réseau Bitcoin, le réseau Bitcoin peut bénéficier d’une augmentation significative de la capacité, de la confidentialité, de la granularité et de la vitesse, sans sacrifier les principes de fonctionnement sans confiance sans intermédiaires :

Bien sûr, comme mentionné précédemment, le protocole Lightning Network n’est pas le seul moyen de mettre en œuvre des canaux de paiement routés. D’autres systèmes proposés incluent Tumblebit et Teechan. À l’heure actuelle, cependant, le Lightning Network a déjà été déployé sur testnet. Plusieurs équipes différentes ont développé des implémentations concurrentes de LN et travaillent à une norme d’interopérabilité commune (appelée BOLT). Il est probable que Lightning Network sera le premier réseau de canaux de paiement routés à être déployé en production.