Analyse approfondie de Usual Money : méfiez-vous des investisseurs détaillants et des pots de miel de liquidité, période de verrouillage de 4 ans à USD0++

Le meilleur mécanisme de consensus est toujours celui qui répond aux besoins des utilisateurs.

Orateur : Uchiha Madara

Éditeur : Pâte à choux

Source : Deschool

Cet article est une note de cours pour la troisième leçon du tutoriel universitaire Web3 de DeSchool, présenté par Uchiha Obito. Le contenu est très condensé et sans ajout inutile, je vous recommande de le sauvegarder pour une digestion lente. De plus, pour faciliter la compréhension, cet article a été légèrement modifié et complété par rapport au contenu du cours.

Le contenu principal de l’article comprend :

1. Introduction à l’algorithme de consensus

2. Algorithme de consensus classification

3. Algorithme de consensus détaillé ( PoW, PoS, PoH, PoA, PBFT, etc.)

01 Mécanisme de consensus简介

Dans l’échange et l’apprentissage sur la blockchain, le terme « Algorithme de consensus » est souvent mentionné, c’est grâce à l’existence de l’algorithme de consensus que la crédibilité de la blockchain peut être garantie.

1. Pourquoi avons-nous besoin d’un mécanisme de consensus ?

Le consensus désigne l’idée d’un accord atteint par plusieurs personnes. Nos vies sont remplies de mécanismes de consensus, par exemple, lorsqu’une entreprise doit prendre une décision, les actionnaires doivent en discuter collectivement, et pour signer un contrat, les parties A et B doivent se rencontrer pour négocier. Ce processus est celui de l’atteinte du consensus.

Dans un système de blockchain, chaque Nœud doit s’assurer que son livre de comptes est en accord avec celui des autres Nœuds. Dans un scénario centralisé traditionnel, cela n’est presque pas un problème, car il existe un serveur central, appelé la base principale, et les autres bases secondaires s’alignent sur la base principale.

Cependant, dans la gestion décentralisée, il n’y a pas de chef, alors comment prendre des décisions ? À ce moment-là, un algorithme est nécessaire pour garantir l’atteinte du consensus. C’est ce dont nous allons parler dans cet article : le mécanisme de consensus.

2. Qu’est-ce que le mécanisme de consensus ?

Le mécanisme de consensus est la validation et la confirmation des transactions effectuées en très peu de temps grâce au vote de nœuds spéciaux ; pour une transaction, si plusieurs nœuds dont les intérêts ne sont pas liés peuvent parvenir à un consensus, nous pouvons considérer que l’ensemble du réseau peut également parvenir à un consensus.

Bien que le consensus (Consensus) et la cohérence (Consistency) soient considérés comme équivalents dans de nombreux scénarios d’application, il existe des différences subtiles dans leur signification : la recherche sur le consensus se concentre sur le processus d’accord entre les nœuds distribués et ses algorithmes, tandis que la recherche sur la cohérence se concentre sur l’état stable atteint à la fin du processus de consensus des nœuds ; de plus, la recherche traditionnelle sur la cohérence distribuée ne prend généralement pas en compte les problèmes de tolérance aux fautes byzantines, c’est-à-dire qu’elle suppose qu’il n’existe pas de nœuds byzantins malveillants qui falsifient ou fabriquent des données. Après tout, dans un réseau blockchain entièrement ouvert et transparent, il est impossible de garantir que tous les nœuds ne commettent pas d’actes malveillants.

3. Mécanisme de consensus peut résoudre quels problèmes ?

Le mécanisme de consensus peut résoudre les problèmes de confiance dans les systèmes distribués, garantissant la cohérence et la sécurité des données entre les nœuds. Dans les systèmes distribués traditionnels, en raison de l’absence de mécanisme de confiance entre les nœuds, ils sont vulnérables aux attaques et aux manipulations de nœuds malveillants, ce qui peut entraîner l’effondrement du système ou la falsification des données. De plus, avant l’émergence de la technologie de chiffrement blockchain, la monnaie numérique, comme d’autres actifs, avait une capacité de reproduction infinie, et sans un organisme médiateur centralisé, les gens n’avaient aucun moyen de confirmer si une monnaie numérique avait déjà été dépensée.

En termes simples, le mécanisme de consensus peut résoudre efficacement deux problèmes : le double dépense (une somme d’argent dépensée deux fois) et la Faute byzantine (des nœuds malveillants altérant les données).

4. double dépense (Double spend attack)

Le mécanisme de consensus peut résoudre dans une certaine mesure le problème de la double dépense (double spend attack) : c’est-à-dire qu’un montant d’argent est dépensé deux fois ou plus, également appelé « double paiement ». Dans le jeu du chat et de la souris, petit Lizi a effectué un acte de double dépense en utilisant des chèques falsifiés, car la vérification des chèques prend du temps, donc pendant cet intervalle, il a utilisé plusieurs fois les informations du même chèque pour acheter des articles.

Comme tout le monde le sait, les nœuds de la blockchain considèrent toujours la chaîne la plus longue comme la chaîne correcte et continuent à travailler et à l’allonger. Si deux nœuds diffusent simultanément des versions différentes d’un nouveau bloc, ils travailleront sur le bloc reçu en premier, mais conserveront également l’autre chaîne au cas où cette dernière deviendrait la chaîne la plus longue. Lorsque le prochain PoW est découvert et qu’une des chaînes est confirmée comme étant la plus longue, les nœuds travaillant sur l’autre chaîne de branchement changeront de camp.

Comment le double dépensé est-il réalisé ? Il y a deux cas :

(1) Double dépense avant confirmation. Les transactions à zéro confirmation peuvent ne pas être finalement inscrites dans la blockchain. Sauf pour de petites sommes, il est préférable d’attendre au moins une confirmation pour éviter ce type de double dépense.

(2) Double dépense après confirmation. Cela nécessite de contrôler plus de 50% de la puissance de calcul pour être mis en œuvre. C’est similaire à un petit fork, mettant une transaction d’un magasin dans un bloc isolé. Cette double dépense après confirmation est très difficile à mettre en œuvre, elle n’est théoriquement possible que.

