Free Press

L’avenir de la série Blockchain

La bataille pour une solution évolutive est la course à la lune de la blockchain. Bitcoin traite 4,6 transactions par seconde. Visa effectue environ 1 700 transactions par seconde en moyenne (sur la base d’un calcul dérivé de l’affirmation officielle de plus de 150 millions de transactions par jour). Le potentiel d’adoption est là, mais il est actuellement bloqué par la mise à l’échelle.

Une étude publiée par Tata Communications en 2018 a montré que 44% des organisations de son enquête adoptent la blockchain, mais fait également allusion aux problèmes universels qui se posent lors du déploiement de nouvelles technologies. Au niveau architectural, le problème non résolu de l’évolutivité apparaît comme un goulot d’étranglement pour l’adoption de la blockchain et les applications pratiques.

Comme le dit Deloitte Insights, « les systèmes basés sur la blockchain sont comparativement lents ». La lenteur des transactions de la blockchain est une préoccupation majeure pour les entreprises qui dépendent de systèmes de traitement des transactions hérités très performants. » Le monde a reçu un avant-goût des problèmes de mise à l’échelle en 2017 et 2018 : de graves retards de transfert et des frais élevés sur le réseau Bitcoin, et la fameuse application Cryptokitties qui a congestionné le réseau blockchain Ethereum (un réseau sur lequel des milliers d’applications décentralisées s’appuient).

Pour mettre à l’échelle une blockchain, il ne suffit pas d’augmenter la taille du bloc ou de diminuer le temps de bloc en réduisant la complexité du hachage. Avec l’une ou l’autre de ces méthodes, la capacité de mise à l’échelle atteint un plafond avant de pouvoir atteindre les transactions nécessaires pour concurrencer des entreprises comme Visa, qui  » traite en moyenne 150 millions de transactions par jour « , soit environ 1 736 transactions par seconde (TPS).

En comparaison, les vitesses de transaction du bitcoin sont énormément plus faibles. Actuellement, la taille des blocs est fixée à 1 Mo (1 048 576 octets – bien que grâce à SegWit, cette taille puisse s’étendre jusqu’à 4 Mo théoriques) et la taille moyenne des transactions est de 380,04 octets (en supposant que chaque transaction est effectuée d’un portefeuille à x autres portefeuilles – une transaction par lot compterait donc comme une seule transaction. Je parlerai plus tard des transactions par lots et de la raison pour laquelle je les ai étiquetées ainsi) et semble être en augmentation.Par conséquent, le montant moyen des transactions qui peuvent tenir dans un des blocs de Bitcoin, actuellement, est calculé comme suit :

Le temps actuel de génération des blocs de Bitcoin est de 10 minutes ; c’est-à-dire, toutes les dix minutes, un nouveau bloc est miné. En dix minutes (600 secondes), Bitcoin peut effectuer en moyenne environ 2 759,12 transactions, selon les hypothèses précédentes. En d’autres termes, la blockchain Bitcoin ne peut actuellement garantir que 4,6 transactions par seconde.

L’augmentation de la taille des blocs ou la diminution du temps de génération des blocs ne résoudra pas le problème : un regard sur le TPS non-SegWit

Le problème de la scalabilité est emballé avec les propositions de valeur de la blockchain ; par conséquent, on ne peut pas simplement augmenter la scalabilité en changeant les paramètres de la blockchain.

La communauté Bitcoin peut ajuster deux variables pour tenter d’augmenter le TPS. La première variable est la taille du bloc (B), qui est actuellement codée en dur à 1 Mo. Idéalement, B devrait être augmenté pour augmenter le TPS. L’autre variable est le temps de génération du bloc (TB), qui est ajusté en modifiant la complexité du puzzle de hachage. Idéalement, TB devrait être réduit pour augmenter le TPS.

Scénarios 1 & 2

Pour passer de 4,4 à 1 736 de Visa, Bitcoin devrait augmenter son TPS de 377,5x. En d’autres termes, B devrait passer de 1 Mo à 377,5 Mo (tableau 1, S1) ou TB devrait être réduit de dix minutes à 1,6 seconde (tableau 1, S2). Un troisième scénario consisterait à ajuster les deux. Aucun de ces trois scénarios n’est réalisable sur la blockchain en raison d’un troisième facteur non contrôlé : le temps de relais (TR) nécessaire pour diffuser un nouveau bloc à chaque nœud du réseau Bitcoin.

En ce moment, on estime qu’il y a 10 198 nœuds dans le réseau Bitcoin. Transmettre un 1MB (1 048 576 octets) à travers le réseau peer-to-peer prend un certain temps. L’Institut de technologie de Karlsruhe mesure le temps de propagation des blocs de Bitcoin, et le temps moyen de propagation des blocs signalé le 17 janvier 2019 était de 13 989,42 millisecondes, soit environ 14 secondes pour se propager à 99 % du réseau. TB ne peut pas tomber en dessous de 99% de TR (TR99)=14 car si c’est le cas, alors un nouveau bloc serait généré avant qu’un ancien bloc ne soit reçu par la plupart des blocs du réseau. Plus TB se rapproche de TR99, plus les problèmes liés aux forks, aux blocs orphelins et aux réorganisations de la chaîne, ainsi que (dans des cas extrêmes) les vulnérabilités de sécurité comme les attaques par double dépense, sont nombreux.

Scénario 3

