samedi 12 mars 2022

Taux d'accès Parcoursup

Par Pablo le samedi 12 mars 2022, 22h04

Ce billet est directement tiré d’un thread publié sur mon compte twitter.

Cette année encore la Licence informatique de l’Université Paris 8 (dont je suis responsable) avec ses 13% de taux d’accès, semble être la plus attractive des 128 licences en informatique listées sur la plateforme Parcoursup, incluant pourtant des formations sélectives (doubles licences, etc).

La première chose à dire là dessus : la distinction que Parcoursup fait entre les formations dites “sélectives” et celles dites “non-sélectives” n’a absolument aucun intérêt en pratique. Ça dit seulement si la formation a le droit de répondre “non” à des candidatures ou si elle doit nécessairement classer tou·tes les candidat·es, mais en pratique, nombre de formations dites sélectives acceptent tout le monde voire ne remplissent pas leur capacité d’accueil, et beaucoup de formations dites non-sélectives atteignent leur capacité d’accueil avant d’avoir atteint la fin du classement qu’elles ont fait des candidatures qu’elles ont reçues, étant donc de fait, sélectives.

Le vrai problème, c’est que les vœux n’étant pas classés sur Parcoursup, on ne peut pas réellement mesurer de taux de satisfaction des candidat·es, ce qui serait la seule mesure réellement intéressante.

En attendant, on peut se demander : que mesure réellement ce taux d’accès mis en avant par la plateforme ?

Déjà, comment est calculé ce taux d’accès ? C’est pas clair du tout… On peut lire par exemple chez L’Étudiant qu’« il s’agit du pourcentage de candidats qui ont reçu une réponse positive lors de la phase principale de l’année précédente ». Sauf que… ça ne marche pas vraiment.

MISE À JOUR (13/03/2022) : en fait si, je n’avais pas les bons chiffres pour la phase principale.

Texte retiré suite à la mise à jour ci-dessus.

La formule est soit très complexe, soit change en fonction de certains seuils. Pour la Licence informatique de Paris 8, qui a reçu l’an dernier 1990 candidatures confirmées pour une capacité d’accueil de 70 places, et a appelé 234 candidat·es depuis le haut de notre classement, si on compte comme l’indique L’Étudiant, on obtient un taux de 11,7% qu’il est difficile d’arrondir au 13% annoncés.

Peut-être que son pris en compte d’une façon où d’une autre le fait que sur les 1990 candidat·es il y en a dont on peut-être certain·es qu’iels ne voulaient pas prioritairement venir chez nous : les appelé·es qui ont refusé·es la proposition, et celleux qu’on a pas appelé bien que classé·es plus haut que notre dernier·es appelé·es car iels ont accepté avant leur tour chez nous une autre formation qui avaient leur préférence. Mais dans ce cas, c’est étrange de procéder ainsi tout en faisant comme si par contre tou·tes les candidat·es qui n’ont pas été appelé·es une fois qu’on a atteint notre capacité d’accueil auraient voulu venir !

Bref, le principe est tout de même d’avoir une idée grossière de combien de candidat·es vont recevoir une proposition d’acceptation dans la formation. Mais est-ce pour autant un critère d’attractivité ou une information pertinente sur la difficulté d’accès à la formation ? Pas vraiment… En fait, ça le serait si les formations comparées ainsi faisaient leur classement de la même manière exactement. Mais c’est très loin d’être le cas, et c’est même probablement ce qui explique principalement les grandes différences de taux d’accès entre formations par ailleurs similaires.

En effet, comment expliquer que des formations dans la même filière, avec un nombre très semblable voire égal de places, et parfois beaucoup plus de candidatures que la notre, aient des taux d’accès bien plus haut ? Tout simplement à la manière dont sont fait les classements !

Et là, désolé, je vais sembler être un peu critique de certain·es collègues dans d’autres établissements, mais sachez bien qu’en aucun cas on ne peut leur reprocher le fonctionnement de Parcoursup qui pousse complètement à faire de la sélection. C’est bien la plateforme qui est en tort, et ça demande une organisation et un travail conséquent de contourner ce qu’elle pousse à faire avec son module d’« aide à la décision ».

Ce qui fait notre taux d’accès si bas, c’est qu’on refuse de recourir à un algorithme de classement basé sur les notes : sinon quelque soit la formule qu’on choisirait d’appliquer, c’est toujours les mêmes — celleux avec les bonnes notes — qu’on retrouverait en haut de classement.