Les trois types d’attaques de double dépense les plus courants sont : l’attaque à 51 %, l’attaque de course (Race Attack) et l’attaque de Finney (Finney Attack).

Attaque à 51 % : une attaque à 51 % se produit lorsqu’une personne ou un groupe obtient le contrôle de 51 % de la puissance de hachage d’une Blockchain, ce qui signifie qu’ils ont la capacité de contrôler certains aspects du projet. Sur une Blockchain en preuve de travail (PoW) comme Bitcoin, cela se réalise en prenant le contrôle de la capacité de minage du réseau. En revanche, pour une Blockchain en preuve d’enjeu comme Cardano, cela se fait en contrôlant 51 % des jetons de mise.

Attaque par compétition : un utilisateur envoie simultanément deux transactions à deux commerçants (ou à un commerçant et à lui-même). Ainsi, l’attaquant reçoit deux ensembles de marchandises ou reçoit des marchandises tout en récupérant le coût de transaction initial.

Attaque de Finney : un mineur extrait un ou une série de blocs, contenant des transactions où il transfère de l’argent à d’autres adresses lui appartenant. Les blocs minés ne sont pas publiés, mais sont conservés pendant que le mineur effectue un transfert au commerçant. Ensuite, le commerçant libère les biens payés par le mineur avant que le mineur ne publie les blocs qu’il a extraits. Par la suite, le mineur publie les blocs extraits, ce qui annule la transaction vers le commerçant, laissant ce dernier payer de sa poche.

Attaque par double dépense classique :

En 2018, un attaquant a contrôlé plus de 51% de la puissance de calcul sur le réseau BTG. Pendant cette période de contrôle, il a envoyé une certaine quantité de BTG à son portefeuille sur la plateforme d’échange, cette branche a été nommée branche A. En même temps, il a envoyé ces BTG à un autre portefeuille qu’il contrôlait, cette branche a été nommée branche B. Une fois que les transactions sur la branche A ont été confirmées, l’attaquant a immédiatement vendu les BTG pour obtenir des liquidités. Par la suite, l’attaquant a miné sur la branche B et, ayant contrôlé plus de 51% de la puissance de calcul, la longueur de la branche B a rapidement dépassé celle de la branche A, faisant de la branche B la chaîne principale. Les transactions sur la branche A ont été annulées et restaurées à l’état précédent. Les BTG que l’attaquant avait échangés contre des liquidités sont ainsi revenus entre ses mains, représentant une perte pour la plateforme d’échange. Ainsi, l’attaquant a réalisé un « double dépense » en utilisant plus de 50% de la puissance de calcul.

5. Faute byzantine (Byzantine failures)

Le problème des généraux byzantins est un problème hypothétique proposé par Leslie Lamport dans les années 1980. Byzance était la capitale de l’Empire romain d’Orient, et en raison de l’immensité du territoire de l’Empire romain d’Orient à l’époque, les garnisons de chaque armée étaient très éloignées les unes des autres, et les généraux ne pouvaient communiquer que par l’intermédiaire de messagers. En cas de guerre, les généraux devaient établir un plan d’action unifié.

Cependant, parmi ces généraux, il y a des traîtres, et les traîtres souhaitent nuire au plan d’action unifié en influençant son élaboration et sa diffusion, afin de déstabiliser l’action conjointe des généraux loyaux. Par conséquent, les généraux doivent avoir un protocole de méthode prédéfinie, de sorte que tous les généraux loyaux puissent parvenir à un consensus. De plus, quelques traîtres ne peuvent pas amener les généraux loyaux à élaborer de mauvais plans. En d’autres termes, l’essence du Faute byzantine est de trouver un moyen permettant aux généraux d’établir un consensus sur le plan de bataille dans un environnement non fiable avec des traîtres.

Dans un système distribué, en particulier dans un environnement de réseau blockchain, il est similaire à l’environnement des généraux byzantins, avec des serveurs fonctionnant normalement (semblables à des généraux byzantins loyaux), ainsi que des serveurs défaillants et des serveurs malveillants (semblables à des généraux byzantins traîtres). Le cœur de l’algorithme de consensus est de former un consensus sur l’état du réseau entre les nœuds normaux. Si seulement 3 nœuds sont présents, le problème des généraux byzantins est insoluble. Lorsque le nombre de nœuds problématiques est x et que le nombre total de nœuds est inférieur à 3x+1, le problème des généraux byzantins est insoluble.

L’apparition du Bitcoin a facilement résolu ce problème, en ajoutant un coût à l’envoi d’informations, en réduisant la vitesse de transmission des informations, et en intégrant un élément aléatoire qui permet à un seul général de diffuser des informations à un moment donné. Le premier général à diffuser des informations est celui qui découvre le premier une valeur de hash valide, tant que les autres généraux reçoivent et vérifient cette valeur de hash valide et les informations qui y sont attachées, ils ne peuvent qu’utiliser les nouvelles informations pour mettre à jour leur copie du grand livre, puis recalculer la valeur de hash. Le prochain général à calculer une valeur de hash valide peut alors attacher ses informations mises à jour à cette valeur de hash valide et les diffuser à tout le monde. La compétition de calcul de hash recommence alors à partir d’un nouveau point de départ. Grâce à la synchronisation continue des informations sur le réseau, tous les ordinateurs du réseau utilisent la même version du grand livre.

02 Algorithme de consensus Classification

1. Mécanisme de consensus de l’histoire

Lorsque les ordinateurs et les réseaux ont commencé à se populariser dans les années 1980 et 1990, des bases de données partagées ont vu le jour, permettant à plusieurs utilisateurs d’accéder aux informations qu’ils y stockaient. La plupart avaient une base de données centrale, à laquelle les utilisateurs pouvaient accéder depuis différents sites. Cette configuration a évolué vers des réseaux centralisés, où les administrateurs accordent des permissions aux utilisateurs et maintiennent l’intégrité des données.