Même si TB = TR99 = 14, avec une taille de bloc de 1MB, la blockchain Bitcoin ne pourrait augmenter sa vitesse qu’à 188 TPS (tableau 1, S3). Bien que cette échelle représente une multiplication par 188 des TPS, elle est loin d’atteindre les 1 736 TPS que Visa effectue quotidiennement ; de plus, elle cumule les risques susmentionnés. L’autre variable, B, peut être réajustée, mais pas sans affecter TR, ce qui affecterait TR99 et donc la limite inférieure de TB.

Scénario 4

Par exemple, en doublant la taille de B (de 1MB à 2MB), le temps nécessaire à chaque nœud du réseau pour télécharger un nouveau bloc, TR, augmenterait également – d’environ 2x ; ainsi, à 2MB, TR99 = 28s, donc la limite inférieure de TB serait également de 28s. En augmentant B d’un facteur quelconque, et en augmentant ensuite TR du même facteur, le TPS net resterait le même – dans ce cas, environ 188 TPS (tableau 1, S4). Une solution pour réduire l’impact de B sur TR est d’augmenter la bande passante entre tous les nœuds du réseau Bitcoin. Malheureusement, comme il s’agit d’un réseau P2P, cette responsabilité incombe à chaque pair du réseau.

L’émergence de SegWit

En 2017, le témoin séparé (SegWit) est entré en vigueur dans tous les nœuds Bitcoin. Remarque – Je ne vais pas entrer dans tous les détails de SegWit, mais si vous voulez connaître son histoire et son rôle dans l’émergence du hard fork de Bitcoin Cash, jetez un coup d’œil à cet article :

Il fait ce que son nom semble faire – séparer la partie témoin de chaque transaction des données de transaction réelles. Il s’est produit comme un soft fork, donc il a été institué sans aucun effet majeur sur le réseau et le code blockchain existants. En raison de la façon dont la transaction du témoin serait pondérée, les nouveaux blocs Bitcoin activés par SegWit pourraient théoriquement être augmentés jusqu’à 4 Mo sans modifier la taille du bloc Bitcoin.

Je dis théoriquement parce qu’il existe des facteurs supplémentaires qui contribuent à la taille finale du bloc SegWit. En fait, si vous consultez un explorateur de blockchain Bitcoin, vous verrez que (du moins au moment où cet article a été publié) la taille moyenne des blocs est toujours inférieure à 1MB.

Mais cela ne veut pas dire que les blocs ne peuvent pas dépasser 1 Mo. Au début de 2018, nous avons assisté à l’une des plus grandes (probablement encore la plus grande) tailles de bloc générées, arrivant à peser environ 2,1 Mo. Le soft fork de SegWit a contribué à améliorer la taille des blocs sans modifier le code de base, mais il n’améliore toujours pas le TPS de manière évolutive.

En examinant les quatre scénarios précédents dans le cadre d’un consensus de preuve de travail, nous avons vu que le simple fait d’augmenter la taille des blocs ou de réduire la complexité de l’exploitation minière ne pouvait pas nous mener plus loin. Même une combinaison de ces éléments serait limitée en raison du temps de propagation des transactions. Essayer de miner de nouveaux blocs plus rapidement que les anciens ne peuvent se propager entraînera des problèmes de sécurité assez importants. SegWit a contribué à atténuer certains des problèmes de TPS dans l’intervalle, mais une solution plus évolutive est toujours nécessaire pour atteindre un TPS de type Visa.

Il semble que la mise en place de toute pièce pour augmenter le TPS déplace une autre pièce hors de sa place quelque part ailleurs dans le puzzle de la blockchain ; indépendamment de cela, il existe des projets et des startups qui travaillent pour obtenir les réponses TPS nécessaires pour pousser l’adoption de la blockchain dans un stade évolutif.

Approches existantes et futures pour résoudre la scalabilité

Lorsque l’on cherche la réponse potentielle au problème de la scalabilité, de multiples autres questions se posent. Par exemple, si la réponse n’est applicable que pour une blockchain particulière, alors elle repose sur l’hypothèse que cette blockchain particulière sera celle qui aura besoin de cette scalabilité à l’avenir ; sinon, l’effort est indu ou mal placé. Une autre considération est de comprendre ce que peut être le compromis. À l’heure actuelle, toutes les solutions disponibles s’accompagnent de limitations.

Les paiements par lots en une seule transaction

Pros : Réduit la taille d’un enregistrement de transaction en mettant plusieurs transactions en une seule, permettant un plus grand nombre de transactions globales par bloc, ce qui peut augmenter le TPS dans une certaine mesure.

Cons : Ne peut pas grouper les transactions de plusieurs portefeuilles ensemble ; risque la vie privée

Les paiements par lots ont été une caractéristique de Bitcoin (et donc, les forks de Bitcoin, y compris Digibyte, Dogecoin, Bitcoin Cash, etc.) à travers le RPC sendmany. Les échanges le font déjà, et vous pouvez le constater lorsque vous essayez de rechercher l’ID de votre transaction sur un explorateur de blockchain. Ce que vous pourriez voir, c’est un portefeuille qui envoie des fonds à plusieurs portefeuilles différents. Dans ce cas, il s’agit d’une transaction par lots.

L’avantage de cela est que le fait de le mettre dans une seule transaction signifie que 1) vous ne devez payer qu’un seul frais de transaction, et 2) vous n’avez pas à écrire une transaction complète qui est, comme je l’ai décrit précédemment, environ 380 octets, pour chaque transaction. En fait, sur les 380 octets que peut représenter la transaction, seuls 34 octets pourraient être les informations de la transaction.