L'algorithm de consensus Tendermint

Introduction

L'algorithm de consensus byzantin (BCA) utilisé par Tendermint est un algorithme de consensus basé sur une solution existante du problème des généraux byzantins (BGT). Il ne nécessite pas de preuve de travail (PoW), il est donc plus efficace en termes de consommation d'énergie, et plus rapide car il ne nécessite pas de temps de blocage. Il peut assurer un fonctionnement sûr du réseau s’il y a au moins 2/3+ (strictement plus des deux tiers) de participants « honnêtes » au réseau.

Vocabulaire

• Validators
  Premièrement les validators, et ce sont les participants qui font fonctionner le réseau.

  Contrairement à la PoW ou à la PoS, où n'importe qui peut devenir mineur à tout moment, au sein de la BCA, seuls les validateurs peuvent participer à la formation de la blockchain.

• Round
  Un tour dans le processus de consensus est appelé un round. Chaque round est composé de trois étapes: Propose, Prevote et Precommit.

• Proposer
  Un proposer est un validateur qui a le droit de proposer un bloc pour le round en cours. Le proposer est choisi en utilisant un algorithme de rotation de round-robin.

Aperçu du consensus

Durant la recherche du N-ème block, le processus suit les étapes suivantes.

NewHeight -> (Propose -> Prevote -> Precommit)+ -> Commit -> NewHeight ->…

1. Propose

   • Un validateur est choisi pour proposer un bloc pour le round en cours.
   • La proposition est diffusée aux restes des nœuds.

2. Prevote

   • Chaque validateur vérifie la validité de la proposition.
   • Si la proposition est valide, le validateur vote pour elle en envoyant un message prevote au reste des nœuds.
   • Si la proposition est invalide, le validateur n'accepte pas la proposition et envoie un message prevote nil au reste des nœuds.

3. Precommit

   • Chaque nœud qui recevra 2/3+ des prevotes pour la même proposition, enverra un message precommit pour cette proposition, sinon il enverra un message precommit nil.
   • Pour chaque nœud, si il recoit +2/3 des precommits pour la même proposition, alors le bloc est considéré comme validé, donc le processus continue avec la phase commit.
   • Sinon, le processus continue avec un nouveau round newRound.

4. Commit

   • Il existe deux conditions pour finaliser le round.
     1. Le nœud doit recevoir le bloc validé par le réseau. Une fois reçu, il signe et diffuse un commit pour ce bloc.
     2. Le nœud doit attends jusqu'à ce qu'il reçoive +2/3 des commit pour le même bloc.

Une fois les deux conditions satisfaites, le nœud définit son CommitTime et passe vers l'étape NewHeight

1. NewHeight
   • Le but de cette étape NewHeight est de rassembler des commits supplémentaires pour le bloc validé au round précédent.
   • Les nœuds restent à cette étape jusqu'à une durée fixe après le commit.
   • Laissant le temps aux validateurs plus lents de recevoir le bloc validé et de signer le commit.
   • Cela permet aux propositions de blocs d'inclure plus que les 2/3 minimum des commits.

Les locks

Si il y a -1/3 des validateurs qui sont malveillants, l'algorithm peut garantir la sécurité du réseaux. C'est-à-dire que les validateurs ne valideront jamais de blocs conflictuels à la même hauteur.

Pour assurer cela, l'algorithm introduit des régles de verrouillage lock.

• Si le validateur avait reçu plus des 2/3 des precommit pour un block donné, il se verrouille sur ce block et libère tous les verrous précédents.
• Un nœud ne peut avoir qu'un seul verrou à la fois.
• Si le nœud avait reçu plus des 2/3 des prevotes nil, il se déverrouille simplement.
• Lors du verrouillage (ou du déverrouillage), le nœud rassemble les prevotes pour le bloc verrouillé (ou les prevotes nil) et les regroupe dans une preuve de verrouillage pour plus tard quand ce sera son tour de proposer.
• Si un nœud n'avait pas reçu plus de 2/3 des prevotes pour un bloc donné, alors il ne verrouille rien.

Sources

• Tendermint: Consensus without Mining

• Medium