Limitations et problématiques structurelles de la blockchain

Ce post est le développement d’une conférence donné à l’institut CDG avec Nadia Filali et animé par Talal Chakir.

Derrière l’engouement médiatique et entrepreneurial de la blockchain, se cachent des limitations et problématiques structurelles dans les implémentations existantes aujourd’hui. Le concept de blockchain est porteur d’espoir et guidé par une vision décentralisée et libertaire des échanges économiques. Mais cette vision a du mal à se concrétiser car la technologie blockchain sous-jacente n’est pas parfaite et continue d’évoluer techniquement et idéologiquement. Nous verrons les principaux freins à la concrétisation de cette vision et comment les différents acteur du monde de la blockchain cherchent à y remédier.

Définition illustrée de la blockchain

Nous avons défini la blockchain dans des articles précédents mais rappelons tout de même les fondamentaux de cette technologie. Pour toutes nos interactions sociales quotidiennes, comme payer le boulanger, légaliser un document ou envoyer un email, nous sommes obligés de faire confiance à un fournisseur de service identifié et à priori de confiance.

1. Lorsque vous payez votre croissant chez le boulanger, ce dernier vous donnera le fruit de son travail contre un bout de papier qui n’a de valeur que parce que la banque centrale contrôle son émission et régule son utilisation. Cet organisme étatique pourrait décider de créer de la monnaie ex-nihilo (les exemples vénézuélien et zimbabwéens avec l’inflation) ce qui diminuerait la valeur du bout de papier entre vos mains. Il pourrait aussi décider que le billet de banque n’a plus aucune valeur (l’exemple indien qui a “annulé” la valeur des billets de 500 et 1000 roupies). Pourtant, vous avez confié le produit de votre dur labeur contre quelque chose que vous pensiez qui avait une valeur correspondante, le juste prix.

2. Lorsque vous légalisez un document, vous faites confiance au service de la commune pour ressortir le document devant des tribunaux et prouver son authenticité. Mais si la commune décide de brûler ses archives, votre légalisation n’a plus aucun existence au yeux de la société alors que la transaction est réelle et valide.

3. Lorsque vous envoyez un email, vous confiez ce bout d’information à un fournisseur d’email (disons gmail par exemple). Celui-ci délivre votre email d’une part vu que c’est le service de base, mais vous garantit à vous et à votre destinataire que le mail sera bien archivé, consultable à tout moment. En cas de litige gmail pourra même prouver l’existence du mail ainsi que la véracité de son contenu. Mais ici, vous dépendez d’une société américaine indépendante qui n’ira pas au-delà de ses intérêts économiques et peut donc à tout moment vous faire faux-bond.

L’idée de la blockchain est de remplacer l’intermédiaire central dans la transaction entre deux ou plus de personnes par une forme distribuée d’intermédiaire qui serait choisi aléatoirement, correctement rémunéré et qui n’aurait pas la possibilité technique d’altérer la transaction une fois celle-ci réalisée. Le nouvel intermédiaire est constitué d’un grand nombre de participants qui forme le réseau blockchain. On appelle blockchain le protocole qui permet de faire travailler ces participants de concerts de manière à aboutir aux propriétés que nous avons cités (et bien d’autres).

Ainsi, une blockchain est censée vous garantir la “bonne tenue” d’une transaction que vous réalisez avec un ou plusieurs partenaires. C’est la principale raison qui a fait que cette technologie a pris beaucoup d’ampleur et a suscité énormément d’attentes. La monnaie étant une des formes des plus simples de transactions entre deux personnes, elle a été le premier use case de la blockchain originelle, à savoir celle du bitcoin. Mais comme nous l’avons illustré via les exemples plus hauts, d’autres formes de transaction sont implémentables dans une blockchain, notamment dans la blockchain Ethereum ou les nombreuses blockchains privées spécifiques à un métier.

Problématiques et limitations

Rentrons dans le vif du sujet : qu’est ce qui fait aujourd’hui qu’un projet blockchain ne marchera pas, et quelles sont les solutions existantes ou envisagées pour chacun des problèmes. Essayons d’avoir un regard fonctionnel sur chacun des problèmes et des solutions.

Le problème du coût de la transaction :

