Mot-clé : blockchain

lundi 5 septembre 2022

Critique : “Cryptomonnaies, NFT… La bulle éclate ?”

Mercredi 17 août l’émission « Le téléphone sonne » portait sur les « cryptomonnaies » et NFT. J’ai écouté l’émission et y ait réagit en direct sur Twitter. J’archive ici le fil de tweets qui en résultent. C’est bien sûr à lire en écoutant l’émission pour avoir le contexte des réactions.

  • Ça commence, je tweeterai ci-dessous si des choses qui sont dites dans l’émission me font réagir :). #TelSonne #blockchain

    Ça se passe ici : Cryptomonnaies, NFT… La bulle éclate ?
    Cryptomonnaies, NFT… La bulle éclate ?

  • Le coût en énergie d’une blockchain n’est pas seulement dû à la preuve de travail, il existe, même si c’est dans une moindre mesure, de toutes façons, parce qu’une blockchain n’existe jamais à la place d’une alternative, mais en plus. J’en parlais là : le coût d’une blockchain.

  • La transition d’ETH vers la preuve d’enjeu, si elle va permettre de consommer beaucoup moins (si ça arrive effectivement), c’est surtout parce que la preuve de travail consomme énormément.

  • Et de fait Bitcoin ne changera pas de méthode, c’est certains, c’est ancré dans son idéologie que ça se passe comme ça. Et à propos de ce que raconte Ludovic Desmedt, je vous invite à lire “The Politics of Bitcoin: Software as Right-Wing Extremism”.

  • “Un système anti-inflationniste” : c’est vrai seulement si on suppose que l’inflation est liée directement et uniquement à la création monétaire. Ce qui est tout simplement… complètement faux.

  • Ce qu’explique Desmedt est très juste également sur le rapport entre coût de l’énergie et récompense pour le minage. C’est pour ça que les frais de transaction sont voués à devenir extrêmement conséquents (alors que c’est un des arguments des défenseurs de cette technologie).

  • Dire que le Bitcoin n’est pas conçu pour la spéculation ça demande quand même quelques contorsions… en pratique c’est issu d’une idéologie libertarienne et est donc intimement lié à l’idée de “marché libre” qui sont censés être efficients, etc. Donc c’était 100% inévitable.

  • Parenthèse sur les marchés “efficients”, je recommande chaudement cette vidéo de Heu?reka :

    Les marchés financiers sont-ils efficients ? - Heu?reka

  • Boulet a raison de rappeler que Bitcoin n’est pas du tout anonyme. Son objectif n’est en aucun cas de protéger la vie privée des personnes.

  • Si on veut reproduire un système de transaction qui reproduise de l’argent liquide (anonymat pour les personnes, véritablement décentraliser, etc), on sait faire, mais certainement pas à base de blockchain : avec GNU Taler par exemple.

  • Boulet précise bien que Bitcoin n’est pas une monnaie et que si on veut s’en servir pour des vrais achats faut convertir en vrai monnaie. C’est à la limite une devise (± tout peut servir de devise, c’est pas une propriété intéressante), mais ce n’est pas un système monétaire…

  • Desmedt en remet une couche sur l’aspect purement spéculatif des « cryptomonnaies », en l’expliquant par plusieurs facteurs. Certaines épargnes qui ont augmentées suite aux confinements par exemple, ce qui explique l’artifice des taux atteint en 2021, intéressant !

  • Et maintenant que c’est plus coûteux d’emprunter, y a moins de quoi alimenter la spéculation, et comme les cryptoactifs sont rattachés à absolument rien et purement spéculatifs, nécessairement ça s’effondre.

  • Desmedt a aussi bien utilisé le mot “intermédiaire” pour parler des plateformes par lesquelles la quasi intégralité des échanges concernant les cryptoactifs se font.

  • Les blockchains ne permettent pas en pratique la moindre désintermédiation.

  • Boulet revient sur le fait que les cryptoactifs ne sont pas des monnaies. Pour lui ils ne permettent que la fonction “réserve de valeur” des 3 fonctions d’une monnaie (intermédiaire d’échange, réserve de valeur, et unité de compte). Franchement, vu la volatilité de ces choses je trouve que ça ne tient pas du tout la route. Comment se servir de réserve d’un jour à l’autre peut perdre 100% de sa valeur ? Il y a besoin de stabilité pour ça.

  • Boulet parle de « cryptomonnaies » qui créent de la valeur parce qu’il y a un produit derrière. Ça pour le coup ça ne tient pas la route. Il ne peut pas y avoir de produit derrière qui ne sont pas l’actif spéculatif qu’est cette « cryptomonnaie » elle-même. Cf la vérité sur la blockchain.

  • Desmedt parle de monnaie virtuel de banque centrale par opposition aux « cryptomonnaies » qu’il dit “complètement décentralisées”.

  • C’est faux que les « cryptomonnaies » sont décentralisés. Le réseaux sous-jacents est décentralisé, les transactions ne le sont pas !

  • Elles nécessitent un centre qui est distribué, mais qui reste un centre. Les euros numériques pourraient tout à fait disposer d’un système de transaction effectivement décentralisé (sans blockchain !), cf Taler News : Comment émettre une monnaie numérique de banque centrale ?.

  • Desmedt fait des raccourcis un peu dangereux. Oui c’est libertarien, oui ça veut échapper au contrôle de l’état, mais certainement pas à Big Brother, du moment que Big Brother est privé (non démocratiquement contrôlé) est agit selon les lois d’un marché libre…

  • Ils ont complètement esquivé la question de l’auditrice qui a dit qu’elle y pige rien alors que c’était ultra pertinent…

  • C’est dommage, Boulet conclu l’émission sur une énorme connerie : NON la technologie blockchain ne peut absolument pas servir à autre chose que des « cryptomonnaies », et l’exemple (typique) qu’il a pris de la traçabilité ne fonctionne pas du tout.

  • C’est vraiment une mécompréhension profonde de ce qu’est une blockchain. Je remets ça là : la vérité sur la blockchain.

  • Ça c’est un très bon point :

    • tweet de @z8po : « puis un système déflationniste (si tu peux pas émettre à l’infini et que y a destruction de monnaie par oubli) c’est pas mieux ».

  • Les bitcoins sont voués à disparaître petit à petit au fur et à mesure qu’ils sont perdus, ne serait-ce que parce qu’on perd la clef qui permet d’accéder au « portefeuille » (c’est un très mauvais terme) qui les contient…

  • Bon ben c’est déjà fini. Je vous laisse avec cette liste d’articles si vous voulez un peu plus de lecture : Blockchain, cryptomonnaie, NFT.

