Le bitcoin, les blockchains, comment ça marche ? et la cybersécurité dans tout ça ?

On souhaite partager entre plein de gens un fichier contenant plein de virements qui arrivent en permanence. Perso j’aurais fait un Google Docs, mais on va vite avoir des soucis de synchro et de modifications malveillantes 🙂

Pour avoir un système fiable, tout le monde travaille sur un fichier en lecture seule sur lequel on ajoute de temps en temps un groupe de virements. Faire un ajout à ce fichier demande beaucoup de puissance de calcul, et c’est donc un effort commun (on reviendra sur ce point).

C’est exactement comme ça que fonctionne une blockchain : chaque groupe de virements représente un bloc, et pour faire évoluer le « fichier » on ajoute un nouveau bloc à la suite des existants.

Chaque bloc contient le hash (un « résumé » cryptographique) du bloc précédent. Ainsi, un bloc repose sur tout l’édifice des blocs qui le précèdent, et il est impossible d’effacer discrètement une partie du passé de la blockchain.

Je vous explique dans un instant comment les virements peuvent être créées et authentifiés de manière sécurisée, mais d’abord on va voir pourquoi c’est si difficile d’ajouter un nouveau bloc à la blockchain et pourquoi il faut dépenser tant d’énergie pour le faire.

Pour éviter d’avoir des blocs trop petits et des évolutions dans tous les sens, on ajoute une contrainte aux blocs ajoutés : leur hash doit commencer par au moins 76 bits consécutifs à zéro (76 est la valeur actuelle mais elle évolue au cours du temps).

Pour avoir un tel bloc qui commence par plein de zéros, pas d’option facile : il faut tester des milliards et des milliards de configurations du bloc jusqu’à en trouver une dont le hash soit valide. Cette forme de bruteforce demande énormément de puissance de calcul.

Chacun va donc essayer de son côté de trouver un nouveau bloc valide qui contient les quelques transactions qui attendent d’être inscrites dans la blockchain. Mais pourquoi les gens s’embêteraient-ils à dépenser du temps de calcul et de l’électricité pour ça ?

Maintenant que vous comprenez mieux la structure d’une blockchain, je vous explique pourquoi seul le propriétaire d’un « compte » bitcoin est capable d’ordonner un virement depuis son wallet, même si n’importe qui peut insérer des transactions dans la blockchain.

Pour accéder à un portefeuille bitcoin, on n’utilise pas son email/mdp : chaque propriétaire est identifié par une adresse publique et détient la clé privée correspondante. Pas besoin de s’inscrire pour détenir un portefeuille bitcoin, il suffit de générer une paire de clés.

Une transaction est un message qui transmet une certaine quantité de fonds d’une adresse A vers une adresse B, accompagnée d’une signature cryptographique de la clé privée A qui certifie que cet ordre de virement a bien été émis par le détenteur de la clé.

Dans chaque virement créé, l’émetteur inclut aussi un pourboire (les fees) qui reviendra au mineur du bloc correspondant. Comme chaque bloc contient un nombre de transactions limité, ce pourboire incite le mineur à inclure dans son bloc celles qui lui seront le plus rentables.

Un grand problème des blockchains par rapport à un système bancaire centralisé est que toutes les transactions sont forcément publiques. Mais comme les adresses ne sont pas directement rattachées à une identité, les échanges sont traçables mais restent entièrement anonymes.

Autre souci majeur : l’espace disque. Bitcoin a déjà enregistré près de 700 millions de transactions depuis 2009, soit plus de 350GB pour avoir sa propre copie de la chaîne. Mais il existe une optimisation remarquable qui réduit largement ce volume sans compromettre la sécurité.

En réalité, les transactions ne sont pas directement incluses dans les blocs : la blockchain est ultra légère, et chaque bloc pèse exactement 80 octets même si chacun contient plusieurs milliers de transactions. Compression ultra efficace ? Non, arbres de Merkle !

Un arbre de Merkle est une structure optimisée pour calculer et vérifier un hash de plusieurs données (ici, les transactions d’un bloc).

