L’invention du Bitcoin Lightning Network et son influence dans le débat sur la scalabilité

Le réseau Lightning, aussi appelé Lightning Network, est une solution technique permettant d’effectuer des paiements en bitcoin hors chaîne sans recourir à un tiers de confiance. Inventé début 2015, il a joué un rôle majeur dans le débat sur la scalabilité de Bitcoin en constituant l’illustration par excellence de la possibilité de passer à l’échelle avec une taille des blocs restreinte.

Les canaux de paiements

Le réseau Lightning se base sur un concept simple : le canal de paiement. L’idée est d’utiliser la programmabilité de Bitcoin afin de pouvoir réaliser des transferts économiques avec quelqu’un sans diffuser de transaction sur la chaîne : seule une transaction d’ouverture est réalisée pour pouvoir échanger de manière répétée avec l’autre. Le modèle est sécurisé par la possibilité de fermer le canal à tout moment en diffusant le dernier état, c’est-à-dire le dernier accord existant entre les deux participants.

Le concept de canal de paiement est au moins aussi vieux que Bitcoin. En effet, dès 2009, Satoshi Nakamoto lui-même envisage la construction d’échanges répétés par l’utilisation du numéro de séquence nSequence, et le mécanisme est implémenté dans le code dès l’origine.

Cependant, ce modèle n’est pas sécurisé et il requiert de faire confiance aux mineurs pour fonctionner. C’est pourquoi il faudra attendre un peu plus longtemps avant que le concept ne se développe de manière robuste.

La premier modèle de canal de paiement après celui de Satoshi est proposé le 4 juillet 2011 par un utilisateur de Bitcointalk écrivant sous le pseudonyme de hashcoin. Dans sa proposition il décrit une façon permettant d’effectuer des paiements répétés vers une plateforme d’échange (Mt. Gox) grâce à des multisignatures et à des verrous temporels. Cette idée n’est pas implémentée mais en inspire d’autres comme celle de Meni Rosenfeld en 2012.

Le 20 avril 2013, Jeremy Spliman propose un concept de canal de paiement unidirectionnel sur la liste de diffusion bitcoin-dev. Ce modèle est légèrement modifié pour être implémenté dans bitcoinj par Mike Hearn et Matt Corallo en juin. Mike Hearn est intéressé par le sujet, intérêt qu’il tient de Satoshi, dans le but d’autoriser les micropaiements sur Bitcoin.

Parallèlement à cela, en mars 2013, Alex Akselrod publie sur le wiki Bitcoin.it une « ébauche de proposition d’un réseau de compensation de paiements décentralisé, pair-à-pair, qui utilise Bitcoin pour le règlement et les bitcoins comme unités de compte » et en dévoile une preuve de concept en octobre 2014. Dans son modèle, les canaux sont bidirectionnels, c’est-à-dire que les paiements peuvent se faire dans les deux sens, et sont liés entre eux pour former un réseau.

Enfin, en décembre 2014, Christian Decker et Roger Wattenhofer ont l’idée d’un autre type de canal bidirectionnel. Leur papier, intitulé « A Fast and Scalable Payment Network with Bitcoin Duplex Micropayment Channels », est publié en août 2015 après plusieurs révisions. Cependant, leur proposition est délaissée au profit d’un autre modèle de canal dévoilé publiquement en février étant à la base d’une solution déjà très populaire : le Lightning Network.

>> Vous cherchez une plateforme crypto dûment régulée ? Inscrivez-vous sur Binance, et économisez 10% de frais (lien commercial) <<

Le Bitcoin Lightning Network

Le 23 février 2015, Joseph Poon et Thaddeus Dryja présentent le concept du Lightning Network lors d’un séminaire de développeurs à San Francisco. Le 28 février, ils publient le livre blanc du leur invention, intitulé « The Bitcoin Lightning Network », qui présente les éléments de base nécessaires pour construire un tel réseau.