Vous souhaitez par exemple utiliser une blockchain comme moyen de dématérialiser le décisions d’une association :

• vote
• décision du bureau
• proposition des membres
• quitus de paiement de cotisation fiscale
• etc …

L’idée est donc d’avoir une forme robuste et très transparente de gestion de l’association qui ne puisse pas être manipulée par des tiers. Aujourd’hui si vous voulez l’implémenter dans une blockchain publique, vous serez confronté aux frais de transaction suivants (échelle logarithmique) :

C’est-à-dire que toute décision de l’association doit être assortie d’une paiement (en devise) aux miners, ie aux validateurs de la transaction. Plus spécifiquement, ce paiement n’ira qu’au validateur unique de la transaction, mais comme il est choisi au hasard, cela revient de facto à imaginer un paiement distribué à tout le réseau.

Par comparaison, le réseau VISA chargera quelque chose comme 30cts de dollars additionné d’un pourcentage sur le montant de la transaction généralement entre 1% et 5%.

Concernant le bitcoin, on remarque que non seulement nous sommes confrontés à des prix plutôt grands mais aussi à une volatilité importante. Pour rappel, nous ne sommes pas en train de faire de la spéculation sur le bitcoin, mais uniquement d’utiliser le réseau pour persister des transactions.

Pour mon association, puis-je permettre que les frais de gestion soient multipliés par 200 en l’espace de quelques mois ? Ce qui aurait pour effet de revenir au bon vieux papier et stylo. La volatilité des frais de transactions de l’ether sont moindres mais dans relativement toujours importants et peuvent également présenter un risque pour mon association.

Alors quelles solutions ?

• Acheter un stock prédéfini de cryptocurrency pour se couvrir contre la volatilité des frais de transaction, ou plus intelligemment déléguer cela à des entreprises spécialisées dans le forex.
• Utiliser une blockchain privée dont vous et vos partenaires contrôlez les noeuds validateurs, ce qui de facto transforme les frais de transaction en des frais d’électricité, de maintenance et en amortissement du matériel. Mais en contrôlant les noeud, vous centralisez la confiance chez vous ce qui diminue l’intérêt d’une blockchain.
• Grouper les transactions associatives dans une seule transaction afin d’économiser sur les frais.
• Ne stocker que la signature des transactions associatives, et garder le contenu de la transaction dans un système externe. De ce fait on allège la taille de la transaction ce qui a un effet important sur les frais. Ce mode de fonctionnement existe dans des uses cases artistiques (garantir une authenticité par la primauté d’existence sur la blockchain). L’avantage est que l’existence de la transaction devient non répudiable et inaltérable car la signature est gravée dans le marbre.

Le problème de la vitesse du réseau :

Les différentes implémentations de la blockchain se caractérisent chacune par une capacité à absorber du flux de transaction entrant. On donne souvent comme chiffre le TPS, nombre de transactions par seconde maximal géré par un réseau. Ce nombre est important dans la mesure où si je veux brancher un process technique sur la blockchain, je dois savoir ce que cette dernière est capable de gérer.

Nous avons typiquement pour ambition au CIH d’utiliser la blockchain pour faciliter les échanges de données entre partenaires. Le principal objectif de ce type de use case est de fluidifier le partage multipartite de donnée, faciliter la mise en place de workflow complexes et proposer une interface technique unique pour tous les acteurs qui veulent collaborer. Prenons ce graphe par exemple :

Il donne le nombre de transactions par jour de la blockchain du Bitcoin (bleu) et de la blockchain Ethereum (en rouge). Force est de constater qu’en prenant une moyenne lisse sur toute la journée, on arrive à environ à

• 3 à 5 transactions par seconde pour la blockchain du Bitcoin
• 7 à 11 transactions par seconde pour la blockchain Ethereum

Pour donner une idée en comparaison :

• 200 transactions par seconde pour Paypal
• 1700 transactions par seconde pour Visa (avec une capacité à gérer des pics plus importants, ils annoncent jusqu’à 56000 tps) Mettre en place un système en forme de goulot d’étranglement au centre de mes échanges, c’est un risque opérationnel important qui élimine de facto ce genre de technologies.