Ces bases de données partagées sont appelées Distributed Ledger, car elles enregistrent des informations et sont connectées pour permettre l’accès à de nombreux utilisateurs à partir de différents emplacements. L’un des problèmes les plus importants à résoudre est d’empêcher la falsification des données et l’accès non autorisé, qu’il soit malveillant ou non. Une méthode de gestion automatisée des bases de données distribuées est nécessaire pour garantir que les données ne soient pas modifiées.

Cette demande a conduit à la création d’un consensus autonome distribué, où les programmes sur le réseau utilisent des techniques de chiffrement pour parvenir à un accord sur l’état de la base de données. Le protocole vise à atteindre cet accord en utilisant un algorithme de chiffrement pour créer une longue chaîne de caractères alphanumériques (hash), qui est ensuite vérifiée par les programmes exécutés sur le réseau. Le hash ne changera que si les informations entrées dans l’algorithme de hachage changent, c’est pourquoi les programmes sont conçus pour comparer les hashes afin de garantir qu’ils correspondent.

Lorsque chaque programme fonctionnant sur le réseau crée une chaîne de hachage correspondante, on peut dire que les données ont atteint un consensus sur le réseau. Ainsi, un mécanisme de consensus a été établi, généralement attribuant le crédit au créateur anonyme de Bitcoin, Satoshi Nakamoto. Cependant, avant que Satoshi ne publie le livre blanc qui a rendu Bitcoin célèbre, de nombreuses personnes avaient travaillé sur des mécanismes de consensus pendant des années.

Moni Naor, Cynthia Dwork, Adam Beck, Nick Szabo et d’autres scientifiques des données et de l’informatique ont travaillé au développement et à la contribution aux mécanismes de consensus du réseau.

2 Algorithme de consensus de classification

Selon le type de tolérance aux fautes, les algorithmes de consensus peuvent être divisés en deux grandes catégories : les algorithmes de consensus CFT (tolérance aux fautes non byzantines, c’est-à-dire ne tenant pas compte des nœuds malveillants) et les algorithmes de consensus BFT (tolérance aux fautes byzantines, c’est-à-dire tenant compte des nœuds malveillants).

La tolérance aux fautes byzantines indique si l’algorithme peut être appliqué à des réseaux à faible confiance. En général, dans un environnement de chaîne publique, il est nécessaire d’utiliser des algorithmes de tolérance aux fautes byzantines, tandis que dans une chaîne d’alliance, le choix peut être fait en fonction du niveau de confiance entre les participants de l’alliance, un niveau de confiance élevé permettant d’utiliser des algorithmes de type CFT (non tolérance aux fautes byzantines).

De plus, on peut les classer en deux grandes catégories selon la cohérence : algorithmes de cohérence probabiliste et algorithmes de cohérence absolue. Les algorithmes de cohérence probabiliste désignent ceux qui garantissent avec une probabilité élevée que les données entre les différents nœuds distribués soient cohérentes, mais il existe toujours une certaine probabilité que des données soient incohérentes entre certains nœuds. Par exemple, l’algorithme de travail en preuve (Proof of Work, PoW), l’algorithme de preuve d’enjeu (Proof of Stake, PoS) et l’algorithme de preuve d’enjeu déléguée (Delegated Proof of Stake, DPoS) relèvent tous des algorithmes de cohérence probabiliste.

L’algorithme de cohérence absolue fait référence à la situation où, à tout moment, les données entre différents nœuds distribués restent absolument cohérentes, sans aucune incohérence entre les données des différents nœuds. Par exemple, l’algorithme PAXOS et son dérivé, l’algorithme RAFT.

Le texte suivant est divisé et présenté en fonction des types de tolérance aux pannes.

3 Algorithmes de consensus de type CFT

Tolérance aux pannes de crash Non-Bitcoin : pour des réseaux avec un haut niveau de confiance dans les nœuds. Comprend Paxos, Raft.

4 Algorithme de consensus BFT

Vérifier si le Nœud présente une tendance aux erreurs byzantines malveillantes dans une structure décentralisée, y compris le PoW, l’attestation, le DPoS, le proof of authority, etc.

03 Algorithme de consensus détaillé

Vous commencez à être un peu fatigué en lisant cela ? Ajoutez-le à vos favoris, reposez-vous un moment et revenez à la partie la plus hardcore de cet article ! Les étudiants pressés peuvent commencer directement à partir du troisième algorithme PoW.

1 Algorithme Paxos

• Introduction de l’algorithme : En 1990, l’algorithme Paxos est un algorithme de consensus distribué basé sur l’échange de messages, proposé par le maître Lamport, et a reçu le prix Turing en 2013. Depuis la naissance de Paxos, il a continué à dominer les algorithmes de consensus distribués, résolvant principalement comment parvenir à un consensus sur une valeur particulière dans les systèmes distribués. Le processus de consensus de l’algorithme Paxos consiste à ce que le Proposer présente une proposition pour obtenir le soutien de la majorité des Accepteurs. Lorsqu’une proposition obtient le soutien de plus de la moitié, le résultat de la conclusion est envoyé à tous les nœuds pour confirmation. Dans ce processus, si le Proposer subit une panne, il peut être résolu en déclenchant un mécanisme de délai. Si à chaque nouvelle proposition, le Proposer tombe en panne, alors le système ne parviendra jamais à un consensus. Mais cette probabilité est extrêmement faible.

Le protocole Basic Paxos initial était complexe et relativement peu efficace, c’est pourquoi des versions améliorées de Paxos ont été proposées par la suite. Par exemple : Fast Paxos, Multi-Paxos et Byzantine Paxos, etc.

• Cas d’utilisation : ZooKeeper
• Principe de l’algorithme : L’algorithme Paxos fonctionne dans des systèmes asynchrones autorisant des pannes, sans exiger de transmission de messages fiable, et peut tolérer la perte, la latence, le désordre et la répétition des messages. Il utilise un mécanisme de majorité (Majority) pour garantir une tolérance aux pannes de 2f+1, c’est-à-dire qu’un système de 2f+1 nœuds peut tolérer jusqu’à f nœuds en panne simultanément. Tant qu’il y a moins de (n-1)/2 échecs, Paxos atteint le consensus. Ces échecs ne peuvent pas être de nature byzantine, sinon cela violerait la preuve BFT. Ainsi, l’hypothèse de cet algorithme est que les messages ne seront jamais détruits et que les nœuds ne s’associeront pas pour compromettre le système.

