Depuis quelques années, il n’est plus un problème qu’une chaîne de blocs* ne permette de résoudre, du moins en théorie. Ces dispositifs supposément transparents et inviolables peinent, depuis plus de dix ans, à trouver une application rentable, si bien que leur utilité paraît aussi incertaine que leur valeur est fluctuante. Il se trouve toutefois toujours un enthousiaste pour expliquer, dans un sabir dont aucun des termes n’est bien défini, la supériorité de ces chaînes de blocs sur ce que l’humanité a pu produire jusqu’ici. À vrai dire, peu importe que ces discours ne mènent nulle part : la fascination des chaînes de blocs s’explique à elle seule par la fortune supposée des prophètes technologiques, qui intéresse aux tribulations des cyberjetons* tous les pauvres hères rêvant de gloire et de conquête.
Comme le coût de fonctionnement et les effets néfastes de Bitcoin commencent à être bien connus (Mora et al., 2018) et exposés en direct par l’université de Cambridge (https://cbeci.org/index), on se résout parfois à penser que ces extravagances seraient le prix à payer pour le progrès. Mais ce prix est-il l’objet d’un arbitrage économique rationnel ou d’un dilemme cornélien ? Les termes du problème s’éclairent si on prend le temps de l’expliquer en bon français. Le présent article détaille, en quatre temps, ce que sont effectivement les chaînes de blocs, ce qui les distingue des bases de données traditionnelles, pourquoi les chaînes à preuve de travail* ne sont pas durables et où en est la recherche d’algorithmes de consensus pour produire des chaînes durables et fiables.
Qu’est-ce qu’une chaîne de blocs ?
Une chaîne de blocs est une base de données dont les enregistrements sont groupés en blocs. Aucun enregistrement n’existe en dehors d’un bloc, c’est-à-dire que tous les enregistrements appartiennent chacun à un bloc déterminé. Ces blocs sont « chaînés » car chaque bloc possède une « signature » qui sera rappelée dans l’en-tête du bloc suivant (voir schéma 1)
En général, la signature est formée à partir des informations du bloc par le protocole* qui gère la chaîne. La fonction qui opère ce calcul n’est pas triviale, de sorte qu’il n’est pas possible
Si on change un bloc intérieur, il faut donc changer tous les blocs situés en aval, c’est-à-dire tous les blocs plus récents, pour assurer la cohérence des en-têtes et des signatures, comme sur le schéma 3.
On aura donc compris que si on veut modifier un enregistrement dans une chaîne de blocs, il faut modifier non seulement le bloc correspondant, mais aussi tous les blocs suivants pour ne pas interrompre la suite « en chaîne » des signatures et des en-têtes. Mais qu’est-ce qui s’oppose à une telle manœuvre ?
En quoi une chaîne de blocs se distingue d'une base de données traditionnelle ?
On considère parfois naïvement que les chaînes de blocs, parce qu’elles peuvent être reproduites à l’envi, sont protégées contre les manipulations malveillantes, puisqu’il faudrait modifier ou détruire toutes les copies pour corrompre effectivement les données inscrites dans la chaîne. En fait, la multiplicité des copies n’est pas une caractéristique des chaînes de blocs. Le principe de sécuriser les données par réplication est très ancien, il existe aussi bien pour les bases de données que pour les supports d’enregistrement (par exemple la duplication en miroir des disques durs). Mais la plupart de ces systèmes sont centralisés, c’est-à-dire qu’une entité dispose seule des droits d’écriture, c’est d’ailleurs aussi le cas pour les chaînes de blocs dites privées
La décentralisation d’une chaîne de blocs signifie que son contenu est lisible par tous, mais qu’aucune entité ne dispose du droit d’écrire un nouveau bloc, qui peut être remis en jeu à chaque nouveau bloc. L’absence d’une autorité habilitée à écrire pose le problème du consensus*, c’est-à-dire de l’unicité des informations contenues dans les différentes copies de la chaîne de blocs. Un premier élément de consensus consiste à privilégier la chaîne la plus longue
Pourquoi les chaînes à preuve de travail ne sont pas durables
L’idée de la preuve de travail est de rendre coûteuse la production d’un bloc valide. En effet, l’algorithme ne valide un bloc que si sa signature satisfait une contrainte dont la satisfaction ne va pas de soi (par exemple, l’écriture binaire de cette signature comporte un certain nombre de zéros consécutifs
Ces 6,25 bitcoins représentent certainement une récompense alléchante. Mais plusieurs centaines de milliers de machines spécialisées s’efforcent déjà de produire le bloc dont la signature sera satisfaisante. La probabilité de trouver la solution avant la concurrence est égale à la proportion de la puissance totale de calcul qu’on peut mobiliser, ce qui coûte au moins le prix de location des machines et leur consommation d’électricité. La seule consommation se compte en gigawatts, il faut donc mobiliser la production de plusieurs réacteurs nucléaires ou de milliers d’éoliennes… pour produire 6 bitcoins. Ce coût exorbitant protège la chaîne de blocs puisque si on veut réécrire des blocs anciens, il faut pouvoir réécrire tous les suivants, et pour aller plus vite que les machines qui coopèrent dans le réseau, il faut tout simplement plus de puissance de calcul et plus d’électricité.
Un certain nombre de chaînes de blocs ont été attaquées avec succès depuis 2018 : elles correspondent à des cyberjetons mineurs, qui ont gagné dans ces aventures le sobriquet peu enviable de shitcoin. Bitcoin Gold, Ethereum Classic (deux scissions très minoritaires des célèbres jetons éponymes), mais aussi Verge ou Vertcoin ont été attaquées par des mineurs pirates, qui ont mobilisé assez de puissance de calcul pour récrire des blocs et s’arroger des jetons dont la valeur, déjà faible, s’est encore amenuisée avec la compromission de la chaîne de blocs qui leur servait de support. On considère que le coût de ces attaques (location du matériel plus consommation électrique) est de l’ordre d’une centaine de milliers de dollars, que le butin aurait permis de rembourser.
S’il est possible d’attaquer pour un coût « modique » une chaîne de blocs défendue par une faible puissance de calcul, il est manifestement hors de prix d’attaquer Bitcoin. Une telle attaque paraît impensable… sauf bien sûr si un acteur parvenait à coordonner les mineurs : dans la mesure où ceux-ci sont vénaux, cela ne doit pas être impossible, simplement très coûteux. Dans le texte qui, en 2008, avait lancé Bitcoin, Satoshi Nakamoto (il s’agit d’un pseudonyme dont l’identité véritable demeure inconnue) calculait la probabilité de réussir une attaque avec une puissance de calcul inférieure à la majorité du réseau. Depuis Perez-Marco et Grunspan (2017) ont calculé des probabilités ajustées : elles restent très faibles, même pour une dépense significative comme 10 % de la puissance du réseau.
On peut donc dire que Bitcoin est sécurisé par la dépense. Et c’est vrai pour tous les protocoles qui reposent sur une preuve de travail ou ses variantes : certains protocoles comme Chia remplissent des disques durs pour satisfaire une « preuve d’espace ». Tous ces protocoles fondés sur la dépense conduisent invariablement à une « course aux armements » : tant que la vente des jetons permet de rentrer dans ses frais – ou de l’espérer – les mineurs augmentent la puissance de calcul dévolue à ces nouveaux Baals des réseaux, qui dévore l’énergie… et produit 100 kg de CO2 par seconde pour le seul Bitcoin. Une telle gabegie est évidemment d’autant plus intolérable qu’elle ne s’accompagne pas de la production d’un service utile, c’est pourquoi le gouvernement chinois, après avoir laissé engranger des milliards de dollars américains pour brûler le charbon mongol, a commis d’éminents membres de l’Académie des sciences de Chine pour expliquer le problème (Jiang et al. 2021), puis prié les mineurs d’aller polluer ailleurs.
À la recherche de la chaîne de blocs durable
Les excès des chaînes à preuve de travail ont lancé la recherche de chaînes durables : Arthur Breitman (2018) remarque ainsi que la confiance dans les bases de données est un bien public qui a nécessairement un coût, mais que ce coût doit être raisonnable. Aussi le protocole qu’il a développé, Tezos, repose sur la preuve d’enjeu. L’idée est que le protocole tire au hasard un des jetons, dont le propriétaire a le droit de valider un nouveau bloc. La probabilité de valider est donc proportionnelle au nombre de jetons détenus ou « mis en jeu »
Dans un article récent, Saleh a montré que l’argument du « rien en jeu » n’était pas universellement valide. L’idée est que celui qui possède des jetons se soucie de la valeur de ses jetons, et que si la récompense obtenue pour valider un bloc est suffisamment faible, alors il préférera maximiser la valeur de ses jetons plutôt que récupérer des récompenses liées à la validation. Un théorème montre qu’en exigeant un minimum de jetons pour participer au tirage au sort, et en limitant la récompense obtenue pour valider un bloc, alors le protocole converge vers le consensus. Ce théorème est intéressant, car il prend le contre-pied des chaînes à preuve de travail, où c’est la récompense qui attire les mineurs à augmenter la puissance des machines dévolues au minage à concurrence de la récompense offerte pour la validation d’un nouveau bloc. Mais si on avait compris que la dépense énergétique assurait les chaînes à preuve de travail contre les attaques, on ne connaît pas vraiment le niveau de sécurité des chaînes à preuve d’enjeu.
En fait, l’argument de Saleh doit être mis en perspective : il prouve seulement qu’on atteint le consensus, mais ne dit rien de la résilience des chaînes de blocs à preuve d’enjeu face à des attaques. Celle-ci doit encore être documentée, et donc l’utilité pratique des bases de données qui font usage d’un tel protocole est pour l’instant incertaine. On peut considérer qu’elle dépend, comme pour toutes les bases de données, de la présence de failles de sécurité (exploits) qui peuvent être mises à profit par les attaquants. La protection contre ces problèmes repose sur la capacité à détecter les usages malveillants et à y remédier. Ce faisant, les chaînes de blocs apparaissent alors simplement comme des bases de données où la hiérarchie est remise en jeu avant chaque opération d’écriture (chaque « validation de bloc »), puisqu’il n’y a pas d’autres droits acquis que les jetons.
Mais le caractère même des bases de données distribuées que sont les chaînes de blocs et, en particulier, le problème du consensus qu’on vient d’évoquer pour les chaînes à preuve d’enjeu sont en fait les mêmes pour toutes les bases distribuées qui sont vulnérables à un type particulier d’attaques, qui viserait l’infrastructure des réseaux elle-même. Apostolaki et al. (2019) ont par exemple montré les conséquences sur Bitcoin d’une attaque ciblant le protocole de communication entre les réseaux des fournisseurs d’accès
En fin de compte, la sécurité des chaînes de blocs à preuve de travail, comme l’est Bitcoin, est assurée par la dépense qui accompagne leur fonctionnement : on sait depuis l’origine qu’une attaque de force brute nécessite une puissance de calcul supérieure à celle des machines loyales à la chaîne. Le coût d’une telle attaque, s’il est modique pour les « shitcoins » qui en ont déjà subi, est prohibitif pour Bitcoin. Mais Bitcoin a lui-même un coût de fonctionnement insoutenable, en particulier si on prend en compte les effets secondaires sur l’environnement.
Aussi a-t-on cherché d’autres méthodes pour sécuriser les chaînes de blocs et régir l’ajout d’un nouveau bloc à une chaîne existante de manière plus économique. Si la possibilité mathématique que des algorithmes à preuve d’enjeu produisent des chaînes cohérentes est désormais établie, la résistance effective des protocoles correspondants doit encore faire l’objet d’une mise au point qui commence à peine. Et les chaînes de blocs n’apparaissent finalement que comme des bases de données distribuées qui remettent périodiquement en jeu la hiérarchie des permissions (le droit d’écrire un nouveau bloc). Quand bien même leur sécurité aurait été éprouvée, comme pour le protocole Bitcoin (qui a déjà été largement amendé pour pallier ses défauts initiaux), tous ces protocoles distribués sont vulnérables à des attaques « de bas niveau » où les infrastructures des réseaux cibleraient les communications entre les machines stockant les copies des chaînes de blocs : cela permet en particulier à un pays de se mettre à l’écart de tels protocoles. La création de zones dépourvues de copies d’une chaîne de blocs n’est évidemment pas dirimante, mais permet enfin d’envisager une régulation de ces entités qu’on a cru un instant affranchies de toute autorité.