Pavillon rouge et noir

Dans un précédent billet critiquant l'usage du terme "portefeuille" dans les cryptomonnaies, j'expliquais rapidement la nécessité pour une blockchain d'être immuable. Dans un autre billet, je revenais sur le fait que, contrairement à une idée fausse mais qui semble assez répandue, la preuve de travail (ou d'enjeu) est un mécanisme de consensus^[1] et pas du tout d'immuabilité.

Dans ce billet, je voudrais donc revenir plus en détail sur ce qui fait l'immuabilité d'une blockchain, et en quoi ce n'est absolument pas spécifique à cette technologie. Pour cela je vais devoir commencer par expliquer ce qu'est un condensat cryptographique.

Condensat. Un condensat est le résultat d'une fonction de hachage. Une fonction de hachage est un algorithme qui à une donnée numérique (par exemple, un fichier) associe un nombre : le condensat. Cet algorithme est déterministe, c'est à dire qu'il n'utilise pas de hasard : si on lui redonne la même donnée en entrée, il reproduira le même nombre en sortie. C'est pour ça qu'on parle parfois d'empreinte numérique (au sens des empreintes digitales, qui permettent une identification) plutôt que de condensat. Une autre particularité de cet algorithme est de devoir mettre en œuvre l'effet d'avalanche, c'est à dire que le moindre changement dans la donnée d'entrée (même un seul bit) doit provoquer un gros changement dans son résultat (chaque bit du nombre résultat a idéalement une chance sur deux de changer de valeur). C'est pour ça qu'on parle parfois de somme de contrôle plutôt que de condensat : ça permet de s'assurer de l'intégrité parfaite de la donnée après un transfert sur le réseau par exemple.

Exemple. La fonction sha256 est un algorithme de hachage qui fait les associations suivantes :

• donnée : "abc" (en binaire : 01100001 01100010 01100011),
  condensat : 9682368737159886­1417056907351531­5707566766479517 ;
• donnée : "Abc" (en binaire : 01000001 01100010 01100011),
  condensat : 8297738529930439­7015238300242493­2415731791513586.

On remarque qu'un seul bit de changement dans la donnée d'entrée (le troisième, qui correspond au passage en majuscule de la première lettre) provoque un changement complet du résultat de l'algorithme de hachage (effet d'avalanche). Et bien sûr, la fonction redonnera toujours le même résultat pour une même donnée en entrée (déterminisme). Ce sont ces deux propriétés qui nous permettent d'utiliser les condensats calculés par la fonction sha256 comme empreintes numériques ou sommes de contrôle pour vérifier l'intégrité de données.

Dans une blockchain, chaque bloc a un identifiant unique, qui correspond au condensat des données qu'il contient. Étant donné un bloc, n'importe qui peut s'assurer de son intégrité en recalculant le condensat cryptographique correspondant à ses données, et en vérifiant qu'il correspond bien à son identifiant. Cela fonctionne comme avec n'importe quelle donnée dont on connaît le condensat de la version intègre (ici, l'identifiant du bloc).

Collision. Si on veut distribuer une version altérée d'une donnée dont le condensat de la version intègre est publiquement connu, il est nécessaire de trouver une collision. C'est à dire qu'il faut trouver comment modifier, en plus des changements qu'on souhaite y apporter, la donnée de façon à ce que la nouvelle version ait le même condensat. C'est parfois possible, car les condensats ont une taille maximale, alors que les données non, donc il peut y avoir plusieurs données qui partagent le même condensat^[2]. Mais en pratique, c'est extrêmement difficile de trouver des collisions si l'algorithme de hachage qu'on utilise est cryptographiquement solide (ce qui est le cas par exemple de sha256 — pour l'instant en tout cas). Cela est notamment dû au fait que les algorithmes de hachage cryptographiques sont des fonctions à sens unique, c'est à dire des fonctions qui sont faciles à calculer dans un sens (donnée → condensat correspondant) mais très très difficiles à calculer dans l'autre sens (condensat → données correspondantes).

Chaîne. Parmi les données que contient un bloc, il y a entre autre l'identifiant de son bloc parent, c'est à dire celui qui le précède. C'est justement ce qui fait que que les blocs sont moralement "attachés" les uns à la suite des autres et forment ainsi une chaîne (d'où le nom "blockchain"). Si on modifie le contenu d'un bloc (par exemple en retirant une transaction, ou en changeant son montant), alors on change son identifiant, ce qui casse la chaîne : le bloc suivant ne contient plus l'identifiant de son parent, on a cassé la chaîne. On doit donc changer aussi le bloc suivant, et donc son identifiant, et ainsi de suite jusqu'au dernier (par réaction en chaîne, littéralement). Par le même effet, le chaînage protège également de la disparition, de l'apparition, ou du réordonnancement de blocs, assurant ainsi l'intégrité de la chaîne dans son ensemble et pas seulement de chaque bloc pris individuellement.

Distribution. Une autre propriété des blockchains est qu'elles sont publiques et distribuées, c'est à dire que n'importe qui peut en faire une copie, la conserver, et la tenir à jour, de sorte à pouvoir vérifier l'intégrité de la chaîne (ou du moins la conformité à la version dont il dispose) à tout moment.

Immuabilité. Ce sont ces deux propriétés réunies (le chaînage et la distribution) qui font l'immuabilité. Il n'est absolument pas possible de modifier la chaîne sans que ce soit immédiatement visible. À moins qu'on ne soit capable de trouver une collision, soit on casse de manière visible l'intégrité de la chaîne, soit on doit changer aussi les identifiants de tous les blocs depuis celui modifié (ou retiré ou ajouté) jusqu'au dernier pour les faire correspondre aux nouveaux condensats, et avoir ainsi une nouvelle chaîne autocohérente, mais cela est encore plus visible car elle sera totalement différente jusqu'à son dernier maillon.

Voilà ce qui fait effectivement l'immuabilité d'une blockchain, et qui n'a donc rien à voir avec la preuve de travail ou d'enjeu, qui sont uniquement des mécanismes de tirage au sort consensuels en situation conflictuelle, et qui sont la réelle innovation des blockchains.

En effet, la structure de chaîne garantissant l'immuabilité n'est pas du tout spécifique aux blockchains et existait déjà bien avant. Par exemple dans le logiciel de contrôle de versions décentralisé Git. C'est pour ça que je m'acharne à répéter que même si ce dont on a besoin est un registre public et garanti immuable, quand il y a un tiers de confiance ou une autorité extérieure, on a pas besoin de blockchain. Cela reste vrai même si l'autorité extérieure n'est pas centralisée mais partagée (par exemple au sein d'un consortium, d'un comité de gouvernance, etc.), en fait dès qu'une liste d'acteurs identifiés sont en charge du registre. En comprenant cela, on discrédite immédiatement tous les projets construits autour d'une blockchain permissionnée ou pire, privée.

Il ne reste plus alors qu'à comprendre qu'une autorité extérieure est forcément nécessaire pour rendre pertinent ce qui est écrit sur une blockchain, dès lors que cela concerne quelque chose d'extérieure à cette blockchain^[3], pour ce rendre compte que décidément, les cas d'usages justifiés de cette technologie sont bien limités…