Paxos se déroule par le biais d’un ensemble de tours de négociation, où un nœud a le statut de « leader ». Si le leader n’est pas en ligne, les progrès seront bloqués jusqu’à ce qu’un nouveau leader soit élu, ou si l’ancien leader se remet soudainement en ligne.

Paxos divise les rôles dans le système en proposeur (Proposer), décideur (Acceptor) et apprenant final (Learner) : Proposeur : propose une proposition (Proposal). Les informations de la proposition incluent l’identifiant de la proposition (Proposal ID) et la valeur proposée (Value). Accepteur : participe à la décision, répond aux propositions des Proposeurs. Après avoir reçu la Proposition, il peut accepter la proposition. Si la Proposition obtient l’acceptation de la majorité des Accepteurs, on dit que cette Proposition est approuvée. Apprenant : ne participe pas à la décision, apprend les dernières propositions (Value) convenues des Proposeurs/Accepteurs.

2. Raft Algorithme

Introduction à l’algorithme : L’algorithme Raft (Replication and Fault Tolerant) est une implémentation simplifiée de l’algorithme Paxos. Le nom Raft vient de l’acronyme « Reliable, Replicated, Redundant, And Fault-Tolerant » (« fiable, répliqué, redondant et tolérant aux pannes »). Raft utilise la continuité des journaux pour simplifier considérablement Paxos. Il garantit la cohérence du système lorsque plus de la moitié des nœuds d’un système composé de n nœuds fonctionnent correctement. Contrairement à l’algorithme Paxos, qui est dérivé directement des problèmes de cohérence distribuée, l’algorithme Raft est proposé du point de vue des machines à états multi-réplication, utilisé pour gérer la réplication des journaux des machines à états multiples. Par exemple, dans un système de 5 nœuds, il permet que 2 nœuds présentent des erreurs non byzantines, telles que des pannes de nœuds, des partitions réseau ou des délais de message.

Cas d’utilisation : Réplication maître-esclave de base de données, chaîne de consortium.

Principe de l’algorithme : Dans le système Raft, il existe trois rôles : Leader, Follower et Candidate. En temps normal, il n’y a qu’un seul Leader, les autres étant des Followers. Le Leader est responsable de toutes les requêtes externes ; si une machine qui n’est pas le Leader reçoit une requête, celle-ci sera redirigée vers le Leader. En général, le Leader envoie des messages à intervalles fixes, appelés battements de cœur (heartbeat), pour informer les Followers que le Leader du cluster est toujours opérationnel. Chaque Follower est doté d’un mécanisme de temporisation (timeout) ; si aucun battement de cœur n’est reçu après un certain temps (généralement 150 ms ou 300 ms), le système entre dans un état d’élection.

À ce moment-là, le groupe entre dans un nouveau cycle électoral (terme) et commence les élections. Si l’élection est réussie, le nouveau leader commence à travailler ; sinon, ce mandat est considéré comme terminé, un nouveau mandat commence et une nouvelle élection est lancée.

Les élections sont lancées par les candidats. Lorsque le cœur du leader s’arrête de battre, cela nécessite que les candidats se nomment eux-mêmes par ordre d’arrivée et fassent campagne auprès des autres serveurs. Chaque serveur ne votera qu’une seule fois par tour pour soutenir ou s’opposer au candidat actuel. Si aucun candidat n’obtient la majorité des voix, un nouveau tour d’élections commence. Les autres candidats continuent de se nommer eux-mêmes selon le principe du premier arrivé, premier servi. Cela continue jusqu’à ce qu’un leader soit élu.

Supériorité de l’algorithme Raft : Le premier point est la simplicité. En creusant profondément dans les raisons pour lesquelles Paxos est plus complexe que Raft, Heidi Howard et Richard Mortier ont découvert que la complexité de Paxos se manifeste de deux manières. Premièrement, Raft soumet les journaux dans l’ordre, tandis que Paxos permet aux journaux d’être soumis dans le désordre, mais nécessite un protocole supplémentaire pour combler les lacunes qui peuvent apparaître. Deuxièmement, toutes les copies des journaux dans Raft ont le même index, terme et commande, tandis que ces termes peuvent être différents dans Paxos.

Le deuxième point est que Raft dispose d’un algorithme d’élection de leader efficace. L’algorithme d’élection donné dans le document Paxos choisit le leader en comparant la taille des identifiants des serveurs ; lorsque plusieurs nœuds se disputent le poste, le nœud avec l’identifiant de serveur le plus élevé l’emporte. Le problème est que, si le leader élu manque de certains journaux, il ne peut pas exécuter immédiatement les opérations d’écriture et doit d’abord copier certains journaux à partir d’autres nœuds. Raft permet toujours de choisir un nœud ayant la majorité des journaux, évitant ainsi la nécessité de rattraper les journaux. Bien que les élections puissent parfois échouer à cause de la division des votes et nécessiter des réessais, c’est dans l’ensemble un algorithme d’élection plus efficace.

Pour l’algorithme Paxos, si un serveur est très en retard, même de plusieurs jours de journaux, mais est élu leader à un moment donné, cela entraînera un blocage pendant un certain temps. Dans l’algorithme Raft, un nœud en retard de journaux ne sera jamais élu.

3 PoW (Proof of Work)

Introduction à l’algorithme : Une technique informatique initialement utilisée pour lutter contre le spam. En 2008, Satoshi Nakamoto a proposé Bitcoin et la blockchain dans le livre blanc de Bitcoin : un système de monnaie électronique de pair à pair, concevant de manière innovante l’algorithme PoW, qui est appliqué à Bitcoin pour résoudre un problème mathématique afin de participer au consensus. Le contenu central de l’algorithme consiste à utiliser la puissance de calcul pour rechercher une valeur nonce qui satisfait le hash du bloc. Cependant, les gens ont rapidement découvert les problèmes de ce mécanisme de consensus, à savoir une forte consommation d’énergie, et le fait que, lorsque des pools de minage importants contrôlent la puissance de calcul, cela entraîne toujours un problème de centralisation.