Et comme beaucoup de formations se contentent de ça, non seulement elles classent en premier les mêmes candidat·es (qui ne vont bien sûr qu’à un seul endroit et donc refusent tous les autres) qui en plus le plus souvent ne mettent des licences qu’en plan B car iels veulent en fait accéder à une classe prépa plus qu’à la fac, prépa qui classe généralement aussi de cette façon. Et donc ces candidat·es refusent en fait toutes les licences qui leurs sont proposées…

L’effet le plus pervers de tout ça c’est que ça ralentit beaucoup la procédure pour tout le monde C’est complètement stupide et ça pourrait être évité très facilement si Parcoursup autorisait tout simplement les candidat·es à classer leurs vœux (à dire avec de l’écho).

Mais alors, qu’est-ce qu’on fait de différent chez nous à Paris 8 en Licence informatique ? Et ben on lit vraiment chaque dossier : le projet de formation motivé, le CV, etc. Puis on essaye du mieux qu’on peut de pondre un classement correspondant à la volonté réelle des candidat·es.

En gros, on cherche les candidat·es qui semblent avoir le plus envie de venir chez nous. Parce que c’est elleux qui seront le plus content·es d’être là, vont du coup le mieux s’épanouir chez nous, et donc vont le mieux réussir leurs études :).

Notre licence est très particulière, même complètement unique par bien des aspects (qui sont détaillés sur le site web de la formation), donc on voit assez vite les candidat·es qui postulent chez nous et pas “génériquement” en licence informatique (et encore… chaque fois on a des candidatures avec un projet de formation motivé pour une tout autre filière, là au moins c’est clair qu’on est pas le premier choix puisqu’on a eu un copier-coller depuis la formation pour laquelle l’effort a été fait ^^).

Sauf qu’en vrai, elle est pas si connue notre licence, et ces cas là ne suffiraient pas à remplir notre capacité d’accueil. Donc l’autre critère important qu’on a, c’est que la candidature montre que la personne sait où elle met les pieds, en particulier ce qu’est la programmation, et qu’elle aime ça. Parce qu’autant dire que dans le cas contraire, ce serait rude. Quelqu’un·e qui n’aime pas la programmation aurait bien du mal à s’épanouir chez nous (cf le programme de la licence) ! Mais c’est pas grave, y a plein d’autres formations qui lui correspondront mieux.

Sur la base de ces critères (qui sont publics et accessibles sur le site de la formation et sur sa fiche sur Parcoursup), on essaye de bidouiller manuellement un classement. C’est à dire qu’on essaye du mieux qu’on peut de détourner Parcoursup de son objectif de sélection pour en faire un outil d’orientation. C’est compliqué, ça demande énormément de travail, et on est jamais sûr·es d’avoir juste… Mais en fait, notre taux d’accès aussi bas, qui montre que celleux qu’on classe en haut ont bien tendance à venir chez nous, c’est finalement la preuve qu’on s’en sort pas si mal ! ☺

La conclusion, c’est qu’il ne faut pas se censurer sur Parcoursup face à des formations qui affichent un taux d’accès bas ou très bas, et ce même quand on n’a pas les meilleures notes : ce sont peut-être justement les formations pour lesquelles les notes comptent moins que la motivation.

vendredi 25 février 2022

Spammeurs : mangez des pneus

Par Pablo le vendredi 25 février 2022, 17h23

Juste un court billet pour dire que je coupe complètement les commentaires et les rétroliens (trackback) sur ce blog, les spams sont ingérables et beaucoup trop nombreux.

J’espère de tout cœur que l’ensemble des personnes qui contribuent à faire du web et plus largement d’internet un espace aussi merdique, que ce soit en développant des outils de spams automatisés, en payant pour les utiliser, ou de quelques autres façons que ce soit, vont crever seules sans être regrettées. J’ai aucun respect ni aucune compassion pour vous quelque soit la raison de votre participation au business du spam. Mangez des pneus et étouffez vous avec.

lundi 7 février 2022

Le coût d'une blockchain

Par Pablo le lundi 7 février 2022, 13h12

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

Par Pablo le vendredi 4 février 2022, 13h12

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

Par Pablo le mercredi 2 février 2022, 13h12

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.

- page 1 de 4