Ensuite on calcule le hash de chaque paire de hashs, et on recommence l’opération jusqu’à n’avoir qu’un seul hash. Tout cet ensemble forme une structure appelée arbre de Merkle, le noeud tout en bas est la racine de cet arbre et c’est cette racine que l’on inclut dans le bloc.

Du coup les transactions ne sont pas dans la blockchain, on utilise leur représentation ultra-condensée à la place. Comme la fonction de hachage (SHA256) est sécurisée, on considère qu’il est impossible de fabriquer un ensemble de transactions différent ayant la même racine.

Mais pourquoi utiliser l’arbre de Merkle alors que le hash de toutes les transactions concaténées fonctionnerait tout aussi bien ? C’est une question de performance lors de la validation des transactions.

Admettons que j’envoie un peu de bitcoin vers le wallet d’un restaurant pour payer mon repas. La preuve de paiement consiste à démontrer que ma transaction (ici T6) figure bien dans l’un des blocs de la blockchain.

Si la blockchain utilisait le hash de toutes les transactions du bloc qui était utilisé au lieu de la racine de Merkle, je devrais fournir une copie des 8 transactions pour que le destinataire recalcule le hash et vérifie qu’il correspond bien au bloc donné.

Au contraire, avec l’arbre de Merkle, je dois seulement fournir une copie de ma transaction T6 ainsi que les hashs H5, H7-8 et H1-4. Avec seulement ces 4 données, je peux prouver de manière irréfutable que l’arbre de Merkle contient ma transaction.

Toujours pas convaincu.e ? C’est normal. L’arbre de Merkle marche sur de grands ensembles de données. Pour un bloc d’un million de transactions, une preuve de transaction demande seulement 19 hashs pour remonter jusqu’à la racine, soit un volume 52 000 fois plus petit !

Il existe plein d’attaques contre les blockchains ! Je vais vous en présenter une qui était déjà identifiée par Satoshi en 2008, et une autre qui utilise du calcul quantique.

La toute première attaque sur les blockchains fut baptisée « attaque des 51% ». Ce nom vient du fait qu’il faut détenir plus de la moitié de la puissance de minage, autant vous dire que pour bitcoin il faut prévoir un sacré budget ! (mais ça a déjà été vu sur d’autres blockchains).

Le principe est simple : après avoir payé une Ferrari en bitcoins, on reprend une vieille copie de la blockchain (antérieure à notre transaction) et on utilise notre puissance de calcul énorme pour générer une chaîne alternative où nos bitcoins n’ont pas bougé.

Comme on dispose de plus de 50% de la puissance, on va plus vite que tous les autres mineurs réunis et on peut créer une chaîne plus longue. Et comme c’est la plus longue chaîne qui est reconnue, on peut réécrire l’histoire à volonté pour faire disparaître des transactions !

Une autre famille d’attaques cool implique l’utilisation d’un ordinateur quantique. Actuellement personne ne dispose d’un tel calculateur, mais si cette technologie voyait le jour (certains spéculent un horizon 2030) elle mettrait fin au bitcoin et plein d’autres blockchains.

Les transactions bitcoin sont signées via le cryptosystème ECDSA, qui est actuellement le standard principal dès qu’il s’agit de faire des signatures cryptographiques (c’est notamment ce qui sécurise les pass sanitaires en France). Mais ECDSA est menacé d’extinction.

En utilisant l’algorithme de Shor sur un ordinateur quantique, il est possible de casser n’importe quelle clé privée ECDSA pour voler l’argent du wallet correspondant. Le calcul quantique sera une révolution énorme pour internet, et la disparition de bitcoin en fera partie.

Et même pour les autres blockchains utilisant des signatures résistantes à l’algorithme de Shor, il existe toujours l’algorithme de Grover qui rendra inutile toute forme de minage. La seule alternative viable sera le Proof of Stake, et la planète nous en remerciera !

Le papier original de Satoshi Nakamoto : https://bitcoin.org/bitcoin.pdf