**Cas d’utilisation :**Bitcoin, ETH1.0, Litecoin, Conflux, Dogecoin.

Algorithme principe : Le système de preuve de travail a pour caractéristique principale que le client doit effectuer un travail d’une certaine difficulté pour obtenir un résultat, tandis que le vérificateur peut facilement vérifier si le client a effectué le travail correspondant à partir du résultat. Une des caractéristiques centrales de cette approche est l’asymétrie : le travail est modéré pour le demandeur, mais facile à vérifier pour le vérificateur. Cela diffère des CAPTCHA, dont le point de départ est de faciliter la résolution par des humains plutôt que par des ordinateurs.

La preuve de travail (PoW) consiste à calculer pour trouver une valeur nonce, de sorte que le hash des données de transaction assemblées respecte une limite spécifiée. Lorsqu’un nœud trouve avec succès un hash valide, il diffuse immédiatement le bloc emballé à l’ensemble du réseau, et les nœuds du réseau qui reçoivent la diffusion valident immédiatement le bloc.

Inconvénients : vitesse lente ; consommation d’énergie énorme, nuisible pour l’environnement ; facilement influencé par les « économies d’échelle ».

Avantages : A été largement testé depuis 2009 et est toujours largement utilisé.

4 attestation (Proof of Stake, PoS)

Introduction à l’algorithme : En 2011, Quantum a été proposé sur le forum Bitcointalk. En août 2012, le premier projet de blockchain basé sur le consensus PoS, Peercoin, est né. Peercoin est la première application à réaliser l’algorithme PoS. Dans Peercoin, les droits sont déterminés par l’âge des pièces, qui est le produit du nombre de pièces détenues par un nœud et de la durée de possession. Initier une transaction consommera un certain âge de pièces, et pour chaque 365 jours d’âge de pièces consommés, un intérêt de 5 % par an sera également obtenu.

Utilisateur : Ethereum(2.0), Conflux, Peercoin.

Algorithme de fonctionnement : Par exemple, si une personne détient 100 jetons dans une transaction et les a conservés pendant 30 jours, alors l’âge du jeton est de 3000. Plus tard, un bloc PoS a été découvert, l’âge du jeton est remis à 0, et l’intérêt obtenu est de 0.05*3000/365=0.41 jeton. Dans le processus de consensus, les nœuds obtiennent le droit de comptabiliser en consommant l’âge des jetons. Plus un nœud consomme d’âge de jeton, plus il a de chances d’obtenir le droit de comptabiliser. Le principe de la chaîne principale défini par l’algorithme est le suivant : la chaîne qui consomme le plus d’âge de jeton est la chaîne correcte et valide du système.

Avantages : pas besoin de matériel de mining puissant et coûteux. Réduit la consommation de ressources, diminue la probabilité d’attaque à 51%.

Inconvénients : cela peut conduire les riches à thésauriser des cryptoactifs, formant ainsi un effet Matthieu, ce qui peut engendrer un problème d’inflation des cryptoactifs.

5 Preuve de l’historique (Proof of History, PoH)

Algorithme Introduction : Preuve de l’historique est créée par Solana, qui est une blockchain à haut débit, lancée en 2018. La preuve de l’historique permet aux participants du réseau d’atteindre un consensus dans le temps en utilisant une fonction de latence vérifiable, évitant ainsi la règle de la « chaîne la plus longue ».

PoH est l’horloge du réseau, tandis que TowerBFT est sa tour de guet, dont la tâche est d’empêcher les nœuds malveillants de tromper les paramètres temporels. Tout validateur votant pour un bloc donné doit attendre la génération du bloc suivant et obtenir la confirmation « le temps est écoulé » à partir de la preuve de l’historique avant de pouvoir voter à nouveau.

Solana a habilement séparé la chaîne temporelle basée sur le hash et l’état, en ne liant pas le hash de chaque bloc ensemble, mais en hashant le hash lui-même à l’intérieur du bloc par les validateurs du réseau. Ce mécanisme est appelé PoH. PoH établit, au fil du temps, un ordre d’événements vérifiable par chiffrement en utilisant des fonctions de latence vérifiables à haute fréquence (VDF). En essence, cela signifie que PoH fonctionne comme une horloge cryptographique, aidant le réseau à s’accorder sur le temps et l’ordre des événements sans attendre les messages d’autres nœuds. La sortie continue du hash de l’état de la blockchain de la preuve de l’historique peut fournir un ordre d’événements vérifiable.

**Utilisateur :**Solana

**Algorithme : ** Le Leader génère un Horodatage pour chaque donnée de signature (transaction à prouver), ce qui permet de trier directement les transactions, évitant ainsi le problème de tri temporel dans le PoS. Chaque validateur peut effectuer la vérification de manière indépendante, ce qui réduit considérablement le problème de réordonnancement lors de la vérification, il suffit de procéder à la vérification de la preuve de transaction.

Avantages : Coûts bas, les frais par transaction ne sont que quelques fractions de cent, vitesse de transaction rapide, bonne extensibilité,

Inconvénients : inquiétudes concernant la centralisation, Solana compte actuellement moins de 1200 validateurs pour valider les transactions sur son réseau. Moins d’applications décentralisées : souvent appelée tueuse d’Ethereum. Selon son site web, plus de 350 Dapp ont été créées sur Solana, tandis qu’il y a près de 3000 Dapp sur Ethereum, et c’est précisément là où Defi a actuellement besoin de plus de temps de développement et d’innovation.

6 proof of authority (Proof of Authority, PoA)

