Le cœur de la blockchain est d'atteindre un consensus mondial strict: c'est-à-dire que, peu importe où les nœuds du réseau sont distribués dans quel pays ou fuseau horaire, tous les participants doivent finalement parvenir à un consensus sur un ensemble de résultats objectifs.

Mais la réalité des réseaux distribués n'est pas idéale : les nœuds se déconnectent, les nœuds mentent, et certains sabotent même intentionnellement. Dans ce cas, comment le système peut-il “parler d'une seule voix” et maintenir la cohérence ?

Il s'agit du problème que le protocole de consensus vise à résoudre. Il s'agit essentiellement d'un ensemble de règles pour guider un groupe de nœuds indépendants et même partiellement non fiables sur la manière d'atteindre une décision unifiée sur l'ordre et le contenu de chaque transaction.

Et une fois que ce 'consensus strict' est établi, la blockchain peut débloquer de nombreuses fonctionnalités clés, telles que la protection des droits de propriété numérique, les modèles de monnaie anti-inflation et les structures de collaboration sociale évolutives. Mais la condition préalable est que le protocole de consensus lui-même doit garantir simultanément deux aspects fondamentaux.

• Deux blocs conflictuels ne peuvent pas être confirmés tous les deux;
• Le réseau doit continuer à avancer et ne peut pas rester bloqué ou s'arrêter.

MonadBFT est la dernière percée technologique dans cette direction.

Un bref examen de l'évolution des protocoles de consensus

Dans le domaine du mécanisme de consensus, il a en fait été étudié depuis des décennies. La première série de protocoles, tels que PBFT (Tolérance aux Fautes Byzantines Pratique), peuvent déjà gérer une situation très réaliste : même si certains nœuds du réseau abandonnent la chaîne, se comportent de manière malveillante ou disent des absurdités, tant qu'ils ne dépassent pas un tiers du nombre total, le système peut toujours parvenir à un consensus.

La conception de ces premiers protocoles est plus "traditionnelle" : un leader est sélectionné à chaque cycle pour initier une proposition, et les autres validateurs votent sur cette proposition dans plusieurs cycles pour confirmer progressivement l'ordre des transactions.

Le processus de vote entier passe généralement par plusieurs étapes, telles que la préparation préalable, la préparation, l'engagement et la réponse. À chaque étape, tous les validateurs doivent communiquer les uns avec les autres. En d'autres termes, tout le monde doit tout dire à tout le monde, et le volume des messages augmente de manière explosive selon un schéma de 'maillage'.

La complexité de cette structure de communication est n² - c'est-à-dire que s'il y a 100 validateurs dans le réseau, chaque tour de consensus peut nécessiter la transmission de près de 10 000 messages.

Dans un petit réseau, ce n'est pas un problème, mais une fois que le nombre de validateurs augmente, la charge de communication du système deviendra rapidement insupportable, affectant directement l'efficacité.

Source d'information:https://medium.com/coinmonks/pbft-understanding-the-algorithm-b7a7869650ae

La structure de communication secondaire "tout le monde parle à tout le monde" est en réalité très inefficace. Par exemple, dans un réseau avec 100 validateurs, chaque tour de consensus peut nécessiter le traitement de dizaines de milliers de messages.

Cela peut encore être géré dans un petit cercle, mais lorsqu'il est placé dans un réseau de chaînes ouvertes et mondiales, la charge de communication devient immédiatement inacceptable. Ainsi, les premiers protocoles BFT comme PBFT et Tendermint sont généralement utilisés uniquement dans des réseaux autorisés ou des systèmes avec très peu de validateurs pour fonctionner à peine.

Afin de permettre au protocole BFT de s'adapter aux environnements de chaîne publique sans autorisation, certaines conceptions de nouvelle génération se tournent vers des méthodes de communication plus légères : permettant à chaque validateur de communiquer uniquement avec le leader, plutôt qu'avec tous les membres.

Cela optimise la complexité du message de n² à n, réduisant considérablement la charge du système.

Le protocole HotStuff a été proposé en 2018 pour résoudre ce problème de scalabilité. Sa philosophie de conception est très claire : remplacer le processus de vote complexe de PBFT par une structure de communication plus concise et dirigée par le leader.

Une des caractéristiques clés de HotStuff est la communication linéaire dite. Dans son mécanisme, chaque validateur doit uniquement envoyer son vote au leader actuel, qui regroupe ensuite ces votes pour générer un certificat de quorum (QC).

Ce QC est essentiellement une signature collective, prouvant à l'ensemble du réseau : 'La plupart des nœuds sont d'accord avec cette proposition.'