dimanche 24 juillet 2022

Lecture : “The Politics of Bitcoin”

J’ai récemment terminé de lire le livre de David Golumbia intitulé The Politics of Bitcoin: Software as Right-Wing Extremism. C’était une excellente lecture que je recommande fortement à toute personne souhaitant s’intéresser sérieusement aux blockchains. Il a d’ailleurs immédiatement rejoint la liste de mes recommandations de livres sur mon site web.

En six chapitres, l’auteur démontre parfaitement à quel point le sous-titre de son livre est justifié. Il commence par expliquer les liens entre une culture historiquement hégémonique sur les Internets, le cyber-libertarianisme, et certains idéaux politiques de droite et d’extrême droite. Il explique en quoi cette idéologie individualiste pousse depuis un certains temps à la volonté de création d’une monnaie alternative puis comment, en se mêlant à des théories complotistes (elles aussi portées par l’extrême droite) concernant notamment les banques centrales et renforcées par la crise économique de 2008, cela a aboutit à la création puis au succès (relatif) de Bitcoin.

Il démontre ensuite assez rigoureusement en quoi ces racines idéologiques et complotistes sont gravées dans Bitcoin et dans la technologie de la blockchain qui le sous-tend, et comment cela impact tout l’écosystème qui va autour, jusqu’à la forme que prennent les arguments des défenseurs de ces technologies — typiquement, le fait d’interpréter deux évènements pourtant contraires (par exemple le court du Bitcoin qui monte ou qui baisse) comme des indicateurs de l’inévitable succès à venir, même quand il y a des preuves du contraire.

Au passage l’auteur se permet de donner les quelques explications techniques, sur Bitcoin lui même comme sur l’économie et la finance (l’inflation, le rôle des banques centrales, la nature de la monnaie, etc) pour mieux démonter les théories conspirationnistes, et tout cela est systématiquement fait sources et citations à l’appui. En particulier il explique très bien la différence entre une devise (“currency”) et une monnaie (“money”) et comment la confusion entre les deux est constamment utilisée par les défenseurs des « cryptomonnaies ». Une monnaie doit avoir trois fonctions : intermédiaire d’échange, réserve de valeur, et unité de compte ; et l’auteur montre sans difficulté que non seulement les crypto-actifs (terme qu’il faut préférer à celui de « cryptomonnaies ») ne peuvent remplir que la première de ces fonctions, mais qu’en vérité plus ou moins n’importe quoi peut remplir cette fonction…