Présentation de l’algorithme : Proposé en 2017 par Gavin Wood, cofondateur d’Ethereum (ETH) et de Parity Technologies. Le mécanisme PoA ne nécessite ni Mining ni TOKEN. Dans un réseau blockchain basé sur PoA, toutes les transactions et blocs sont traités par des validateurs. La plateforme PoA a un faible coût de maintenance, mais dans le PoA, les validateurs des transactions et des blocs de vérification de la blockchain doivent être des personnes pouvant passer un examen de fiabilité. Ainsi, les validateurs de PoA doivent accorder une grande importance à leur réputation. La réputation est un actif très important dans le PoA. En général, les validateurs divulguent leur véritable identité. Actuellement, la technologie blockchain résultant de ce mécanisme de consensus est principalement appliquée dans des chaînes de consortium et des chaînes privées avec des caractéristiques industrielles marquées.

Utilisateurs : PoA, Ethereum Kovantestnet, xDai, VeChain et la chaîne logistique de Walmart.

Algorithme principe :

a. Choisir un vérificateur d’autorité;

b. Des validateurs génèrent des blocs pour enregistrer des transactions et obtiennent une récompense du bloc ainsi que des frais de transaction. Dans PoA, les validateurs sont la clé de tout le mécanisme de consensus, et ils acquièrent le droit au réseau de garantie en adoptant cette identité, échangeant cela contre une récompense du bloc. Si un validateur agit de manière malveillante durant tout le processus, ou collude avec d’autres validateurs, il peut être retiré et remplacé grâce à la gestion off-chain. Les garanties légales anti-fraude existantes seront utilisées pour protéger tous les participants du réseau contre les comportements malveillants des validateurs.

Avantages :

a. Nécessite moins de puissance de calcul, pas besoin de mining, économe en énergie et respectueux de l’environnement;

b Vitesse de vérification rapide, prend en charge des transactions plus rapides;

c. L’ensemble du réseau de validateurs se surveille mutuellement et peut voter à tout moment pour ajouter des validateurs de retour d’expérience ou exclure des validateurs non conformes.

d. Les forks durs sont protégés par la loi, chaque Validator signe un protocole légal.

Inconvénients :

a. L’identité publique, la vie privée et l’anonymat seront réduits.

b. Les validateurs sont spécifiquement des nœuds d’autorité centralisés soutenus par la loi.

**7 Delayed Proof-of-Work (**dPoW)

Introduction à l’algorithme : Avant d’expliquer DPoW, il est nécessaire de définir ce qu’est le PoB. Le PoB (Proof of Burn) est un mécanisme de preuve de brûlage, qui consiste à brûler des jetons détenus par soi-même pour voter qui a le droit de diriger le réseau. Plus le nombre de jetons brûlés est élevé, plus la probabilité d’obtenir une position de leadership dans le réseau est grande.

Dans une blockchain basée sur le dPoW, les mineurs ne reçoivent plus des jetons en récompense de leur minage, mais du « wood » — du bois à brûler. Les mineurs utilisent leur propre puissance de calcul, à travers un algorithme de hachage, pour finalement prouver leur travail, puis obtenir le wood correspondant, qui n’est pas échangeable. Lorsque le wood atteint une certaine quantité, il peut être brûlé sur le site de combustion.

Après calcul par un ensemble d’Algorithmes, les personnes brûlant beaucoup de wood ou BP ou un groupe de BP peuvent obtenir le droit de produire un bloc lors du prochain segment d’événement, et après avoir réussi à produire un bloc, elles reçoivent une récompense (Token). Comme plusieurs personnes peuvent brûler du wood dans une même période, la probabilité de produire un bloc lors de la prochaine période dépend du nombre de wood brûlé par chaque individu. Plus on brûle, plus la probabilité d’obtenir le droit de produire un bloc lors de la prochaine période est élevée.

Cela permet d’atteindre un équilibre entre la puissance de calcul et les droits de production de blocs. Il n’est pas nécessaire que seuls les mineurs et les pools de minage avec une puissance de calcul énorme puissent devenir des producteurs de blocs. Les petits mineurs ont également leur chance, tant qu’ils travaillent dur et accumulent une certaine quantité de wood, ils peuvent aussi produire des blocs. Assurer l’efficacité, permettre à tout le monde de participer, la manière de participation la plus populaire garantit le principe de décentralisation, évitant ainsi que des organisations possédant de la puissance de calcul ou des grands investisseurs contrôlent le réseau.

Utilisateur : Komodo

Principe de l’algorithme : Dans le système dPoW, il existe deux types de nœuds : les nœuds notaires et les nœuds normaux. Les 64 nœuds notaires sont élus par les détenteurs de droits (holder) de la blockchain dPoW, et ils peuvent ajouter des blocs vérifiés par notariat de la blockchain dPoW à la blockchain PoW à laquelle ils sont attachés. Une fois qu’un bloc est ajouté, son hash sera ajouté à une transaction Bitcoin signée par 33 nœuds notaires, et un enregistrement de bloc dPow sera créé, liant le hash à la blockchain Bitcoin. Cet enregistrement a été notarié par la majorité des nœuds notaires du réseau.

Pour éviter une guerre entre les nœuds de notaires lors du Mining, ce qui réduirait l’efficacité du réseau, Komodo a conçu une méthode de Mining utilisant un mécanisme de sondage, qui a deux modes de fonctionnement.

Dans le mode « No Notary », tous les nœuds du réseau peuvent participer au mining, ce qui est similaire au mécanisme de consensus PoW traditionnel. En revanche, dans le mode « Notaries Active », les notaires du réseau utilisent un taux de difficulté réseau considérablement réduit pour le mining. Dans le mode « Notaries Active », chaque notaire est autorisé à exploiter un bloc avec sa difficulté actuelle, tandis que les autres nœuds notaires doivent miner avec une difficulté 10 fois supérieure, et tous les nœuds normaux minent avec une difficulté 100 fois celle des nœuds notaires.

Avantages : Économie d’énergie ; sécurité accrue ; possibilité d’ajouter de la valeur à d’autres blockchains sans avoir à payer le coût des transactions en Bitcoin (ou toute autre chaîne sécurisée).