En revanche, le mode de communication du PBFT est 'diffusé à tous', où tout le monde parle dans le groupe, ce qui peut parfois entraîner une scène chaotique. Le mode de HotStuff est plus comme 'un rassemble, un empaquète à la fois', ce qui peut maintenir une opération efficace peu importe le nombre de personnes sur le réseau.

La figure compare la structure de communication de diffusion en éventail de HotStuff avec le mode entièrement interconnecté de PBFT Source:

https://www.mdpi.com/1424-8220/24/16/5417

En plus de la communication linéaire, HotStuff peut être encore amélioré pour devenir une version en pipeline, utilisée pour améliorer l'efficacité.

Dans le HotStuff original, le même validateur servira de leader pour plusieurs rounds d'affilée, jusqu'à ce qu'un bloc soit entièrement confirmé. Ce processus consiste à 'traiter un bloc par round', tous les efforts étant concentrés sur l'avancement de celui en cours.

Dans le pipeline HotStuff, le mécanisme est encore plus flexible : un nouveau leader est sélectionné à chaque tour, et chaque leader a deux tâches :

• Emballer le dernier tour de votes dans un certificat de quorum (QC) d'un côté et le diffuser à l'ensemble du réseau;
• D'un côté, proposez un nouveau bloc, prêt à démarrer le prochain tour.

En d'autres termes, il ne s'agit plus de "confirmer un avant de traiter le suivant", mais comme une chaîne de production, différents leaders se relaient pour être responsables de chaque étape. Le précédent propose un bloc, le suivant le confirme et continue de proposer de nouveaux blocs, et le consensus sur la chaîne se transmet comme dans une course de relais.

C'est l'origine de la métaphore de la « chaîne de montage » : le bloc actuel est encore en cours de confirmation, tandis que le suivant est déjà en préparation, plusieurs étapes sont parallèles, augmentant ainsi l'efficacité du débit.

En résumé, des protocoles comme HotStuff ont apporté des améliorations significatives par rapport au BFT traditionnel dans deux dimensions :

• Tout d'abord, la communication est plus légère, chaque validateur n'ayant besoin de communiquer qu'avec le leader;
• Deuxièmement, l'efficacité de traitement est plus élevée et plusieurs processus de confirmation de blocs peuvent fonctionner en parallèle.

Cela fait de HotStuff un modèle de conception pour de nombreux mécanismes de consensus blockchain PoS modernes. Mais tout a ses avantages et ses inconvénients - alors que la structure en pipeline est puissante en termes de performances, elle introduit également discrètement un risque structurel non facilement découvrable.

Ensuite, nous allons nous plonger dans cette question centrale : Tail Forking.

Problème de division de la queue à la fin

Bien que HotStuff, en particulier sa version en pipeline, résolve le problème de scalabilité du protocole de consensus, il introduit également de nouveaux défis. Le plus crucial et facilement négligé est le problème de "Tail Forking".

Qu'est-ce qu'une fourchette de queue? On peut simplement le comprendre comme suit : une blockchain subit une réorganisation accidentelle des blocs à la 'queue' de la chaîne.

Plus précisément, il existe un bloc qui est valide, a été propagé avec succès à la majorité des validateurs et a reçu suffisamment de votes. En théorie, il devrait être confirmé et écrit immédiatement dans la chaîne principale. Cependant, à la fin, il est "sauté", orpheliné et remplacé par un autre nouveau bloc au même hauteur.

Ce n'est pas un bug, ni une attaque, mais à cause de la structure de conception du protocole lui-même, il y a une possibilité de ce 'chain tailing'. Cela semble un peu injuste? Alors, comment cela se produit-il?

Comme mentionné précédemment, chaque leader du pipeline HotStuff a deux tâches :

• A. Proposez un nouveau bloc (tel que Bₙ₊₁)
• B. Collecter des votes pour le bloc du précédent leader afin de générer un QC (par exemple, pour confirmer finalement Bₙ)

Ces deux tâches sont parallèles, se relayant tour à tour. Mais le problème survient ici.

Par exemple, supposons qu'Alice soit la leader et qu'elle ait proposé le bloc Bₙ à la hauteur n, qui a reçu une supermajorité de votes et est "presque confirmé".

Ensuite, ce devrait être au tour de Bob de prendre le rôle de leader, de continuer à avancer vers le prochain bloc Bₙ₊₁ de la chaîne, et d'inclure également le QC (Qualified Commitment) de Bₙ dans sa proposition pour compléter la confirmation finale de Bₙ.

Mais si Bob est hors ligne à ce moment, ou ne soumet pas intentionnellement le QC de Bₙ, alors il y a un problème.

