Bitcoin : SegWit ou Lightning Network pour fluidifier les transactions ?

Depuis le début de l'année, les coûts des transactions via Bitcoin ont été multipliés par 10, la faute à la congestion du réseau, incapable de traiter le nombre grandissant d'opérations que l'on lui demande. Plusieurs options pour le fluidifier sont à l'étude, mais aucune ne fait encore consensus.

Plus le temps passe, et plus le coût des transactions via le réseau Bitcoin pose problème. Sur la journée du 7 juin, BitInfoCharts a relevé une moyenne de 5,5 dollars de frais par transaction, contre 1,32 dollar le 7 mai et 0,35 dollar au 1er janvier. Au 26 juin, il est toujours question de plus de 3,5 dollars.

Cette augmentation rapide n'est pas un bon signe pour Bitcoin. Les utilisateurs du réseau ont pendant longtemps vanté ses mérites en mettant en avant le coût réduit des transactions et leur quasi instantanéité. Si l'argument de la vitesse reste encore valable, à condition d'y mettre le prix, celui du coût devient franchement discutable.

Quelques dollars sur une opération à plusieurs dizaines de milliers de dollars, cela reste une ponction indolore, mais quand il s'agit de payer son café en bitcoins, comme certains rêvaient de le faire il y a quelques années, cela devient une autre paire de manches...

Des blocs trop pleins, des frais de transaction qui explosent

Pour comprendre le problème, il faut revenir sur le principe de fonctionnement de Bitcoin. Des blocs d'une taille maximale de 1 000 ko (un million d'octets) sont générés toutes les 10 minutes. Ceux-ci renferment les informations propres aux transactions, dont les « signatures » des parties concernés. 

Cette structure fait que chaque bloc ne peut contenir qu'un nombre limité de transactions (quelques centaines), le poids moyen d'une opération se situe autour de 500 bits, avec une médiane se situant plutôt autour de 230 bits. Quand un bloc est plein, c'est un peu comme dans le métro, il faut attendre que le prochain arrive à quai et espérer avoir une place. 

Dans le cas de Bitcoin, les transactions ne sont pas traitées dans l'ordre chronologique. Dans le protocole, les opérations pour lesquelles des frais ont été provisionnés ont un accès prioritaire aux blocs. Ces frais sont fixés par l'émetteur de la transaction et sont redistribués aux mineurs qui traitent le bloc.

Depuis le 30 avril, la taille moyenne des blocs se situe au-delà de 975 ko, avec une médiane a 998 ko. Les blocs sont en grande majorité pleins à ras-bord. Les places sont donc de plus en plus chères, ce qui explique l'envolée que l'on peut observer aujourd'hui.

« Eh bien il suffit de faire des blocs plus gros dans ce cas ! »

Bien essayé, mais non. Si c'était aussi simple, cette solution aurait été adoptée depuis belle lurette, or c'est loin d'être le cas. Comme l'explique l'équipe de Bitcoin Core dans une FAQ dédiée à la mise en place de SegWit (qu'on détaillera un peu plus bas, promis), l'augmentation de la taille maximale des blocs n'est pas une opération anodine. 

Elle nécessiterait un hard-fork de la blockchain de Bitcoin de la même envergure que celui opéré sur celle d'Ethereum pour oublier l'épisode The DAO. Il s'agit d'un acte compliqué à réaliser, qui nécessite le soutien et la préparation d'une majorité des acteurs de la blockchain. Pour les utilisateurs de clients légers qui ne se procurent leurs blocs que depuis un nœud du réseau, le risque de se retrouver sur la mauvaise chaîne et de perdre leurs bitcoins n'est par ailleurs pas à négliger. 

Enfin, il ne suffirait pas seulement de changer le paramètre Block_size de 1 000 000 à 2 000 000 pour que cela fonctionne correctement. Selon Bitcoin Core, qui développe le client « standard » pour Bitcoin, il y a encore d'autres points à prendre en compte, notamment les risques d'attaques par déni de service (DoS).