Pourquoi de telles limitations existent sur les blockchains ? Sans rentrer dans les détails techniques, il faut imaginer que des milliers de noeuds doivent quasi simultanément se “mettre d’accord” sur des transactions qui peuvent être en conflit les unes par rapport aux autres, typiquement un acteur qui veut dépenser plus de crypto monnaie qu’il n’en a.

Cet effort de coordination est réputé difficile et la blockchain est une des premières technologies à avoir proposé de le résoudre de manière sécurisée et efficace (modulo les questions énergétiques qui sont un problème écologique mais non économique). A l’inverse, il est plus simple pour des systèmes fortement centralisés de gérer un nombre important de transactions par seconde. C’est donc par design une forme de limitation.

Alors quelles solutions ?

Difficile de répondre à cette question, car la scalabilité des implémentations de la blockchain est un problème central que cherchent à résoudre beaucoup de gens aujourd’hui. De nombreuses versions de la blockchain Bitcoin et Ethereum existent avec des paramétrages différents. On augmente le nombre de transaction par seconde mais on perd en stabilité ou en sécurité.

Des évolutions technologiques fortes comme le Lightning Network ou Ethereum Casper sont censées donner aux deux blockchains historiques la scalabilité promise mais ces changements viennent avec beaucoup d’incertitudes au niveau théorique et mettent du temps à être implémentés en production.

Pour mon use case, je n’ai pas d’autre choix que d’utiliser une blockchain privée, avec un nombre de membres restreint. Là encore, le fait d’avoir peu de membre la rend moins robuste, moins de confiance. Par conséquent, c’est un trade-off à peser.

Le problème du temps de confirmation :

Supposons que je veuille faire porter un système de wallet par la blockchain. Dans un tel scénario, j’imagine que mon portefeuille virtuel (qui est un compte de paiement dans le système actuel) soit un portefeuille d’une cryptocurrency nationale (disons le e-dirham) dont les fonds sont garantis par la banque centrale (1dhs = 1edhs). Ce serait dans le jargon un stablecoin à la manière de la blockchain Tether.

Dans un tel système, le protocole blockchain me permet de garantir que les échanges entre particuliers sont sécurisés, irrévocables et non frauduleux (usurpation d’identité, création de monnaie etc…). C’est en gros le bitcoin remis à la sauce nationale avec un degré d’ouverture important vers le monde des startup technologiques. Maintenant, il y a juste un tout petit problème que nous rencontrons dans toutes les implémentations des blockchains sans exception : Les temps de confirmation.

En effet, pour qu’une transaction soit validée (j’ai donné 100.000 edhs à Monsieur X (blockchain) en échange de sa voiture (contrat et carte grise)), il faut être sûr qu’elle est bien dans la blockchain. Dans ce cas, le vendeur veut avoir la garanti que l’argent virtuel est bien sur sa wallet edhs. Mais pour avoir cette garantie, il n’y a pas d’interlocuteur unique (typiquement une banque ou un établissement de paiement) mais un réseau de participants qui sont plus ou moins d’accords sur l’état des transactions enregistrées à l’instant T et qui stabilisent cet état petit à petit grâce au protocole. Pour le bitcoin,

• pour être sûr à 60% que la transaction est passée, il faut attendre en moyenne 10 minutes et vérifier la blockchain
• pour être sûr à 95%, il faut attendre une bonne demi-heure
• pour être sûr à 99%, il faut attendre une heure

Le risque paraît faible mais il est arrivé que sur des petites blockchains, des commerçants n’attendent pas et que la transaction qui est censé leur donner leur dû apparaisse au début dans les blocs puis disparaît au bout de 2 ou 3 heures (500k$ volé sur la blockchain Ethereum Classic en janvier dernier. Ceci a eu pour effet que les plateforme d’échange de cryptocurrency ont augmenté leur temps d’attente pour se prémunir de ce risque)

Alors quelles solutions ?

Pour ma edhs-wallet, il est inconcevable de faire attendre 1h à un client et un épicier afin de permettre la vente d’un bouteille d’eau à 5edhs. Il faut donc ou bien accepter le risque ou bien chercher des blockchains dont les temps de confirmations sont plus courts :

