Analyse et comparaison des mécanismes de consensus dans la blockchain

De la “Proof of Work” à la “Delegated Proof of Stake” : quel mode de gouvernance pour instaurer la confiance dans un registre partagé au travers d’un réseau décentralisé ?

Godefroy Galas
46 min readMay 14, 2018
Source: Pixabay

Plongée dans les coulisses de la blockchain : zoom sur le concept de consensus afin de bien comprendre ce processus clé opérant au cœur du mode de gouvernance d’un registre distribué.

Projet co-réalisé avec Jihane Harazi dans le cadre de la filière Cybersécurité de Télécom Paris, première grande école française du numérique.

Introduction

La technologie Blockchain permet à des utilisateurs de consulter et de mettre à jour un registre commun partagé (que l’on appelle une blockchain) et dont le contenu est maintenu de façon décentralisée, sans la présence d’un tiers de confiance. C’est au travers d’un mécanisme de consensus que s’effectue la mise à jour de cette blockchain, mécanisme qui assure un ordonnancement clair et sans ambiguïté des transactions et des blocs et qui garantit l’intégrité et la consistance du contenu de ce registre partagé entre les différents nœuds distribués du réseau.

Il est nécessaire de faire d’emblée une distinction entre les blockchains publiques (permissionless) et les blockchains privées (permissioned). Dans une blockchain publique de type Bitcoin ou Ethereum, n’importe quel utilisateur ou nœud du réseau est en mesure d’effectuer une transaction ou de prendre part au processus de consensus entre l’ensemble des nœuds distribués afin d’ajouter un nouveau bloc au registre. Au contraire, au sein de plateformes privées telles que Hyperledger Fabric ou Multichain, la participation au processus de consensus est contrôlée et réservée à une liste restreinte de nœuds autorisés par le consortium administrant ladite plateforme.

Dans le cadre d’une blockchain publique, n’importe qui est libre de créer son propre nœud distribué. Ainsi, chacun de ces nœuds est anonyme et se doit d’être considéré, de base, comme “untrusted” et non sûr. Un mécanisme de consensus entre ces nœuds, qui sont généralement nombreux, doit donc être déployé afin de pallier efficacement la possibilité d’attaque Sybil ou DDoS. Initialement, ce problème a été résolu par les toutes premières plateformes blockchains en exigeant des nœuds qu’ils fournissent la preuve d’un travail difficilement réalisable mais facilement vérifiable (la Proof of Work ou PoW). Cette preuve nécessite la dépense d’une quantité significative d’énergie, ce qui garantit la sécurité du mécanisme et endigue le déploiement potentiel de nœuds malveillants visant à manipuler le consensus.

Une attaque Sybil consiste à contourner le système de réputation d’un réseau pair à pair en créant une grande quantité d’identités et en les utilisant pour avoir une influence disproportionnée.

Dans le cadre d’une blockchain privée, les nœuds qui mettent en œuvre le mécanisme de consensus sont enregistrés, connus et vérifiés par le consortium administrant ladite blockchain. Ainsi, de base, les nœuds ne sont pas considérés comme malveillants. En outre, le nombre de nœuds distribués est en général bien plus faible comparé à une blockchain publique ou permissionless. Il n’est donc pas nécessaire de mettre en œuvre un mécanisme très gourmand en matière de consommation énergétique tel que la PoW. On préférera alors déployer des mécanismes plus classiques et légers tels que Paxos, RAFT ou les algorithmes BFT (Byzantine Fault Tolerance).

Tout au long du présent article, nous nous intéresserons principalement aux mécanismes de consensus des blockchains publiques. Néanmoins, qu’elles soient publiques ou privées, les plateformes blockchains doivent répondre aux exigences croissantes des applications pour lesquelles elles sont conçues :

  • Performances élevées (latence faible, grand nombre de transactions par seconde)
  • Scalabilité poussée
  • Faible consommation d’électricité
  • Irrévocabilité des transactions
  • Grande résistance aux attaques, etc.

Si le mécanisme PoW a permis d’instaurer un consensus fiable au sein d’un réseau étendu, il n’est absolument pas adapté aux applications nécessitant, par exemple, une faible consommation d’énergie ou un très haut débit de transactions. Ainsi, dans l’optique de s’affranchir de ces différentes limitations, de nouveaux mécanismes de consensus, que nous tâcherons d’analyser et de comparer dans cet article, ont été imaginés et développés : Proof of Stake, Delegated Proof of Stake, Proof of Elapsed Time, etc.

Généralités sur les mécanismes de consensus

L’objectif d’un mécanisme de consensus dans le cadre d’un réseau décentralisé reposant sur une blockchain publique est de laisser les membres du réseau s’accorder sur l’état actuel de l’historique des transactions (ledger) sans confiance entre ces différents intervenants (les nœuds du réseau) et en l’absence d’une entité centralisée chargée de mettre à jour ce registre. En d’autres termes, c’est le processus qui permet à un réseau décentralisé partageant un historique commun (la blockchain) de se mettre d’accord sur la validité et sur l’ordre des transactions à rajouter audit historique, par l’ajout successif de nouveaux blocs. En anglais, on peut synthétiser ce principe dans l’expression “trustless and distributed consensus”.

En général, la sécurité d’un mécanisme de consensus est l’aspect le plus important et le plus vital de la conception d’une plateforme blockchain. C’est le bon fonctionnement de ce mécanisme qui garantit à l’ensemble des utilisateurs l’inviolabilité des données enregistrées sur cette blockchain. En outre, ce dernier doit être en mesure de protéger et de maintenir la cohérence de ladite blockchain même en présence de pannes (arrêt inopiné de nœuds composant le réseau) ou de conditions difficiles (attaques sporadiques visant à semer la confusion entre les nœuds, pics de latence du réseau).

Effets induits par la défaillance d’un mécanisme de consensus

Le choix d’un mécanisme de consensus inadapté peut rendre le système blockchain sous-jacent inutilisable et compromettre l’intégralité des données stockées dans le registre (double spending, auto-octroi de coins, réécriture de transaction, etc.). La défaillance d’un mécanisme de consensus peut notamment induire les effets suivants :

  • Fork : Certains nœuds convergent alors vers une chaîne différente du reste du réseau. En général, les latences du réseau induisent des forks temporaires qui sont résolus au bout de deux ou trois blocs maximum.
  • Absence de consensus (Consensus Failure) : Le mécanisme n’est pas en mesure de permettre aux membres du réseau de s’accorder sur l’état actuel de l’historique des transactions. Dans ce cas, on peut dire que la blockchain est totalement inopérante.
  • Domination : Le mécanisme de consensus n’empêche pas un attaquant de créer de fausses identités au sein du réseau de nœuds distribués. Ces fausses identités sont alors utilisées pour semer la confusion et manipuler le consensus afin d’injecter de fausses données dans le registre, voire de le réécrire (attaque Sybil). Dans un réseau de type PoW (Proof of Work), la domination peut être réalisée en contrôlant plus de la moitié de la puissance de calcul total du réseau. C’est ce qu’on appelle une “attaque des 51%”.
  • Triche : Un nœud ou un ensemble de nœuds peuvent volontairement décider de maintenir une chaîne parallèle et donc présenter aux yeux d’une personne extérieure (un vendeur en ligne acceptant le paiement en crypto-monnaies par exemple) une liste falsifiée de transactions. Les mécanismes de consensus et de lecture du registre doivent donc être en mesure de rendre impossible la réalisation de ce genre d’attaque sur une plateforme blockchain.
  • Mauvaises performances : En fonction de l’algorithme implémenté par le mécanisme de consensus, les nœuds peuvent mettre un certain temps avant de converger vers la même chaîne, d’autant plus si la latence du réseau est instable ou si des nœuds malveillants retardent la transmission des messages.

Mesure de l’efficacité d’un mécanisme de consensus

Comme nous venons de le constater dans la section précédente, parvenir à un consensus au sein d’un réseau de nœuds distribués n’est pas chose aisée. Les algorithmes de consensus doivent être résilients aux pannes de nœuds, aux retards de transmission, aux messages égarés ou corrompus et doivent également faire face aux nœuds malveillants tentant de manipuler le consensus ou de le retarder.

Pour ce faire, une pluralité de mécanismes existent dans la littérature : Proof of Work (PoW), Proof of Stake (PoS), Delegated Proof of Stake (DPoS), Proof of Elapsed Time (PoET), etc. Chacun d’entre eux dispose de ses propres caractéristiques en matière de synchronisation, d’émission de message (fréquence, taille), de tolérance aux pannes, de prévention contre les nœuds malveillants, de performance et de sécurité des messages échangés.

Ainsi, dans le cadre d’un système blockchain, parvenir à un consensus garantit que l’ensemble des nœuds du réseau s’accordent sur un même état du registre et des données qui y sont stockées. Pour déterminer plus précisément l’efficacité d’un mécanisme de consensus, on évalue ce dernier selon 3 critères principaux :

  • Terminaison (Liveness) : Tous les nœuds opérationnels participant au consensus doivent finalement produire une valeur.
  • Sûreté / Consistance (Safety) : Tous les nœuds opérationnels doivent s’accorder en temps réel sur l’une des valeurs proposées par l’un des nœuds. Cette valeur doit être valide selon les règles définies par le mécanisme.
  • Tolérance aux fautes : Le mécanisme doit être capable de fonctionner même si un ou plusieurs nœuds sont défaillants.