Il est actuellement possible de forger des transactions qui (à elles seules) peuvent occuper tout un bloc de 1 Mo, mais les valider ne demande que 30 secondes à un ordinateur moderne. Une même transaction de 2 Mo demanderait plus 10 minutes de calcul pour arriver au même résultat. Il faudrait donc développer en parallèle des moyens permettant de parer ces risques.

SegWit : une solution on-chain poussée par Bitcoin Core

Pour s'éviter de devoir gérer un hard-fork qui pourrait avoir des conséquences destructrices, Bitcoin Core a planché sur une solution baptisée SegWit (rien à voir avec le Segway), pour Segregated Witnesses ou « témoins séparés ». Son idée est plutôt simple à comprendre. 

Une transaction est composée de plusieurs éléments : 

• Un montant
• Les adresses de l'expéditeur et du(des) destinataire(s)
• Une empreinte cryptographique prouvant la possession de la clé privée de l'émetteur (la signature)
• Une « énigme » qui ne peut être résolue que par le propriétaire de la clé privée du destinataire

L'un des soucis est que les signatures ne sont nécessaires qu'au moment de la vérification de la transaction. Or ces signatures représentent environ 60 % de la taille occupées par un échange dans un bloc. L'idée est donc de sortir les empreintes cryptographiques des blocs de transaction afin de pouvoir y glisser davantage d'opérations, et ainsi désengorger, au moins temporairement, la blockchain. Les signatures elles, voyagent en dehors de la blockchain.

Anatomie d'un bloc dans la blockchain de Bitcoin- Crédits : Sean Au

Pour les défenseurs de SegWit, cette méthode permettrait, dans le cas le plus favorable de faire passer dans un bloc de 1 Mo autant de transactions que dans un bloc de 1,6 à 1,7 Mo utilisant la formule actuelle. Les détracteurs de cette solution estiment quant à eux que l'effort est très largement insuffisant et ne permettra pas à Bitcoin de gérer des transactions à l'échelle mondiale.

Selon la réserve fédérale américaine, rien qu'aux États-Unis, les opérateurs de cartes de paiement (Mastercard, Visa...) ont géré 103,3 milliards de transactions en 2015, soit près de 3 300 par seconde. Actuellement, la blockchain de Bitcoin a une capacité réelle estimée à 7 opérations par seconde, à partager avec le monde entier.

Une adoption qui traine

Techniquement, SegWit est déjà présent dans le client Bitcoin Core depuis la version 0.13.1 distribuée en octobre 2016. Seulement, ce protocole n'est pas encore utilisé car il n'a pas atteint le seuil d'adhésion requis pour permettre un soft-fork de la blockchain.

Pour cela, il faut que 95 % des mineurs cochent une case indiquant qu'ils supportent SegWit et souhaitent donc sa mise en place. Un taux mesuré grâce au nombre de blocs minés par des acteurs ayant affiché leur soutien à SegWit sur une période de deux semaines, soit 2016 blocs. À l'heure actuelle, le taux d'adoption n'est que de 36,5 % sur les deux dernières semaines. 26 périodes d'activation sont programmées, et les 17 premières sont pour l'instant de cuisants échecs. Sur la blockchain de Litecoin, SegWit est en place depuis mai dernier.

Il faut dire que sur le court terme, les mineurs sont gagnants avec la situation actuelle. Les récompenses obtenues lors du minage d'un bloc sont en effet constituées d'un montant fixe qui décroit à intervalles réguliers (actuellement 12 BTC par bloc) auquel s'ajoute la somme des frais consentis par les émetteurs de transactions. Au 1er janvier 2017, cela représentait en moyenne 0,4 BTC par bloc. Depuis le 30 avril, la moyenne est à 2,58 BTC selon Tradeblock.

Lightning Network, l'autre alternative