• Utiliser Ethereum ramène le temps de confirmation à 5 minutes environ en moyenne
• Utiliser une blockchain privée qui avec des noeuds en petit nombre peut avoir des temps de confirmations très faibles (on tend vers les systèmes de paiement VISA ou Mastercard)

Comme la scalabilité, le problème du temps de confirmation est intimement lié à la stabilité et à la scalabilité de la blockchain. Le sujet est donc difficile solvable en soi sur des blockchains publiques.

Le problème de l’erreur humaine et l’immutabilité :

Parfois il arrive qu’un agent humain se trompe lors d’une saisie de montant ou de libellé, par exemple lors de l’émission de virement d’un client d’une banque vers une autre banque. S’il n’y a pas de contrôle manuel postérieur, et vraisemblablement il ne peut pas y en avoir en raison de la volumétrie de ce type d’opération, alors ce virement peut être amené à aller dans des tuyaux automatiques et déboucher sur une hypothétique blockchain qui gère l’échange de valeur entre des partenaires bancaires.

• Que faire lorsque l’agent a saisi 100 millions de dirhams au lieu de 1 million de dirhams ?
• Comment revenir en arrière proprement alors la transaction a été dûment enregistrée par l’ensemble des partenaires et doit normalement être honorée ?

Si on autorise l’annulation d’un tel virement aujourd’hui, qu’est ce qui nous garantit demain que le cas ne se produira pas arbitrairement pour des raisons différentes de l’erreur de saisie par un partenaire de mauvaise foi ?

De telles problématiques se posent aujourd’hui dans les blockchains publiques lorsque des petits malins décident de mettre dans des transactions des morceaux d’oeuvres protégées, des informations confidentielles ou pires de images pédopornographiques. Dans la minute qui suit, ce sont des milliers de serveurs partout dans le monde qui deviennent de facto complice d’un geste répréhensible.

Alors quelles solutions :

Les différentes blockchains ont répondu à cette problème de manières différentes :

Certains choisissent après consensus de forcer l’effacement des transactions concernées (souvent liées à un vol ou à un piratage), ce qui dénature l’immutabilité et donc une des raisons primaires d’exister de la blockchain. Une nouvelle blockchain avec le même nom est créée en quelque sorte et les participants ont le choix de continuer l’aventure avec la nouvelle version ou de garder l’ancienne version (Ethereum Classic vs Ethereum en 2016).

D’autres décident d’accepter toutes les transactions, qu’elles soient d’origine frauduleuse ou pénalement répréhensibles. Considérant ainsi que tant qu’une transaction est techniquement et cryptographiquement valide, et tant que les frais de transaction ont été payés, elle a le droit de vie dans la blockchain. Pour ma part, en tant que banque qui imagine par exemple un jour un système d’échange de valeur sur la blockchain, je ne peux me résigner à l’idée de ne pas avoir la possibilité de revenir en arrière. La justice et le régulateur ne me laisseraient pas faire de toute manière.

Je ne peux utiliser qu’une blockchain qui permette après décision de justice de revenir par exemple en arrière. Mais la justice de quel pays ? Et si les autres s’amusaient à enlever mes transactions ? Je dois donc de facto m’orienter vers une blockchain nationale avec une forme de régulateur suprême qui a des droits de modification et de suppression sur les données de la blockchain.

Le problème de la confidentialité des données :

En discutant avec un agent d’autorité marocain, le sujet du partage d’information de santé entre hôpitaux, médecins et clinique est venu sur la table. L’idée d’un tel use case revient souvent dans les journaux car elle apparaît une application naturelle du principe de partage sécurisé de données entre acteurs distincts qu’il est traditionnellement difficile de connecter entre eux (voir par exemple les problématiques du DMP en France).

Une blockchain de santé aurait des effets très positifs sur les systèmes de sécurité sociale car elle offrirait plus de transparence aux administrations sur les soins administrés d’une part. D’autre part, ce type de blockchain permet au patient de se réapproprier sa data, et de choisir de la partager ou pas avec les acteurs qu’il décide, plutôt que de trimballer son épais dossier médical physique (ce qu’il ne fait même pas au final).

