Eltoo, un protocole pour améliorer le Lightning Network
Modifié le 27 juin 2022.
8 minutes de lecture
Le Lightning Network (appelé réseau Lightning en français) est un réseau de paiement décentralisé, instantané et quasi-gratuit bâti en surcouche de Bitcoin. Il représente aujourd'hui la solution la plus plébiscitée pour résoudre les problèmes de scalabilité rencontrés par ce dernier.
Eltoo (déformation de l'anglais « L2 », layer two) est un protocole permettant d'améliorer le maintien des canaux de paiement au sein du réseau Lightning. Il a été décrit par Christian Decker, Rusty Russell et Olaoluwa Osuntokun dans un livre blanc publié en avril 2018. Les auteurs de ce livre blanc ne sont pas des inconnus : Christian Decker et Rusty Russell sont tous deux des développeurs de Blockstream qui contribuent grandement aux spécifications du réseau Lightning, et Olaoluwa Osuntokun est l'actuel directeur technique de Lightning Labs.
Quels problèmes Eltoo cherche à résoudre ?
Le réseau Lightning se fonde sur des canaux de paiement bidirectionnels qui relient les utilisateurs deux-à-deux et leur permettent d'effectuer des échanges sans diffuser de transaction sur la chaîne de blocs de Bitcoin. Ces canaux de paiement sont mis en réseau de sorte qu'un utilisateur n'est pas obligé d'avoir ouvert un canal avec un autre pour effectuer un paiement.
Paiement sur le réseau Lightning : les fonds d'Alice circulent jusqu'à Bob en passant par des nœuds intermédiaires.
Les canaux de paiement utilisés pour le moment sont les canaux dits « de Poon-Dryja » en référence aux co-concepteurs du réseau Lightning : Joseph Poon et Thaddeus Dryja. L'existence d'un canal se base sur trois phases :
- La phase d'ouverture ou d'installation, lors de laquelle les fonds sont bloqués sur une contrat autonome de multi-signature impliquant deux participants ;
- La phase de négociation ou de mise à jour (update), où est ajustée la répartition des fonds au sein du canal sans avoir recours à la chaîne de blocs ;
- La phase de fermeture ou de règlement (settlement), qui voit les fonds être distribués sur la chaîne, généralement selon le dernier état du canal. La fermeture peut avoir lieu de manière consensuelle ou non consensuelle.
La phase de négociation est la plus importante car c'est elle qui permet d'effectuer un grand nombre de paiements sans devoir passer par la chaîne. À chaque mise à jour, chaque participant signe une transaction d'engagement et le donne à l'autre en guise de garantie. S'il n'y a pas de différend, le canal est fermé de manière consensuelle, mais si quelqu'un ne coopère pas, alors l'autre peut diffuser la dernière transaction d'engagement, ce qui permettra de régler le différend sur la chaîne.
Pour en savoir plus sur le fonctionnement des canaux de Poon-Dryja, vous pouvez vous référer à cet article qui présente les contrats impliqués plus en détail : Les smart contracts avec Bitcoin (3/3) : Les cas d’utilisation
Le problème est que les transactions d'engagement se succèdent : un participant pourrait diffuser une ancienne transaction pour gagner des fonds après une mise à jour du canal. Par exemple, Alice pourrait acheter quelque chose à Bob, puis diffuser l'état antérieur du canal. C'est pour cela que les canaux de Poon-Dryja prévoient un un mécanisme de punition : si Bob tente de tricher et si Alice le voit, tous les fonds sont envoyés à Alice, d'où l'incitation à ne pas tricher.
Cependant, ce mécanisme à quelques inconvénients. Il est d'abord très punitif : si quelqu'un diffuse une transaction d'engagement antérieure par accident, il perd tous ses fonds. Ensuite, il est très contraignant : les participants doivent donc garder des copies de tous les états du canal et constamment veiller à ce que les transactions antérieures ne soient pas diffusées sur la chaîne de blocs. Et enfin, il impose aux participants de choisir les frais des transactions à l'avance, ce qui est dans le cas de Bitcoin est plutôt problématique.
De plus, tous les contrats plus complexes sur le réseau Lightning (les canaux à 3 personnes personnes par exemple) doivent tenir compte de ce mécanisme, ce qui allourdit considérablement leur implémentation.
Comment Eltoo améliore le réseau Lightning ?
Avec Eltoo, les canaux utilisés sont les canaux dits « de Decker-Russel-Osuntokun » dont le fonctionnement est plutôt différent de celui des canaux de Poon-Dryja.
Eltoo se base sur une chaîne de transactions, qui ne sont pas censées être diffusées sur la chaîne, mises à part la transaction d'ouverture et la transaction de fermeture. Le principe est le suivant :
- Le canal est ouvert par une transaction d'ouverture (Tu,0), préalablement garantie par une transaction de règlement (Ts,0) qui rembourse les participants en cas de litige.
- Le canal est mis à jour par des transactions de mise à jour (Tu,i) qui invalident les transactions de règlement précédentes (Ts,i-1).
- La fermeture du canal peut se faire après un certain délai d'expiration par la diffusion de la dernière transaction de règlement (Ts,i).
Ce procédé peut être mis en place sur la chaîne de blocs (comme on peut l'observer ci-dessus) : cela ne règle en rien le problème de scalabilité mais permet d'illustrer la chose. Chaque transaction dépense la sortie créée par la transaction précédente. Ainsi, en étant confirmée sur la chaîne, une transaction de mise à jour permet d'invalider la transaction de règlement précédente, par interdiction de double dépense. Ceci est représenté sur le schéma ci-dessous.
Pour reproduire le procédé en dehors de la chaîne, Eltoo fait intervenir ce qu'on appelle des transactions flottantes, qui peuvent dépenser les fonds issus de n'importe quelle transaction de mise à jour précédente. De cette manière, chaque transaction de mise à jour est flottante, ainsi que chaque transaction de règlement, ce qui permet de « sauter » toutes les mises à jour précédentes. De plus, un nombre d'état est inscrit dans chaque transaction (grâce à une utilisation astucieuse du code opération CHECKLOCKTIMEVERIFY) pour ordonner les transactions et ainsi éviter la diffusion d'un état antérieur.
Notez qu'une transaction supplémentaire est ajoutée à la chaîne de transactions pour éviter que le délai d'expiration des transactions de règlement Ts,i soit atteint et qu'elles soient diffusées sur la chaine. Cette transaction envoie simplement les fonds vers un compte multisignatures classique, et est signée et diffusée après que les premières transactions de mise à jour et de règlement (Tu,0 et Ts,0) aient été signées. Le délai d'expiration ne commence que lorsque la transaction Tu,0 est diffusée.
Tout ceci permet d'obtenir un protocole simple de mise à jour du canal, ne faisant pas intervenir mécanisme de punition, et cela pourrait améliorer le réseau Lightning de façon conséquente.
Tout d'abord, Eltoo rendrait le réseau Lightning beaucoup moins punitif : en effet, dans les canaux de Poon-Dryja, si une transaction d'engagement précédente est diffusée par accident, l'utilisateur perd tous ses fonds impliqués dans le canal.
Ensuite, Eltoo permettrait de simplifier l'implémentation des canaux de paiement et de tout ce qui s'y rapporte, ce qui dans le cas d'un système aussi complexe que le réseau Lightning est un bon point. Ainsi, des services comme les watchtowers (tours d'observation) pourraient en bénéficier en n'ayant plus à conserver l'intégralité des transactions d'engagement. Cette facilité d'implémentation pourrait aussi rendre plus facile la création de canaux de paiement à 3 participants ou plus.
Enfin, les frais de fermeture n'auraient plus à être décidés à l'avance comme cela est fait aujourd'hui.
Bien entendu, les canaux de Decker-Russel-Osuntokun utilisant Eltoo ne doivent pas forcément remplacer les canaux de Poon-Dryja dans le réseau Lightning : les deux types de canaux peuvent en effet cohabiter.
Le seul réel défaut d'Eltoo est que son existence dépend d'un élément qui ne se trouve actuellement pas dans Bitcoin : SIGHASH_NOINPUT. En effet, les transactions flottantes que l'on a évoqué plus haut ne peuvent pas être implémentées sans ce dernier.
Le signal de signature SIGHASH_NOINPUT
Le signal de signature SIGHASH_NOINPUT a été proposé pour la première fois par Joseph Poon en février 2016 afin d'améliorer le fonctionnement des canaux de paiement. Il a ensuite été remis au goût du jour avec Eltoo et fait depuis l'objectif d'une proposition d'amélioration de Bitcoin (BIP118).
Dans Bitcoin, les signaux utilisés dans la signature permettent de déterminer quelles parties de la transaction sont concernées par la signature. La plupart du temps les portefeuilles utilisent SIGHASH_ALL qui indique que toutes les sorties de la transaction sont signées (les entrées qui signées par défaut).
Mais il est possible d'obtenir d'autres types de signature. On peut par exemple combiner SIGHASH_ALL avec SIGHASH_ANYONECANPAY pour faire en sorte qu'une seule entrée soit signée.
Cela permet typiquement de créer une transaction de financement participatif qui n'est pas valide tant qu'un montant cible n'est pas atteint : les donateurs peuvent ajouter leur contribution en ne signant que leur entrée, et une fois le montant cible atteint, la transaction est diffusée sur le réseau.
Actuellement, il n'existe pas de signal de signature permettant de ne signer aucune entrée de la transaction et c'est ici qu'intervient SIGHASH_NOINPUT. Tout comme SIGHASH_ANYONECANPAY, il peut se combiner avec SIGHASH_ALL : il en résultera alors que seules les sorties de la transaction seront signées.
Le signal SIGHASH_NOINPUT permet donc d'implémenter les transactions flottantes utilisées dans Eltoo qui n'ont pas à faire référence à une ancienne transaction : la seule condition est que les signatures doivent être valides.
Ce signal « aucun entrée signée » devrait être implémenté dans Bitcoin dans les années à venir sous la forme d'un soft fork, et viendra sans doute avec la version 2 de SegWit (nous en sommes pour le moment à la version 0). Notez qu'une proposition équivalente à SIGHASH_NOINPUT a été faite par Anthony Towns : il s'agit des deux signaux SIGHASH_ANYPREVOUT et SIGHASH_ANYPREVOUTANYSCRIPT, qui ont l'avantage de s'adapter à Taproot.
Conclusion
Ainsi, Eltoo est un protocole qui d'améliorer la mise à jour des canaux de paiement du réseau Lightning. Il évite d'avoir recours le mécanisme de sanction des canaux de Poon-Dryja qui est souvent considéré comme trop punitif (celui qui triche perd tout). Cela apporte de nombreux avantages dont une plus grande simplicité d'implémentation et une meilleure gestion des frais.
Malheureusement, il faudra attente un peu avant que Eltoo ne voie le jour. En effet, ce protocole dépend du signal de signature SIGHASH_NOINPUT, qui n'existe actuellement pas dans Bitcoin, et dont l'implémentation n'aura pas lieu avant quelques années.
Pour aller plus loin...
Christian Decker, Rusty Russell, Olaoluwa Osuntokun, eltoo: A Simple Layer2 Protocol for Bitcoin (livre blanc), avril 2018.
René Pickhardt, Thoughts about eltoo: Another protocol for payment channel management in the lightning network, 17 juillet 2018.
Aaron van Wirdum, The Noinput Class: How a Bitcoin Soft Fork Could Simplify Lightning, 12 juillet 2019.
Christian Decker, [Lightning-dev] Reconciling the off-chain and on-chain models with eltoo, 6 septembre 2019.
Je suis fasciné par les cryptomonnaies et par l’impact qu’elles pourraient avoir sur nos vies. De formation scientifique, je m’attache à décrire leur fonctionnement technique de la façon la plus fidèle possible. Sur Cryptoast, je me propose de vous aider à mieux comprendre comment fonctionnent les cryptomonnaies (principalement Bitcoin, Bitcoin Cash et Ethereum) et quels sont les enjeux qui animent cet écosystème fascinant.
Ludovic Lars
65 articles
