Mot-clé : blockchain

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, je publierai prochainement un billet expliquant comment mettre en œuvre un système de certificats d’authenticité pour des œuvres d’art, 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.

mardi 1 février 2022

Cryptomonnaie / blockchain : un serpent qui se mord la queue

Dans le billet “La vérité sur la blockchain”, j’expliquais pourquoi la seule application possible (ou du moins, valable) d’une blockchain est une cryptomonnaie. Grossièrement, c’est le seul cas d’utilisation où l’écriture sur la chaîne est performative sans dépendre d’une autorité / d’un tiers de confiance extérieur. C’est donc le seul cas où l’on est effectivement face au problème du consensus distribué[1].

Dans un autre billet sur la nécessité de la preuve de travail (ou d’enjeu), j’expliquais qu’effectivement dans les cas où il est nécessaire de résoudre le problème du consensus distribué, on ne sait pas se passer d’une blockchain (c’est d’ailleurs exactement pour ça que cette technologie a été inventée).

Une chose que j’ai évoquée seulement indirectement dans ce dernier billet, c’est la nécessité de récompenser le travail (ou l’enjeu) pour inciter à la participation. En effet, le coût de la preuve de travail (ou l’inconvénient de l’enjeu) serait prohibitif si il n’y avait aucune contrepartie promise en échange de cette participation au fonctionnement du réseau, avec une espérance de gain supérieure au coût de la preuve.

Bien sûr, cette récompense doit forcément être “interne” à la blockchain[2], sinon on sort de la situation décentralisée et sans confiance qui nécessite l’usage d’une blockchain. Cela signifie qu’une blockchain a besoin de sa cryptomonnaie pour fonctionner.

Récapitulons : une cryptomonnaie nécessite une blockchain pour exister, et à la manière d’un serpent qui se mort la queue, cette blockchain nécessite cette cryptomonnaie pour fonctionner. Cryptomonnaies comme blockchains sont des solutions qui sont leur propre problème. À cela s’ajoute que la seule application valide d’une blockchain est justement une cryptomonnaie, et qu’à leur tour les cryptomonnaies ne semblent avoir comme intérêt pratique que la création d’actifs purement spéculatifs…

Bref, pour finir rappelons qu’un système de monnaie numérique, même décentralisé, peut tout à fait exister sans blockchain[3] !

Notes

  1. ^ C’est à dire devoir mettre tous les participants, sans qu’ils ne se fassent confiance, d’accord sur l’un d’eux au hasard sans disposer d’aucun agent qui puisse jouer le rôle de “chef d’orchestre”. À ce sujet voir également mon billet sur la notion de “consensus” dont il est ici question.
  2. ^ Il y a probablement beaucoup à dire sur ce que cela implique en terme (d’absence) de possibilité de contrôle de la monnaie (création/destruction), et d’inflation inévitable des frais des transactions si on veut éviter une création infinie d’unité de cryptomonnaie au fil du temps. Mais cela sort trop de mon champs de compétences pour que je puisse disserter là dessus sans craindre de dire quelques bêtises…
  3. ^ Voir par exemple le projet Taler.

lundi 24 janvier 2022

NFT: even more stupid

This is an english translation of my post entitled “NFT : encore plus stupide”.

Le singe fume sa cigarette
‘21 NFT or ‘12 french rap?

The goal of an NFT is to establish a property deed. The idea is to certify an association between a digital identity (the owner) and an object (the property, a digital asset most of the time), and to then use a blockchain to store and distribute this certificate.

It’s off to a bad start: people claiming to be able to assert ownership using a blockchain are either lying or have no idea what they are talking about. This was already pointed out in a previous post (that should probably be read before this one) where I explained that a blockchain cannot serve as a source of truth for anything that is not intrinsically “inside” the said blockchain. This technology thus has no advantage over paper[1] for this purpose. It has however many inconveniences: power consumption, the impossibility of having actual peer to peer transactions, etc.

NFTs are supposed to allow decentralization and disintermediation (getting rid of the need for trusted third-parties). This in itself is enough to discredit NFTs, since an NFT is a property deed on a blockchain, and that precisely, blockchains cannot actually offer any decentralization nor any elimination of the need for trust, as demonstrated in the post linked in the previous paragraph. Still, as the title of this post suggests: NFTs are even more stupid.

NFT stands for “non-fungible token”: it is a non-interchangeable piece of data, as opposed to units of cryptocurrencies for example. When someone has 1 bitcoin, they have 1 bitcoin, whichever it is: they’re all equivalent in the strict sense of having the same value. Each NFT is unique and identifiable. A 10€ bill has the same value as any other 10€ bill (or as any other set of bills and coins that sums up to 10€): euros are fungible. Now, if we decide that 10€ bills are no longer in circulation but that we keep them and open a market of 10€ bills where each one is unique and identified by its serial number, then I can hope to sell my 198357 numbered bill at a higher price than my 840414 numbered bill for example, by saying that its serial number is prime and that there is a limited quantity of such bills (which is false then idiotic, but I can still say it…).

This idea illustrate what is meant by “non-fungible”. The fact is that numbering objects that are available in limited quantity can increase their value[2]: not only they are rare, but now they are unique since each has a different number. However in the case of NFTs, it is even more stupid: absolutely nothing prevents to make multiple NFTs for the same object (so there can be multiple certificates of ownership for a single artwork, for example), and anyone can make an NFT for anything (so there is no guarantee whatsoever that a person selling an NFT owns the associated object). Everything is as if a same 10€ bill (in the sense of the physical object, necessarily unique) could have an inifite number of serial numbers, and that it is to these serial numbers that we attribute value, and potentially different values to each one. I know, this makes absolutely no sense.