Il est crucial de pouvoir satisfaire les trois propriétés listées ci-dessus si on souhaite résoudre, dans son intégralité, le problème du consensus. Malheureusement, Fischer, Lynch et Patterson, trois chercheurs en informatique, ont montré en 1985 qu’aucun algorithme déterministe de consensus ne permettait de garantir en même temps ces trois propriétés au sein d’un système asynchrone tel qu’un réseau de nœuds distribués (FLP Impossibility). Ainsi, en règle générale, puisque la tolérance aux fautes est absolument vitale dans le cadre d’un réseau de nœuds distribués, les mécanismes de consensus doivent choisir entre la sûreté et la terminaison en fonction des exigences de l’application pour laquelle a été conçue la plateforme distribuée.

Un système asynchrone est un système au sein duquel un nœud émetteur n’obtient jamais de confirmation de réception de la part d’un nœud destinataire lors de l’envoi d’un message au travers d’un réseau distribué.

En matière de tolérance aux fautes, les mécanismes de consensus traditionnels opérant dans un réseau de nœuds distribués et connus se sont d’abord évertués à corriger à faire face aux fautes “fail-stop” où un nœud ne répond plus suite à un problème matériel ou logiciel. Par exemple, des mécanismes comme Paxos ou RAFT sont capables de tolérer jusqu’à “f” fautes “fail-stop” simultanées si le réseau en question est composé d’au moins “2f+1” nœuds. Par la suite, ces mécanismes ont tâché de résoudre le problème des généraux byzantins et d’endiguer les fautes “byzantines” où un nœud “traître” transmet volontairement des messages erronés afin d’empêcher l’établissement d’un consensus. Ces dernières étant bien plus complexes à gérer, il est nécessaire d’implémenter des couches supplémentaires de messages au sein du mécanisme : c’est ce qu’on appelle l’overhead. L’algorithme PBFT (Practical Byzantine Fault Tolerance) est le premier à pouvoir tolérer des fautes “byzantines” dans un réseau de nœuds connus et distribués sans ajout d’un overhead volumineux. Ce mécanisme est capable de supporter jusqu’à “f” fautes “byzantines” si le réseau sous-jacent est composé d’au moins “3f+1” nœuds parmi lesquels on trouve un nœud primaire (commandant) et plusieurs nœuds secondaires (lieutenants). Les nœuds secondaires vérifient constamment la validité des décisions prises par le nœud primaire et peuvent collectivement nommer un nouveau nœud primaire si ce dernier se retrouve compromis.

Un overhead correspond à l’ensemble des données supplémentaires rajoutées en complément des informations utiles contenues dans le corps des messages afin de corriger les éventuelles erreurs de transmission : sommes de contrôle, redondances, etc.

Pour les plateformes de type blockchain publique (permissionless) où les nœuds sont considérés comme “untrusted”, ce sont la tolérance aux fautes et la terminaison (liveness ou disponibilité) qui ont été choisies pour le mécanisme de consensus au détriment de la consistance. Ce choix de la terminaison apporte de la réactivité à l’ajout de transactions et à la mise à jour du registre, registre qui est partagé entre un nombre relativement important de nœuds. Mais il implique également, au fil du temps, que des nœuds différents peuvent voir se confronter des pseudo-états courants distincts, ce que l’on nomme dans le jargon un fork. Ainsi, il peut y avoir des situations dans lesquelles les nœuds divergent sur plusieurs versions potentielles du registre, empêchant ainsi les utilisateurs ou des tiers extérieurs de déterminer à l’avance laquelle sera finalement retenue par le réseau suite au consensus. Cela aboutit à un modèle doté d’une finalité de transaction probabiliste (chaque chaîne potentielle ayant une certaine probabilité de devenir la chaîne principale) où une transaction ajoutée à un bloc dans la blockchain n’est pas immédiatement considérée comme définitive puisque les clients devront escompter un certain délai avant que cette dernière soit confirmée et reconnue par l’ensemble du réseau.

À l’inverse, dans les blockchains privées où les nœuds sont connus et généralement peu nombreux, on préfère privilégier la tolérance aux fautes et la consistance. Les nœuds partagent alors en permanence la même version du registre et aucun fork n’apparaît. Ce modèle est donc doté d’une finalité de transaction immédiate, c’est-à-dire qu’une fois la transaction incluse dans le bloc, elle est confirmée sans possibilité d’annulation ultérieure.

Analyse du mécanisme Proof of Work (PoW)

Généralités

Le mécanisme Proof of Work (PoW) est le mécanisme de consensus original implémenté dans les premières plateformes de type blockchain. Il consiste en la résolution d’un problème cryptographique difficile afin de pouvoir ajouter un nouveau bloc de données (tels que des transactions) au registre partagé. Ce problème est conçu de telle manière que le travail induit pour le résoudre doit être difficilement réalisable (en matière de puissance informatique et d’énergie notamment) pour le demandeur, mais facilement vérifiable par un tiers.

Par définition, une blockchain fait appel à un réseau de nœuds dont le rôle est d’exécuter le code de la plateforme et de vérifier les données entrantes sur le registre. Ce principe de fonctionnement nous conduit naturellement à la question suivante : comment choisir le prochain nœud qui sera chargé d’écrire le prochain bloc ? Compte tenu de ce qui a été expliqué précédemment, la réponse à cette question nous impose d’établir un mécanisme de consensus :

  • Permettant de désigner le nœud auquel on accordera un droit d’écriture pour prolonger la seule et unique chaîne de blocs.
  • Se révélant dissuasif pour les éventuels utilisateurs malveillants.

La preuve de travail est un moyen extrêmement efficace de répondre à ce besoin. Pour être autorisé à ajouter un nouveau bloc à la blockchain, chaque nœud doit montrer qu’il a effectué une certaine quantité de travail : c’est ce qu’on appelle la Proof of Work (PoW). Pour prouver la réalisation effective de cette quantité de travail, ce mécanisme demande à l’ensemble des nœuds distribués du réseau la résolution d’un défi mathématique complexe qui consomme une grande puissance de calcul. Néanmoins, si une solution possible est trouvée, cette dernière peut facilement être vérifiée par les autres nœuds du réseau. Le premier nœud à trouver la solution obtient le droit d’ajouter son bloc à la blockchain et reçoit une récompense : le mining reward (ou coinbase). Le mineur touche également l’ensemble des frais adjoints par les utilisateurs à chaque transaction effectuée : c’est ce qu’on appelle les transaction fees. Ainsi, on appelle les nœuds prenant part à un mécanisme de consensus de type PoW des mineurs, car l’énergie qu’ils déploient pour trouver la solution au problème complexe demandé est analogue à celle déployée par les chercheurs d’or dans leur quête de pépites dans une mine. En outre, un mécanisme de type PoW est capable d’ajuster en temps réel la difficulté du problème en fonction de la puissance de calcul totale du réseau (hashrate), ceci dans le but de maintenir un délai constant entre l’ajout de chaque nouveau bloc.

Implémentation PoW de Bitcoin (BTC)

Photo by Thought Catalog on Unsplash

L’implémentation la plus célèbre d’un mécanisme de consensus de type PoW est le système Bitcoin. C’est en effet le Bitcoin qui a jeté les fondements pratiques de ce type de consensus. Le puzzle/défi utilisé par la plateforme Bitcoin est le Hashcash. Ce dernier dispose d’une difficulté adaptable en fonction de la puissance de calcul totale du réseau afin d’ajuster le temps moyen de création d’un bloc à environ 10 minutes.

Ce mécanisme fournit également à chacun des nœuds une méthodologie afin de savoir s’il faut accepter ou non un bloc ajouté par un autre nœud. Elle permet à chaque utilisateur de prendre des décisions locales et par conséquent de satisfaire au critère d’efficacité dit de terminaison (cf. supra). Cette méthodologie précise notamment quels blocs il faut garder et/ou diffuser et lesquels sont à rejeter.

Vérification de la validité de l’en-tête du bloc

Le schéma ci-dessus représente le problème cryptographique à résoudre et pour lequel les nœuds sont en compétition les uns avec les autres. Le processus de résolution de ce problème est nommé mining ; les nœuds y
prenant part sont les mineurs. Pour ce faire, les mineurs doivent généralement utiliser un matériel informatique spécialisé très puissant appelé ASIC (Application-Specific Integrated Circuit i.e. un chipset de circuit intégré spécifique à une application) spécialement dédié à la résolution du problème demandé par Hashcash. Ce dernier consiste en la recherche d’une valeur, le nonce, dont la concaténation avec les autres éléments de l’en-tête d’un bloc potentiel (version/hauteur/numéro du bloc, date ou timestamp, hash du bloc précédent, difficulté actuelle, ainsi que le hash de l’arbre de Merkle qui constitue une sorte d’image de l’ensemble des transactions contenues dans ledit bloc) produit un hash (après deux tours d’une fonction de hachage, SHA-256) d’une valeur inférieure à un certain seuil. Ce seuil est établi en fonction de la difficulté retenue par le réseau : plus celle-ci est élevée plus la valeur du seuil sera faible, et plus la valeur du hash requis devra commencer par un nombre important de zéros.

Une fonction de hachage calcule, à partir d’une donnée d’entrée de taille arbitraire, une image standardisée de taille fixe, que l’on appelle un hache (hash en anglais). Cette dernière est conçue de telle sorte qu’il soit facile de calculer l’image d’une donnée d’entrée mais extrêmement difficile de déterminer l’inverse d’une image par cette fonction, c’est-à-dire de retrouver la donnée d’entrée qui a généré ladite image.