De façon intéressante, l’auteur fait aussi remarquer que, si sur les plans économique et technique les blockchains n’ont aucune utilité et aucun avenir, sur le plan politique, elles servent de porte d’entrée et de porte-voix à des idées qui, avant l’arrivée de Bitcoin, étaient assez universellement perçues comme d’extrême droite et de droite libertarienne. Il expose ainsi comment les discours, et même le vocabulaire, issus de ces tendances politiques sont généralisés autour des blockchains. Par exemple, le fait que soit résumé à « liberté » ce qui est en fait « l’absence de régulation par une entité démocratique », ou encore qu’il soit question de « limiter le pouvoir » seulement quand il s’agit de celui du gouvernement.

C’est d’ailleurs tout au long du livre, et c’est de nouveau le message qu’il utilisera en guise de conclusion, que l’auteur met en garde contre les tentations que pourraient avoir les personnes de gauche de détourner les blockchains à leur avantage : cela ne fonctionnera pas, car cette technologie est structurellement opposée à leur valeur. Au contraire, « ce qu’il faut pour combattre [le pouvoir en place], ce n’est pas plus de guerres entre des plateformes algorithmiques et des individus qui se considèrent au-dessus de la politique, mais une réaffirmation du pouvoir politique, ce que la blockchain est spécifiquement construite pour démanteler »[1].

Bref, je ne détaille pas plus et ne vous raconte pas tout : lecture recommandée ! Le bouquin n’est pas cher, et pour celles et ceux qui sont vraiment fauché·es, il se trouve assez facilement sur le web…

Note

  1. ^ C’est la dernière phrase du livre : “What is required to combat that power is not more wars between algorithmic platforms and individuals who see themselves as above politics, but a reassertion of the political power that the blockchain is specifically constructed to dismantle.”.

lundi 7 février 2022

Le coût d'une blockchain

Quand on parle du coût d’une blockchain, on fait souvent référence à son mécanisme de consensus, typiquement de la preuve de travail. Quand on explique que ce coût est exorbitant, il est souvent rétorqué que d’autres mécanismes de consensus à base de preuve d’enjeu peuvent être utilisés et qu’ils sont beaucoup moins consommateur d’énergie. Dans ce billet, je vais m’intéresser au coût d’une blockchain indépendamment du mécanisme de consensus choisi, c’est à dire à une partie incompressible du coût que l’on doit payer quand on choisi d’utiliser une blockchain.

Une blockchain est un registre immuable en ajout seulement (append-only). C’est à dire qu’on ne peut y rajouter de l’information qu’à la suite de ce qui est déjà écrit dedans, et qu’une fois qu’on y a ajouté une information, on ne peut plus modifier ou supprimer cette information. En pratique, cela signifie qu’une blockchain ne contient pas directement l’état d’un système, mais une suite de modifications ordonnées de l’état d’un système. Le sens de cette dernière phrase est probablement assez obscure, je vais donc l’expliquer avant d’en tirer des conclusions.

Commençons avec un exemple qui ressemble[1] à une cryptomonnaie : le ¢. Dans ce système, il y a des participant·es : Alice, Bob, Charlie, Diane, Emma, et Farid. Initialement il y a deux participant·es qui sont tiré·es au sort et qui reçoivent 5¢ : Bob et Diane. Et donc l’état initial de mon système est que Bob et Diane ont chacun·e 5¢, et que tou·tes les autres ont 0¢. On pourrait noter cet état comme ça par exemple : (A:0, B:5, C:0, D:5, E:0, F:0).

Maintenant faisons tourner notre système. Imaginons que Bob envoie 2¢ à Alice et 1¢ à Farid, et que Diane envoie 1¢ à Bob. On pourrait noter ces transactions comme ceci : [B→A:2, B→F:1, D→B:1]. Le nouvel état du système serait donc (A:2, B:3, C:0, D:4, E:0, F:1). Continuons avec Alice qui envoie 1¢ à Charlie, Bob qui envoie 2¢ à Farid, et Diane qui envoie 1¢ à Emma et 1¢ à Alice : [A→C:1, B→F:2, D→E:1, D→A:1]. Le nouvel état du système serait alors (A:2, B:1, C:1, D:2, E:1, F:3).