Parce que personne n'a emballé le bloc d'Alice avec QC, l'enregistrement des votes de Bₙ ne s'est pas propagé. Ce bloc, qui aurait dû être confirmé, a donc été 'traité à froid' et finalement ignoré par l'ensemble du réseau.

C'est l'essence d'une fourchette de queue : un bloc du leader précédent est sauté en raison de la négligence ou de la malveillance du prochain leader.

Pourquoi la fourche de la queue est-elle si grave?

Le problème de la fourchette de queue se concentre principalement sur deux aspects : 1) le mécanisme d'incitation est perturbé, 2) l'activité du système est menacée.

Tout d'abord, les récompenses sont avalées :

Si un bloc est abandonné, le leader qui l'a proposé ne recevra aucune récompense, que ce soit des récompenses de bloc ou des frais de transaction. Par exemple, si Alice propose un bloc valide et reçoit un soutien massif dans le vote, mais en raison d'une erreur ou d'une opération malveillante de Bob, le bloc ne peut pas être confirmé, Alice ne recevra pas un sou à la fin. Cela entraînera une structure d'incitation défectueuse : les nœuds malveillants comme Bob peuvent ‘couper’ leur source de récompense en sautant les blocs de leurs adversaires. Ce comportement ne nécessite pas d'attaques techniques, seulement une ‘non-coopération’ délibérée pour affaiblir les profits des concurrents. Si cela se produit à plusieurs reprises, avec le temps, la participation et l'équité de l'ensemble du système diminueront, et pourraient même déclencher une collusion entre les nœuds.

Deuxièmement, la surface d'attaque MEV s'élargit:

Les fourches arrière posent également un problème plus insidieux mais sérieux : il y a plus de place pour que la MEV (Maximum Extractable Value) soit manipulée de manière malveillante. Voici un exemple : supposons qu’Alice ait une transaction d’arbitrage précieuse dans son bloc. Si Bob veut causer des ennuis, il peut s’entendre avec le prochain leader, Carol, et délibérément ne pas étendre le blocage d’Alice. Carol reconstruit ensuite un nouveau bloc à la même hauteur, « volant » l’échange d’arbitrage original d’Alice - faisant en sorte que le MEV gagne le sien. Cette pratique du « réarrangement de la tête de chaîne + collusion et appropriation » est encore un bloc selon les règles en surface, mais il s’agit en fait d’un pillage bien conçu. Pire encore, cela induit une « collusion » entre les dirigeants, transformant la confirmation de bloc en un jeu de partage des avantages plutôt qu’en un service public.

Troisièmement, compromettre la garantie de finalité, affectant l'expérience utilisateur:

Par rapport aux protocoles de type Nakamoto, un avantage majeur du BFT est la finalité déterministe: une fois qu'un bloc est validé, il ne peut pas être annulé. Cependant, la fourchette de queue perturbe cette garantie, en particulier sur les blocs qui sont 'pré-validés mais pas formellement confirmés.' Certaines dapps à haut débit veulent souvent lire les données immédiatement après le vote sur les blocs pour réduire la latence, et si le bloc est soudainement rejeté, cela peut entraîner un retour en arrière de l'état de l'utilisateur, tel que des soldes de compte anormaux, des transactions à effet de levier élevé qui viennent d'être effectuées disparaissant sans raison, ou des réinitialisations soudaines de l'état du jeu.

Quatrièmement, peut causer une défaillance en chaîne :

En général, une fourchette de queue ne peut que retarder la confirmation d'un bloc pour un tour, ce qui n'a pas un gros impact. Cependant, dans certains cas particuliers, si plusieurs leaders à la suite choisissent de sauter le bloc précédent, le système peut rester bloqué et personne ne souhaite "prendre en charge" le bloc précédent. Toute la chaîne est bloquée jusqu'à ce qu'un leader qui est prêt à assumer la responsabilité apparaisse enfin, et le réseau continuera à avancer.

Bien qu'il y ait eu certaines solutions auparavant, telles que le mécanisme d'évitement de fourche de queue proposé par le protocole BeeGees, elles nécessitent souvent de sacrifier les performances, telles que la réintroduction de la complexité de communication secondaire, ce qui n'en vaut pas la peine.

Qu'est-ce que MonadBFT?

MonadBFT est un protocole de consensus de nouvelle génération conçu spécifiquement pour résoudre le problème de la fourchette de queue. Sa force réside dans le fait qu'en abordant les vulnérabilités structurelles, il ne sacrifie pas les avantages de performance apportés par le pipeline HotStuff. En d'autres termes, MonadBFT ne recommence pas à zéro, mais continue plutôt à s'optimiser en fonction du cadre principal de HotStuff. Il conserve trois caractéristiques clés :