Ainsi, dans le cadre du système Bitcoin, la preuve de travail consiste en la détermination du nonce qui, concaténé avec les autres composants de l’en-tête du bloc, permettra d’aboutir à un hash commençant par un nombre minimum de zéros i.e. inférieur à un seuil. Ainsi, en pseudo-code, la PoW de Bitcoin peut être exprimée comme suit :

Tant que (valeur du hash) >= SEUIL :
1. Calculer le hash de l’en-tête du bloc
2. Si (valeur du hash) < SEUIL, retourner le hash (bloc miné)
Sinon, incrémenter le nonce de 1

Le premier nœud parvenant à exhiber un hash gagnant acquiert ainsi le droit d’ajouter le bloc afférent à la chaîne et de réclamer la récompense de minage : des bitcoins nouvellement générés qui viendront s’ajouter aux unités déjà en circulation.

Dans le cas où plusieurs nœuds trouvent simultanément un hash gagnant, chacun d’entre eux va s’évertuer à diffuser son propre nouveau bloc au sein d’un maximum de nœuds du réseau. En conséquence, un fork temporaire affecte la blockchain puisque certains nœuds du réseau chercheront à ajouter des blocs à l’une des branches, tandis que d’autres viseront à ajouter des nouveaux blocs à l’autre branche, ceci en fonction du bloc gagnant le plus proche d’eux. Dans cette situation où deux branches (voire plus) sont en concurrence, ce sera celle où le plus de travail aura été mené, c’est-à-dire la chaîne la plus longue, qui sera retenue par l’ensemble du réseau en tant que chaîne principale.

L’algorithme de consensus Bitcoin PoW fonctionne bien dans un environnement ouvert où n’importe quel nombre de nœuds peut participer au réseau et commencer à miner. Aucune connaissance technique ou d’authentification n’est nécessaire, ce qui rend ce type de modèle de consensus extrêmement efficace et adaptable dans le cadre de la prise en charge de milliers de nœuds. Néanmoins, le mécanisme de consensus PoW de Bitcoin reste vulnérable aux attaques dites des “51%” où un regroupement de mineurs, appelé un pool de minage, travaillant ensemble et contrôlant 51% de la puissance de calcul (i.e. hashrate), serait en mesure d’ajouter ses propres blocs à la blockchain ou de créer une branche indépendante concurrente vers laquelle convergera, plus tard, la branche principale et légitime. Ce type d’attaque permet notamment au pool attaquant de pouvoir dépenser deux fois ses propres fonds et de rejeter les transactions qu’il ne veut pas voir incluses dans le registre.

Implémentation PoW d’Ethereum (ETH)

Logo du projet Ethereum (Source: Pixabay)

Comme le réseau Bitcoin, la blockchain Ethereum est publique (permissionless) et le processus du minage des blocs est ouvert à tous. Ainsi, n’importe quel utilisateur peut télécharger le client Ethereum et l’exécuter sur sa machine pour la transformer en nœud et rejoindre le réseau Ethereum. Cette plateforme utilise sa propre crypto-monnaie interne appelée Ether (ETH), qui est utilisée pour payer les nœuds validant les blocs (mining reward et transaction fees) et servir de mesure de défense contre les attaques DDoS. Ethereum est conçu pour être utilisé par n’importe quel type d’application nécessitant un support de blockchain (système de paiement, exécution de smart-contracts adossés à un token, etc.). Toutes les transactions sont enregistrées sur la blockchain Ethereum et peuvent être vérifiées par tous les utilisateurs du réseau.

Ethereum (dans la version actuelle appelée Homestead) utilise sa propre implémentation du mécanisme PoW, appelé Ethash, qui fournit des temps rapides de confirmation des blocs et renforce la résistance aux ASIC afin de se prémunir des attaques “51%” auxquelles Bitcoin est vulnérable. Comme pour Bitcoin, ce mécanisme consiste à trouver une entrée de nonce à l’algorithme de sorte que le résultat soit inférieur à un seuil précis qui est fonction de la difficulté. De plus, il n’y a pas de stratégie optimale permettant de trouver une telle valeur, la seule technique consistant à énumérer toutes les possibilités le plus rapidement possible, ce qui consomme énormément de ressources et incite donc à utiliser des ASIC. Au contraire, la vérification de ce nonce par les nœuds est triviale et peu coûteuse.

La difficulté du réseau Ethereum s’ajuste dynamiquement, de sorte qu’en moyenne un bloc est produit par l’ensemble du réseau toutes les 14 secondes. Ce “tempo” orchestre la synchronisation de l’état du registre et garantit l’impossibilité de démarrer une chaîne illégitime (pour permettre une double dépense) ou de réécrire l’historique, sauf si l’attaquant possède plus de la moitié de la puissance de minage du réseau. Tout nœud participant au réseau peut devenir un mineur et son revenu sera directement proportionnel à sa puissance de calcul (relative) ou à son taux de hachage (hashrate), c’est-à-dire au nombre de tentatives par seconde normalisées par la puissance de calcul totale du réseau.

Pour Bitcoin, ce mode de revenu incitait donc les mineurs à se regrouper entre eux dans le cadre de coopérations (appelés pools) et à user de matériels de calcul nommés ASIC et spécialisés dans le calcul de hash à grande vitesse. Ethash a justement été conçu pour lutter contre ce phénomène de centralisation minière (qui va à l’encontre de l’idée originale de Satoshi Nakamoto) qui était une faiblesse dans le Bitcoin pour lequel un grand nombre d’ASIC étaient produits à bas prix afin d’effectuer des opérations de hachage à des vitesses élevées, surpassant de loin le matériel informatique classique (CPU, GPU). Ainsi, de grandes entités ont pu créer des pools de minage dont le taux de hachage inégalable leur a permis de contrôler une grande partie de la puissance de calcul du réseau Bitcoin, au détriment des utilisateurs minant seuls qui ne pouvaient rivaliser.

En conséquence, Ethash utilise deux techniques pour lutter contre la centralisation minière :

1 - Memory hardness

La première technique utilise une propriété appelée memory hardness. Ainsi, le mécanisme Ethereum ne demande pas seulement d’effectuer rapidement des calculs, mais également d’aller chercher des données
dans un fichier stocké en mémoire qui s’appelle le DAG (Directed Acyclic Graph i.e. un graphe orienté sans circuit, cf. infra), fichier qui est régénéré tous les 30 000 blocs (5 jours) et dont la taille augmente progressivement au fil du temps. Le matériel de type ASIC étant, à l’heure actuelle, incapable de réaliser de nombreuses “petites” opérations de recherche en mémoire en parallèle, l’algorithme de minage Ethereum est donc ASIC-résistant et empêche les grandes entreprises puissantes de prendre, en théorie, le contrôle de la puissance minière du réseau Ethereum, au profit de nœuds plus petits et plus décentralisés faisant usage d’un matériel plus accessible comme des cartes graphiques (GPUs).

Représentation d’un DAG (Source : Wikipedia)

2 - GHOST

Une deuxième technique appelée GHOST (Greedy Heaviest Observed SubTree) impose aux nœuds de minage d’inclure, dans l’en-tête du bloc qu’ils veulent valider, les en-têtes des blocs récemment orphelins connus sous le nom d’uncles (oncles). Les blocs orphelins sont des blocs qui ont été ajoutés sur des chaînes parallèles à la blockchain principale (fork temporaires). Pour Bitcoin, un oncle est donc un bloc qui serait considéré comme un orphelin parce qu’il n’est pas situé sur la plus longue chaîne (c’est un bloc alternatif à la même hauteur que le parent du bloc actuellement en phase de minage sur la chaîne principale). Ethereum incite les mineurs à inclure une liste d’oncles lorsqu’ils valident un nouveau bloc. Cette technique a deux effets principaux :

Illustration du fonctionnement de GHOST (Source : La blockchain en détail, Benoît Lafontaine & Yann Rouillard, slide 61–62)
  • Elle réduit l’incitation à la centralisation en récompensant toujours (de manière réduite) les mineurs qui produisent des blocs périmés ou orphelins parce qu’ils ne font pas partie d’un grand groupe et qu’ils entendent parler des blocs plus tard (en raison des retards de propagation du réseau).
  • Elle augmente la sécurité de la chaîne en augmentant la quantité de travail sur la chaîne principale comparée à celle menée sur les oncles des chaînes alternatives. En conséquence, beaucoup moins de travail est gaspillé au niveau des chaînes alternatives au profit de la chaîne principale.

Fonctionnement détaillé de l’algorithme Ethash

Si on rentre dans les détails, l’algorithme Ethash repose sur un jeu de données pseudo-aléatoire, le DAG, initialisé par la longueur actuelle de la blockchain (block height). Celui-ci est régénéré tous les 30 000 blocs (ou tous les 5 jours environ). En mars 2017, la taille de la DAG était d’environ 2 Go. Le DAG continuera de croître au fur et à mesure de l’augmentation de la longueur de la blockchain. Le fonctionnement de l’algorithme de hachage Ethash peut être résumé comme suit :

