Le Lightning Network

Après plusieurs années de recherche et de développement, le Lightning Network (Réseau Éclair), une couche secondaire du protocole Bitcoin, est désormais fonctionnel et déployé. Cette solution technique élaborée permet, entre autres, d’améliorer grandement la capacité de mise à l’échelle du réseau; elle est globalement considérée comme la meilleure réponse aux problèmes de montée en charge qu’éprouve Bitcoin de par son succès. Présentation de son fonctionnement dans les grandes lignes et des implémentations disponibles.

Qu’est-ce que le Lightning Network ?

Le whitepaper : The Bitcoin Lightning Network – Scalable Off-Chain Instant Payments par Joseph Poon et Thaddeus Dryja.

Présentation générale

Bitcoin, par conception, présente certaines limitations :

• Le délai de confirmation d’une transaction sur la blockchain est a minima de dix minutes; et on considère que six confirmations sont nécessaires pour une sécurité optimale.
• Les frais sont variables, et ne sont pas adaptés aux micro-transactions qui sont de l’ordre de quelques centimes.

Le Lightning Network contourne ces limitations en utilisant judicieusement le système de script de Bitcoin, qui permet notamment de créer des paiements conditionnels (smart contracts, multi-signatures) et des tours de passe-passe cryptographiques ingénieux.

Historique

Le Lightning Network est le fruit d’une longue réflexion. L’idée de créer des réseaux de canaux de paiements fonctionnant hors de la chaîne principale, afin de préserver l’utilisation des ressources du réseau, permettre son utilisation à grande échelle et effectuer des paiements instantanés aux frais minimes remonte à plusieurs années. Aaron van Wirdum, de Bitcoin Magazine, a dressé l’historique du Lightning Network dans un excellent article.

Le point de départ est une idée de Satoshi Nakamoto lui-même, qui dans une des premières versions du code source, suggère une méthode pour mettre à jour des transactions qui ne sont pas encore confirmées sur la blockchain : il s’agit bien d’un canal de paiement basique où le solde d’une adresse est modifié plusieurs fois hors-chaîne avant qu’une transaction finale ne soit inscrite dans le registre et valide le solde définitif des adresses concernées par la transaction.

Reprenons donc l’historique d’Aaron van Wirdum :

• Durant l’été 2011, “hashcoin” décrivit le fonctionnement basique d’un canal de paiement basé sur les multi-signatures et utilisant un timelock (délai d’expiration), permettant ainsi de ne pas compromettre les fonds des parties si l’une d’entre elles venait à ne pas respecter son engagement. Le fonctionnement de ce canal de paiement était cependant unidirectionnel.
• En 2013, Mike Hearn (désormais considéré comme un traître par les “maximalistes” pour avoir rejoint le consortium R3CEV après avoir critiqué l’immobilisme de la communauté Bitcoin) publia dans une mailing list une explication plus détaillée du fonctionnement des canaux de paiements tels que suggérés par Satoshi, dévoilant ainsi une partie de ses échanges privés avec le créateur de Bitcoin.
• En avril 2013, une autre description d’un canal de paiement fut proposée par Jeremy Spilman, améliorée par Mike Hearn puis codée par le co-fondateur de Blockstream Matt Corallo vers la mi-2013.
• En 2014, Alex Akselrod proposa un premier canal de paiement bi-directionnel en jouant sur les timelocks, mais ce ne fut jamais implémenté.

L’idée des canaux de paiements est donc ancienne, mais créer un réseau de canaux de paiements hors-chaîne, sans se reposer sur des tierces parties, était plus difficile à conceptualiser. Plusieurs experts se sont alors progressivement rapprochés de la conceptualisation de Lightning Network actuel :

