Le cœur de la blockchain réside dans la réalisation d'un consensus mondial strict : c'est-à-dire que peu importe où les nœuds du réseau sont répartis, dans quel pays ou fuseau horaire, tous les participants doivent finalement s'accorder sur un ensemble de résultats objectifs.
Mais les réseaux distribués dans la réalité ne sont pas idéaux : il y a des nœuds qui se déconnectent, des nœuds qui mentent, et même des gens qui sabotent intentionnellement. Dans ce cas, comment le système parvient-il à maintenir un "consensus" et à rester cohérent ?
C'est le problème que le protocole de consensus doit résoudre. C'est essentiellement un ensemble de règles qui guide un groupe de nœuds indépendants, voire pas totalement fiables, sur la manière de parvenir à un accord uniforme sur l'ordre et le contenu de chaque transaction.
Une fois que ce "consensus strict" est établi, la blockchain peut débloquer de nombreuses caractéristiques clés, telles que la protection des droits de propriété numériques, un modèle monétaire anti-inflation et une structure de collaboration sociale extensible. Mais à condition que le protocole de consensus lui-même garantisse simultanément deux fondamentaux :
Il ne peut pas y avoir deux blocs en conflit qui soient tous deux confirmés ;
Le réseau doit continuer à avancer, il ne doit pas être bloqué ou à l'arrêt.
MonadBFT est la dernière percée technologique dans cette direction.
Revue brève de l'évolution du protocole de consensus
Le domaine des mécanismes de consensus a en fait été étudié pendant des décennies. Les premiers protocoles, comme le PBFT (Tolérance aux pannes byzantines pratiques), peuvent déjà gérer une situation très réaliste : même si une partie des nœuds du réseau tombe en panne, agit mal ou raconte des histoires, tant qu'ils ne dépassent pas 1/3 du total, le système peut encore parvenir à un consensus.
Ces premiers protocoles ont été conçus de manière plutôt "traditionnelle" : à chaque tour, un leader est choisi, qui propose une initiative, et les autres validateurs votent plusieurs fois sur cette initiative, confirmant progressivement l'ordre des transactions.
Le processus de vote entier passe généralement par plusieurs étapes, comme pre-prepare, prepare, commit, reply. À chaque étape, tous les validateurs doivent communiquer entre eux. En d'autres termes, tout le monde doit parler à tout le monde, et la quantité de messages augmente de manière "en réseau" exponentielle.
La complexité de cette structure de communication est n² - c'est-à-dire que si le réseau compte 100 validateurs, alors chaque round de consensus pourrait nécessiter la transmission de près de 10 000 messages.
Cela ne pose pas de problème dans un petit réseau, mais une fois que le nombre de validateurs augmente, la charge de communication du système deviendra rapidement insoutenable, et l'efficacité s'effondrera directement.
Cette structure de communication secondaire où "chacun doit communiquer avec tout le monde" est en réalité très inefficace. Par exemple, dans un réseau de 100 validateurs, chaque cycle de consensus peut nécessiter le traitement de plusieurs milliers de messages.
Cela peut fonctionner dans un petit cercle, mais lorsque cela est placé dans un réseau ouvert de blockchain à l'échelle mondiale, la charge de communication devient immédiatement inacceptable. Ainsi, des protocoles BFT précoces comme PBFT et Tendermint sont généralement utilisés uniquement dans des scénarios à accès contrôlé (réseau permissionné) ou dans des systèmes avec peu de validateurs, où ils peuvent à peine fonctionner.
Pour permettre au protocole BFT de s'adapter à un environnement public sans autorisation, certaines conceptions de nouvelle génération commencent à adopter des modes de communication plus légers : faire en sorte que chaque validateurs communique uniquement avec le leader, plutôt qu'avec tous les membres.
Cela a réduit la complexité du message de n² à n —— allégeant considérablement la charge du système.
Le protocole HotStuff a été proposé en 2018, précisément pour résoudre ce problème d'évolutivité. Son idée directrice est très claire : remplacer le processus de vote complexe de PBFT par une structure de communication plus simple et dirigée par un leader.
La caractéristique clé de HotStuff est ce que l'on appelle la communication linéaire (linear communication). Dans son mécanisme, chaque validateur n'a besoin d'envoyer son vote qu'au leader actuel, qui regroupe ensuite ces votes pour générer un Quorum Certificate (QC, certificat de majorité légale).
Ce QC est essentiellement une signature collective, prouvant à l'ensemble du réseau : "La plupart des nœuds ont approuvé cette proposition."
En comparaison, le mode de communication de PBFT est « diffusion de tous », chacun parle dans le groupe, ce qui rend la situation très chaotique. Le mode de HotStuff ressemble davantage à « un collecte, un paquet », peu importe le nombre de personnes dans le réseau, il peut toujours fonctionner efficacement.
En plus de la communication linéaire, HotStuff peut également être mis à niveau vers une version pipelinaire (pipelined HotStuff) pour améliorer l'efficacité.
Dans le HotStuff d'origine, le même validateur occupe successivement plusieurs tours de leader jusqu'à ce qu'un bloc soit complètement confirmé. Ce processus consiste à "traiter un bloc par tour", toute l'énergie étant concentrée sur l'avancement de celui-ci.
Dans la chaîne de production HotStuff, le mécanisme est encore plus flexible : à chaque tour, un nouveau leader est sélectionné, et chaque leader a deux tâches :
D'un côté, empaquetez le vote de la dernière ronde en un Certificat de Quorum (QC) et diffusez-le à l'ensemble du réseau ;
Proposer un nouveau bloc d'un côté, prêt à lancer le prochain tour.
Cela signifie qu'il ne s'agit plus de "confirmer un puis de traiter le suivant", mais plutôt comme une chaîne de production, où différents leaders sont responsables de chaque étape à tour de rôle. Le précédent propose un Bloc, le suivant le confirme et continue à proposer de nouveaux Blocs, le Consensus sur la chaîne se transmet comme un relais.
C'est ainsi que vient la métaphore de "la chaîne de montage" : le bloc actuel est encore en cours de processus de confirmation, tandis que le suivant est déjà en préparation, avec plusieurs étapes parallèles, augmentant l'efficacité du débit.
En résumé, les protocoles comme HotStuff ont réalisé des améliorations significatives par rapport au BFT traditionnel sur deux dimensions :
Premièrement, la communication est plus légère, chaque validateurs n'a besoin de communiquer qu'avec le leader ;
Deuxièmement, l'efficacité de traitement est plus élevée, plusieurs processus de confirmation de blocs peuvent être parallèles.
Cela a fait de HotStuff un modèle de conception pour de nombreux mécanismes de consensus Blockchain modernes PoS. Mais comme tout, il y a des avantages et des inconvénients - bien que la structure en pipeline soit performante, elle introduit discrètement un risque structurel qui n'est pas facile à détecter.
Ensuite, nous allons approfondir cette question centrale : le Forking de Queue (Tail Forking).
Problème de bifurcation de queue (Tail-Forking)
Bien que HotStuff — en particulier sa version en pipeline — résolve le problème d'évolutivité des protocoles de consensus, il introduit également de nouveaux défis. Le plus crucial, et le plus facilement négligé, est ce que l'on appelle le problème de "Tail Forking".
Qu'est-ce qu'un fork terminal ? On peut le comprendre simplement comme : une reconfiguration inattendue d'un bloc se produisant à la "queue" de la Blockchain (reorg).
Plus précisément, il y a un bloc qui est valide, a déjà été propagé avec succès à la majorité des validateurs et a reçu suffisamment de votes de soutien. En théorie, il devrait être immédiatement confirmé et inscrit dans la chaîne principale. Mais finalement, il a été "sauté", abandonné (orphané), remplacé par un autre nouveau bloc au même niveau.
Ce n'est pas un Bug, ni une attaque, mais c'est parce qu'il existe dans la structure de conception même du protocole la possibilité de ce type de "chute de chaîne". Cela ne semble-t-il pas un peu injuste ? Alors, comment cela se produit-il vraiment ?
Nous avons mentionné précédemment que chaque leader de la chaîne de blocs HotStuff a deux tâches :
A. Proposer un nouveau Bloc (par exemple Bₙ₊₁)
B. Collecter les votes pour le bloc du leader précédent, générer QC (par exemple, finaliser la confirmation pour Bₙ)
Ces deux tâches sont parallèles, se relayant alternativement. Mais le problème réside ici.
Prenons un exemple : supposons qu'Alice soit la leader, elle a proposé le bloc Bₙ à la hauteur n, ce bloc a obtenu le vote d'une super majorité et est déjà "presque confirmé". Ensuite, c'est au tour de Bob d'assumer le rôle de leader et de continuer à avancer le prochain bloc de la chaîne Bₙ₊₁, tout en devant également inclure le QC (preuve de majorité légale) de Bₙ dans sa proposition, afin de finaliser la confirmation de Bₙ.
Mais si Bob est hors ligne à ce moment-là, ou refuse délibérément de soumettre le QC de Bₙ, cela pose problème.
Parce qu'aucune personne n'a terminé le QC pour le bloc d'Alice, l'enregistrement de vote de Bₙ n'a pas pu se propager, et ce bloc qui aurait dû être confirmé a été "mis de côté", étant finalement ignoré par l'ensemble du réseau.
C'est la nature de la fourchette terminale : le bloc de l'ancien leader est sauté en raison de l'inaction ou de la malveillance du nouveau leader.
Pourquoi la bifurcation à la fin est-elle grave ?
Les problèmes de bifurcation à la fin se concentrent principalement sur deux aspects : 1) le mécanisme d'incitation est compromis, 2) l'activité du système est menacée.
Premièrement, la récompense est avalée : un bloc qui est abandonné ne rapportera aucune récompense à son leader. Que ce soit la récompense de création de bloc ou les frais de transaction. Par exemple, si Alice soumet un bloc valide et obtient le soutien d'une super majorité de votes, mais que, en raison d'une erreur de Bob ou d'une manipulation malveillante, ce bloc n'est pas confirmé, Alice ne recevra finalement aucun centime. Cela conduira à une structure d'incitation erronée : des nœuds malveillants comme Bob peuvent "coupurer" la source de récompense de leurs concurrents en sautant leurs blocs. Ce comportement ne nécessite pas d'attaque technique, il suffit d'une "non-coopération" délibérée pour affaiblir les gains des concurrents. Si cela se produit de manière répétée, au fil du temps, cela réduira la participation et l'équité de l'ensemble du système, voire incitera à la collusion entre les nœuds.
Deuxièmement, l'espace d'attaque MEV s'élargit : la bifurcation en queue entraîne également un problème plus caché mais sérieux : l'espace de manipulation malveillante du MEV (Maximum Extractable Value) s'est agrandi. Prenons un exemple : supposons qu'il y ait une transaction d'arbitrage de grande valeur dans le bloc d'Alice. Si Bob veut créer des problèmes, il peut s'entendre avec le prochain leader, Carol, pour ne pas diffuser le bloc d'Alice. Ensuite, Carol peut reconstruire un nouveau bloc à la même hauteur et « voler » la transaction d'arbitrage d'Alice - transformant ainsi les bénéfices du MEV en siens. Cette méthode de « réorganisation de la chaîne + détournement concerté » semble à première vue respecter les règles de création de blocs, mais en réalité, c'est un pillage soigneusement conçu. Pire encore, cela incite les leaders à établir des « relations de complicité », faisant de la confirmation des blocs un jeu de distribution de bénéfices, plutôt qu'un service public.
Troisièmement, la destruction de la garantie d'irrévocabilité affecte l'expérience utilisateur : par rapport aux protocoles de type Nakamoto, un grand avantage du BFT est l'irrévocabilité déterministe : une fois qu'un bloc est soumis, il ne peut pas être annulé. Cependant, les forks en queue détruisent cette garantie, en particulier pour les blocs qui "ont reçu des votes mais n'ont pas encore été officiellement confirmés". Certains dapps à haut débit espèrent généralement pouvoir lire les données immédiatement après l'approbation du vote du bloc pour réduire la latence, et si ce bloc est soudainement abandonné, cela peut entraîner un retour en arrière de l'état de l'utilisateur - par exemple, un solde de compte anormal, des transactions à effet de levier récemment complétées disparaissant sans raison, ou l'état d'un jeu se réinitialisant soudainement.
Quatrièmement, cela peut provoquer des défaillances en cascade : d’une manière générale, les fourches arrière peuvent seulement provoquer la confirmation d’un blocage avec un tour de retard, et l’impact n’est pas significatif. Cependant, dans certains scénarios marginaux, si plusieurs leaders d’affilée choisissent de sauter le bloc précédent, le système peut s’arrêter et personne ne veut « reprendre » le bloc précédent. Toute la chaîne est bloquée en cours jusqu’à ce qu’il y ait enfin un leader qui est « prêt à prendre la responsabilité » et que le réseau avance.
Bien qu'il y ait eu précédemment quelques solutions, comme le mécanisme d'évitement des forks de fin proposé par le protocole BeeGees, cela nécessite souvent de sacrifier la performance, par exemple en réintroduisant la complexité de la communication secondaire, ce qui n'en vaut pas la peine.
Qu'est-ce que MonadBFT ?
MonadBFT est un nouveau protocole de consensus conçu spécifiquement pour résoudre le problème de la bifurcation terminale. Sa force réside dans le fait que, tout en résolvant les risques structurels, il n'a pas sacrifié les avantages de performance apportés par le pipeline HotStuff. En d'autres termes, MonadBFT ne s'agit pas de tout remettre à zéro, mais de continuer à optimiser sur la base du cadre central de HotStuff. Il conserve trois caractéristiques clés :
Leader rotatif (rotating leader) : à chaque tour, un nouveau leader est choisi pour faire avancer la chaîne ;
Soumissions en pipeline (pipelined commits) : plusieurs processus de confirmation de blocs peuvent se chevaucher.
Communication linéaire (linear messaging) : chaque validateurs n'a besoin de communiquer qu'avec le leader, économisant ainsi une grande quantité de frais de réseau.
Mais ces trois points à eux seuls ne suffisent pas à garantir la sécurité. Pour combler la vulnérabilité structurelle de la bifurcation terminale, MonadBFT a ajouté deux mécanismes clés :
Mécanisme de re-proposition (Re-Proposal)
Certificat sans endossement (NEC, No-Endorsement Certificate)
Mécanisme de Re-proposition (Re-Proposal)
Dans le protocole BFT, le temps est divisé en tours (appelés view), chaque tour ayant un leader responsable de la proposition d'un nouveau Bloc. Si le leader échoue (par exemple, ne propose pas le Bloc à temps ou si la proposition est invalide), le système passera au tour suivant et élira un nouveau leader.
MonadBFT a ajouté un mécanisme qui garantit que, lors du changement de vue, aucun bloc proposé honnêtement ne sera "perdu" en raison de la rotation du leader.
Lorsque le leader actuel échoue, les validateurs envoient un message de changement de vue signé, indiquant que le tour actuel a expiré.
Particulièrement, ce message ne signifie pas seulement "temps écoulé", mais doit également contenir les informations sur le bloc du dernier vote de ce validateurs, ce qui revient à dire : "Je n'ai pas reçu de proposition valide, voici le dernier bloc que je vois actuellement."
Le nouveau leader collectera ces messages de dépassement de délai auprès d'une super majorité (2f+1) de validateurs et les combinera en un certificat de dépassement de délai (Timeout Certificate, TC). Ce TC représente : lorsque le tour précédent échoue, un instantané de la compréhension unifiée du réseau sur le "Bloc de tête de chaîne". Le nouveau leader sélectionnera le bloc de la plus haute hauteur (ou du dernier numéro de vue), appelé high_tip.
Exigences de MonadBFT : la proposition du nouveau leader doit inclure un TC valide et doit re-proposer le bloc en attente le plus élevé dans le TC, afin que ce bloc ait à nouveau une chance d'être confirmé.
Pourquoi ? Comme nous l'avons mentionné précédemment : nous ne voulons pas qu'un Bloc proche d'être confirmé disparaisse.
Prenons un exemple : supposons qu'Alice soit la leader du view 5, qu'elle ait proposé un bloc valide et obtenu la majorité des votes. Ensuite, le leader du view 6, Bob, est hors ligne et n'a pas réussi à faire avancer le processus de la chaîne. Lorsque Carol devient la leader du view 7, selon les règles de MonadBFT, elle doit inclure TC et proposer à nouveau le bloc d'Alice. Ainsi, le travail honnête d'Alice ne sera pas vain.
Si Carol n'a pas le Bloc d'Alice, elle peut en demander à d'autres Nœuds. Les Nœuds peuvent :
Fournir ce Bloc, ou
Retourne un message « sans endorsement » (No-Endorsement, NE) signé, indiquant qu'il ne possède pas ce bloc (la mécanique sera présentée plus tard). (Au maximum, f nœuds byzantins pourraient choisir d'ignorer la demande et de ne pas répondre.)
Une fois que Carol aura réintroduit le bloc d'Alice, elle obtiendra une opportunité de proposition supplémentaire, garantissant qu'elle ne sera pas "puni" en raison de l'échec du leader précédent.
Le rôle de ce mécanisme de réexamen est clair : garantir que l'avancement de la chaîne est équitable et qu'aucun travail valide ne sera discrètement abandonné en raison de malchance ou de perturbations.
Certificat sans endossement (NEC)
Pour continuer 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 moment-là, au moins 2f+1 validateurs répondront :
Soit fournir le bloc d'Alice
Envoyer un message NE signé, indiquant qu'il n'a pas reçu le Bloc d'Alice.
Dès que Carol a reçu le Bloc d'Alice, elle doit le proposer à nouveau conformément aux règles. Carol ne peut sauter ce Bloc et en proposer un nouveau que si au moins f+1 validateurs ont signé le message NE.
Pourquoi f+1 ? Dans un système BFT composé de 3f+1 validateurs, il ne peut y avoir au maximum que f malfaiteurs. Si le bloc d'Alice a effectivement reçu un vote de la super majorité, alors au moins 2f+1 nœuds honnêtes l'ont reçu.
Ainsi, si Carol prétend "je ne peux pas obtenir le bloc d'Alice", elle doit fournir f+1 signatures de validateurs, prouvant que ces personnes n'ont pas reçu. Cela constitue un certificat sans endorsement (No-Endorsement Certificate, NEC).
NEC est le certificat de "non-responsabilité" des leaders : c'est une preuve vérifiable indiquant que le bloc précédent n'est pas encore prêt à être confirmé, qu'il ne s'agit pas d'un saut malveillant, mais d'un "abandon" justifié.
Nouvelle proposition + Certificat sans endorsement = Résoudre le fork terminal
MonadBFT établit un ensemble de règles de traitement de la tête de chaîne rigoureuses et claires en introduisant le mécanisme de re-proposition (Re-Proposal) et le certificat sans endorsement (NEC, No-Endorsement Certificate) :
Soit finaliser la soumission d'un bloc "proche d'être confirmé" ; soit fournir suffisamment de preuves pour démontrer que ce bloc ne répond pas aux conditions d'être confirmé, sinon, il n'est pas permis de sauter ou de remplacer le bloc précédent.
Ce mécanisme garantit que : tout bloc ayant obtenu une majorité légale de votes ne sera pas abandonné en raison d'une erreur du leader ou d'une esquive intentionnelle. Le risque structurel de bifurcation de fin est systématiquement résolu, et le protocole peut imposer des contraintes claires sur les comportements de saut inappropriés.
Si un leader tente sans raison de sauter le bloc précédent, mais qu'il ne fournit pas de preuve NEC, le protocole reconnaîtra immédiatement et rejettera ce comportement. Un 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 qu'un bloc est proposé honnêtement et soutenu par un vote, sa récompense ne sera pas dépouillée en raison d'une défaillance dans les étapes suivantes ;
Même dans des situations extrêmes, par exemple lorsqu'un nœud saute délibérément son tour de proposition pour tenter d'aider d'autres à s'emparer du MEV du bloc précédent, le protocole obligera le leader suivant à re-proposer le bloc original, empêchant ainsi l'attaquant de tirer un profit économique en sautant le processus.
Plus important encore, MonadBFT n'a pas sacrifié les performances du protocole pour améliorer la sécurité.
Certaines conceptions pour faire face aux bifurcations finales (comme le protocole BeeGees) possédaient une certaine capacité de protection, mais elles reposaient souvent sur une complexité de communication élevée (n²) ou nécessitaient un processus de communication redondant à chaque cycle, ce qui augmente considérablement la charge du système en pratique.
La stratégie de conception de MonadBFT est donc plus raffinée :
Une communication supplémentaire (comme des messages de délai d'attente, des propositions de bloc) ne doit être lancée qu'en cas d'échec de la vue ou d'exception. Dans la plupart des chemins réguliers où des leaders honnêtes produisent des blocs consécutivement, le protocole maintient toujours un état de fonctionnement léger et efficace.
Cet équilibre dynamique entre performance et sécurité est l'un des principaux avantages de MonadBFT par rapport aux protocoles précédents.
Résumé
Cet article passe en revue les mécanismes de base du consensus PBFT traditionnel, retrace le parcours de développement du protocole HotStuff et explique en détail comment MonadBFT résout, au niveau de la structure du protocole, le problème de bifurcation terminale inhérent à HotStuff en mode pipeline.
La bifurcation de la fin peut déformer les incitations économiques des proposeurs de blocs et constitue également une menace potentielle pour l'activité du réseau. MonadBFT garantit qu'aucun bloc proposé par un leader honnête et ayant obtenu un vote de majorité légale ne sera abandonné ou sauté, grâce à l'introduction d'un mécanisme de ré-proposition et de certificats sans endossement (NEC).
Dans le prochain article, nous continuerons à explorer deux autres caractéristiques clés de MonadBFT :
Finalité spéculative
Réactivité Optimiste
et analyser davantage la signification réelle de ces mécanismes pour les validateurs et les développeurs.
À suivre.
Voir l'original
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
MonadBFT analyse (partie 1) : comment résoudre le problème des forks de fin
Le cœur de la blockchain réside dans la réalisation d'un consensus mondial strict : c'est-à-dire que peu importe où les nœuds du réseau sont répartis, dans quel pays ou fuseau horaire, tous les participants doivent finalement s'accorder sur un ensemble de résultats objectifs.
Mais les réseaux distribués dans la réalité ne sont pas idéaux : il y a des nœuds qui se déconnectent, des nœuds qui mentent, et même des gens qui sabotent intentionnellement. Dans ce cas, comment le système parvient-il à maintenir un "consensus" et à rester cohérent ?
C'est le problème que le protocole de consensus doit résoudre. C'est essentiellement un ensemble de règles qui guide un groupe de nœuds indépendants, voire pas totalement fiables, sur la manière de parvenir à un accord uniforme sur l'ordre et le contenu de chaque transaction.
Une fois que ce "consensus strict" est établi, la blockchain peut débloquer de nombreuses caractéristiques clés, telles que la protection des droits de propriété numériques, un modèle monétaire anti-inflation et une structure de collaboration sociale extensible. Mais à condition que le protocole de consensus lui-même garantisse simultanément deux fondamentaux :
Il ne peut pas y avoir deux blocs en conflit qui soient tous deux confirmés ;
Le réseau doit continuer à avancer, il ne doit pas être bloqué ou à l'arrêt.
MonadBFT est la dernière percée technologique dans cette direction.
Revue brève de l'évolution du protocole de consensus
Le domaine des mécanismes de consensus a en fait été étudié pendant des décennies. Les premiers protocoles, comme le PBFT (Tolérance aux pannes byzantines pratiques), peuvent déjà gérer une situation très réaliste : même si une partie des nœuds du réseau tombe en panne, agit mal ou raconte des histoires, tant qu'ils ne dépassent pas 1/3 du total, le système peut encore parvenir à un consensus.
Ces premiers protocoles ont été conçus de manière plutôt "traditionnelle" : à chaque tour, un leader est choisi, qui propose une initiative, et les autres validateurs votent plusieurs fois sur cette initiative, confirmant progressivement l'ordre des transactions.
Le processus de vote entier passe généralement par plusieurs étapes, comme pre-prepare, prepare, commit, reply. À chaque étape, tous les validateurs doivent communiquer entre eux. En d'autres termes, tout le monde doit parler à tout le monde, et la quantité de messages augmente de manière "en réseau" exponentielle.
La complexité de cette structure de communication est n² - c'est-à-dire que si le réseau compte 100 validateurs, alors chaque round de consensus pourrait nécessiter la transmission de près de 10 000 messages.
Cela ne pose pas de problème dans un petit réseau, mais une fois que le nombre de validateurs augmente, la charge de communication du système deviendra rapidement insoutenable, et l'efficacité s'effondrera directement.
Cette structure de communication secondaire où "chacun doit communiquer avec tout le monde" est en réalité très inefficace. Par exemple, dans un réseau de 100 validateurs, chaque cycle de consensus peut nécessiter le traitement de plusieurs milliers de messages.
Cela peut fonctionner dans un petit cercle, mais lorsque cela est placé dans un réseau ouvert de blockchain à l'échelle mondiale, la charge de communication devient immédiatement inacceptable. Ainsi, des protocoles BFT précoces comme PBFT et Tendermint sont généralement utilisés uniquement dans des scénarios à accès contrôlé (réseau permissionné) ou dans des systèmes avec peu de validateurs, où ils peuvent à peine fonctionner.
Pour permettre au protocole BFT de s'adapter à un environnement public sans autorisation, certaines conceptions de nouvelle génération commencent à adopter des modes de communication plus légers : faire en sorte que chaque validateurs communique uniquement avec le leader, plutôt qu'avec tous les membres.
Cela a réduit la complexité du message de n² à n —— allégeant considérablement la charge du système.
Le protocole HotStuff a été proposé en 2018, précisément pour résoudre ce problème d'évolutivité. Son idée directrice est très claire : remplacer le processus de vote complexe de PBFT par une structure de communication plus simple et dirigée par un leader.
La caractéristique clé de HotStuff est ce que l'on appelle la communication linéaire (linear communication). Dans son mécanisme, chaque validateur n'a besoin d'envoyer son vote qu'au leader actuel, qui regroupe ensuite ces votes pour générer un Quorum Certificate (QC, certificat de majorité légale).
Ce QC est essentiellement une signature collective, prouvant à l'ensemble du réseau : "La plupart des nœuds ont approuvé cette proposition."
En comparaison, le mode de communication de PBFT est « diffusion de tous », chacun parle dans le groupe, ce qui rend la situation très chaotique. Le mode de HotStuff ressemble davantage à « un collecte, un paquet », peu importe le nombre de personnes dans le réseau, il peut toujours fonctionner efficacement.
En plus de la communication linéaire, HotStuff peut également être mis à niveau vers une version pipelinaire (pipelined HotStuff) pour améliorer l'efficacité.
Dans le HotStuff d'origine, le même validateur occupe successivement plusieurs tours de leader jusqu'à ce qu'un bloc soit complètement confirmé. Ce processus consiste à "traiter un bloc par tour", toute l'énergie étant concentrée sur l'avancement de celui-ci.
Dans la chaîne de production HotStuff, le mécanisme est encore plus flexible : à chaque tour, un nouveau leader est sélectionné, et chaque leader a deux tâches :
D'un côté, empaquetez le vote de la dernière ronde en un Certificat de Quorum (QC) et diffusez-le à l'ensemble du réseau ;
Proposer un nouveau bloc d'un côté, prêt à lancer le prochain tour.
Cela signifie qu'il ne s'agit plus de "confirmer un puis de traiter le suivant", mais plutôt comme une chaîne de production, où différents leaders sont responsables de chaque étape à tour de rôle. Le précédent propose un Bloc, le suivant le confirme et continue à proposer de nouveaux Blocs, le Consensus sur la chaîne se transmet comme un relais.
C'est ainsi que vient la métaphore de "la chaîne de montage" : le bloc actuel est encore en cours de processus de confirmation, tandis que le suivant est déjà en préparation, avec plusieurs étapes parallèles, augmentant l'efficacité du débit.
En résumé, les protocoles comme HotStuff ont réalisé des améliorations significatives par rapport au BFT traditionnel sur deux dimensions :
Premièrement, la communication est plus légère, chaque validateurs n'a besoin de communiquer qu'avec le leader ;
Deuxièmement, l'efficacité de traitement est plus élevée, plusieurs processus de confirmation de blocs peuvent être parallèles.
Cela a fait de HotStuff un modèle de conception pour de nombreux mécanismes de consensus Blockchain modernes PoS. Mais comme tout, il y a des avantages et des inconvénients - bien que la structure en pipeline soit performante, elle introduit discrètement un risque structurel qui n'est pas facile à détecter.
Ensuite, nous allons approfondir cette question centrale : le Forking de Queue (Tail Forking).
Problème de bifurcation de queue (Tail-Forking)
Bien que HotStuff — en particulier sa version en pipeline — résolve le problème d'évolutivité des protocoles de consensus, il introduit également de nouveaux défis. Le plus crucial, et le plus facilement négligé, est ce que l'on appelle le problème de "Tail Forking".
Qu'est-ce qu'un fork terminal ? On peut le comprendre simplement comme : une reconfiguration inattendue d'un bloc se produisant à la "queue" de la Blockchain (reorg).
Plus précisément, il y a un bloc qui est valide, a déjà été propagé avec succès à la majorité des validateurs et a reçu suffisamment de votes de soutien. En théorie, il devrait être immédiatement confirmé et inscrit dans la chaîne principale. Mais finalement, il a été "sauté", abandonné (orphané), remplacé par un autre nouveau bloc au même niveau.
Ce n'est pas un Bug, ni une attaque, mais c'est parce qu'il existe dans la structure de conception même du protocole la possibilité de ce type de "chute de chaîne". Cela ne semble-t-il pas un peu injuste ? Alors, comment cela se produit-il vraiment ?
Nous avons mentionné précédemment que chaque leader de la chaîne de blocs HotStuff a deux tâches :
A. Proposer un nouveau Bloc (par exemple Bₙ₊₁)
B. Collecter les votes pour le bloc du leader précédent, générer QC (par exemple, finaliser la confirmation pour Bₙ)
Ces deux tâches sont parallèles, se relayant alternativement. Mais le problème réside ici.
Prenons un exemple : supposons qu'Alice soit la leader, elle a proposé le bloc Bₙ à la hauteur n, ce bloc a obtenu le vote d'une super majorité et est déjà "presque confirmé". Ensuite, c'est au tour de Bob d'assumer le rôle de leader et de continuer à avancer le prochain bloc de la chaîne Bₙ₊₁, tout en devant également inclure le QC (preuve de majorité légale) de Bₙ dans sa proposition, afin de finaliser la confirmation de Bₙ.
Mais si Bob est hors ligne à ce moment-là, ou refuse délibérément de soumettre le QC de Bₙ, cela pose problème.
Parce qu'aucune personne n'a terminé le QC pour le bloc d'Alice, l'enregistrement de vote de Bₙ n'a pas pu se propager, et ce bloc qui aurait dû être confirmé a été "mis de côté", étant finalement ignoré par l'ensemble du réseau.
C'est la nature de la fourchette terminale : le bloc de l'ancien leader est sauté en raison de l'inaction ou de la malveillance du nouveau leader.
Pourquoi la bifurcation à la fin est-elle grave ?
Les problèmes de bifurcation à la fin se concentrent principalement sur deux aspects : 1) le mécanisme d'incitation est compromis, 2) l'activité du système est menacée.
Premièrement, la récompense est avalée : un bloc qui est abandonné ne rapportera aucune récompense à son leader. Que ce soit la récompense de création de bloc ou les frais de transaction. Par exemple, si Alice soumet un bloc valide et obtient le soutien d'une super majorité de votes, mais que, en raison d'une erreur de Bob ou d'une manipulation malveillante, ce bloc n'est pas confirmé, Alice ne recevra finalement aucun centime. Cela conduira à une structure d'incitation erronée : des nœuds malveillants comme Bob peuvent "coupurer" la source de récompense de leurs concurrents en sautant leurs blocs. Ce comportement ne nécessite pas d'attaque technique, il suffit d'une "non-coopération" délibérée pour affaiblir les gains des concurrents. Si cela se produit de manière répétée, au fil du temps, cela réduira la participation et l'équité de l'ensemble du système, voire incitera à la collusion entre les nœuds.
Deuxièmement, l'espace d'attaque MEV s'élargit : la bifurcation en queue entraîne également un problème plus caché mais sérieux : l'espace de manipulation malveillante du MEV (Maximum Extractable Value) s'est agrandi. Prenons un exemple : supposons qu'il y ait une transaction d'arbitrage de grande valeur dans le bloc d'Alice. Si Bob veut créer des problèmes, il peut s'entendre avec le prochain leader, Carol, pour ne pas diffuser le bloc d'Alice. Ensuite, Carol peut reconstruire un nouveau bloc à la même hauteur et « voler » la transaction d'arbitrage d'Alice - transformant ainsi les bénéfices du MEV en siens. Cette méthode de « réorganisation de la chaîne + détournement concerté » semble à première vue respecter les règles de création de blocs, mais en réalité, c'est un pillage soigneusement conçu. Pire encore, cela incite les leaders à établir des « relations de complicité », faisant de la confirmation des blocs un jeu de distribution de bénéfices, plutôt qu'un service public.
Troisièmement, la destruction de la garantie d'irrévocabilité affecte l'expérience utilisateur : par rapport aux protocoles de type Nakamoto, un grand avantage du BFT est l'irrévocabilité déterministe : une fois qu'un bloc est soumis, il ne peut pas être annulé. Cependant, les forks en queue détruisent cette garantie, en particulier pour les blocs qui "ont reçu des votes mais n'ont pas encore été officiellement confirmés". Certains dapps à haut débit espèrent généralement pouvoir lire les données immédiatement après l'approbation du vote du bloc pour réduire la latence, et si ce bloc est soudainement abandonné, cela peut entraîner un retour en arrière de l'état de l'utilisateur - par exemple, un solde de compte anormal, des transactions à effet de levier récemment complétées disparaissant sans raison, ou l'état d'un jeu se réinitialisant soudainement.
Quatrièmement, cela peut provoquer des défaillances en cascade : d’une manière générale, les fourches arrière peuvent seulement provoquer la confirmation d’un blocage avec un tour de retard, et l’impact n’est pas significatif. Cependant, dans certains scénarios marginaux, si plusieurs leaders d’affilée choisissent de sauter le bloc précédent, le système peut s’arrêter et personne ne veut « reprendre » le bloc précédent. Toute la chaîne est bloquée en cours jusqu’à ce qu’il y ait enfin un leader qui est « prêt à prendre la responsabilité » et que le réseau avance.
Bien qu'il y ait eu précédemment quelques solutions, comme le mécanisme d'évitement des forks de fin proposé par le protocole BeeGees, cela nécessite souvent de sacrifier la performance, par exemple en réintroduisant la complexité de la communication secondaire, ce qui n'en vaut pas la peine.
Qu'est-ce que MonadBFT ?
MonadBFT est un nouveau protocole de consensus conçu spécifiquement pour résoudre le problème de la bifurcation terminale. Sa force réside dans le fait que, tout en résolvant les risques structurels, il n'a pas sacrifié les avantages de performance apportés par le pipeline HotStuff. En d'autres termes, MonadBFT ne s'agit pas de tout remettre à zéro, mais de continuer à optimiser sur la base du cadre central de HotStuff. Il conserve trois caractéristiques clés :
Leader rotatif (rotating leader) : à chaque tour, un nouveau leader est choisi pour faire avancer la chaîne ;
Soumissions en pipeline (pipelined commits) : plusieurs processus de confirmation de blocs peuvent se chevaucher.
Communication linéaire (linear messaging) : chaque validateurs n'a besoin de communiquer qu'avec le leader, économisant ainsi une grande quantité de frais de réseau.
Mais ces trois points à eux seuls ne suffisent pas à garantir la sécurité. Pour combler la vulnérabilité structurelle de la bifurcation terminale, MonadBFT a ajouté deux mécanismes clés :
Mécanisme de re-proposition (Re-Proposal)
Certificat sans endossement (NEC, No-Endorsement Certificate)
Mécanisme de Re-proposition (Re-Proposal)
Dans le protocole BFT, le temps est divisé en tours (appelés view), chaque tour ayant un leader responsable de la proposition d'un nouveau Bloc. Si le leader échoue (par exemple, ne propose pas le Bloc à temps ou si la proposition est invalide), le système passera au tour suivant et élira un nouveau leader.
MonadBFT a ajouté un mécanisme qui garantit que, lors du changement de vue, aucun bloc proposé honnêtement ne sera "perdu" en raison de la rotation du leader.
Lorsque le leader actuel échoue, les validateurs envoient un message de changement de vue signé, indiquant que le tour actuel a expiré.
Particulièrement, ce message ne signifie pas seulement "temps écoulé", mais doit également contenir les informations sur le bloc du dernier vote de ce validateurs, ce qui revient à dire : "Je n'ai pas reçu de proposition valide, voici le dernier bloc que je vois actuellement."
Le nouveau leader collectera ces messages de dépassement de délai auprès d'une super majorité (2f+1) de validateurs et les combinera en un certificat de dépassement de délai (Timeout Certificate, TC). Ce TC représente : lorsque le tour précédent échoue, un instantané de la compréhension unifiée du réseau sur le "Bloc de tête de chaîne". Le nouveau leader sélectionnera le bloc de la plus haute hauteur (ou du dernier numéro de vue), appelé high_tip.
Exigences de MonadBFT : la proposition du nouveau leader doit inclure un TC valide et doit re-proposer le bloc en attente le plus élevé dans le TC, afin que ce bloc ait à nouveau une chance d'être confirmé.
Pourquoi ? Comme nous l'avons mentionné précédemment : nous ne voulons pas qu'un Bloc proche d'être confirmé disparaisse.
Prenons un exemple : supposons qu'Alice soit la leader du view 5, qu'elle ait proposé un bloc valide et obtenu la majorité des votes. Ensuite, le leader du view 6, Bob, est hors ligne et n'a pas réussi à faire avancer le processus de la chaîne. Lorsque Carol devient la leader du view 7, selon les règles de MonadBFT, elle doit inclure TC et proposer à nouveau le bloc d'Alice. Ainsi, le travail honnête d'Alice ne sera pas vain.
Si Carol n'a pas le Bloc d'Alice, elle peut en demander à d'autres Nœuds. Les Nœuds peuvent :
Fournir ce Bloc, ou
Retourne un message « sans endorsement » (No-Endorsement, NE) signé, indiquant qu'il ne possède pas ce bloc (la mécanique sera présentée plus tard). (Au maximum, f nœuds byzantins pourraient choisir d'ignorer la demande et de ne pas répondre.)
Une fois que Carol aura réintroduit le bloc d'Alice, elle obtiendra une opportunité de proposition supplémentaire, garantissant qu'elle ne sera pas "puni" en raison de l'échec du leader précédent.
Le rôle de ce mécanisme de réexamen est clair : garantir que l'avancement de la chaîne est équitable et qu'aucun travail valide ne sera discrètement abandonné en raison de malchance ou de perturbations.
Certificat sans endossement (NEC)
Pour continuer 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 moment-là, au moins 2f+1 validateurs répondront :
Soit fournir le bloc d'Alice
Envoyer un message NE signé, indiquant qu'il n'a pas reçu le Bloc d'Alice.
Dès que Carol a reçu le Bloc d'Alice, elle doit le proposer à nouveau conformément aux règles. Carol ne peut sauter ce Bloc et en proposer un nouveau que si au moins f+1 validateurs ont signé le message NE.
Pourquoi f+1 ? Dans un système BFT composé de 3f+1 validateurs, il ne peut y avoir au maximum que f malfaiteurs. Si le bloc d'Alice a effectivement reçu un vote de la super majorité, alors au moins 2f+1 nœuds honnêtes l'ont reçu.
Ainsi, si Carol prétend "je ne peux pas obtenir le bloc d'Alice", elle doit fournir f+1 signatures de validateurs, prouvant que ces personnes n'ont pas reçu. Cela constitue un certificat sans endorsement (No-Endorsement Certificate, NEC).
NEC est le certificat de "non-responsabilité" des leaders : c'est une preuve vérifiable indiquant que le bloc précédent n'est pas encore prêt à être confirmé, qu'il ne s'agit pas d'un saut malveillant, mais d'un "abandon" justifié.
Nouvelle proposition + Certificat sans endorsement = Résoudre le fork terminal
MonadBFT établit un ensemble de règles de traitement de la tête de chaîne rigoureuses et claires en introduisant le mécanisme de re-proposition (Re-Proposal) et le certificat sans endorsement (NEC, No-Endorsement Certificate) :
Soit finaliser la soumission d'un bloc "proche d'être confirmé" ; soit fournir suffisamment de preuves pour démontrer que ce bloc ne répond pas aux conditions d'être confirmé, sinon, il n'est pas permis de sauter ou de remplacer le bloc précédent.
Ce mécanisme garantit que : tout bloc ayant obtenu une majorité légale de votes ne sera pas abandonné en raison d'une erreur du leader ou d'une esquive intentionnelle. Le risque structurel de bifurcation de fin est systématiquement résolu, et le protocole peut imposer des contraintes claires sur les comportements de saut inappropriés.
Si un leader tente sans raison de sauter le bloc précédent, mais qu'il ne fournit pas de preuve NEC, le protocole reconnaîtra immédiatement et rejettera ce comportement. Un 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 qu'un bloc est proposé honnêtement et soutenu par un vote, sa récompense ne sera pas dépouillée en raison d'une défaillance dans les étapes suivantes ;
Même dans des situations extrêmes, par exemple lorsqu'un nœud saute délibérément son tour de proposition pour tenter d'aider d'autres à s'emparer du MEV du bloc précédent, le protocole obligera le leader suivant à re-proposer le bloc original, empêchant ainsi l'attaquant de tirer un profit économique en sautant le processus.
Plus important encore, MonadBFT n'a pas sacrifié les performances du protocole pour améliorer la sécurité.
Certaines conceptions pour faire face aux bifurcations finales (comme le protocole BeeGees) possédaient une certaine capacité de protection, mais elles reposaient souvent sur une complexité de communication élevée (n²) ou nécessitaient un processus de communication redondant à chaque cycle, ce qui augmente considérablement la charge du système en pratique.
La stratégie de conception de MonadBFT est donc plus raffinée :
Une communication supplémentaire (comme des messages de délai d'attente, des propositions de bloc) ne doit être lancée qu'en cas d'échec de la vue ou d'exception. Dans la plupart des chemins réguliers où des leaders honnêtes produisent des blocs consécutivement, le protocole maintient toujours un état de fonctionnement léger et efficace.
Cet équilibre dynamique entre performance et sécurité est l'un des principaux avantages de MonadBFT par rapport aux protocoles précédents.
Résumé
Cet article passe en revue les mécanismes de base du consensus PBFT traditionnel, retrace le parcours de développement du protocole HotStuff et explique en détail comment MonadBFT résout, au niveau de la structure du protocole, le problème de bifurcation terminale inhérent à HotStuff en mode pipeline.
La bifurcation de la fin peut déformer les incitations économiques des proposeurs de blocs et constitue également une menace potentielle pour l'activité du réseau. MonadBFT garantit qu'aucun bloc proposé par un leader honnête et ayant obtenu un vote de majorité légale ne sera abandonné ou sauté, grâce à l'introduction d'un mécanisme de ré-proposition et de certificats sans endossement (NEC).
Dans le prochain article, nous continuerons à explorer deux autres caractéristiques clés de MonadBFT :
Finalité spéculative
Réactivité Optimiste
et analyser davantage la signification réelle de ces mécanismes pour les validateurs et les développeurs.
À suivre.