Si l'adoption de SegWit ne va pas aussi vite que l'aimerait l'équipe de Bitcoin Core, c'est en partie parce qu'une alternative existe : Lightning Network. Elle est portée par les développeurs du client Bitcoin Unlimited et repose sur une philosophie très différente. Alors que SegWit veut gonfler les capacités de la blockchain, Lightning Network veut au contraire la décharger du plus de travail possible. 

Aujourd'hui, si Alice veut envoyer 1 BTC à Bob, elle doit impérativement passer par la blockchain de Bitcoin, se délester de l'équivalent de quelques dollars et attendre que sa transaction soit validée. L'idée poussée par les développeurs de Bitcoin Unlimited est d'ouvrir des canaux sécurisés, de pair à pair, en marge de la blockchain qui resterait le juge de paix en cas de conflit. 

« On sait déjà effectuer des transactions sécurisées en bitcoin sans utiliser la blockchain. Vous le faites d'ailleurs tous les jours quand vous échangez des crypto-monnaies sur Coinbase », résumaient ainsi les deux rédacteurs du whitepaper de Lightning Network Joseph Poon & Thaddeus Dryja lors d'une conférence.

Plus de canaux qu'à Venise

Pour décharger la blockchain, l'idée derrière Lightning Network est plutôt simple sur le papier. Il suffit de créer des canaux de pair à pair, qui seraient matérialisés par une adresse Bitcoin, ouverts pour une durée quelconque (disons 30 jours pour simplifier). À l'issue de ce délai, le nouveau solde est inscrit définitivement dans la blockchain. En pratique, c'est un peu plus compliqué à expliquer, et les créateurs du système ont tenté d'en vulgariser le principe... au travers d'un long diaporama.

Pour comprendre ce qui suit, il est important de rappeler qu'un transfert d'argent en BTC se décompose en deux étapes, et de faire appel à Alice et Bob, nos deux cobayes préférés.

Si Alice dispose de 50 BTC, et qu'elle en envoie un à Bob, la transaction dit qu'Alice transfère 1 BTC à Bob, et 48,995 BTC à sa propre adresse de remboursement. La différence de 0,005 BTC est alors considérée par le réseau comme les frais de transaction versés aux mineurs.

Alice et Bob ouvrent donc leur canal. Alice place 1 BTC dans l'adresse lui correspondant. L'opération n'est effective qu'une fois que Bob a signé une transaction disant de renvoyer le BTC dans 24 heures à l'adresse de remboursement. Ainsi, si Bob disparaît après cela, Alice peut toujours récupérer l'intégralité de la somme après 24 h. S'il file à l'anglaise avant, le BTC n'a jamais quitté les poches d'Alice.

Tant que le canal est ouvert, Alice et Bob peuvent disposer de l'argent qu'ils y ont déposé comme ils le souhaitent. Ainsi si Alice veut envoyer 0,1 BTC à Bob, il lui suffit d'écrire que parmi l'argent présent dans le canal, 0,1 BTC appartient à Bob, et 0,9 BTC à elle. De même si elle veut effectuer une seconde transaction du même montant, elle n'a qu'à dire que Bob a 0,2 BTC et elle 0,8. À l'inverse Bob peut alors dire, « non, j'ai 0,1 BTC et Alice 0,9 ». Par contre, Bob ne peut pas faire varier son solde à la hausse en piquant des sous à Alice.

Si maintenant, Alice veut envoyer de l'argent à Dave. Elle peut soit ouvrir directement un canal avec lui, soit profiter du fait qu'elle en a déjà ouvert un avec Bob, qui lui-même est lié à Carol, qui dispose d'un canal fonctionnel avec Dave. Le problème qui se pose alors est que n'importe quel intermédiaire peut, en théorie, dire ne pas avoir reçu l'argent, ou tout simplement le garder. 

Pour éviter ça, Dave envoie directement à Alice un hash d'une clé verrouillant la transaction, dont seul lui dispose. Bob et Carol voient alors une transaction chiffrée passer devant eux, sans pouvoir interférer avec ce qu'il s'y trouve. Une fois que Dave a reçu son argent, il refait circuler la clé vers Carol et Bob, pour qu'ils puissent toucher leur commission pour avoir fait passer le message.