Inconvénients : Seules les blockchains utilisant PoW ou PoS peuvent adopter cet algorithme de consensus ; dans le mode « Notaires Actifs », il est nécessaire d’ajuster le hashrate des différents nœuds (notaires ou nœuds normaux), sinon la différence de hashrate peut exploser.

8 Autorisation PoS (DPoS, Proof-of-Stake Délégué)

Présentation de l’Algorithme : Le mécanisme DPoS, également appelé « mécanisme de DPoS » et « mécanisme de fiduciaire », a été proposé en avril 2014 par Dan Larimer (BM), le développeur en chef de Bitshares. D’un certain point de vue, le DPOS ressemble un peu à un système parlementaire ou à un système de congrès des représentants du peuple. Si les représentants ne peuvent pas remplir leurs fonctions (lorsqu’il est temps pour eux de générer un Bloc), ils seront exclus, et le réseau choisira de nouveaux Nœuds super pour les remplacer.

Pour faciliter la compréhension, prenons un autre exemple. Imaginez une entreprise de ce type : l’entreprise compte 1000 employés, chacun détenant un nombre variable d’actions de l’entreprise. À intervalles réguliers, les employés peuvent voter pour leurs 10 personnes préférées pour diriger l’entreprise, où le poids de chaque vote est proportionnel au nombre d’actions détenues par chaque employé. Une fois que tous les votes ont été exprimés, les 10 personnes ayant obtenu le plus de voix deviennent les dirigeants de l’entreprise.

Si un leader n’est pas compétent ou agit contre les intérêts de l’entreprise, les employés peuvent annuler leur vote pour ce leader, empêchant ainsi son taux de vote d’atteindre le top 10, ce qui le fait sortir de la direction.

**Utilisateurs :**BitShares, Steemit, EOS, Lisk, Ark.

Avantages : Énergétique ; Rapide ; Le site de blog à fort trafic Steemit l’utilise. Le temps de bloc d’EOS est de 0,5 seconde.

Inconvénients : légèrement centralisé ; les participants ayant un fort enjeu peuvent voter pour devenir un validateurs (c’est un problème qui est récemment apparu dans EOS).

9 tolérance aux fautes byzantines pratique (Practical Byzantine Fault Tolerance, PBFT)

Algorithme Introduction : Dans l’algorithme PBFT, un nœud est désigné comme masternode, tandis que les autres nœuds sont des nœuds de sauvegarde. Tous les nœuds du système communiquent entre eux, l’objectif final étant d’atteindre un Consensus selon le principe de la minorité obéissant à la majorité.

Consensus process :

a. Le client envoie une requête au masternode pour exécuter une opération.

b. Le masternode diffuse cette demande aux différents nœuds de sauvegarde

c. Tous les nœuds exécutent des opérations et renvoient les résultats au client.

d. Lorsque le client reçoit f+1 résultats identiques provenant de différents nœuds, le processus se termine. f représente la valeur maximale des nœuds pouvant mentir.

Utilisateur : HyperLedgerFabric, Stellar, Ripple, Dispatch

Avantages : Haute vitesse, évolutivité.

Inconvénients : généralement utilisé pour les réseaux privés et les réseaux autorisés.

10 Autorisation de tolérance aux fautes byzantines (dBFT DeleGated Byzantine Fault Tolerance, dBFT)

Introduction à l’algorithme : La communauté blockchain en Chine NEO (anciennement connu sous le nom de XiaoYi) propose un algorithme de tolérance aux fautes byzantines amélioré, le dBFT. Cet algorithme s’inspire du PBFT et du concept de conception de PoS. Tout d’abord, il sélectionne le comptable en fonction des droits des nœuds, puis les comptables atteignent le consensus par le biais de l’algorithme de tolérance aux fautes byzantines. Cet algorithme améliore le problème d’absence de consensus final dans PoW et PoS, permettant à la blockchain d’être applicable dans des scénarios financiers.

De la même manière, pour résoudre le Faute byzantine, le mécanisme de « tolérance aux fautes byzantines » est un Algorithme de consensus qui garantit la tolérance aux fautes au sein de la blockchain NEO. Dans ce mécanisme, il y a deux participants : un « Nœud » de comptabilité spécialisé et un utilisateur ordinaire dans le système.

Les utilisateurs ordinaires votent pour décider des nœuds de comptabilité en fonction de la proportion de leurs droits. Lorsqu’un consensus doit être atteint, un porte-parole est choisi au hasard parmi ces nœuds de comptabilité pour proposer un plan. Ensuite, les autres nœuds de comptabilité s’expriment en fonction de l’algorithme de tolérance aux fautes byzantines, c’est-à-dire selon le principe de la minorité obéissant à la majorité. Si plus de 66 % des nœuds acceptent le plan du porte-parole, le consensus est atteint ; sinon, un nouveau porte-parole est choisi et le processus de vote est répété.

Puisque tous les représentants peuvent vérifier les propositions de blocs, il est facile de comprendre si les données envoyées par le président sont valides ou non. Ainsi, si le président n’est pas honnête et envoie des propositions invalides à deux tiers des représentants, le bloc ne correspondra pas, et les propriétaires de nœuds ne le valideront pas. Un consensus sera atteint avec deux tiers des voix, et un nouveau président sera élu.

**Utilisateur :**Neo

Consensus process :

a. Quiconque peut devenir représentant, tant qu’il ou elle remplit les conditions. Tous les détenteurs de jetons NEO peuvent voter, les représentants ne sont pas anonymes, et devenir propriétaire d’un nœud nécessite 1 000 GAS.

b. Choisir un porte-parole au hasard parmi les représentants.

c. Le porte-parole construit un nouveau Bloc à partir des transactions en attente de validation. Ensuite, le président envoie la proposition aux représentants élus. Ils doivent suivre toutes les transactions et les enregistrer sur le réseau.

d. Les représentants peuvent librement partager et comparer les propositions qu’ils ont reçues pour tester l’exactitude des données et l’honnêteté des orateurs. Si plus des deux tiers des représentants parviennent à un consensus et vérifient, alors le Bloc est ajouté à la blockchain.

