Voici la suite du compte-rendu de la conférence Scaling Bitcoin, dédiée aux améliorations techniques du protocole. Après avoir abordé les questions de la confidentialité des transactions et de la fongibilité de Bitcoin, les core developers ont présenté les résultats de leurs recherches concernant la propagation des blocs, les clients logiciels légers ou encore des outils d’analyse heuristique.
Cette série d’articles a pour but de rendre compréhensibles les nombreuses solutions développées par les experts du réseau Bitcoin, devant permettre à celui-ci d’accueillir plus de participants, et de traiter plus de transactions en un temps donné, pour des frais moindres. C’est peu à peu que ces solutions seront testées et implémentées, et ces articles resteront sans doute d’actualité plusieurs mois.
Le coût élevé des transactions pose de plus en plus de problèmes aux utilisateurs de Bitcoin et divise la communauté quant à la façon d’y remédier. Les solutions qui passent par les canaux de paiements secondaires à la blockchain sont longues à implémenter, et l’approche prudente des développeurs est souvent critiquée et comparée à de l’immobilisme. Encore faut-il rappeler que Bitcoin reste très jeune et que la sécurité du réseau doit rester la priorité numéro un des acteurs et utilisateurs de l’écosystème.
FlyClient: Super Light Clients for Cryptocurrencies
Par Benedikt Bünz (Université de Stanford)
On parle de logiciel client léger ou super léger lorsque ce dernier ne stocke pas l’intégralité de la blockchain sur la machine-hôte pour vérifier la validité des transactions soumises. Ce sont les wallets les plus répandus (notamment les portefeuilles mobiles).
Benedikt Bünz a rappelé les caractéristiques d’une blockchain :
- Chaque bloc est connecté au précédent à travers les hashes (les résultantes de la fonction de hachage, que cherchent les mineurs).
- L’en-tête de chaque bloc est relié à l’ensemble des transactions qu’il contient via l’arbre de Merkel (où chaque nœud engendre les branches secondaires de l’arbre par une fonction de hachage).
Afin de vérifier que la blockchain est valide, il faut :
- S’assurer que les requêtes transactions ne dépensent pas plus que ce qui est possible ;
- Vérifier que l’arbre a été construit correctement ;
- Enfin, vérifier que chaque en-tête est correct, c’est-à-dire qu’il est relié au bloc précédent par la preuve de travail, ce qui impose que son hash commence par un nombre fixé de zéros (c’est pourquoi les mineurs génèrent aléatoirement des valeurs de hash et sont en compétition pour trouver une solution qui convient).
Pour vérifier que notre blockchain est correcte, par exemple dans le cas où l’on se retrouve avec deux versions différentes, l’une des règles est de suivre la chaîne présentant le plus de preuve de travail cumulée (la chaîne la plus longue). La conjecture est donc la suivante :
- Miner de façon honnête est la stratégie d’équilibre, ainsi la meilleure stratégie est donc de suivre les règles de consensus du réseau ;
- La majorité des nœuds sont rationnels; ils mineront donc honnêtement et suivront les règles de consensus.
Ainsi, même après avoir été offline pendant plusieurs mois, il est facile de télécharger la bonne blockchain, car il suffit de vérifier que les en-têtes des blocs sont valides pour s’assurer que les bonnes règles de consensus ont été suivies.
Aujourd’hui, la blockchain de Bitcoin fait plus de 150 Go et il est impensable de la télécharger entièrement sur son smartphone : Satoshi l’avait prévu et avait proposé l’idée de simple payment verification client (SPV) :
- Pas de stockage des transactions mais seulement les en-têtes des blocs ;
- Vérification de la longueur des chaînes et de la preuve de travail ;
- Possibilité de prouver qu’une transaction est dans un bloc en utilisant simplement la racine de l’arbre de Merkel des transactions, ce qui est pratique car sa taille n’augmente pas avec le nombre de transactions.
Cependant, avec ce système SPV, même si seuls les en-têtes des blocs sont téléchargés, la taille des données augmente tout de même avec le nombre de blocs produits : pour l’instant, cela représente 2,2 Go, ce qui est déjà trop pour la plupart des téléphones portables.
Pour améliorer cela, il y a des techniques très difficiles à mettre en oeuvre, basées sur les fameuses zk-SNARKs ou les NiPoPoW (non-interactive proofs of PoW), mais ce n’est pas ce qui a été retenu.
Benedikt Bünz a alors présenté FlyClient, qui a une approche différente : chaque bloc conserve la racine de l’arbre de Merkel de la totalité de la chaîne précédente. Le logiciel client n’a alors besoin que de la “tête” de la blockchain pour remplir ses fonctions.
Le chercheur a prouvé que son système était viable dans le cas où FlyClient se trouve face à deux chaînes prétendant être honnêtes :
- En plus de la “tête” de la chaîne, FlyClient recueille de façon aléatoire 80 blocs et détermine avec une méthode probabiliste celle qui a le plus de preuve de travail ;
- Si la chaîne malicieuse est un fork de la chaîne mère, ces 80 blocs ne suffiront pas. Il faut en plus de cela déterminer la zone du fork : la méthode utilisée est assez complexe, mais encore une fois la taille des données à télécharger pour effectuer les vérifications est relativement faible (varie de façon logarithmique avec la taille de la blockchain).
Les slides de la présentation.
BlockSci: a Platform for Blockchain Science and Exploration
Par Harry Kalodner (Université de Princeton)
Après toutes ces présentations très techniques et fonctionnelles, l’étudiant à l’université de Princeton a pris du recul sur la notion de scalabilité du protocole afin de présenter BlockSci, son outil analytique.
Motivation : pour améliorer Bitcoin de façon coordonnée et motivée, il est nécessaire de pouvoir analyser la blockchain de façon globale afin d’identifier quels cas d’usage requièrent des solutions techniques de scalabilité.
Des questions économiques se posent :
- Peut-on différencier la demande organique de la demande artificielle sur le réseau ?
- Les blocs sont-ils totalement pleins ? Le mempool[1] est-il surchargé parce qu’il y a beaucoup de personnes qui souhaitent effectuer des transactions dans le même temps ou y a-t-il une attaque ?
Il faut pouvoir différencier les types de demandes et l’espace requis dans les blocs. Par exemple, si l’on regarde quel est le volume de bitcoins déplacés sur une journée, il y aura de nombreuses imprécisions : ces mesures n’incluent pas l’utilisation de l’option “change adresses“[2] ou les utilisateurs qui s’envoient des fonds à eux-mêmes, etc. Il faut pouvoir estimer quelle quantité de bitcoins est transférée entre utilisateurs et entre les entreprises. Bitcoin est-il une réserve de valeur, ou un moyen de paiement ? Quelle est sa “viscosité” ? Les utilisateurs sont-ils juste des investisseurs, comme cela semble être le cas à l’heure actuelle, ou sont-ils en train d’acheter leur café ? Quel est le volume d’échange de bitcoins contre des biens ? Comment différencier la demande organique de la base des utilisateurs ou du spam ? Y a-t-il un type de business qui sature le réseau ?
Harry Kalodner a montré la corrélation entre le volume d’échange sur les plateformes de trading et l’activité sur la blockchain : tous les pics d’activité correspondent à d’importants mouvements sur les plateformes de change. Afin d’avoir une vue plus précise, BlockSci utilise différentes méthodes heuristiques qui permettent de relier des adresses entre elles et déterminer lesquelles correspondent à un même utilisateur. Le code source de BlockSci est public et l’application présente plusieurs avantages :
- Clustering de la blockchain en moins de 10 minutes ;
- Incorporation facile de données externes ;
- Nul besoin de disposer d’une forte puissance pour pouvoir analyser chaque entrée ou sortie dans la blockchain ;
- Interface facile à programmer.
En conclusion, Harry Kalodner a signalé qu’en utilisant BlockSci pour analyser certains portefeuilles multisignatures, il était possible d’en déduire certaines données confidentielles sur l’organisation utilisant ces portefeuilles…
Les slides de la présentation.
Graphene: A New Protocol for Block Propagation Using Set Reconciliation
Par Brian Neil Levine (College of Information and Computer Sciences, UMass Amherst)
Définition du problème : il faut pouvoir relayer des informations de la façon la plus rapide possible sur un réseau pair à pair. Il s’agit donc avant tout d’éviter d’envoyer une quantité trop importante de données entre deux pairs. Évidemment, les blocs sont propagés plus rapidement lorsqu’ils sont de petite taille, et une propagation plus rapide diminue le nombre de blocs orphelins, ce qui augmente l’efficacité du minage.
Graphene, la solution présentée, est dix fois plus performante que les méthodes existantes. Elle s’appuie sur différents protocoles :
- Compact blocks (BIP 152): il s’agit de ne pas envoyer les transactions dans leur totalité pour annoncer un bloc mais seulement les identifiants, permettant d’annoncer un bloc de 1 Mo avec seulement 21 Ko de données. La taille croît de façon linéaire avec le nombre de transactions incluses dans le bloc mais reste indépendante de celle du mempool.
- Xtreme thin blocks : basé sur les filtres de Bloom, le protocole part du principe que les nœuds voisins ont déjà la plupart des identifiants des transactions et qu’il ne leur en manque que quelques-uns. Les filtres de Bloom permettent de vérifier rapidement qu’un item appartient bien à un ensemble : les pairs peuvent donc communiquer le set de transactions présent dans le bloc ou leur mempool sous la forme d’un filtre de Bloom. Désavantage : cette méthode peut générer des erreurs (faux positifs).
- IBLTs (Invertible Bloom Lookup Tables) : une architecture de données encore plus complexe que les filtres de Bloom, qui permet de comparer des ensembles en utilisant moins de données. Inconvénient : la taille des tables varie en fonction du ratio entre la taille du bloc propagé et la taille du memory pool.
Graphène combine astucieusement ces différentes architectures dans un protocole qui permet aux pairs du réseau de bénéficier de l’ensemble de leurs avantages, tout en surmontant leurs inconvénients, en ajustant la quantité de données propagées en fonction d’un taux d’erreurs acceptable. C’est le compromis le plus performant trouvé à ce jour :
- Il suffit d’un paquet IP pour inclure Graphène ;
- Cela n’ajoute pas d’usage CPU ou disque notoire.
Les slides de la présentation.
Measuring maximum sustained transaction throughput on a global network of Bitcoin nodes
Par Peter Rizun, Andrea Suisani, Andrew Stone (Bitcoin Unlimited)
Andrew Stone, de Bitcoin Unlimited, n’a pas mâché ses mots quant à l’état de Bitcoin pour présenter son projet :
- Le volume de transactions effectuées sur le réseau Bitcoin grandit de façon exponentielle mais il y a une limite au nombre de transactions pouvant être confirmées. Les frais ont fortement augmenté et les temps de confirmation ne sont pas fiables, rendant Bitcoin inutilisable pour certains usages.
- Certains souhaitent voir la taille des blocs augmenter afin d’améliorer les choses. D’autres s’inquiètent de voir la fonction “cash électronique pair à pair” disparaître s’il n’y a pas de changement.
- Bitcoin reste hautement scalable car chaque utilisateur peut devenir sa propre banque, vérifier ses propres transactions et envoyer des paiements aux autres utilisateurs sans passer par les mineurs, et cette technologie est déjà disponible.
- Les problèmes de scalabilité concernent les noeuds du réseau qui doivent traiter chacune des transactions sans exception afin de sécuriser le réseau. Si 4 milliards d’utilisateurs effectuent chacun une transaction par jour, cela fait 50 000 transactions par seconde à traiter.
L’équipe de Bitcoin Unlimited s’est donc intéressée à cet objectif de 50 000 tx/s. Est-ce facile à atteindre ? Est-ce physiquement impossible ? Sans doute entre les deux : l’équipe a voulu mesurer le débit maximal que l’on peut atteindre avec le logiciel actuel et voir à quel point on pouvait s’approcher de cet objectif.
Le Gigablock Tesnet : l’équipe a monté un testnet de 18 noeuds qui utilise des blocs de 1 Go ! Machines à processeurs quadri-cœurs, connexion Internet 30 Mo/sec, 16 Go de RAM et un bon disque dur SSD. Elle utilise 4 à 6 noeuds pour miner et le reste pour créer des transactions et les diffuser. Andrew Stone a présenté les résultats de leurs tests :
- Les générateurs pouvaient maintenir un rythme de 2000 tx/sec ;
- Jusqu’à 100 tx/s, tout se passe plutôt bien ;
- Au-delà, le mempool commence à avoir un gros temps de latence ;
- La limite de 500 tx/s n’a jamais pu être dépassée.
Les problèmes surviennent car actuellement le code source qui gère le mempool ne permet pas de paralléliser les tâches. En effectuant quelques modifications, et en changeant les protocoles de propagation des blocs avec la méthode “Xtreme thin blocks” exposée durant la présentation de Graphène, il sera possible d’augmenter le nombre de transactions traitées de façon significative, sans doute jusqu’à 1000 tx/s, voire 10 000. Andrew Stone a insisté sur le fait que les limitations ne viennent pas du protocole Bitcoin lui-même, ou encore de la capacité des ordinateurs utilisés ou de la bande passante dont ils disposent, mais de l’implémentation logicielle du protocole. Avec du travail, il sera selon lui possible d’atteindre des ordres de grandeur comparables à Visa.
Il a décrit les optimisations réalisées, basées sur les fameux filtres de Bloom présentés précédemment, quant au protocole gérant la façon dont le mempool accepte les requêtes de transaction.
L’idée des blocs de 1 Go a révulsé de nombreux adeptes des petits blocs, bien évidemment ! La seule présence de l’équipe Bitcoin Unlimited fut critiquée par certains participants intégristes. Cependant, les organisateurs ont rappelé à plusieurs reprises que Scaling Bitcoin était une conférence “agnostique” et que chacun pouvait présenter les solutions qui lui semblaient les meilleures pour accroître la scalabilité du réseau.
Les slides de la présentation.
Break !
Le repas de midi fut l’occasion pour de nombreux spectateurs de poser leurs questions aux développeurs. Les débats portaient principalement sur la faisabilité et le niveau de sécurité des solutions apportées.
À suivre !
Commentaires