• Un premier système fut imaginé par le mathématicien Meni Rosenfeld durant l’été 2012. Un processeur de paiement devait effectuer les échanges hors-chaîne entre différentes paires d’utilisateurs. Cette solution fut jugée trop centralisée par la communauté.
• En 2014 et 2015, plusieurs propositions furent faites, sans voir le jour. Parmi les contributeurs se trouvent Peter Todd, mais aussi le processeur de paiement historique BitPay ou encore la startup suédoise Strawpay.
• C’est encore le prolifique Alex Akselrod qui proposa une solution trustless de réseaux de canaux de paiements; mais comme elle reposait uniquement sur les timelocks pour garantir le remboursement des utilisateurs, son implémentation n’était pas très élégante (ce remboursement pouvant prendre des mois).
• En 2015, Corné Plooy, qui planchait sur le développement de cette sous-couche de Bitcoin depuis plusieurs années, proposa une version trustless de son système, Amiko Pay; cependant, afin de garantir la décentralisation du système, un hard fork de Bitcoin était nécessaire, notamment pour ajouter la possibilité de rendre certaines transactions réversibles, ce qui avait très peu de chances d’être accepté par la communauté.
• Christian Decker (chercheur à l’Université technique de Zurich et désormais chez Blockstream) proposa également avec Roger Wattenhofer un système de réseau de canaux de paiements bidirectionnels reposant sur les timelocks et un mécanisme cryptographique ingénieux (invalidation tree).

Ces recherches intensives démontrent l’ingéniosité des développeurs et des scientifiques qui travaillent jour et nuit à améliorer Bitcoin. Ce sont deux chercheurs/développeurs hyperactifs dans la crypto-communauté qui fournirent le whitepaper du Lightning Network en janvier 2016, Joseph Poon et Thaddeus Dryja.