Zoom sur le fonctionnement d’Ethash (Source : Blog de Vijay Pradeep)
  1. L’en-tête prétraitée (dérivée du dernier bloc) et le nonce testé (current nonce) sont concaténés en utilisant un algorithme semblable à SHA-3 pour créer notre mélange initial de 128 octets, appelé Mix 0.
  2. Le Mix 0 est utilisé pour déterminer la page de 128 octets du DAG à récupérer dans la mémoire (Fetch DAG Page).
  3. Le Mix 0 est concaténé avec la page DAG récupérée. Cette opération est réalisée en utilisant une fonction de hachage spécifique à Ethereum pour générer le mélange suivant, appelé Mix 1.
  4. Les étapes 2 et 3 sont répétées 64 fois, ce qui nous permet d’obtenir Mix 64.
  5. Le Mix 64 est retraité pour donner un Mix Digest de 32 octets.
  6. Le Mix Digest est comparé au seuil cible (qui dépend de la difficulté) prédéfini de 32 octets. Si la valeur du Mix Digest est inférieure ou égale à la valeur du seuil cible, le nonce testé (current nonce) est considéré comme valide et sera diffusé sur le réseau Ethereum pour valider le prochain bloc. Sinon, le nonce testé est considéré comme invalide et l’algorithme est exécuté avec un nonce différent (soit en incrémentant le nonce actuel, soit en choisissant un nouveau au hasard).

En conclusion, Ethereum partage les mêmes préoccupations que Bitcoin au niveau de l’attaque des 51%. Ainsi, si un attaquant est en mesure de contrôler 51% de la puissance totale de calcul, un fork pourra être généré et maintenu dans la blockchain Ethereum. Cependant, le caractère “ASIC-resistant” de l’implémentation du mécanisme PoW d’Ethereum induit un frein significatif à la réalisation d’une attaque à 51% au sein du réseau Ethereum.

Comparaison BTC/ETH

Les écosystèmes Bitcoin et Ethereum ont, à l’heure actuelle, quatre points communs : une crypto-monnaie sous-jacente (i.e. un coin), une blockchain dite intrinsèque, un mécanisme de consensus de type PoW ainsi qu’une communauté de nœuds/mineurs prenant part au fonctionnement du réseau au travers de ce mécanisme.

Néanmoins, la principale différence entre les deux plateformes est la possibilité offerte par Ethereum d’utiliser un langage de programmation interne qui permet aux développeurs de pouvoir concevoir une infinité d’applications décentralisées (par le biais des smart-contracts).

De plus, si on se focalise sur le mécanisme en lui-même et sa communauté de mineurs, certaines différences existent :

  • Délai de validation des blocs : pour Ethereum, un nouveau bloc apparaît théoriquement toutes les 14 secondes alors que ce délai est de 10 minutes pour Bitcoin.
  • Taille des blocs : 1 MB pour Bitcoin et taille ajustable par le système pour Ethereum.
  • Vitesse de transaction : en considérant environ 2000 transactions par bloc dans Bitcoin, on peut calculer une performance d’environ 3 transactions par seconde. Pour Ethereum, la performance en matière
    de vitesse de transaction est bien plus grande (grâce notamment à l’utilisation de GHOST) et atteint actuellement en moyenne 10 transactions par seconde.
  • Adaptation de la difficulté : le système Bitcoin adapte la difficulté en fonction de la puissance de calcul totale du réseau tous les 2000 blocs soit tous les 14 jours environ. Le système Ethereum est quant à lui capable d’ajuster sa difficulté en temps réel en fonction de la puissance totale du réseau.
  • Système de récompense : pour Bitcoin, la récompense pour le minage d’un bloc est divisée par 2 tous les 4 ans environ (récompense de 12,5 BTC actuellement). Ce système permet de contrôler l’émission de nouveaux BTC afin d’atteindre un plafond maximum de 21 millions d’unités. Pour Ethereum, la récompense est constante au fil du temps et fixée à 5 ETH. Ainsi, 5 ETH sont créés environ toutes les 14 secondes, ce qui porte à 15,6 millions le nombre d’ETH émis chaque année. Ethereum repose donc sur un système inflationniste tandis que Bitcoin repose sur un système déflationniste.
  • Sécurité : les algorithmes déployés par Ethereum (memory hardness / GHOST) permettent de lutter bien plus efficacement contre les attaques potentielles, notamment celle des “51%”. En effet, le protocole de consensus Ethash empêche l’utilisation d’ASICs et désavantagent les mineurs se regroupant au sein de pools. Il privilégie plutôt le mining décentralisé utilisant du matériel standard et facilement accessible comme des GPUs.

Analyse du mécanisme Proof of Stake (PoS)

Généralités

Nous venons de voir, dans la section précédente, le fonctionnement du mécanisme Proof of Work où chaque nœud du réseau essaie simultanément de résoudre un problème mathématique complexe afin de valider et diffuser au reste du réseau un nouveau bloc de transactions. Ce nœud, que l’on appelle un mineur, est récompensé pour ce travail de résolution complexe par un block mining award. Cette récompense vient en complément des transaction fees prélevés sur le montant de chacune des transactions validées par un noeud (et qui seront rajoutées au sein du Merkle tree, ou arbre de transactions, du prochain bloc).

Le fonctionnement au sein d’un mécanisme de consensus Proof of Stake est tout autre. Dans ce système, chacun des nœuds du réseau se doit de prouver qu’il possède une certaine part de la circulating supply (c’est-à-dire de l’ensemble des coins en circulation) s’il souhaite prendre part au processus de validation des blocs. L’algorithme du réseau va alors choisir de déléguer la validation d’un nouveau bloc à l’un des nœuds du réseau en fonction d’un algorithme tenant compte de quelques critères tels que l’âge des coins possédés et/ou la quantité de coins possédés. De façon simpliste, dans le cadre d’un mécanisme de consensus de type PoS, la probabilité pour un nœud d’être sélectionné pour valider un nouveau bloc correspond à son pourcentage de détention (son “stake”) de la circulating supply. Cette sélection se fait de manière pseudo-aléatoire pour éviter qu’un nœud sache à l’avance quand viendra son tour de valider le prochain bloc. Néanmoins, la prise en compte de certains paramètres supplémentaires tels que la durée de détention des coins possédés, permet aux nœuds les plus “riches” d’être quasi-systématiquement sélectionnés (exemple de Peercoin). Enfin, la validation d’un bloc en elle-même ne donne pas stricto-sensu lieu à une rémunération, c’est plutôt la détention d’un certain montant de crypto-monnaie qui rapporte une rémunération (d’une manière analogue aux intérêts) à laquelle s’ajoute les fees prélevés sur le montant de chaque transaction.

En conséquence, dans le cadre d’un système de type PoS, les nœuds du réseau sont appelés forgerons au lieu de mineurs. En effet, les nœuds utilisent leur quantité stockée de coins (analogue à une réserve de métal) pour frapper, tel un forgeron, des unités de crypto-monnaies supplémentaires (minting). Plus le forgeron dispose de métal, plus la quantité de nouvelles unités frappées sera importante.

Par rapport à la méthode PoW, le PoS a deux avantages principaux :

  • Économie d’énergie : Le PoS est un mécanisme qui consomme beaucoup moins d’énergie que le PoW (qui, lui, nécessite de mener un grand nombre de calculs cryptographiques afin de trouver la preuve de travail demandée pour la validation de chaque bloc).
  • Attaque des 51% plus difficile : Dans un système de type PoS, l’attaque des 51% nécessite de contrôler plus de la moitié de la circulating supply, ce qui est généralement beaucoup plus onéreux que de contrôler 51% de la puissance de calcul dans le cadre d’un système PoW.

Les implémentations naïves des mécanismes PoS souffrent d’un problème supplémentaire nommé Nothing-at-Stake. En effet, celles-ci n’incitent pas les nœuds à voter pour la chaîne qui serait la plus à même d’être légitime (i.e. la plus longue pour la plateforme Bitcoin). En présence de plusieurs chaînes potentielles (en cas de fork), les nœuds vont donc allouer uniformément leur “stake” et donc voter en parallèle pour les derniers blocs composant les chaînes potentielles, ceci dans le but de maximiser leur probabilité d’obtenir la récompense. Contrairement au PoW où “miner” sur plusieurs chaînes simultanément coûte de l’énergie et donc de l’argent au mineur, “minter” sur plusieurs chaînes ne coûte rien aux forgerons dans un système PoS. En conséquence, en assouvissant leur intérêt personnel et en agissant de la sorte, les forgerons facilitent la réalisation d’attaque de type double spending (double dépense) puisque le nœud malveillant initiant une autre chaîne où il aura inversé une transaction de la chaîne légitime sera sûr de pouvoir compter sur les votes de tous les autres nœuds “cupides”.

Illustration du problème dit du « rien à perdre » ou nothing-at-stake (Source : Github — Wiki Ethereum)

Ainsi, comme l’illustre l’image ci-dessous, si tous les forgerons sont purement rationnels économiquement dans le cadre d’un mécanisme PoS où il n’existe que des récompenses à la production de blocs, ces derniers ont tout intérêt à voter sur les deux chaînes potentielles simultanément pour maximiser leurs chances d’obtenir une récompense sur au moins l’une des deux.

Implémentation PoS d’Ethereum (Casper)

Pour endiguer ce problème, la dernière phase du projet Ethereum, dite Serenity, vise à déployer une implémentation avancée du mécanisme de consensus PoS nommée Casper. Au travers de plusieurs Proofs of Concept, cette implémentation est actuellement toujours en phase de test et utilise dans le cadre de son fonctionnement un système de dépôt de sécurité et de “pari” pour atteindre un consensus.