Avantages : Rapide (la génération d’un bloc prend 15 à 20 secondes) ; grande capacité de traitement des transactions, sans consommation d’énergie, évolutif, sans fork.

Inconvénients : Pas d’anonymat, nécessite une identité réelle pour être élu. Chacun s’efforce de devenir la chaîne racine. Il peut y avoir plusieurs chaînes racines.

11. Rotation Pratique de la Tolerance aux Fautes Byzantines (RBPFT)

Introduction à l’algorithme : Les principes de dBft et RPBFT sont similaires à ceux de PBFT, sauf que tous les nœuds ne participent pas au consensus, mais les nœuds sont divisés en deux types :

a. Nœud de consensus : nœud exécutant le processus de consensus PBFT, ayant le droit de produire des blocs à tour de rôle.

b. Nœud de vérification : n’exécute pas le processus de consensus, vérifie si le nœud de consensus est valide, vérification du bloc, après plusieurs tours de consensus, il passera au nœud de consensus.

Dans la tolérance aux fautes byzantines, les nœuds de consensus sont alternativement remplacés par des nœuds de validation.

Cas d’utilisation : Fisco-BCOS

Avantages : La vitesse de diffusion est plus rapide que celle du gossip, sans paquets de messages redondants.

Diviser pour régner, chaque nœud a une bande passante de O(1), grande évolutivité.

Inconvénients : Le nœud intermédiaire est un point unique, nécessitant des stratégies de tolérance aux pannes supplémentaires.

12. AptosBFT

Introduction à l’algorithme : Il s’agit également d’un algorithme dérivé de PBFT, l’algorithme de consensus nommé d’après Aptos, basé sur HotStuff, qui est lui-même basé sur PBFT. Les avantages de ce modèle d’algorithme ressemblent à ceux d’un oignon et d’une poupée russe, nécessitant d’être pelés couche par couche. Chaque nœud communique uniquement avec le leader, plutôt que d’envoyer des messages au leader et à tous les autres « généraux ». Le leader diffuse le message à voter (le bloc proposé) ; chaque nœud envoie son vote au leader qui collecte les messages.

Cas d’utilisation : Aptos

Enfin, voici le résumé de cette section :

De plus, il existe quelques algorithmes de consensus peu courants.

En 2015, le professeur David Mazieres, directeur scientifique de Stellar.org, a proposé le protocole de consensus Stellar (Stellar consensus protocol, SCP). Le SCP a évolué à partir du protocole Federated Byzantine Agreement et du protocole Ripple, et est le premier mécanisme de consensus prouvablement sécurisé, possédant quatre attributs clés : contrôle décentralisé, latence faible, confiance flexible et sécurité asymptotique.

La même année, le projet Lac en dents de scie d’Hyperledger a combiné Ripple et le consensus SCP pour proposer un algorithme de consensus par vote à quorum, afin de répondre aux scénarios d’application nécessitant une finalité de transaction instantanée.

En 2016, le lauréat du prix Turing et professeur au MIT, Silvio Micali, a proposé un algorithme de consensus rapide appelé AlgoRand. Cet algorithme utilise la technique de tirage au sort cryptographique pour sélectionner les validateurs et le leader du processus de consensus, et par le biais de son protocole de tolérance aux fautes byzantines BA*, il parvient à un consensus sur les nouveaux blocs. AlgoRand nécessite une très faible quantité de calcul et très peu de forks, et est considéré comme une technologie de consensus de registre distribué véritablement démocratique et efficace.

En 2017, l’université Cornell a proposé un nouvel algorithme appelé Sleepy Consensus (Consensus dormant). Ce consensus vise à traiter la situation réelle où la majorité des nœuds de consensus dans un environnement Internet à grande échelle peuvent être hors ligne, avec seulement quelques nœuds en ligne participant au processus de consensus. Cette recherche a prouvé que les algorithmes de consensus traditionnels ne peuvent pas garantir la sécurité du consensus dans un tel environnement. En revanche, avec l’algorithme de consensus dormant, tant que le nombre de nœuds honnêtes en ligne dépasse celui des nœuds défaillants, la sécurité et la robustesse peuvent être garanties.

04 Résumé

Si l’on sort du point de vue des développeurs et qu’on intègre davantage de réflexions politiques et économiques, il pourrait y avoir davantage d’algorithmes de consensus, comme des méthodes de consensus similaires au concept de PPP, qui non seulement peuvent pénaliser les malveillants, mais aussi atteindre l’objectif d’économiser la puissance de calcul de manière très efficace.

En résumé, le mécanisme de consensus est au cœur de la technologie blockchain. Il peut résoudre les problèmes de confiance dans les systèmes distribués, garantir la cohérence et la sécurité des données entre les nœuds, éviter les attaques et les falsifications des nœuds malveillants, assurant ainsi la stabilité et la fiabilité du système blockchain. De plus, le mécanisme de consensus peut également résoudre le problème du « double dépense » et améliorer le débit et la vitesse de traitement du système blockchain. Cependant, les différents algorithmes de consensus ne sont pas absolument sûrs, efficaces et décentralisés.

Il n’y a pas le meilleur algorithme, seulement l’algorithme le plus adapté à soi-même. Le choix et l’application de l’algorithme de consensus sont fortement liés au scénario d’application. Dans un environnement de confiance, on utilise Paxos ou RAFT, un consortium avec autorisation peut utiliser PBFT, et une chaîne non autorisée peut être PoW, PoS, consensus Ripple, etc. Le meilleur mécanisme de consensus est toujours celui qui répond aux besoins des utilisateurs.

Référence:

1. Quels sont les mécanismes de consensus dans la blockchain et les cryptomonnaies ?

2. Attaque par double dépense contre la blockchain

3. Comprendre en un article 11 algorithmes de consensus majeurs, comprendre complètement ce que sont au juste PoS, PoW, dPoW, PBFT, dBFT ?

4 Comprendre le double-dépense et comment prévenir les attaques

5 Introduction aux applications des mécanismes de consensus byzantin

6 AptosBFT : tout ce que vous devez savoir sur le consensus BFT dans Aptos