1) Leader rotatif : Sélectionnez un nouveau leader pour chaque tour afin de faire avancer la chaîne ;
2) Engagements en pipeline : Les processus de confirmation de plusieurs blocs peuvent se chevaucher ;
3) Communication linéaire (messagerie linéaire) : Chaque validateur doit seulement communiquer avec le leader, ce qui permet d'économiser beaucoup de bande passante réseau.

Mais se fier uniquement à ces trois points n'est pas suffisamment sécurisé. Afin de combler la vulnérabilité structurelle de la fourche arrière, MonadBFT a ajouté deux mécanismes clés :

1) Mécanisme de re-proposition obligatoire (Re-Proposal)
2) Certificat de non-approbation (NEC)

Mécanisme de Re-Proposal

Dans le protocole BFT, le temps est divisé en rounds (appelés vues), avec un leader à chaque round responsable de proposer un nouveau bloc. Si le leader échoue (par exemple, en ne proposant pas de bloc à temps ou avec une proposition invalide), le système passe au round suivant et sélectionne un nouveau leader.

MonadBFT a ajouté un mécanisme pour s'assurer que tout bloc proposé de manière honnête pendant le processus de changement de vue ne "perdra pas la chaîne" en raison de la rotation du leader.

Lorsque le leader actuel échoue, les validateurs enverront un message signé pour un changement de tour (changement de vue), indiquant que le tour actuel a expiré.

En particulier, ce message indique non seulement un 'délai d'attente', mais doit également inclure les informations de bloc du vote récent du validateur, ce qui équivaut à dire, 'Je n'ai pas reçu de proposition valide, voici le dernier bloc que je vois actuellement.'

La nouvelle série de leaders collectera ces messages d'expiration de la majorité absolue (2f+1) des validateurs et les fusionnera dans un certificat d'expiration (TC). Ce TC représente l'instantané cognitif unifié de la 'tête de chaîne' de l'ensemble du réseau lorsque la série précédente échoue. Le nouveau leader sélectionnera le bloc avec la hauteur la plus élevée (ou le dernier numéro de vue), appelé high_tip, à partir de celui-ci.

MonadBFT exige : La proposition d'un nouveau leader doit inclure un TC valide et doit reproposer le bloc en attente le plus élevé dans le TC pour donner à ce bloc une autre chance d'être confirmé.

Pourquoi? Comme mentionné précédemment: nous ne voulons pas qu'un bloc qui est proche d'être confirmé disparaisse.

Par exemple, supposons qu'Alice soit le leader de la vue 5, ait proposé un bloc valide et reçu la majorité des votes. Ensuite, lorsque le leader de la vue 6, Bob, est hors ligne et échoue à faire avancer le processus de la chaîne, au moment où Carol prend le relais en tant que leader de la vue 7, selon les règles de MonadBFT, elle doit inclure TC et reproposer le bloc d'Alice. De cette manière, le travail honnête d'Alice ne sera pas vain.

Si Carol n'a pas le bloc d'Alice, elle peut le demander à d'autres nœuds. Les nœuds peuvent :

• Fournir le block, ou
• Renvoyer un message signé "Pas de recommandation (NE)", indiquant que l'expéditeur ne possède pas ce bloc (son mécanisme est expliqué plus tard). (Jusqu'à f nœuds byzantins peuvent choisir d'ignorer la demande et de ne pas répondre.)

Une fois que Carol re-propose le bloc d'Alice, elle bénéficiera d'une opportunité de proposition supplémentaire pour s'assurer qu'elle n'est pas "impliquée" en raison de l'échec du leader précédent.

Le rôle de ce mécanisme de re-proposition est clair : garantir que l'avancement de la chaîne est équitable, et aucun travail valide n'est discrètement jeté en raison de la malchance ou du sabotage de quelqu'un.

Certificat non endossable (NEC)

Poursuivant avec l'exemple précédent: Après le délai de Bob, Carol demande à d'autres validateurs de fournir le bloc high_tip (c'est-à-dire le bloc d'Alice). À ce stade, au moins 2f+1 validateurs répondront:

• Fournir les blocs d'Alice
• Envoyez un message NE signé indiquant que vous n'avez pas reçu le bloc d'Alice.

Dès que Carol reçoit le bloc d'Alice, elle doit le reproposer selon les règles. Carol ne peut sauter le bloc et en proposer un nouveau que lorsque au moins f+1 validateurs ont signé le message NE.

Pourquoi f+1 ? Dans un système BFT composé de 3f+1 validateurs, au plus seulement f peuvent être malveillants. Si le bloc d'Alice a effectivement reçu une majorité écrasante de votes, alors au moins 2f+1 nœuds honnêtes l'ont reçu.

