Blocage de taille sur taille de blocs

Ceci est l’histoire d’une guerre entre les tenants du code originel du bitcoin et les mineurs.

Le réseau bitcoin voit transiter bon an mal an entre cinq et six milliards d’euros par mois, plus de quinze millions de bitcoins en mars 2016.

La mécanique se doit d’être à la hauteur et à même d’absorber la croissance du trafic. Les transactions en bitcoin sont regroupées dans des blocs de taille fixe pour être validées – le compte à débiter est-il suffisamment fourni ? - par les mineurs à intervalles réguliers avant d’être consignées dans le livre de compte bitcoin. Deux mesures de performance plaident pour un changement de taille de ces blocs.

Penchons nous d’abord sur le nombre de transactions par seconde. Avec une poignée de transactions par seconde (statistiquement mille cinq cents transactions par bloc en mai 2016 et un bloc toutes les dix minutes soit moins de trois transactions par seconde) le bitcoin fait pâle figure face aux vingt mille de la carte Visa. Et pourtant, paradoxe, le bitcoin est censé avoir pour vertu la rapidité ! Alors oui, un virement bitcoin réalisé en quelques minutes indépendamment des situations géographiques des protagonistes est bien plus rapide qu’un virement bancaire qui passe la nuit en chambre de compensation. Et non, attendre dix minutes à une caisse de supermarché que la transaction soit validée n’atteint pas l’aisance de la carte Visa. Très rapide donc pour certains services, trop lent pour d’autres. Toujours est-il que l’évolution de la taille du bloc est attendue avec impatience.

Autre paramètre : le taux de remplissage des blocs. Il est en mai 2016 de l’ordre des trois quarts, sachant qu’il était de quarante pour cent il y a un an. À ce rythme, c’est une question de mois pour que les blocs soient pleins. Il devient urgent de s’attaquer au problème de la taille des blocs.

Conscient de ces échéances, le petit groupe détenteur des clefs du code de bitcoin, le « Bitcoin Core Developer » a fait une proposition durant l’été 2015. Précisons que si le bitcoin a une image libertaire, où les chefs sont absents et remplacés par des relations directes entre pairs, le code originel est maintenu par une petite équipe exerçant de fait une forme de gouvernance centralisée.

Proposer une évolution du code n’est pas le tout, il faut aussi qu’elle soit acceptée par l’ensemble des mineurs. Théoriquement, cinquante et un pour cent suffisent mais pour assurer la fluidité de la mise en œuvre soixante quinze à quatre vingt pour cent sont préférables. En pratique si les mineurs ignorent superbement les recommandations du Bitcoin Core Developer, si une majorité s’abstient d’en télécharger le code et de le faire tourner, la mesure ne sera pas appliquée. Force de proposition côté Core, force de veto côté mineurs. Notons que les mineurs peuvent proposer eux aussi des évolutions.

C’est à ce stade que le conflit à éclater. Le bitcoin core developer a proposé que le passage d’un bloc de taille un Megaoctet passerait à huit Megaoctets en janvier 2016, puis serait doublé tous les deux ans. C’est la proposition BIP 101 / XT, pour Bitcoin Improvement Proposal.

Le refus des mineurs a été patent, le ton est monté et a mené à des remaniements et des démissions de postes clefs. Il a même été question que le Bitcoin ne s’en relève pas. Des contre propositions ont vu le jour (BIP 100) sur la base de taille de blocs qui s’adaptent mais la chose qui nous intéresse est le résultat des courses : une non-décision. On ne bouge pas.

Les arguments sont très techniques et a priori tous fondés. Par exemple l’augmentation de la taille des blocs gonflera la taille de la blockchain bitcoin . Ensuite la mise en réseau de cette version provoque l’apparition de fourches dans la blockchain lors du passage d’un standard à l’autre avec des délais et des pertes de transactions. De plus, un accroissement trop conséquent de la taille mène à une augmentation significative des équipements de minage et donc accentue la concentration. Notons qu’un autre phénomène pourrait bien accentuer la concentration dans cette même période. Au mois de juin a lieu le « halving » qui consiste à diviser par deux la prime que perçoivent les mineurs. Bien des mineurs pourraient changer de métier car les revenus ne sont plus à la hauteur des charges. La concentration nous guette donc plutôt deux fois qu’une avec à la clef le risque de domination par un groupe de mineurs voire par un seul mineur.

En ce printemps 2016, un compromis semble se dessiner pour le court terme. La base serait une légère augmentation de 1 à 1,6 MB dans l’immédiat puis un passage à 4 MB en 2017.

Quoi qu’il en soit, nous pouvons craindre là l’illustration d’un effet de bord du principe de consensus qui est un blocage qui pourrait amener à une cristallisation de la situation. C’est une question de gouvernance qui serait probablement moins prégnante en blockchain privée. Faute de pouvoir évoluer la tentation de créer une autre chaine pourrait être la plus forte. Mais n’est-ce pas ce que nous voyons déjà avec la profusion de blockchain ?

Nous reviendrons largement sur ce thème lors de l'évènement "La blockchain a-t-elle les moyens de ses ambitions?" du 5 juillet dans le cadre de la CloudWeek à l'ISEP, 10 rue de Vanves à Issy les Moulineaux. Les inscriptions sont ouvertes sur le site du Forum ATENA. Attention, le nombre de place est limité !

Auteur: 
Jacques Baudron

Ajouter un commentaire

Full HTML

  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Vous pouvez utiliser du code PHP. Vous devrez inclure les tags <?php ?>.
  • Les lignes et les paragraphes vont à la ligne automatiquement.

Filtered HTML

  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Tags HTML autorisés : <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Les lignes et les paragraphes vont à la ligne automatiquement.

Plain text

  • Aucune balise HTML autorisée.
  • Les adresses de pages web et de courriels sont transformées en liens automatiquement.
  • Les lignes et les paragraphes vont à la ligne automatiquement.