Le problème qui se pose ici c’est que tous les acteurs de la blockchain ont fondamentalement la donnée (ou du moins la métadonnée) de tous les patients par exemple. Même si cette information est cryptée et que la clé n’est possédée que par le patient (et une administration par exemple), il est possible que le patient se fasse voler sa clé. A ce moment, il n’y a pas de possibilité d’avoir une option “mot de passe perdu” ou “bloquer mon compte”. Le pirate ayant la donnée cryptée et maintenant la clé, il a la donnée déchiffrée. Un deuxième problème qui se pose est que le cryptage des données sur la blockchain peut être cassé dans les 50 prochaines années ce qui de facto rendra publique la donnée médicale de tous les patients sans leur consentement. Le progrès technologique évoluant par sauts, difficile de prédire le moment où les tailles des clés cryptographiques utilisées aujourd’hui ne seront plus suffisantes.

Enfin, bien qu’il soit possible de crypter le contenu de la transaction entre des acteurs, il est impossible de crypter les parties prenantes ainsi que la nature de la transaction car cela fait partie du protocole de validation. Techniquement, cela signifie, je sais que “telle clinique” a eu à faire avec “telle clé de chiffrement” (correspondant de manière unique à un patient). Cette seule information, par définition publique, peut avoir des conséquences désastreuses sur l’employabilité ou les relations sociales d’une personne.

Alors quelles solutions ?

Concernant les volets cryptographiques, il n’y a pas de solution réaliste aujourd’hui qui ne fasse pas intervenir des acteurs centraux pour centraliser la donnée et laisser à la blockchain uniquement le volet “metadata”, c’est-à-dire de prouver qu’une transaction entre plusieurs parties a effectivement eu lieu.

De nouvelles formes de blockchain dites ZK (Zero Knowledge) permettent de répondre à la dernière problématique. A savoir de masquer l’identité des personnes qui effectuent la transaction tout en maintenant un niveau de confiance quasi-parfait. Si je veux déployer un use case médical, il me sera globalement difficile d’utiliser une blockchain car les risques semblent trop importants par rapport aux bénéfices. Une architecture centralisée (avec potentiellement plusieurs acteurs mis intelligemment en concurrence comme le système des wallets) paraît plus adéquate dans le contexte actuel.

Le problème de l’isolation de l’extérieur :

Il existe une pratique d’épargne traditionnel dans notre société qu’on appelle “daret”, forme de tontine rotative pratiquée pour répondre à des besoins ponctuels de financement entre membres d’une communauté soudée sans recourir au système bancaire. Daret n’existe que parce qu’il y a un niveau de confiance fort entre les acteurs. C’est donc typiquement un use case que la blockchain pourrait gérer entre personnes qui ne se connaissent même pas. Le protocole de la blockchain assurerait alors la confiance et offrirait une redistribution conforme au contrat de départ implémenté dans la blockchain. Ce type de use case est facilement faisable avec une blockchain de type Ethereum.

La question qui pose est que faire si on veut lier ce contrat avec quelque chose d’extérieur comme par exemple un générateur de nombre aléatoire pour tirer au sort le bénéficiaire de daret ? Cela va supposer le branchement de la blockchain à un service externe dont les appels doivent pouvoir être rejoués dans le futur, et dont la pérennité doit être garantie car tout membre de la blockchain doit pouvoir valider les transactions à tout moment.

On appelle ce type de service “un oracle”. Ce genre de dépendance est primordial pour des services de type assurance également qui ont par exemple besoin d’utiliser l’information issue de l’extérieur (“ma maison a brûlé”) pour débloquer une police d’assurance (“l’assurance va me payer basé sur mon contrat dans la blockchain”).

Alors quelles solutions ?

Il n’existe pas d’oracle parfait pour ma tontine aléatoire. En participant à une telle tontine, je dois accepter que ce hasard sera importé de l’extérieur. Et que potentiellement demain si je veux vérifier dans la blockchain que la distribution des versements est bien aléatoire (parce que je m’estime lésé par exemple), le service de hasard peut ne pas être disponible ou avoir tout simplement disparu car indépendant de la blockchain.

Le problème de l’identité des mineurs :