Si maintenant je vous pose des questions comme : “Combien Alice possède-t-elle de ¢ ?” ou “Est-ce que Bob peut dépenser 3¢ sans être à découvert ?”, vous allez naturellement regarder la dernière version de l’état du système pour pouvoir y répondre directement. Mais, comme je le disais plus haut, si vous utilisez une blockchain, vous n’avez pas un accès direct à l’état du système, mais seulement aux modifications successives de celui-ci. Dans notre exemple, la blockchain ressemblerait à ça :

[_→B:5, _→D:5] ⇒ [B→A:2, B→F:1, D→B:1] ⇒ [A→C:1, B→F:2, D→E:1, D→A:1]

Si vous ne disposez que de la blockchain, pour chaque question vous devez forcément recalculer la partie de l’état du système qui est nécessaire pour y répondre, et cela vous demande forcément de reparcourir toute la chaîne et depuis le début, parce que vous ne pouvez pas savoir à l’avance dans quels blocs il y aura des informations pertinentes. De plus, pour trouver les informations pertinentes, il faut également parcourir l’ensemble des transactions dans chaque bloc pour être sûr de ne pas en rater une où la personne concernée par la question est émettrice ou destinataire.

Sur notre tout petit exemple ça reste raisonnable, mais dans le cas d’un système grandeur nature, où des participant·es peuvent se rajouter au système n’importe quand, où il y a beaucoup plus de transactions dans chaque bloc, et surtout, beaucoup et de plus en plus de blocs, il est impossible de se satisfaire de cette méthode. Ce serait bien trop lent et inefficace.

Pour calculer le coût il faut regarder combien d’opérations doivent être effectuée pour répondre à une question. Ici, une “opération” peut être : suivre un lien dans la chaîne (passer au bloc suivant), lire une transaction (à l’intérieur d’un bloc), faire une addition (quand on voit une transaction entrante pour le compte qui nous intéresse), ou faire une soustraction (quand on voit une transaction sortante pour le compte qui nous intéresse).

Pour répondre à la question “Combien Alice possède-t-elle de ¢ ?” on initialise un compteur (qui représentera le solde de Alice) à zéro, on se place sur le premier bloc, puis on doit faire 14 opérations (je vous laisse les retrouver en vous aidant du dessin ci-dessus) pour pouvoir répondre : “Alice possède 2¢”.

Pour répondre à la question “Est-ce que Bob peut dépenser 3¢ sans être à découvert ?”, on initialise un compteur à zéro (le solde de Bob), on se place sur le premier bloc, puis on doit faire 16 opérations puis une soustraction pour pouvoir répondre : “non” (de même, je vous laisse faire l’exercice).

Le problème, c’est qu’on doit tout recalculer à chaque fois, et qu’on est obligé de faire des opérations inutiles parce qu’on ne peut pas savoir avant de lire une transaction si elle concerne le compte qui nous intéresse, par exemple. Et bien sûr c’est de plus en plus coûteux à chaque fois que la chaîne grandit par l’ajout d’un bloc.

La solution n’est pas compliquée : idéalement, on ne veut faire qu’une seule fois chaque opération, et se rappeler du résultat pour les prochaines fois. C’est à dire maintenir l’état qui nous intéresse effectivement : le solde de chaque compte. On peut faire ça dans un tableau. Ça ne prend qu’une seule opération d’accéder à une case d’un tableau, et ensuite il suffit de lire le contenu de la case (tout comme on devait lire les transactions)

Ici la réponse est récupérée en temps constant : deux opérations (accès à la bonne case du tableau puis lecture de la case), même quand on aura rajouté des nouveaux blocs. Il suffit de maintenir le tableau à jour à l’arrivée de chaque nouveau bloc, une fois pour toutes.

Bon, en pratique, on va plutôt utiliser un logiciel de base de données plutôt qu’un simple tableau, mais l’idée est globalement la même, le coût de l’accès et de la mise à jour de l’information restera très faible (s’il n’est pas constant, il sera logarithmique — comprendre très petit par rapport au nombre d’informations qu’on doit stocker pour représenter l’état du système, et en tout cas toujours indépendant de la taille de la chaîne qui peut donc grossir sans affecter le temps d’accès à l’état du système ou de sa mise à jour). Ce qu’il faut retenir de tout ça c’est que quand on fait le choix d’utiliser une blockchain, ce n’est pas à la place d’une base de donnée “classique”, mais bien en plus.