Ainsi, au sein de Casper, les nœuds sont autorisés à être liés au système Ethereum en effectuant des dépôts de sécurité importants définis par le protocole. Ces nœuds sont alors nommés des “validateurs liés” (bonded validators en anglais) et démontrent leur engagement et leur intérêt à faire progresser la chaîne de blocs Ethereum en mettant en jeu leurs dépôts de sécurité. La liste initiale des “validateurs liés” est suivie par un contrat spécial connu sous le nom de contrat Casper. À partir de là, la liste des “valideurs liés” peut évoluer en fonction des nouveaux nœuds qui la rejoignent et des plus anciens qui quittent le système. Chaque validateur est sélectionné de manière pseudo-aléatoire pour produire un bloc à partir de l’ensemble de validateurs actifs, la probabilité de sélection étant pondérée proportionnellement au dépôt de chaque validateur. Si un validateur est hors ligne, un validateur différent est sélectionné et ce processus se répète jusqu’à ce qu’un validateur en ligne soit trouvé pour créer le bloc. Si un validateur produit un bloc qui est ensuite inclus dans la chaîne, il reçoit une récompense de bloc égale à la quantité d’ETH qu’il avait misée au travers de son dépôt de sécurité. Si le validateur produit un bloc qui n’est pas inclus dans la chaîne, le protocole le sanctionne en confisquant alors l’intégralité de son dépôt. Ce mécanisme propose donc de résoudre le problème du Nothing-at-Stake en incitant les nœuds à ne pas produire de blocs non destinés à être inclus dans la chaîne principale.

Analyse du mécanisme Delegated Proof of Stake (DPoS)

Le mécanisme DPoS est une variante du PoS, qui a lui-même été développé afin de réduire les coûts et la consommation élevée d’électricité associée aux mécanismes de type PoW tels que celui utilisé par Bitcoin.

La méthode DPoS a d’abord été implémentée par la plateforme BitShares, développée par le développeur principal de BitShares, Daniel Larimer. Depuis lors, d’autres blockchains, telles que Crypti ou Lisk, ont mis en place des systèmes DPoS similaires.

La différence entre le mécanisme PoS classique et le mécanisme DPoS est analogue à la différence entre la démocratie directe (PoS) et la démocratie représentative (DPoS). Pour le PoS classique, chaque utilisateur dispose d’une certaine quantité de crypto-monnaie qu’il va bloquer à une fin de staking, c’est-à-dire dans le but de participer au processus de validation des transactions et de former le consensus distribué dans l’optique de gagner une récompense en retour. Dans un système de DPoS, chaque portefeuille contenant des unités de crypto-monnaies peut voter pour des délégués proportionnellement au nombre d’unités qu’il détient. Ce sont ces délégués (au nombre de 101 dans la première mise en œuvre de BitShares) qui effectuent la validation des transactions en signant chacun des nouveaux blocs avec leur clé privée, garantissent l’inviolabilité des données du registre et récupèrent les frais des transactions inscrites dans le bloc.

Dans l’implémentation DPoS de BitShares 1.0, les délégués potentiels peuvent définir un “taux de rémunération” lorsqu’ils se présentent aux élections. Un taux de rémunération de 90%, par exemple, signifierait que le délégué conserverait 90% des frais des transactions qu’il traite et en détruirait (par l’intermédiaire d’un burn) 10%. Un burn a donc pour effet de réduire l’offre et, en supposant que la valeur totale du réseau reste la même, d’augmenter par conséquent la valeur de toutes les pièces restantes. Cela équivaut à payer des dividendes aux utilisateurs qui disposent d’une quantité importante de crypto-monnaies et donc d’un droit de vote important.

Logo de BitShares (Source : bitshares.org)

L’idée initiale de BitShares consiste à voir sa plateforme non pas comme une monnaie ou comme de l’or, mais comme la première DAO (Decentralized Autonomous Organisation) c’est-à-dire, en reprenant la définition fournie par Wikipédia, une organisation fonctionnant grâce à un programme informatique qui fournit des règles de gouvernance transparentes et immuables car inscrites dans la blockchain. En séparant les rôles d’administration (réservés aux actionnaires ou stakeholders) et les rôles opérationnels (réservés aux délégués élus), un peu à la manière d’une grande entreprise qui place un conseil d’administration (représentant les actionnaires) au-dessus du comité exécutif pour surveiller ses faits et gestes et le révoquer le cas échéant, le mécanisme de consensus DPoS permet aux détenteurs de la monnaie de voter dans le cadre d’une démocratie numérique pour des candidats qui se proposent de valider des transactions et d’assurer l’inviolabilité du registre en échange d’un salaire. Le système de démocratie permet de révoquer à tout moment les délégués élus si ces derniers accomplissent mal leur travail ou se montrent malveillants. On peut considérer que ce mécanisme est, à l’heure actuelle, celui qui assure la meilleure décentralisation au sein d’une plateforme blockchain. En outre, ce mécanisme est bien plus efficace et efficient qu’un mécanisme de type PoW. En effet, l’élection des délégués permet de valider les transactions en quelques secondes seulement, au lieu des 10 minutes nécessaires à la validation de la Proof of Work employée par Bitcoin.

Enfin, en matière de décentralisation, BitShares est allé encore plus loin en déployant en juin 2015 sa mouture 2.0 qui opère une stratification plus avancée des rôles dits opérationnels. En effet, les détenteurs de BTS peuvent maintenant voter pour deux rôles distincts :

  • Les témoins (Witnesses), qui ont pour unique rôle de valider les transactions en les incluant dans des blocs qu’ils signent. Ils touchent une rémunération fixe qui peut être sujette à modification.
  • Les délégués (Committee Members) qui ont le privilège de pouvoir proposer des modifications aux paramètres du réseau et de la blockchain tels que les frais appliqués pour les différents types de transactions, l’intervalle entre deux blocs, la taille des blocs, la rémunération des témoins, etc. Une fois que la majorité des délégués a approuvé une proposition de modification, les stakeholders se voient accorder une période de réflexion de deux semaines au cours de laquelle ils peuvent voter contre certains délégués afin d’annuler les changements proposés.

Analyse du mécanisme Proof of Elapsed Time (PoET)

Le PoET est un mécanisme de consensus né par l’intermédiaire du projet Intel/Ledger (ou Intel Sawtooth Lake), une plate-forme blockchain privée (permissioned) développée par Intel et ouverte par la suite à l’usage de la communauté. Ce projet est désormais connu sous le nom d’Hyperledger Sawtooth et est développé par la Linux Foundation.

Logo du projet Hyperledger Sawtooth (Source : hyperledger.org)

De façon simplifiée, le mécanisme du PoET fonctionne de la manière suivante :

  • Chaque participant au réseau blockchain attend une quantité aléatoire de temps.
  • Le premier participant à terminer son temps d’attente devient leader du nouveau bloc.

Pour que ce mécanisme fonctionne, deux exigences doivent être vérifiées. Premièrement, le gagnant de la loterie a-t-il bel et bien choisi un temps d’attente aléatoire ? Dans le cas contraire, un participant pourrait par exemple intentionnellement s’attribuer un court temps d’attente pour gagner. Deuxièmement, le gagnant de la loterie a-t-il effectivement fini d’attendre l’intégralité du délai spécifié ?

Pour satisfaire ces deux exigences et garantir la sécurité du mécanisme de consensus, PoET repose sur un ensemble spécial d’instructions CPU appelé Intel Software Guard Extensions (SGX). SGX permet aux applications d’exécuter du code approuvé dans un environnement protégé (Trusted Execution Environment ou TEE). Les fonctions dans le TEE sont conçues de telle sorte que l’exécution de ce code ne puisse pas être altéré par un logiciel externe. Pour PoET, ce code approuvé constitue donc la garantie que ces deux exigences sont bien satisfaites et permet de mettre en place une loterie réellement équitable.

Lorsqu’un nœud de validation prétend être un leader et extrait un bloc, il peut également produire une preuve, générée dans le TEE, que les autres nœuds peuvent facilement vérifier. Il doit prouver qu’il a eu le temps d’attente le plus court et qu’il a attendu un temps défini par le protocole avant de pouvoir commencer à extraire le bloc suivant.

Le caractère aléatoire de la génération des temps d’attente assure que le rôle de leader est réparti au hasard parmi tous les nœuds distribués du réseau. Le seul inconvénient de cet algorithme est l’écosystème SGX qui impose le recours à du matériel spécialisé, seul à même d’attester qu’un code de confiance particulier ait été correctement configuré dans un environnement protégé.

Analyse du mécanisme Byzantine Fault Tolerance (BFT)

Hyperledger Fabric, une autre plateforme blockchain privée (permissioned) en cours de développement par la Linux Foundation (créé à l’origine par IBM), fournit une architecture flexible avec un modèle de consensus adaptable. Fabric est conçu pour être déployé au sein de consortiums où le groupe de participants est non seulement connu, mais dont les identités sont enregistrées et vérifiées par un service de registre central. Il prend également en charge les contrats intelligents sur la blockchain, au travers d’un système intitulé chain-code. Hyperledger est actuellement compatible avec deux modèles de consensus dont notamment le Practical Byzantine Fault Tolerance algorithm (PBFT).

