TELECOM PARIS ALUMNI
Retour aux actualités
Article suivant Article précédent

Revue TELECOM 190 - Qu'est-ce qu'un "mécanisme de consensus", pilier de la sécurité d'une blockchain ?

Articles Revue TELECOM

-

01/10/2018

QU'EST-CE QU'UN "MÉCANISME DE CONSENSUS", PILIER DE LA SÉCURITÉ D'UNE BLOCKCHAIN ?


Par Jihane Harazi (2018) et Godefroy Galas (2017) dans la revue TELECOM n° 190


Plongée dans les coulisses de la blockchain et zoom sur le concept de consensus. Ce mécanisme clé, opérant au cœur du mode de gouvernance d'un registre distribué,est indispensable à l’établissement d’une confiance durable envers les données stockées sur ce dernier.


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.


Blockchains publiques et blockchains privées

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, 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 Distributed Denial of Service. Initialement, ce problème a été résolu par les toutes premières plateformes blockchain en exigeant des nœuds qu’ils fournissent la preuve d’un travail difficilement réalisable mais facilement vérifiable : la Proof of Work (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.

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. 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).

Qu’elles soient publiques ou privées, les plateformes blockchain 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 d’une blockchain publique, il n’est absolument pas adapté aux applications qui nécessitent, 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 ont été imaginés et développés : Proof of Stake, Delegated Proof of Stake, Proof of Elapsed Time, etc.


Objectif d’un mécanisme 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, il s’agit du processus clé qui permet à un réseau décentralisé partageant un historique commun de se mettre d’accord sur la validité et sur l’ordre des transactions à rajouter au dit historique, par l’ajout successif de nouveaux blocs.

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 : Certain 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 maximums.

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 " 51% attack ".

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

Parvenir à un consensus au sein d’un réseau de nœuds distribués ne semble donc 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 trois 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 (Fault Tolerance) : 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 décentralisée.

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 à faire face aux fautes "fail-stop" où un nœud ne répond plus à la suite d’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.

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 (safety). 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 coexister 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 vers 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 à la suite du 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. Les clients devront donc 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.


1/ L’attaquant contourne 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.

2/ 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é.
3/ 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 ALLER PLUS LOIN


Cet article constitue l’introduction d’un travail complet d’analyse et de comparaison des principaux mécanismes de consensus existants : Proof of Work (PoW), Proof of Stake (PoS), Delegated Proof of Stake (DPoS), etc. Pour ceux qui souhaiteraient approfondir le sujet, notre article complet est disponible sur la plateforme Medium à l’adresse suivante :

 https://bit.ly/2IoCHio




Biographie des auteurs


Jihane Harazi (2018) est ingénieur d’état diplômée de l’École nationale des sciences appliquées de Tétouan en Génie des Systèmes de Télécommunications et Réseaux. Passionnée par le domaine de la sécurité des systèmes d’information, elle a choisi de poursuivre ses études au sein du Mastère Spécialisé Cybersécurité et Cyberdéfense de Télécom ParisTech.




Godefroy Galas (2017) est élève-ingénieur en cybersécurité à Télécom ParisTech et étudiant au sein du programme Grande École d’HEC Paris. Conscient de la nécessité de sensibiliser le grand public aux multiples enjeux de la révolution numérique, il s’efforce d’en étudier tous les aspects, qu’ils soient économiques, sociétaux, juridiques, organisationnels ou politiques.



798 vues Visites

J'aime

Commentaires0

Veuillez vous connecter pour lire ou ajouter un commentaire

Articles suggérés

Articles Revue TELECOM

Revue TELECOM 194 - Editorial Laura Peytavin et Yves Poilane

User profile picture

Rédaction Revue TELECOM

13 novembre

Articles Revue TELECOM

Revue TELECOM 194 - Sevenhugs

User profile picture

Rédaction Revue TELECOM

12 novembre

Articles Revue TELECOM

Revue TELECOM 194 - Bye Bye Barrault

User profile picture

Rédaction Revue TELECOM

12 novembre