Le réseau Lightning est un réseau de canaux de paiements bidirectionnels, dits de « Poon-Dryja » en hommage à leurs créateurs. Les contrats impliqués sont appelés des Hash Time Locked Contracts ou HTLC, c’est-à-dire des contrats dont les clauses de libération des fonds dépendent d’une empreinte et d’un temps de verrouillage. La mise à jour de l’état des canaux se base sur un mécanisme de punition. La sécurité dépend ainsi du comportement des deux participants : si l’un essaie de tricher, l’autre doit être prêt à réagir pour publier une transaction contradictoire.

À l’époque, d’autres propositions concurrentes basées sur des idées similaires existent comme Amiko Pay (conceptualisé par Corné Plooy), Impulse (développé par Jeff Garzik pour Bitpay) et Ström (imaginé par la start-up Strawpay). Néanmoins, Lightning devient rapidement la solution dominante, notamment parce qu’il est présenté comme une solution de passage à l’échelle pour Bitcoin :

« Le protocole Bitcoin peut englober le volume global des transactions financières de tous les systèmes de paiement électronique actuels, sans qu’un tiers dépositaire unique ne détienne les fonds et sans demander aux participants de de posséder plus qu’un ordinateur muni d’une connexion domestique à haut débit. Un système décentralisé est proposé, dans lequel les transactions sont envoyées sur un réseau de canaux de micropaiement (aussi connus sous le nom de canaux de paiement ou de canaux de transaction) dont le transfert de valeur se fait en dehors de la chaîne de blocs. »

Joseph Poon et Thaddeus Dryja, The Bitcoin Lightning Network, 28 février 2015

De cette manière, l’idée du réseau Lightning s’inscrit dans le débat sur la scalabilité de Bitcoin, et œuvre à renforcer la vision d’une chaîne de blocs dont la taille des blocs serait relativement petite. Si les créateurs du Lightning Network ne s’opposent pas à une augmentation de capacité transactionnelle (le livre blanc mentionne une taille des blocs de 133 Mo pour permettre une adoption mondiale), ils désirent néanmoins préserver le potentiel de décentralisation de Bitcoin en développant une solution alternative.

Le 5 mai 2015, le développeur Mike Hearn publie un article intitulé « The Capacity Cliff » dans lequel il critique le réseau Lightning et promeut l’augmentation de la taille des blocs. En particulier, il met en lumière le fait que Lightning ne pourra pas être prêt avant que la limite de 1 Mo ne soit atteinte de façon répétée :

« Il n’existe aucune proposition technique crédible susceptible d’être adoptée à grande échelle au cours des douze prochains mois, si ce n’est une simple augmentation de la capacité du système existant, qui est déjà bien comprise et mise en œuvre par tous. »

Plus tard dans l’année d’autres critiques émergent. Voici les éléments qui sont reprochés à Lightning :

• La capacité des canaux est limitée et, de ce fait, pose un problème de liquidité ;
• Le routage, c’est-à-dire la façon de trouver une route pour un paiement, est un procédé difficile à mettre en œuvre ;
• Les deux éléments précédents incitent le développement d’un réseau en étoile centré sur des moyeux centraux traitant l’essentiel des transactions ;
• Une personne a besoin d’être en ligne pour recevoir un paiement ;
• Une personne a besoin de disposer d’un nœud ou de reposer sur un tiers de confiance (« watchtower »)pour empêcher toute fermeture frauduleuse de canal ;
• La complexité du système est très élevée, ce qui réduit la sécurité du réseau, et centralise le développement des portefeuilles ;
• L’implémentation est trop lente pour compenser l’augmentation d’activité ;
• Les bitcoins sur le réseau Lightning sont des reconnaissances de dette (IOU) ;
• Le Lightning Network nécessitera de toute manière une augmentation de la taille des blocs comme mentionné dans le livre blanc.

Ces critiques sont plus ou moins valides : certaines sont complètement fausses (comme celle des IOU), d’autres seront vérifiées avec le temps, d’autres encore seront partiellement voire totalement résolues.