Ce mécanisme de consensus, proposé par Miguel Castro et Barbara Liskov, constitue la première solution pratique au problème des généraux byzantins (cf. supra) pour atteindre le consensus en dépit des fautes “byzantines”. Comme on a pu le voir précédemment, ce mécanisme est capable de supporter jusqu’à “f” fautes “byzantines” si et seulement si le réseau est composé d’au moins “3f+1” nœuds. L’implémentation particulière de cet algorithme fonctionne avec un overhead de taille raisonnable si le réseau est composé d’une vingtaine de nœuds au maximum. Malheureusement, la taille de l’overhead nécessaire augmente exponentiellement avec le nombre de nœuds, rendant de fait inopérant le fonctionnement du mécanisme lorsque l’on souhaite passer à l’échelle (mauvaise scalabilité). En outre, cet algorithme implémente également un système de signature et de chiffrement entre les nœuds de validation (connus) du réseau et les utilisateurs pour garantir la confidentialité des transactions et le caractère privé (permissioned) de la blockchain sous-jacente.

RAPPEL : un overhead correspond à l’ensemble des données supplémentaires rajoutées en complément des informations utiles contenues dans le corps des messages afin de corriger les éventuelles erreurs de transmission : sommes de contrôle, redondances, etc.

Si on entre dans les détails du fonctionnement du mécanisme PBFT au sein de la plateforme Hyperledger Fabric, on peut constater que tous les nœuds de validation maintiennent en permanence une connexion ouverte entre eux. Une fois qu’une transaction est soumise à l’un des nœuds du réseau, cette dernière sera diffusée à l’ensemble des autres nœuds du réseau. À chaque instance de validation d’un nouveau bloc, l’un des nœuds est élu “leader” (primary node ou commandant) à partir de règles pré-établies. Au moment où un nouveau bloc va être généré :

Étape 1 : Le leader ordonne les transactions candidates qui doivent être incluses dans un bloc, et diffuse cette liste de transactions ordonnées à tous les autres nœuds de validation (secondary/replica nodes ou lieutenants) du réseau.

Étape 2 : Lorsque chacun des nœuds de validation reçoit la liste ordonnée de transactions, chacun d’entre eux effectue les opérations suivantes :

  • Il commence à exécuter les transactions ordonnées une par une.
  • Dès que toutes les transactions ont été exécutées, il calcule le hash pour le bloc nouvellement créé (l’algorithme de hachage prévoit des hash différents pour les transactions exécutées et l’état final du registre).
  • Ensuite, il diffuse sa réponse (le hash résultant) à tous les autres pairs du réseau et commence à comptabiliser les réponses de ceux-ci.
  • S’il constate que plus des 2/3 de tous les nœuds de validation (secondary nodes) communiquent le même hash, il enregistre alors le nouveau bloc dans sa copie locale du registre.

Ainsi, à l’issue de chaque instance de validation, l’ensemble des nœuds du réseau s’accordent pour ajouter le même bloc au registre. En conséquence, ces derniers partagent toujours la même version dudit registre en temps réel et les forks sont dès lors inexistants. Ce mécanisme est donc doté d’une finalité de transaction immédiate, c’est-à-dire que lorsqu’une transaction est incluse dans un bloc, celle-ci est confirmée de suite sans possibilité d’annulation ultérieure.

Enfin, il existe plusieurs variantes de ce mécanisme que l’on regroupe sous l’appellation de Federated Byzantine Agreement. Ces protocoles permettent notamment d’augmenter la scalabilité du réseau et de rendre possible son ouverture à un nombre plus important de nœuds, qu’ils soient vérifiés ou non. C’est ce type de mécanisme qu’utilisent notamment Ripple et Stellar Lumens pour leurs systèmes de micro-paiements et de transferts de fonds qui rendent possible l’exécution de transactions transfrontalières (et de devise FIAT à une autre devise FIAT) en quelques secondes seulement.

Étude comparative des différents mécanismes de
consensus

Sécurité

Tout ce qu’on a pu voir dans les sections précédentes confirme que la stabilité face aux montées en charge (i.e. la résilience face à l’augmentation du nombre de transactions sur le réseau, qu’elle soit malveillante ou non) et l’inviolabilité sont les deux piliers de la sécurité des mécanismes de consensus de la blockchain. Dans cette section, nous allons exposer les différentes vulnérabilités connues qui peuvent remettre en cause ces deux piliers ainsi les lacunes potentielles que peut présenter chaque mécanisme de consensus.

Dans cette optique, nous nous sommes appuyés sur le whitepaper “Proof of Stake versus Proof of Work” publié par Bitfury Group afin de lister les vulnérabilités auxquelles sont sujettes les trois principaux mécanismes de
consensus des blockchains publiques : PoW, PoS et DPoS.

Le tableau ci-dessous regroupe les différents types d’attaque qui peuvent affecter les trois mécanismes de consensus PoW, PoS et DPoS.

Tableau récapitulatif des vulnérabilités présentées par les principaux mécanismes de consensus

Vulnérabilités communes

Les vulnérabilités qui sont partagées par les trois mécanismes de consensus sont les suivantes :

I - Attaque par Déni de Service (DoS) : Cette attaque vise à perturber le fonctionnement normal du réseau en inondant les nœuds d’informations. Par exemple, un attaquant peut inonder le réseau de nombreuses transactions de faible valeur, comme ce fut le cas lors d’une attaque à grande échelle sur le réseau Bitcoin, en juillet 2015 (PoW est plus vulnérable du fait du calcul de la preuve cryptographique).

II - Attaque Sybil : L’attaquant perturbe le réseau en créant un certain nombre de nœuds malveillants qui vont prendre part au processus de mining ou de minting (PoW est plus vulnérable que PoS car il est en général moins cher d’acheter du matériel de minage que d’acquérir une part significative de la circulating supply d’une crypto-monnaie)

III - Attaque des 51% : Dans le mécanisme PoW, l’attaque des 51% est déterminée par la quantité de travail nécessaire pour attaquer une chaîne. Un mineur qui possède 51% de la puissance est capable d’attaquer la chaîne principale. Au sein du mécanisme PoS, un utilisateur qui possède 51% des coins est également capable d’attaquer la chaîne. Acheter autant de crypto-monnaie peut sembler onéreux au départ mais pas pour de riches utilisateurs dans un système PoS qui reçoivent des intérêts de plus en plus importants grâce à l’augmentation de leur stake. De plus, l’attaquant n’a pas techniquement besoin d’acheter 51% de la circulating supply car toutes les pièces du réseau ne sont pas systématiquement disponibles pour le staking (stockées sur de gros exchanges par exemple). Néanmoins, pour les deux mécanismes PoW et PoS, un attaquant possédant 51% de la puissance de calcul ou 51% de la circulating supply n’a aucun intérêt sur le plan pécuniaire à mener une telle attaque qui aurait pour conséquence de détruire toute la confiance accordée au réseau et donc de faire s’effondrer la valeur du coin sous-jacent. L’attaquant se retrouverait ainsi avec une grande quantité de crypto-monnaies qui ne vaudrait absolument plus rien.

Vulnérabilités propres à PoW

La seule vulnérabilité spécifique à la PoW est l’attaque minière égoïste (Selfish Mining Attack). Dans le cadre de celle-ci, les mineurs normalement honnêtes sont incités à soutenir un pool attaquant et à participer, à terme, à l’exécution d’une attaque analogue à celle des “51%”.

Ce dernier, disposant d’un pourcentage significatif (en général au moins 25%, cf. infra) de la puissance totale de calcul (hashrate), commence à miner en partant du bloc le plus récent de la chaîne principale. Si le pool trouve un nouveau bloc avant le reste du réseau, alors celui-ci, au lieu de le publier et de le diffuser aux autres nœuds, va préférer le garder secret. Avec un bloc d’avance par rapport à la chaîne publique principale, le pool continue alors de miner sur sa chaîne secrète pour essayer de trouver un second bloc avant que la chaîne principale ne puisse avancer de son côté.

Si le réseau parvient à miner un bloc avant que le pool ne trouve son second bloc, l’attaquant publie alors son bloc. Les deux chaînes sont alors en compétition puisqu’elles se trouvent être de la même longueur (1 bloc). Un fork se produit ; une certaine fraction du réseau va miner la chaîne de l’attaquant tandis que l’autre va miner la chaîne principale, le pool attaquant minant bien évidemment sur sa propre chaîne. Trois cas sont alors possibles :

  1. L’attaquant découvre un autre bloc. Dans ce cas, il le publie de suite ce qui fait basculer l’ensemble du réseau sur la chaîne de l’attaquant (car c’est la chaîne la plus longue qui l’emporte). Le pool récupère ainsi deux récompenses suite à l’attaque.
  2. La fraction du réseau travaillant sur la chaîne de l’attaquant trouve un autre bloc. Ce dernier est publié de suite et par conséquent la chaîne à l’origine cachée par le pool l’emporte. Ce dernier ainsi que le réseau touche chacun une seule récompense.
  3. La fraction travaillant sur la chaîne publique principale découvre le prochain bloc. La chaîne de l’attaquant est donc abandonnée et par conséquent le pool ne touche rien, tandis que le réseau remporte les deux récompenses. L’attaque échoue mais rien n’empêche le pool de retenter sa chance ultérieurement.

Si le pool attaquant découvre son second bloc avant que le réseau ne parvienne à miner un seul nouveau bloc (ce qui est statiquement possible car il dispose d’une part significative du hashrate), la chaîne de l’attaquant affiche désormais deux blocs d’avance, que celui-ci conserve toujours secrètement. Il continue son minage et essaie de conserver cet écart de deux blocs d’avance avec la chaîne publique principale. Dès que le reste du réseau réduit l’écart à un seul bloc, le pool publie d’un seul coup l’ensemble de sa chaîne qui est alors adoptée par le reste du réseau. Ce dernier remporte donc les récompenses afférentes et rend de suite invalides les blocs minés par les nœuds honnêtes du réseau (travaillant sur la chaîne principale).