Bien sûr, si on a besoin des fonctionnalités de la blockchain, son coût peut être justifié. Mais le fait est que l’écrasante majorité des projets qui utilisent cette technologie le font sans que ce soit nécessaire, par pur effet de mode. Et dans ces cas là, il est important de comprendre que le coût d’une blockchain (que ce soit celui de son stockage qui ne peut qu’augmenter, ou celui de sa mise en œuvre et de son utilisation comme on l’a vu dans ce billet), aussi petit qu’il soit, est un coût entièrement supplémentaire, puisque pour des raisons pratiques, on doit de toutes façons maintenir également la base de données qui, dans bien des cas, pourrait être utilisée à la place.

Note(s)

  1. ^ AJOUT (07/02/2022) : C’est très (peut-être trop) simplifié. Après la lecture de ce billet, vous pouvez aller voir quelques corrections/suppléments apportés par Franck Gabriel sur Twitter en réaction, puis lire la suite de cette note : un autre exemple simple que j’aurais pu prendre pour illustrer le même propos en déformant moins un cas d’usage réel, ça aurait été celui de la certification de diplômes (sauf que du coup on est sur un cas d’usage injustifié — bien que réel — d’une blockchain…) : pour vérifier si Alice est titulaire d’un diplôme, si on ne maintient pas une base de données des diplômé·es à jour, il faudra d’abord trouver le bloc qui décerne son diplôme à Alice (ça, on peut imaginer qu’elle nous le fournit), mais ensuite il faudra vérifier dans l’ensemble des blocs suivants qu’il n’y en a aucun où son diplôme serait révoqué (suite à la découverte d’une fraude ou d’un plagiat par exemple).

vendredi 4 février 2022

L'immuabilité d'une blockchain

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…

Notes

  1. ^ À ce sujet, voir aussi mon billet mettant en garde sur le sens du terme “consensus” dans le cadre des blockchains.
  2. ^ C’est le principe des tiroirs à chaussette (ça s’appelle vraiment comme ça !).
  3. ^ Voir à ce sujet mon billet “la vérité sur la blockchain”.

mercredi 2 février 2022

Le problème résolu par la blockchain n'existe pas

Il y a quelques jours, lors d’une discussion, un ami (Antoine) m’a dit la chose suivante : « Un truc m’échappe, qu’est-ce qui motive les participants existants d’une blockchain à fournir l’historique de celle-ci aux nouveaux participants ? ». La réponse à cette question semble être : rien, dans le protocole en tout cas. Depuis, cette question tout à fait pertinente (mais pas tout à fait innocente), et surtout les implications qui découlent de la réponse, me trottent dans la tête.

Comme je l’expliquais dans mon précédent billet sur la nécessité de la preuve de travail (ou d’enjeu), les seules situations qui justifient le recours à une blockchain sont celles où se pose la question de résoudre le problème du consensus distribué, dans un cas à la fois décentralisé et conflictuel (personne ne fait confiance à qui que ce soit).

Mérion à dos rouge
Mérion à dos rouge[1]

Si ces deux conditions (décentralisation et conflictualité) ne sont pas réunies, on sait faire mieux et plus efficacement que de recourir à l’usage d’une blockchain. Comme exemple, on peut prendre celui de la certification de diplômes, puisque cette (mauvaise) justification d’utilisation de NFT revient sans cesse.

Quel que soit le cas d’usage qu’on prétend avoir pour une blockchain, on a besoin de conserver son historique pour au moins une raison : permettre l’arrivée de nouveaux participants sur le réseau. En effet, sans l’historique complet, un nouveau participant devrait faire entièrement confiance à ceux qui lui fournissent l’état du système lors de son arrivée. Dans le cas d’une cryptomonnaie par exemple, il est nécessaire d’avoir accès à tout l’historique pour vérifier la validité d’une transaction, car seul l’historique des transactions permet de calculer le solde d’un compte. On ne peut pas se satisfaire d’un état du système (qui donnerait le solde de chaque compte) fourni par un ou des participants existants sans complètement sortir du modèle de sécurité qui justifie le recours à une blockchain (puisque cela impliquerait de leur faire confiance).

Il est donc nécessaire au fonctionnement du système que l’historique de toute la blockchain soit conservé et partagé. Cela soulève ces deux questions.