Lightning prend une autre dimension après la sortie de Bitcoin XT 0.11A le 15 août 2015, qui déclenche la guerre civile entre les partisans des petits blocs et ceux qui militent pour des blocs plus gros. Suite à cette annonce, une conférence d’urgence est organisée dans le but de résoudre le conflit croissant se développant au sein de la communauté. Intitulée Scaling Bitcoin, la première édition de cette conférence se déroule à Montréal les 12 et 13 septembre et parvient à réunir avec bonne foi des individus des deux camps. La deuxième édition a lieu à Hong Kong les 6 et 7 décembre, où la tension est plus intense.

Joseph Poon et Thaddeus Dryja sont présents durant les deux conférences pour présenter leur invention. Durant la première, ils la présentent ensemble ; durant la deuxième, ils réalisent des présentations individuelles plus détaillées. Cela fait que le réseau Lightning se retrouve cité dans le courriel récapitulatif de Gregory Maxwell du 7 décembre 2015 sur la liste de diffusion bitcoin-dev, courriel qui deviendra par la suite la feuille de route de Bitcoin Core.

En janvier 2016, l’abandon rageur de Mike Hearn et l’échec de Bitcoin XT font que le camp des small blockers devient plus influent. Le Lightning Network gagne alors en importance dans la vision du passage à l’échelle de Bitcoin et des moyens sont mis en œuvre pour que son développement s’accélère.

Le développement de Lightning

Bien que le concept du Lightning Network soit bien appréhendé, son implémentation est difficile, notamment en raison de sa complexité et des différents choix qui peuvent être réalisés. Durant la première année après la présentation de Poon et Dryja, trois implémentations logicielles se démarquent :

• c-lightning, développé par Rusty Russell à partir de mai 2015 pour le compte de Blockstream ;
• Eclair (ou Éclair), conçu par l’entreprise française ACINQ à partir de l’été 2015 ;
• lnd, qui est le résultat du travail de Lightning Labs, une entreprise fondée par Joseph Poon, Thaddeus Dryja, Elisabeth Stark et Olaoluwa Osuntokun en janvier 2016.

D’autres entreprises comme Bitfury ou Amiko Pay participent également à ce développement parallèle. En octobre 2016, après la troisième édition de Scaling Bitcoin à Milan, les différentes équipes mettent en place un système de documents formels indiquant les spécificités du protocole Lightning. Ceux-ci sont appelés Bases of Lightning Technology ou BOLT, et leur permettent de coordonner leurs développements.

Le réseau Lightning est également un enjeu pour le développement de Bitcoin lui-même : Lightning exige en effet des modifications du protocole Bitcoin afin d’être implémenté de manière optimale. Tout d’abord, il demande formellement d’intégrer la possibilité de programmer temps de verrouillage absolus au sein du système de script, ce qui sera réalisé avec l’ajout du code opération OP_CHECKLOCKTIMEVERIFY le 14 décembre 2015. Ensuite, pour faciliter son implémentation, les temps de verrouillages relatifs sont également requis, ce qui sera implémenté dans le protocole le 4 juillet 2016, avec notamment le code opération OP_CHECKSEQUENCEVERIFY. Enfin, pour réduire la taille des transactions réalisées, il demande une correction de la malléabilité des transactions, chose qui sera faite par l’activation de SegWit le 24 août 2017.

Quoi qu’il en soit, Lightning ne débutera réellement qu’au début de l’année 2018, lorsque les différentes implémentations passeront en version bêta et lorsque la capacité sur le réseau commencera à augmenter.

Ainsi, Lightning a marqué le débat sur la scalabilité en constituant l’exemple par excellence de solution aux problèmes de scalabilité de Bitcoin. Ayant émergé la même année que Bitcoin XT, ce concept d’un réseau de canaux de paiement a réussi à se faire une place au fil des années, en dépit de problèmes difficiles à résoudre.

Pour écrire ce texte, je me suis basé sur l’article « The History of Lightning: From Brainstorm to Beta » de Aaron van Wirdum ainsi que sur l’ouvrage The Blocksize War de Jonathan Bier.