Pour les lecteurs des articles techniques de BitConseil, le nom de Joseph Poon est certainement familier : en effet, en plus du développement du Lightning Network sur Bitcoin, le jeune génie est également (avec Vitalik Buterin) à l’origine de la solution qui permettra d’améliorer grandement la scalabilité d’Ethereum, Plasma, qui pourrait éventuellement être implémentée sur Bitcoin. En plus d’être d’une intelligence supérieure, Joseph est également humble et extrêmement sympathique. Quant à Thaddeus Dryja, on ne compte plus ses apports au réseau Bitcoin, basés notamment sur ses recherches dans le cadre du problème du logarithme discret et des signatures de Schnorr, qui ont de nombreuses applications dans le cadre des smart contracts (voir Scaling Bitcoin #3).

Fonctionnement technique du Lightning Network

Avant d’étudier le réseau Lightning à proprement parler, il faut comprendre comment fonctionne un canal de paiement bidirectionnel entre deux parties. Ce canal de paiement doit fonctionner hors-chaîne et respecter les propriétés désirées (rapidité, coût très faible et décentralisation). Pour cela, la totalité des échanges entre Alice et Bob qui seront effectués sur le canal sera résumée en seulement deux transactions sur la blockchain : l’une servant à ouvrir le canal, c’est-à-dire à le financer, et l’autre à fermer le canal, c’est-à-dire à créditer les deux parties de leur solde final une fois les échanges effectués.

Quelques notions préalables :

Pour effectuer des paiements hors de la chaîne principale, le tour de magie consiste à mettre des bitcoins sous séquestre, dans un portefeuille multi-signatures 2-2 (qui est en fait un smart contract basique où exactement deux signatures doivent être utilisées pour qu’une transaction soit validée par le réseau).

Une fois les bitcoins mis sous séquestre, les utilisateurs vont s’échanger des “promesses de transactions” et non des bitcoins en tant que tels. Le solde final qui sera crédité sur les adresses des parties concernées sera mis à jour en fonction de ces promesses de transactions, et lorsque l’un des utilisateurs souhaitera rendre ces transactions effectives, le canal sera fermé, et la transaction résultante représentant le dernier état du canal accepté par les deux parties sera diffusée sur la blockchain.

Afin de mettre ces canaux en réseau, et pour qu’Alice, qui a ouvert un canal avec Bob mais non avec Carole, puisse effectuer des paiements avec Carole, un système de “saut” lui permettra de diffuser ces promesses de transactions à Carole en passant par Bob.

Bien entendu, c’est beaucoup plus facile à dire qu’à faire : ces “promesses de transactions” doivent obligatoirement devenir des réalités (il faut donc un mécanisme de preuve cryptographique), les tentatives de double-dépense doivent toujours échouer. De plus, si l’une des parties ne respecte pas ses engagements, l’autre partie doit pouvoir récupérer ses fonds.

Grâce au système de script de Bitcoin et au génie de ses développeurs, cela devient possible.

Ouverture d’un canal bidirectionnel entre Alice et Bob

Problématique : permettre aux deux parties d’échanger des transactions signées, pouvant être validées à tout moment sur le réseau principal, mais tout en empêchant l’une des parties de tricher (dépenser plus de fonds que ce que l’autre lui autorise), et sans passer par un tiers de confiance.

Pour mettre les bitcoins des deux parties sous séquestre sans passer par un tiers qui en assure la garde, il faut utiliser les portefeuilles multi-signatures.

Une fois la transaction d’ouverture inscrite sur la blockchain, il suffit de répéter le processus d’engagement pour mettre l’état du canal à jour en fonction des paiements effectués. L’échange des secrets de l’état précédent permet de prévenir la triche :

Création d’un réseau de canaux de paiements

Là où les choses se compliquent un peu, c’est lorsque l’on fait intervenir une autre personne, tout en souhaitant garder ce modèle décentralisé. Alice souhaite payer 1 bitcoin à Carole : elle pourrait évidemment ouvrir un canal bidirectionnel de plus, mais il se trouve que Carole a déjà ouvert un canal avec Bob. L’idée est de payer 1 BTC à Bob, qui donnera à son tour ce coin à Carol. Bien évidemment, Alice ne fait pas forcément confiance à Bob et à Carole : il faut donc s’assurer via un mécanisme cryptographique qu’Alice donnera le coin à Bob si et seulement si elle est assurée que Bob le donnera à Carole à coup sûr.

C’est ici qu’interviennent les Hash Time-Locked Contracts. Leur mécanisme repose encore sur les multi-signatures, ainsi que sur la fonction CheckSequenceVerify qui “verrouille” les coins durant une période définie. Dans un système à trois participants, il y aura deux HTLC, dans un système à quatre participants, trois HTLC, etc. Ces contrats permettent de lier les paiements entre eux de façon à s’assurer que Bob livre bien les coins d’Alice à Carole et qu’Alice livre bien les coins à Bob.

Le premier HTLC concerne Alice et Bob. Il s’agit d’un contrat où les coins d’Alice peuvent être déverrouillés de deux façons :

• Par Bob s’il signe la transaction en fournissant un secret généré par Carole (de façon à ce que Bob puisse prouver à Alice que Carole recevra bien les coins).
• Par Alice à la fin du délai d’expiration fixé (de façon à ce que Bob ne puisse pas partir avec s’il ne les a pas donnés à Carole) ;

Le deuxième HTLC concerne Bob et Carole. Les coins peuvent être déverrouillés ainsi :

• Par Carole si elle signe la transaction et fournit son secret à Bob ;
• Par Bob après un délai d’expiration défini (pour s’assurer qu’Alice ne manquera pas à son engagement).

Ces deux contrats sont donc liés entre eux : Bob est le pivot entre les transactions, s’il donne les coins à Carole, il doit avoir la garantie qu’Alice les lui donne en retour.

En plus des deux premiers multi-signatures entre Alice et Bob, la présence des coins destinés à Carole complexifie un peu les choses : en effet, il y a désormais plusieurs façons de les “débloquer” :

• Tout se passe bien et Carole donne le secret à Bob, qui signe le premier HTLC, et “prend” ces coins à Alice pour les donner à Carole ;
• Bob ne signe pas le HTLC entre Alice et lui (par exemple, si Carole n’a pas donné le secret) : les coins reviennent à Alice après le délai d’expiration ;
• Bob tente de tricher et Alice peut réclamer ses coins grâce au secret de Bob.

La différence entre le délai d’expiration imposé à Alice – supérieur au délai imposé à Bob pour fournir le secret de Carole – permet de s’assurer qu’à partir du moment où Bob envoie les coins à Carole, il est certain qu’il recevra les coins d’Alice en retour.

Le Lightning Network nous propose donc bien un réseau de canaux de paiements : il est possible de multiplier ces opérations avec autant d’utilisateurs qu’on le souhaite (multi-hop HTLC, HTLC à sauts multiples).

Mais il faut garder à l’esprit que, puisque ce mécanisme prévient la triche, il n’y a pas à publier la transaction d’engagement faisant intervenir le HTLC sur la blockchain : Alice et Bob peuvent tout simplement mettre à jour l’état du canal une fois que le secret de Carole a été communiqué à Alice.

Fermeture du canal

Les deux parties n’ayant pas intérêt à tricher, ni à fermer le canal prématurément, toutes ces transactions ne sont donc pas diffusées sur la blockchain tant que le canal reste ouvert. Elles ne servent que de garantie. Lorsque les deux parties souhaitent conjointement fermer le canal, il leur suffit de signer et diffuser une transaction correspondant au dernier état du canal, transférant les coins du portefeuille multi-signatures original vers leurs adresses respectives.

Ainsi, quel que soit le nombre de transactions hors-chaîne qui ont été effectuées entre les deux parties, il n’aura suffi que de deux transactions sur la blockchain de Bitcoin pour synthétiser tout cela.

Le Lightning Network en pratique

Il existe à l’heure actuelle plus de nœuds Lightning sur le réseau mainnet que sur le réseau de test ! On compte plus de 1000 nœuds pour plus de 10 000 canaux.

Explorateurs du Lightning Network :

• #recksplorer (visuel et interactif)
• Lightning Network Explorer [Testnet] par Acinq

Un outil d’agrégation de données : Shabang.io

Afin de déployer un nœud Lightning, il faut disposer d’un nœud Bitcoin complet. Il est bien sûr vivement recommandé de disposer de la dernière version de Bitcoin Core.

Les différentes implémentations

Il existe actuellement trois implémentations du Lightning Network. Elles ne sont pas concurrentes et se basent sur les spécifications standards du Lightning Network, appelées BOLTs.

Lightning-c

il s’agit de l’implémentation d’Elements Project, une communauté de développeurs soutenue par la firme Blockstream.

• Le code source et les instructions de déploiement.
• Lightning Charge, une interface developer friendly permettant d’effectuer des paiements.

Pour l’instant, Lightning-c fonctionne seulement sous Linux et nécessite un nœud complet parfaitement synchronisé avec le réseau utilisé (testnet ou mainnet).

Lightning Network Daemon (LND)

Cette implémentation est développée par Lightning Labs.

• Le code source.
• Les instructions de déploiement.
• Neutrino : une plateforme permettant aux utilisateurs d’appareils mobiles d’utiliser un client léger pour les paiements Lightning.

Programmée en Golang, l’implémentation nécessite donc d’installer la version 1.9 de Go.

Eclair

Eclair est le fruit de la startup française Acinq.

• Le code source et les instructions.
• Le client Androïd [Note : pour l’instant, en raison de l’effacement accidentel de la clef permettant de mettre le logiciel à jour, Acinq recommande de ne pas utiliser cette version et d’attendre la sortie de la prochaine].

L’implémentation nécessite la version 0.16.0 de Bitcoin Core, et possède une API JSON-RPC.

Les applications Lightning (LApps)

Ces applications sont pour l’instant développées par Blockstream, et disponibles sur le GitHub d’Elements Project. L’une d’entre elles est déjà déployée sur le site de Blockstream : cette implémentation du LN pour WooCommerce permet d’acheter des T-shirts.

Commerce :

• Nanopos — Un système simple de point de vente pour des biens à prix fixé.
• WooCommerce Lightning Gateway — Une application d’e-commerce intégrant la gestion des stocks et le suivi des commandes.

Création et diffusion de contenu :

• FileBazaar — Un système pour vendre des fichiers (documents, images, vidéos…)
• Lightning Publisher for WordPress — Un système permettant des micropaiements déverrouillant des billets WordPress.

Micropaiements :

• Paypercall — Boîte à outils pour programmeur – micropaiements pour appels individuels à une API.
• Ifpaytt — Extension de Paypercall permettant aux développeurs web d’utiliser IFTTT pour demander des micropaiements pour utiliser un service.

Outils geek :

• Lightning Jukebox — Démo amusante qui réinvente une technologie classique pour le Lightning Network.
• Nanotip — Pourboires simples via le LN.

Conclusion

Cette première version du Lightning Network, même si elle est encore assez bancale (problèmes de connectivité entre les nœuds, interface utilisateur très limitée, utilisation complexe pour le néophyte, etc.), pave la voie vers la vision à long terme de Satoshi : un Bitcoin accessible à tous, pouvant être utilisé par des milliards d’individus simultanément, avec des frais minimes.

Il s’agit d’une excellente nouvelle et de la démonstration des talents exceptionnels que compte la communauté en son sein. La collaboration entre les différentes équipes de développement de par le monde, l’implication des chercheurs qui donnent en amont les outils mathématiques pour donner vie à Bitcoin rappellent à tous que sa valeur n’est pas uniquement liée au prix de marché que les spéculateurs lui donnent, mais repose aussi sur le capital humain incroyable que cette aventure agrège.