Par conséquent, si Carol affirme : « Je ne peux pas obtenir le bloc d'Alice », elle doit produire f+1 signatures de validateur pour prouver que personne ne l'a reçu. Ceci constitue un certificat de non-approbation (NEC).

NEC est une attestation de "désaveu" du leader : c'est une preuve vérifiable que le bloc précédent n'est pas prêt à être confirmé, n'a pas été volontairement omis, mais a été "abandonné" avec des raisons.

Re-proposition + Certificat non approuvé = Résoudre la fourche de la queue

MonadBFT introduit un ensemble de règles de traitement des têtes de chaîne rigoureuses et claires en introduisant le mécanisme de re-proposition et le certificat de non-approbation (NEC).

Soit enfin s'engager dans le bloc « proche de la confirmation »;

Fournissez suffisamment de preuves pour prouver que le bloc n'est pas encore prêt à être confirmé,

Sinon, il n'est pas permis de sauter ou de remplacer le bloc précédent.

Ce mécanisme garantit qu'aucun bloc ayant reçu une majorité légale de votes ne sera abandonné en raison d'erreurs du leader ou de contournements intentionnels.

Les risques structurels de la fourche arrière sont systématiquement résolus, et le protocole peut clairement contraindre un comportement de saut incorrect.

Si un leader tente de sauter le bloc précédent sans fournir de preuve NEC, le protocole reconnaîtra immédiatement et rejettera le comportement. Le comportement de saut sans preuve cryptographique sera considéré comme illégal et ne recevra pas le soutien du consensus du réseau.

D'un point de vue des incitations économiques, cette conception offre une protection claire aux validateurs:

• Tant que le bloc est proposé de manière honnête et reçoit un soutien lors du vote, sa récompense ne sera pas privée en raison d'échecs ultérieurs.
• Même dans des situations extrêmes, comme lorsque un nœud saute délibérément sa propre ronde de proposition et tente d'aider d'autres à saisir le MEV du bloc précédent, le protocole forcera le leader suivant à donner la priorité à la re-proposition du bloc original, empêchant l'attaquant de tirer des avantages économiques en évitant le processus.

Plus important encore, MonadBFT n'a pas sacrifié les performances du protocole pour renforcer la sécurité.

Certains designs qui s'occupent des fourches de queue (comme le protocole BeeGees) dans le passé ont certaines capacités de protection, mais s'appuient souvent sur une complexité de communication élevée (n²) ou permettent des processus de communication lourds à chaque tour, ce qui augmente considérablement la charge du système en pratique.

La stratégie de conception de MonadBFT est plus sophistiquée :

Les communications supplémentaires (telles que les messages de temporisation, les re-propositions de blocs) ne sont initiées que lorsque la vue échoue ou que des anomalies existent. Sur le chemin régulier où la plupart des leaders honnêtes produisent continuellement des blocs, le protocole maintient toujours un état opérationnel léger et efficace.

L'équilibre dynamique entre les performances et la sécurité est précisément l'un des principaux avantages de MonadBFT par rapport à ses protocoles prédécesseurs.

Résumé

Cet article passe en revue le mécanisme de base du consensus PBFT traditionnel, trie le chemin de développement du protocole HotStuff et se concentre sur la manière dont MonadBFT résout le problème de la fourchette arrière inhérent du pipeline HotStuff au niveau de la structure du protocole.

Les fourches arrière peuvent fausser les incitations économiques des proposants de blocs et représenter une menace potentielle pour l'activité du réseau. MonadBFT garantit qu'un bloc proposé par des leaders honnêtes et approuvé par un vote à majorité statutaire ne sera pas abandonné ou sauté en introduisant un mécanisme de re-proposition et un Certificat Non-Endorsed (NEC).

Dans le prochain article, nous continuerons à explorer les deux autres fonctionnalités essentielles de MonadBFT :

1）Finalité Spéculative
2）Réactivité Optimiste

Analyse approfondie de ces mécanismes et de leur importance pratique pour les validateurs et les développeurs.

Déclaration :

1. Cet article est repris de [michael_lwy], les droits d'auteur appartiennent à l'auteur original [michael_lwy]，si vous avez des objections à la reproduction, veuillez contacterGate Apprendre Équipe)，l'équipe s'en chargera dès que possible selon le processus pertinent.
2. Avis de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les autres versions linguistiques de l'article sont traduites par l'équipe Gate Learn, sans mentionnerGate.ioNe copiez pas, ne distribuez pas, ne plagiez pas les articles traduits sans permission.