Nous sommes d’accord pour dire que la blockchain a remplacé le problème de faire confiance à un acteur par le fait de faire confiance à de multiples acteurs qui collaborent ensemble pour certifier et accuser réception mes transactions. Mais que se passe-t-il si ces acteurs ne sont pas répartis équitablement à travers les pays et les régions du monde, mais concentrés aux mains d’un nombre d’acteurs plus réduit qui se sont préalablement concertés ?

J’ai toujours imaginé une blockchain administrative qui puisse garantir à un citoyen un acte de la même manière qu’il est possible de légaliser un document dans les services d’une commune. Cette blockchain aurait une force juridique opposable dans les administrations et tribunaux et serait un support pour par exemple les transactions immobilières ou commerciales entre personnes physiques et morales.

Maintenant imaginons que ce use case utilise une blockchain mondiale pour garantir un niveau de confiance encore plus grand. Puis petit à petit, qu’on se rende compte qu’une majorité de mineurs de cette blockchain sont de nationalité canadienne. Sur ordre judiciaire, ces mineurs pourraient être contraints de supprimer des informations dans la blockchain (par le procédé de soft fork, difficile mais possible), ou de ralentir fortement les transactions d’un certain pays.

Il est difficile d’avoir la nationalité exacte de qui contrôle un noeud. Et encore plus difficile d’avoir la puissance de calcul derrière chaque noeud inscrit dans le réseau Bitcoin. Par conséquent, l’utilisation d’une blockchain mondiale peut révéler un problème de souveraineté si des uses cases sensibles et vitaux sont hébergés dessus.

Alors quelles solutions ?

Là encore, il faut trouver un juste équilibre entre ne pas trop contrôler les noeuds (notion de confiance) et les contrôler un peu quand même (jurisprudence de pays amis par exemple) de manière à sécuriser les services administratifs par exemple. La blockchain nationale se prête bien à un use case administratif, avec des mineurs constitués d’entreprises marocaines toutes soumise aux lois marocaines.

Le problème énergétique :

La consommation d’énergie requise par les mineurs d’une blockchain est aujourd’hui intolérable sachant qu’elle est équivalente à celle de Singapore, soit 48TWh (soit 0.21% de la consommation mondiale). Pour valider une transaction, le bitcoin utilise jusqu’à une semaine de consommation électrique d’un foyer américain.

Le réel problème est que la capitalisation du bitcoin a attiré beaucoup de mineurs ce qui a rendu la collaboration “plus difficile” pour la synthèse des blocs. C’est précisément cette difficulté qui protège le protocole de manipulations et qui consomme de l’énergie. Quelque part, les médias et grandes institutions véhiculent l’idée que la blockchain historique du bitcoin n’a pas d’intérêt dans le monde réel et que cette énergie est quelque part “perdue”. Mais la réalité est plus complexe car la capitalisation montre que fondamentalement des gens pensent que cette blockchain a et aura des retombées positives (ils peuvent être aussi simplement des spéculateurs mais c’est une autre histoire).

Le problème écologique ne m’impacte pas en tant qu’utilisateur de la blockchain, mais plutôt en tant que citoyen planétaire. Ce n’est donc pas un frein dans l’absolu pour les uses cases.

Alors quelles solutions ?

Le problème énergétique est fortement lié à la force de la blockchain. Plus il y a de participants et plus la construction des blocs est rendue difficile par le protocole blockchain. Plus la construction des blocs est difficile et plus la blockchain est stable et offre une garantie de non-répudiation des transactions.

Plus la blockchain est stable et plus elle est utilisée, donc plus la cryptocurrency est demandée, son prix monte et plus les participants sont nombreux pour participer à la construction des blocs (prendre des frais de transactions). C’est donc par construction un serpent qui se mord la queue. La blockchain victime de de son succès ne peut que consommer plus d’énergie.

Il y a donc eu des efforts importants pour trouver des algorithmes qui permettent le même niveau de stabilité de la blockchain avec une difficulté algorithmique plus facile. On parle beaucoup du PoS (Proof Of Stake) comme manière de remplacer le PoW (Proof Of Work) mais ce système induit des changements importants dans la manière dont les noeuds collaborent ensemble. Et rien ne dit si en pratique les réseaux blockchain garderont leur stabilité.