Ainsi, en ne jouant pas le jeu du mécanisme dans l’optique d’accroître ses revenus (et en sacrifiant ses revenus à court terme), un attaquant est en mesure de miner une chaîne secrète qu’il pourra publier au moment opportun pour remporter les mining rewards liées aux nouveaux blocs et réduire à néant le travail des mineurs honnêtes qui ne peuvent que constater l’annulation de leurs blocs par le système. En réitérant plusieurs fois l’opération, le pool attaquant fait donc perdre de la puissance “utile” de calcul et, in fine, des revenus au reste du réseau. Certains nœuds honnêtes se rendent alors compte qu’il est plus rentable de soutenir et de rejoindre le pool attaquant, ce qui peut amener ce dernier à rassembler finalement plus de 51% du hashrate et lui offre la possibilité de mener une attaque des 51%.

Par ailleurs, deux chercheurs de l’université américaine Cornell, Ittay Eyal et Emin Gün Sirer, ont démontré dans ce papier que cette attaque était techniquement réalisable au sein du réseau Bitcoin si le pool attaquant disposait d’un minimum de 25% de la puissance totale de calcul. Néanmoins, même si cette attaque représente toujours un risque potentiel, il semble qu’elle n’ait jamais été menée avec succès à l’encontre du réseau Bitcoin. En effet, sa probable détection annihilerait la confiance accordée au réseau par les utilisateurs, impactant lourdement la valeur des revenus illégitimement acquis par le pool attaquant. Enfin, cette attaque est inefficace envers le mécanisme PoS car celui-ci ne demande aucune puissance de calcul pour la génération de blocs.

Enfin, pour ceux qui s’intéressent aux considérations mathématiques en jeu dans le cadre de cette attaque peuvent lire ce très bon article vulgarisateur écrit par Vitalik Buterin : https://bitcoinmagazine.com/articles/selfish-mining-a-25-attack-against-the-bitcoin-network-1383578440/

Vulnérabilités propres à PoS

Les vulnérabilités spécifiques au mécanisme PoS sont les suivantes :

I - Attaque à courte portée / Attaque Bribe (Short Range Attack) : Dans le cadre de cette attaque, l’assaillant essaie de réaliser une double dépense en suivant la démarche ci-dessous :

  1. L’attaquant réalise une transaction de dépense qu’il souhaite faire annuler ultérieurement.
  2. Immédiatement après la transaction, l’attaquant commence à construire une chaîne alternative en secret, en partant du bloc antérieur à celui qui contient sa transaction de dépense.
  3. Une fois que la transaction a accumulé le nombre de confirmations nécessaires (6 par exemple), l’attaquant publie auprès d’un certain nombre de nœuds la chaîne parallèle où il a inversé sa transaction
    de dépense. Il essaie alors de corrompre ces derniers en leur payant un pot-de-vin (bribe) afin de les inciter à allouer leur stake et à minter uniquement sur cette chaîne illégitime au lieu de minter simultanément sur cette dernière et la chaîne principale dans le cas où le système est vulnérable au problème du Nothing-at-stake (car si les nœuds mintent
    à la fois sur la chaîne principale et la chaîne de l’attaquant, la seconde ne pourrait jamais rattraper la première).
  4. Une fois que la chaîne de l’attaquant est plus longue que la chaîne valide, l’attaquant la publie entièrement auprès de l’ensemble du réseau. Par conséquent, cette dernière est acceptée comme nouvelle chaîne principale et la transaction est alors inversée.

Pour que cette attaque fonctionne, il est important de noter que le montant des bribes payés doit compenser la somme des récompenses perdues par les nœuds corrompus en ne votant pas sur la chaîne principale. Elle est donc rentable tant que le montant total des pots-de-vin payés ne dépasse pas la valeur du bien acheté grâce à la transaction inversée.

II - Attaque à longue portée (Long Range Attack) : C’est à peu près le même principe que l’attaque Bribe (c’est-à-dire créer une chaîne plus longue qui réécrit le registre en faveur de l’attaquant) mais au lieu de commencer l’attaque en remontant 6 blocs en arrière, on remonte beaucoup plus loin (de 60 000 blocs par exemple). Ce type d’attaque est impossible avec la PoW qui nécessite une grande puissance de calcul mais elle est réalisable avec un système PoS qui ne nécessite pas une grande puissance de calcul. Ainsi, en partant d’un petit stake correspondant à un solde détenu dans le passé et en se déconnectant totalement du reste du réseau de nœuds, un attaquant peut se mettre à minter en secret sa propre chaîne de blocs en recopiant l’intégralité des transactions inscrites sur la chaîne principale publique (i.e. les 60 000 blocs que l’attaquant doit remonter). Ce faisant, il perçoit l’intégralité des revenus liés au minting, ce qui lui permet d’augmenter très rapidement son stake et d’accélérer le processus de minting qui est d’autant plus facile que le stake est grand. Ainsi, l’attaquant peut facilement produire beaucoup plus de blocs en comparaison avec la chaîne principale et créer une chaîne illégitime plus longue, chaîne qui est alors adoptée par l’ensemble du réseau lors de sa publication finale en un seul trait (tous les blocs de la chaîne illégitime sont publiés d’un seul coup) si aucun mécanisme de protection adéquat n’a été implémenté pour endiguer le problème de Nothing-at-Stake. En conclusion, en cas de réussite, l’attaquant parviendrait à récupérer les récompenses de minting liées à une fraction importante des blocs du registre et s’octroierait alors une portion significative de la circulating supply de la monnaie sous-jacente.

Pour ceux qui souhaitent rentrer dans les considérations techniques de cette attaque (mettant notamment en jeu la condition à respecter pour obtenir le droit de minter le prochain bloc), nous vous invitons à consulter ce lien : https://ethereum.stackexchange.com/questions/34439/how-does-the-secret-chain-catch-up-with-the-real-chain-in-the-long-range-attac

III - Attaque d’accumulation de crypto-monnaies âgées (Coin Age Accumulation Attack) : Cette attaque est spécifique à Peercoin et à d’autres systèmes utilisant l’âge des crypto-monnaies au lieu de la richesse comme mesure du droit de vote de l’utilisateur (l’âge de la crypto-monnaie correspondant au solde multiplié par le temps pendant lequel les crypto-monnaies n’ont pas été déplacées). Dans les premières versions du protocole Peercoin, l’âge des pièces n’était pas plafonné. Cela signifiait qu’en attendant suffisamment longtemps, un attaquant pouvait potentiellement accumuler assez d’âge pour dépasser effectivement le reste du réseau et devenir le nœud le plus influent au sein du mécanisme de consensus. Par exemple, dans le réseau Peercoin, un attaquant possédant 5% de la circulating supply pouvait diviser son solde en plusieurs UTXO (Unspent Transaction Outputs) et attendre que l’âge de ces derniers deviennent 10 fois plus élevé que la moyenne. Suite à cette attente, l’attaquant était ensuite en mesure de créer plusieurs blocs à la suite avec une probabilité élevée (d’où l’intérêt de diviser au préalable le stake initial en plusieurs UTXO suffisamment petits, l’âge d’un UTXO étant en effet réinitialisé à zéro lorsqu’il est “sélectionné” par l’algorithme de consensus pour minter le prochain bloc) pour effectuer une “double dépense” ou une autre transaction malveillante. Cette attaque est généralement plutôt difficile à réaliser car elle demande un investissement de départ important (pour acheter le stake initial) ainsi que de s’armer de beaucoup de patience.

Un UTXO est un output de transaction qui n’a pas encore été dépensé et qui pourra servir une seule et unique fois en tant qu’input d’une transaction ultérieure. Cette notion est développée plus en détails dans la documentation développeur Bitcoin à cette adresse : https://bitcoin.org/en/developer-guide#block-chain-overview

IV - Attaque de précalcul (Precomputing Attack) : Dans le cadre de cette attaque, on suppose que l’attaquant est le minter du bloc B(h). Si ce dernier a une puissance de calcul importante à sa disposition, il sera en mesure d’influencer la valeur du hash de B(h) en rajoutant quelques transactions supplémentaires (de lui-même à lui-même par exemple) dans le bloc. Ce faisant, l’attaquant peut également jouer sur la timestamp et vérifier en temps réel la balance des autres utilisateurs pour s’assurer qu’il sera le seul à respecter la condition de hachage permettant d’obtenir le droit de minter le bloc B(h+1). En effet, cette condition dépend plus précisément de hash(B(h)) et de la timestamp t (variables manipulables en temps réel par l’attaquant) ainsi que de l’adresse A des différents nœuds du réseau et la balance bal(A) correspondant au stake détenu par chacun d’entre eux (données a priori publiques et donc connues de l’attaquant). Ainsi, celui-ci peut s’arroger le droit de minter l’ensemble des blocs suivants et de construire une plus longue chaîne, soit pour collecter plus de transaction fees, soit pour mener une attaque de type double spending. Au sein d’un système PoW, cette attaque est pratiquement impossible à réaliser car il faut exponentiellement plus de travail pour générer un bloc B(h) avec un “bon” hash que pour générer un bloc valide (en trouvant le bon nonce). Enfin, dans un système de type DPoS, ce genre d’attaque n’est pas réalisable car le choix des délégués qui vont minter les prochains blocs de la chaîne est indépendant des caractéristiques du bloc le plus récent (ce choix se faisant uniquement grâce à un vote des détenteurs de coins).

