Quel consensus dans une blockchain privée ?
Un consensus est un procédure qui consiste à dégager un accord sans procéder à un vote formel. Contrairement à Raft et Paxos (la version non byzantine), les consensus suivants permettent de gérer les noeuds malveillants dans des réseaux distribués sans confiance.
Ethereum est une blockchain publique, donc qui n’intègre pas de gestion des autorisations. Elle définit en effet un réseau où les acteurs ne se connaissent pas et utilise un consensus qui est adapté à cet environnement. Celui-ci est la preuve de travail, ou “Proof of Work”, qui permet de choisir un mineur de façon non-prédictible et de rendre la fraude très chère à mettre en oeuvre.
Les blockchains privées ou de consortium ont des modèles très différents car les noeuds sont connus et représentent des entités, d’autres consensus sont donc plus adaptés que la preuve de travail énergivore et lente des blockchains publiques :
- Preuve d'autorité (PoA)
- Tolérance aux fautes Byzantines en pratique (PBFT)
- Délégation de preuve de possession (DPOS) (aussi applicable aux blockchains publiques)
Preuve d'autorité
La preuve d’autorité consiste seulement en l’autorisation de un ou plusieurs noeuds à ajouter les blocs dans la blockchain. Dans ce cas, la décentralisation de l’ajout de blocs est mise de côté, c’est plutôt la vérification de l'exécution et l’auditabilité des données dans la blockchain qui est intéressante.
Tolérance aux fautes Byzantines en pratique
Le problème des généraux byzantins est une métaphore qui traite de remise en cause de la fiabilité des transmissions et
Une faute byzantine est donc un défaillance qui consiste en la présentation d’informations erronées ou incohérentes.
Le consensus “Practical Bizantine Fault Tolerance” (PBFT) est un protocole de réplication de machines à états qui tolère les fautes arbitraires, ou “byzantines”.
Alors que les travaux précédents concernant les protocoles de tolérance aux fautes Byzantines étaient théoriques et ne comportaient que peu d’implémentations, ce papier blanc écrit par Castro et Liskov en 1999 est, comme son nom l’indique, réalisable.
Il est résistant aux fautes, rapide, vivace et une attaque n’impacte pas trop ses performances. Ce protocole est constitué de trois phase : pre-préparation, préparation & validation, il requiert 3f+1 répliques pour tolérer f fautes byzantines simultanées.
Bref descriptif du protocole
Un client soumet une requête au réplica principal, les autres répliques vont ensuite procéder aux trois phases pour se mettre d’accord sur la validation de cette requête.
Chaque phase requiert un quorum de signature pour passer à la phase suivante et les requêtes sont donc toutes exécutés dans le même ordre par toutes les répliques.
Chaque exécution du protocole constitue une vue, qui représente une configuration du système à un moment donné.
Lorsque le réplica principal est malicieux et va par exemple tenter d’envoyer un message de validation prématuré, les différentes répliques vont êtres dans un état inconsistant et ne vont pas valider la requête. Le client renvoie donc sa requête initiale avec une demande de changement de vue qui entraîne un changement de réplica principal. Le replica malicieux est mis de côté.
Quand une requête est approuvé dans ce protocole, on ne peut retourner à l’état précédent, comme dans la preuve de travail ou le DPOS. Dans ces derniers, une requête est validée par son ancienneté dans la blockchain.
Ce protocole est très performant et peut exécuter près de 1000 transactions par seconde. Néanmoins celles-ci baissent considérablement pour un nombre de noeuds supérieur à 30 car chacun des noeuds doit envoyer et recevoir les messages de tous les noeuds du réseau.
Enfin l’ajout de nouveaux noeuds dans le réseau est compliqué à mettre en place. Ces deux points limitent l’utilisation de ce consensus à des réseaux restreints.
Délégation de preuve de possession
Le consensus de délégation de preuve de possession (Delegated Proof of Stake, ou DPoS) a été pensé comme successeur au consensus de preuve de possession (Proof of Stake, ou PoS).
Il existe de nombreuses versions différentes, nous allons ici parler de l’implémentation de BitShares, une blockchain publique qui fut la première à l’utiliser.
Dans la preuve de possession, tout compte qui contient des jetons peut participer dans le processus de validation des transactions et recevoir des jetons en retour. Plus le compte contient de jetons, plus il aura de chance d’être choisi pour valider le prochain bloc. En effet, pourquoi voudrait-il tricher si il a un grand capital ?
La différence entre un PoS et un DPoS peut être comparé à une démocratie directe versus une démocratie représentative.
La preuve de possession était également pensée comme successeur au consensus de preuve de travail utilisé dans Bitcoin, beaucoup critiquée pour sa re-centralisation avec les fermes de minages et le nombre restreint de fabricant d’ASICs ainsi que son gaspillage énergétique.
Le consensus DPoS utilise un système de réputation, on élit grâce au vote un groupe limité de personnes de confiance. Seul ce groupe de personnes a le droit d’inscrire des blocs et ce chacun leur tour, dans un ordre aléatoire.
Tous les possesseurs de jetons peuvent voter, les votes sont pondérés par le nombre de jetons que possède le votant, il a une influence correspondant à son capital car cela le crédibilise.
Si le comportement d’un délégué est jugé suspect (il n’intègre pas toutes les transactions qu’il reçoit ou transmet des blocs non-valides), il peut être éjecté de cette liste par les votants. Les délégués touchent une récompense pour leur travail, ils ne cherchent donc pas à être exclu de cette liste et peuvent même baisser leur salaire pour rester dans cette liste.
Si un délégué ne produit pas le bloc dans le temps qui lui est imparti, le prochain délégué produira donc un plus grand bloc avec les nouvelles transactions reçues.
Le consensus DPoS peut gérer un grand nombre de noeuds, car à chaque fois qu’un nouveau bloc est créé, un validateur
Si le vote en lui-même est très rapide, il fonctionne sur le même principe que la preuve de travail, avec la branche la plus longue qui est “gagnante”, donc en ajoutant les délais de propagation du au réseau, on revient à une performance plus modeste.
Le temps d’attente entre chaque bloc est donc augmenté dans le but de sécuriser le réseau : dans BitShare, le temps de validation est de 3 secondes en moyenne. On constate néanmoins qu’avec ce consensus il y un un couplage fort avec la monnaie intrinsèque au réseau (comme la preuve de travail), ce qui n’est pas toujours nécessaire dans une blockchain privée ou de consortium.
Conclusion
Les trois consensus cités ci-dessus ont tous été utilisés et existent dans des implémentations différentes.
En résumé :
- Avec la preuve d’autorité, on fait confiance à une entité qui se place en tier de confiance.
- Le consensus PBFT a fait ses preuves et est le plus efficace dans des réseaux de moins de 30 noeuds. Il a d’ailleurs été amélioré dans de nouvelles versions.
- Le consensus DPOS est moins performant que les deux précédent mais peut s’utiliser dans des grands réseaux. A cause de sa jeunesse, on constate que son implémentation est différente sur les différentes blockchains l’utilisant.
Aujourd’hui, dans les blockchains publiques existantes (notamment Ethereum), quel que soit le consensus choisi, tous les noeuds doivent exécuter toutes les transactions incluses dans chaque bloc, ce qui relativise la vitesse supposée de ces consensus.
Pour Ethereum, son hypothétique sharding résoudra on l’espère cette limite !