Chacun de ces canaux est ouvert pour un temps limité fixé au départ. Toutes les transactions qui y transitent ne sont pas inscrites dans la blockchain. Par contre, dès qu'un canal se ferme, le point est fait sur le solde de chacun des participants et celui-ci est enregistré comme il se doit dans la blockchain. Ainsi, on peut réaliser, virtuellement, une infinité de transactions hors chaine, et n'en inscrire que quelques-unes.

SegWit2x, un compromis en attendant mieux

Une troisième alternative a récemment gagné du terrain. Baptisée SegWit2X elle a le soutien de plusieurs coopératives de mineurs (ou pools), dont AntPool, Bitcoin.com, Bitfury, Bixin, BTC.com, BTC.top, BW Pool, F2Pool et ViaBTC, qui représentent à elles seules environ 70 % de la puissance de calcul déployée sur le réseau.

Son principe est maintenant assez simple à expliquer, puisqu'il s'agit de combiner à la fois la mise en place de SegWit, que l'on a décrit un peu plus haut, avec celle de blocs d'une taille de 2 Mo, que l'on a aussi vue encore un peu plus tôt. Cette solution ferait grossir plus rapidement la taille de la blockchain, avec les problèmes que l'on connait, mais désengorgerait au moins temporairement le flux des transactions.

Plusieurs problèmes se posent toutefois. Le premier est qu'en raison du changement de la taille des blocs, cette solution impose de procéder à un hard-fork, une éventualité que les développeurs de Bitcoin Core souhaiteraient éviter à tout prix. « Je pense que ce hard-fork ne permettra pas une transition sécurisée du réseau. Il n'y a pas de protection permettant de revenir en arrière. C'est une fenêtre de tir extrêmement courte, et cette solution ne profite pas de nos recherches passées sur les hard-forks », résumait ainsi au début du mois Bryan Bishop, l'un des contributeurs de Bitcoin Core.

Le deuxième est que contrairement aux deux autres options proposées, le code de SegWit2X n'est pas encore finalisé, même si une première préversion est en ligne depuis le 16 juin. Il reste donc encore de nombreux détails à régler, ce qui n'est guère rassurant à quelques semaines seulement de l'adoption supposée de ce nouveau protocole. En effet, les mineurs font pression pour que la manœuvre soit bouclée avant le 1er août et que le code définitif soit publié le 21 juillet.

Enfin, politiquement la mesure est loin de faire l'unanimité. Si les gros pools de mineurs sont d'accord et poussent son adoption, le reste des acteurs est moins enthousiaste. « Cette proposition n'a approximativement aucun soutien des développeurs », note ainsi Elisabeth Stark, PDG de Ligntening Labs devant Coindesk. La dirigeante tacle également la consanguinité des discussions autour du projet : « malheureusement, la liste de diffusion d'e-mails est seulement accessible à ceux qui soutiennent SegWit2x », regrette-t-elle.

Les mineurs font bloc

Néanmoins, cette proposition est en passe d'être adoptée, puisque la nature du protocole Bitcoin fait que ce sont les mineurs, au prorata de leur puissance de calcul, qui votent en marquant leurs blocs avec un bit spécifique. Si à partir du 21 juillet et pendant 3 jours de suite, 80 % des blocs soient marqués avec ce fameux bit, le vote sera considéré comme acquis.

Avec 70 % de la puissance de calcul en poche, les mineurs poussant cette proposition ont de très fortes chances d'obtenir gain de cause. Ils ont par ailleurs précisé qu'ils marqueront leurs blocs avant le 31 juillet. Les autres acteurs de la blockchain de Bitcoin, qu'il s'agisse des bourses d'échange, des prestataires de paiement, ou même des utilisateurs lambda, devront quant à eux se plier au choix qui sera effectué par les mineurs. Qu'il leur plaise, ou non.