Conservation. L’historique d’une blockchain est nécessairement de plus en plus lourd, son stockage est donc de plus en plus coûteux. De plus, comme un participant se fait confiance à lui même, une fois qu’il a eu une copie complète de l’historique, il peut l’utiliser pour calculer l’état du système (par exemple le solde de chaque compte dans le cas d’une cryptomonnaie), stocker cet état dans une base de donnée classique, puis utiliser les informations contenues dans les nouveaux blocs qui arrivent pour mettre à jour cette base de donnée. Ce sera beaucoup moins lourd que de conserver l’historique complet tout en lui apportant exactement les mêmes garanties et capacité de vérification de la validité des transactions. En fait, maintenir cette base de donnée est même indispensable dans tous les cas, y compris si on décide de conserver une copie de l’historique de la blockchain : recalculer l’état du système en reprenant tout depuis le début à chaque fois serait bien trop coûteux et inefficace (je reviendrai là dessus dans un prochain billet sur le coût des blockchains). Du coup, un participant n’a aucun intérêt à conserver l’historique, même pour lui même.

Partage. L’utilisation de la bande passante nécessaire au partage de l’historique a également un coût. De manière générale, rien n’incite les participants à payer le coût de ce partage, ni de celui des transactions et des blocs qui ne les concernent pas. Ce serait d’ailleurs assez difficile à mettre en œuvre[2]. Pourtant, ce partage est indispensable au fonctionnement d’une blockchain. On peut par exemple voir, en gras dans la documentation de bitcoin, une simple recommandation de ne pas limiter trop strictement la bande passante…

Une question se pose alors : si on est effectivement dans une situation décentralisée et en absence de confiance qui justifie de recourir à une blockchain dont le fonctionnement repose sur le fait que les participants sont en compétition les uns avec les autres, pourquoi les participants choisiraient-ils de coopérer ? Qu’est-ce qui les pousse à agir de manière altruiste alors qu’ils sont par définition en compétition ? Pourquoi payer le coût du stockage et de la bande passante au bénéfice de la communauté alors que l’intérêt individuel de chacun est de ne pas le faire ? Deux possibilités.

Soit on est effectivement dans une situation de conflictualité, face à une forme de dilemme du prisonnier qui va inévitablement nous mener à une tragédie des communs : dès que les coûts de stockage et partage seront jugés trop élevés par certains participants, ils arrêteront de les payer en comptant sur les autres pour le faire. Mécaniquement, cela augmentera la charge et donc le coût en bande passante pour les participants restants, qui toléraient encore le coût jusque là. Certains qui étaient à la limite de leur capacité arrêteront donc à leur tour, et ainsi de suite jusqu’à disparition de la ressource, ou que la poignée d’acteurs restants à la fin (forcément les plus riches) soient en total contrôle de celle-ci. On assiste alors à un contraction du réseau, à sa recentralisation. Dans le cas d’une situation de conflictualité, il n’est donc absolument pas possible d’utiliser la prétendue pérennité de la blockchain comme argument en faveur de cette technologie.

Soit il faut admettre que, manifestement, tout système social nécessite une forme de confiance, ne serait-ce qu’un ensemble de règles que les participants se mettent d’accord de respecter, même quand rien ne les y oblige et que ça leur coûte de le faire. Cet altruisme au service du collectif, contre l’individualisme (supposé) de chacun[3], bénéficie au final à tout le monde puisqu’il permet de maintenir le bien commun. Sauf que dans le cas d’une situation de confiance, on remet sérieusement en cause les hypothèses qui justifient le recours à l’utilisation d’une blockchain.

C’est plutôt cette deuxième possibilité à laquelle je crois. La tragédie des communs, vu comme quelque chose d’inéluctable (d’où l’utilisation du mot “tragédie”), est une conclusion à laquelle arrivent des économistes libéraux qui modélisent tous les acteurs de leur économie comme purement individualistes. Un tel monde n’est pas possible, ni souhaitable, d’ailleurs. Dans le titre je dis de façon un peu provocante que le problème résolu par la blockchain n’existe pas (bien sûr qu’il existe, il suffit de le poser pour ça). C’est plutôt que dans la vraie vie, je ne crois pas que ce problème ait un réel intérêt, qu’il existe de vraies situations sociales concrètes qui nécessitent de résoudre ce problème.

Décidément, on vit dans une société.

Notes

  1. ^ Le Mérion à dos rouge fait partie de ces espèces d’oiseaux qui ont un comportement coopératif pour la reproduction, comme la mésange à longue queue, mais avec une plus jolie robe, assortie à ce blog ;).
  2. ^ Techniquement, cela demanderait de déterminer le ratio téléversement / téléchargement des participants, toujours sans pouvoir leur faire confiance et de façon décentralisée. À ma connaissance, on ne sait pas tellement faire ça.
  3. ^ Je n’ai pas lu plus que le résumé, mais ça semble être ce qui est défendu par Bourdieu dans son ouvrage L’intérêt au désintéressement.

- page 1 de 3