Inégalité à vérifier pour obtenir le droit de minter B(h+1)

Sur la figure ci-dessus, on retrouve l’inégalité que le nœud attaquant essaie de vérifier en permanence avec :

  • La timestamp t en UTC
  • L’adresse A du nœud
  • Le solde bal(A) détenu par le nœud
  • La constante M correspondant à la difficulté maximum du mécanisme
  • La variable D appartenant à l’intervalle [1, M] et correspondant à la difficulté cible

Conclusion

On peut aisément conclure que le mécanisme de consensus PoS est plus enclin aux attaques que PoW ou DPoS, ce qui est dû au fait que ce dernier ne nécessite aucun facteur extérieur (comme la quantité de travail demandée pour trouver la solution au problème cryptographique du mécanisme PoW ou l’élection des delegates du mécanisme DPoS) pour pouvoir valider le prochain bloc de la chaîne.

Consommation énergétique

1 - PoW de la blockchain Bitcoin

Le minage par preuve de travail (PoW) utilisé par Bitcoin est très énergivore. La figure ci-contre présente la consommation énergétique du Bitcoin, entre le 5 mars 2018 et le 5 avril 2018.

Consommation énergétique du Bitcoin entre le 5 mars 2018 et le 5 avril 2018 (Source : digiconomist.com)

En outre, le site digiconomist.com nous donne accès à des statistiques supplémentaires quant à la consommation énergétique du système Bitcoin au 5 avril 2018 :

  • Consommation électrique annuelle actuelle de Bitcoin : 59,48 TWh
  • Revenus miniers mondiaux annualisés : 5 315 768 430 $
  • Coûts miniers estimés annualisés : 2 973 830 240 $
  • Pourcentage de coût actuel : 55,94%
  • Pays le plus proche du Bitcoin en matière de consommation d’électricité : Colombie
  • Électricité consommée par transaction : 939 KWh
  • Consommation d’électricité de Bitcoin en pourcentage de la consommation mondiale d’électricité : 0,27%
  • Empreinte carbone totale annuelle : 29,144 kT de CO2
  • Empreinte carbone par transaction : 460,16 kg de CO2

2 - PoW de la blockchain Ethereum

Ethereum permet d’économiser beaucoup plus d’énergie par rapport à la consommation d’énergie de Bitcoin. La figure ci-contre illustre la consommation énergétique d’Ethereum, entre le 5 mars 2018 et le 5 avril 2018.

Consommation énergétique d’Ethereum entre le 5 mars 2018 et le 5 avril 2018 (Source : digiconomist.com)

En outre, le site digiconomist.com nous donne accès à des statistiques supplémentaires quant à la consommation énergétique du système Ethereum au 5 avril 2018 :

  • Consommation électrique annuelle actuelle d’Ethereum : 16,98 TWh
  • Revenus miniers mondiaux annualisés : 3 434 999 436 $
  • Coûts miniers estimés annualisés : 2 037 605 019 $
  • Pourcentage de coût actuel : 59,32%
  • Pays le plus proche d’Ethereum en matière de consommation d’électricité : Cuba
  • Électricité consommée par transaction : 77 KWh
  • Consommation d’électricité d’Ethereum en pourcentage de la consommation mondiale d’électricité : 0,08%

3 - Autres mécanismes de consensus (PoS, DPoS et PoET)

À la différence du mécanisme de consensus Proof of Work qui demande aux nœuds du réseau de mobiliser une gigantesque puissance de calcul dans l’optique de valider les ajouts de blocs successifs au registre, les mécanismes Proof of Stake, Delegated Proof of Stake et Proof of Elapsed Time n’exigent pas le calcul de la moindre preuve cryptographique. En conséquence, en comparaison avec le PoW, les mécanismes PoS, DPoS et PoET induisent
une consommation énergétique quasiment nulle
.

Philosophie

Les questions philosophiques peuvent se révéler particulièrement importantes lorsqu’on en vient à devoir choisir entre tel ou tel mécanisme de consensus.

Ainsi, choisir un mécanisme de type PoW implique de mettre en place un système où la gouvernance est entièrement aux mains des mineurs qui, grâce à leur puissance de calcul, peuvent décider de soutenir une chaîne particulière, même si cette dernière ne rencontre pas le soutien des utilisateurs ou des développeurs d’une monnaie. Par exemple, en août 2017, un contingent important de mineurs du réseau Bitcoin ont décidé de faire sécession pour initier un hard fork qui a donné naissance à la blockchain Bitcoin Cash (BCH) et ceci malgré l’opposition de la totalité des développeurs Bitcoin et d’une grande part des possesseurs de wallets BTC. En conséquence, on constate bel et bien que dans un système fonctionnant en PoW, le réseau est entièrement tributaire du bon vouloir des mineurs qui peuvent décider de soutenir une chaîne particulière afin de maximiser leur profit même si cela va à l’encontre de l’intérêt général ou de l’avis de la communauté.

Un système de type PoW se révèle donc problématique du point de vue de la gouvernance, car celle-ci se retrouve centralisée dans les mains de quelques individus seulement. Le mécanisme PoS vise à mettre fin à cette oligarchie et tend à rendre le pouvoir aux utilisateurs de la plateforme, c’est-à-dire aux détenteurs de monnaie sous-jacente à celle-ci. Ainsi, plus un utilisateur possède d’unités de cette dernière et plus il est en mesure d’exercer un certain pouvoir au sein de ladite plateforme (puisque l’algorithme lui attribuera plus de blocs à valider que les autres détenteurs). Cette forme de démocratie directe rend le pouvoir aux premiers intéressés d’une plateforme mais elle a le défaut d’avantager les plus riches utilisateurs qui pourront valider plus de blocs que les autres et donc toucher plus d’intérêts, devenant ainsi encore plus riche. En conséquence, on peut dire que la gouvernance est une nouvelle fois centralisée, mais cette fois-ci aux mains des utilisateurs les plus aisés dans le cadre d’une ploutocratie.

C’est pour cette raison que le mécanisme de consensus DPoS a été développé afin d’aller encore plus loin dans cette idée de décentralisation de la gouvernance et de séparation des pouvoirs. En effet, DPoS met en place une démocratie participative au sein de laquelle les utilisateurs de la plateforme vont voter (avec un droit de vote proportionnel à leur taux de détention de la circulating supply) pour des représentants qui seront chargés de valider les blocs et auront le pouvoir de modifier certains paramètres de la blockchain. Une forme de séparation des pouvoirs s’opère donc, ce qui va dans le sens d’une décentralisation totale de la gouvernance. Par ailleurs, on peut remarquer que les détenteurs de monnaie ne sont pas rémunérés par le biais d’intérêts comme dans le mécanisme PoS, ce qui permet d’éviter que les riches deviennent encore plus riches.

Enfin, le mécanisme de consensus PoET implémente un principe d’équité absolu entre les différents nœuds de validation du réseau, ces derniers ayant tous la même probabilité d’être sélectionné afin de valider le prochain bloc. Il a malheureusement le désavantage de requérir un matériel spécialisé et propriétaire (compatible SGX par exemple, cf. supra), ce qui constitue un frein pour atteindre une décentralisation réelle.

Synthèse et conclusion

Dans le tableau ci-dessous est présentée une comparaison synthétique des mécanismes de consensus abordés tout au long de cet article. Cette comparaison a été faite sur la base de l’ensemble des enjeux liés auxdits mécanismes que nous avons progressivement traités : type de blockchain, consommation énergétique, niveau de sécurité, niveau de décentralisation, débit de transaction, scalabilité, etc.

Tableau comparatif des principaux mécanismes de consensus

Les mécanismes de consensus utilisés aujourd’hui par les principales plateformes blockchains dépendent très largement des spécificités des applications pour lesquelles ils ont été conçus et des menaces qu’ils doivent endiguer pour garantir l’intégrité du registre. Généralement, les blockchains publiques (permissionless) parviennent à un consensus robuste parmi un très grand nombre de nœuds non fiables en jouant sur la complexité de participation au consensus (calculs poussés, mémoire importante, financement initial) tout en sacrifiant la consistance du mécanisme (c’est-à-dire l’unicité permanente de la chaîne de blocs et des transactions afférentes entre les différents nœuds du réseau) ainsi que le débit de transaction. De leur côté, les blockchains privées (permissioned) opteront pour un mécanisme de consensus moins adaptable à grande échelle mais dont le débit de transaction est plus important et dont la finalité de transaction est quasi instantanée.

En conclusion, lorsque l’on envisage de déployer une solution de type blockchain dans l’optique de résoudre un problème concret (application business, cas d’usage précis), il est impératif de prendre en compte certaines considérations, à la fois fonctionnelles et non fonctionnelles, avant de pouvoir s’assurer de la pertinence d’un mécanisme de consensus particulier :

  • Nature publique (permissionless) ou privée (permissioned) de la plateforme souhaitée
  • Objectifs de performance (débit de transaction notamment)
  • Limite de consommation énergétique
  • Exigences en matière de scalabilité et de taille du réseau de nœuds (mineurs, minteurs, replica nodes)
  • Relations souhaitées entre les différents acteurs : utilisateurs, nœuds de validation et développeurs
  • Niveau de décentralisation et “philosophie” réclamée par le commanditaire ou la communauté des utilisateurs
  • Niveau de sécurité et de tolérance aux fautes
  • etc.

--

--