It is actually even more stupid: the object associated to an NFT is generally a digital object, whose rarity does not exist[3] since they are transmissible by copy (as opposed to my 10€ bill that I would no longer have in my possession if I give it to someone else). This means that the object associated to the NFT (and which obviously contributes to its value on the market, even though we have already seen in the previous paragraph that this does not make sense) can itself be replicated infinitely. This may seem obvious, and yet there are many cases of people who bought an NFT to use its associated object (an image file) as a profile picture on social networks and called thieves people who would retrieve the image by a simple right click and then “save image as…”, for example.

All these criticisms are valid even if we accept the idea that an NFT would indeed be a property deed, but in reality it is even more stupid. In principle, at least from the point of view of the proponents of this technology, having an NFT associated to the object (digital or not) X allows to say “I am the official owner of X, I have a certificate that proves it”. The thing is, the notion of ownership is anything but natural, it does not exist as anything else than a social construct. Ownership can be the result of a (maybe litteral) power struggle[4] or of a common agreement, but in both cases it is a form of violence. In the first case, the power struggle has to be constantly renewed. In the second case, it is necessary that a third-party enforces the agreement, with an ability to punish in case of disrespect, or an absolute power of constraint. In both cases, the notion of ownership exists and has a meaning only for the concerned community[5]. In short, a property deed has no intrinsic value if there is no third-party to enforce its application and thus giving it its value. This is true when the deed is written on a piece of paper, and it stays true when it is an NFT: by recording on a blockchain that a given person is the owner of a given object, one does not perform anything more than if they would have written this same statement on paper: it has absolutely no value if there is no third-party with the ability to enforce what is written, to make it true[6]. Once again, the idea of decentralization or disintermediation is gone…

Now hang on, there is more. The association of an object to an NFT is usually not recorded directly on the blockchain for technical reasons (even digital objects are too big for that). Note that even in the rare cases where it would be the case, everything said until now still holds perfectly. What is stored on the blockchain is most often a link to a web page[7] that itself points to the associated object. Here again, we have lost all idea of decentralization (which is supposed to be why this technology exists in the first place — even if, as we have seen, this belief is based on a huge misunderstanding of what a blockchain can do), since a centralized platform is necessary to link an NFT to its associated object. This is bad enough, but things are even more stupid: because of this necessary and centralized third-party, an NFT can be subject to link rot in the best case (for example if the centralized platform no longer exists or moves to another URL). But it could be worse: the website could be hacked and/or later be replaced by one that does fancy associations, displays ads, attempts to infect its visitors with viruses, or simply trolls.

It is terefore quite clear that NFTs are purely and entirely hot air and have no possible serious applications (except of course to enrich the higher stages of a Ponzi scheme while accelerating global warming). But let’s take a closer look at the non purely speculative use case that is the most often put forward by the proponents of this technology: its use in a metaverse or in video games (I will talk about “virtual worlds” in general) for “in-game” markets.

What makes this idea seem to work is that in the case of a virtual world in which we have control over everything, we can indeed decide that a given blockchain where NFTs are recorded is a source of truth. Technically, it works. The virtual world can completely prevent participants who are not identified as owners of an NFT to benefit from the associated object. The company which builds the game, through the implementation of the virtual world (that is, the rules that they write in its source code), plays the role of the centralized third-party that has absolute power to make whatever they want true, and thus among other things what is written on a given blockchain. If the company changes its mind, the truth in the virtual world changes with it… And again, it is even more stupid. Contrary to what has regularly been said on the subject, it would absolutely not allow the transfer of items from one virtual world to another if this is not intended in the source code of both virtual worlds: if a game does not have code to display a yellow hat on your avatar, even if you own an NFT associated with the idea of a yellow hat in another game, you wont be able to add a yellow hat to your avatar in this game even if the game takes into account the blockchain where that NFT is recorded. NFTs cannot be used to build a “second hand” market of items between players of a same virtual world either if the virtual world does not implement the possibility of ownership transfer (which it could perfectly decide to allow but only with a tax, for example). To sum up, anything other than a speculative market of (re)selling fake property deeds to gullible buyers depends entirely on the will of the centralized entity that controls the virtual world. Therefore, we are dealing with centralized systems, where there is no advantage to use NFTs, or a blockchain. Technically, there a many disadvantages: it will cost more resources and be less efficient than a simple database to achieve the same results.

Notes

  1. ^ I talk about paper here to emphasize my point, but the criticism remains the same in the digital world, with technologies that we could use instead of a blockchain, whether they are distributed (Git repository, DHT, etc.) or centralized (like a good old fashion database).
  2. ^ We are talking about the exchange value on a scarcity-based market here, assuming a strong demand. The use value of these objects obviously has no reason to change because they are numbered…
  3. ^ It is possible to create artificial scarcity on digital objects, but NFTs are unable to do that. Only DRMs (“digital rights maganement”) can do that, but they are historically a huge failure at the technical level, and absolutely can’t work without a trusted third-party anyway, which annihilates again the potential interest of NFTs.
  4. ^ Wars for land in human societies, fight (or just pee that smells stronger ^^) in animal communities, for example.
  5. ^ In animals that mark their territory, for example, most other species (at least those with no predatory or cooperative relationship) probably don’t care about territory markers, if they are even capable of interpreting them. The same is true for our fences and borders (otherwise we could issue laws to forbid mosquitoes to enter our lands).
  6. ^ The idea developed in this paragraph is explored in more details in the aforementioned post: The Truth on the Blockchain.
  7. ^ Only a link, not even a cryptographic hash of the object which would allow to ensure its integrity… Except in some rare cases where the link points to an IPFS identifier, but that does not solve any other problem.

- page 1 de 3