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 situés, dans quel pays ou quel fuseau horaire, tous les participants doivent finalement parvenir à un accord 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 il y a même des personnes qui sabotent intentionnellement. Dans ce cas, comment le système peut-il être "d'accord à l'unanimité" et maintenir la cohérence ?
C'est le problème que le protocole de consensus doit résoudre. Il s'agit essentiellement d'un ensemble de règles visant à guider un groupe de nœuds indépendants, voire pas entièrement fiables, sur la manière de parvenir à un consensus 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 caractéristiques clés, telles que la protection de la propriété numérique, un modèle monétaire anti-inflation, et une structure de coopération sociale évolutive. Mais à condition que le protocole de consensus lui-même doive garantir simultanément deux aspects fondamentaux :
Il ne peut pas y avoir deux blocs conflictuels qui soient tous les deux confirmés;
Le réseau doit continuer d’avancer et ne pas rester bloqué ou arrêté.
MonadBFT est la dernière avancée technologique dans cette direction.
Un aperçu de l'évolution des protocoles de consensus
Le domaine des mécanismes de consensus a en fait été étudié pendant des dizaines d'années. Les premiers protocoles, comme le PBFT (Practical Byzantine Fault Tolerance), sont déjà capables de gérer une situation très réaliste : même si certains nœuds du réseau tombent en panne, agissent mal ou racontent des absurdités, tant qu'ils ne dépassent pas un tiers du total, le système peut encore parvenir à un consensus.
Ces protocoles initiaux étaient conçus de manière relativement "traditionnelle" : un leader est élu à chaque tour, qui initie une proposition, et les autres validateurs votent plusieurs fois sur cette proposition pour confirmer progressivement l'ordre des transactions.
Le processus de vote passe généralement par plusieurs étapes, telles que pre-prepare, prepare, commit, reply. À chaque étape, tous les validateurs doivent communiquer entre eux. En d'autres termes, chacun doit parler à tout le monde, ce qui entraîne une explosion du volume de messages en raison de la nature "maillée".
La complexité de cette structure de communication est n², c’est-à-dire que s’il y a 100 validateurs dans le réseau, chaque cycle de consensus peut transmettre près de 10 000 messages.
Cela ne pose pas de problème dans les petits réseaux, mais une fois que le nombre de validateurs augmente, la charge de communication du système devient rapidement insupportable, et l'efficacité s'effondre directement.
Source des données :
Ce genre de structure de communication secondaire de « tout le monde suit et communique avec tout le monde » est en fait très inefficace. Par exemple, dans un réseau de 100 validateurs, des dizaines de milliers de messages peuvent être traités par cycle de consensus.
Cela peut fonctionner dans un petit cercle, mais une fois mis en réseau sur une chaîne ouverte à l'échelle mondiale, la charge de communication devient immédiatement inacceptable. Ainsi, des protocoles BFT tels que PBFT et Tendermint sont généralement utilisés uniquement dans des scénarios de réseau autorisé (permissioned network) ou dans des systèmes avec un nombre très limité de validateurs, où ils peuvent à peine fonctionner.
Afin d’adapter le protocole BFT à un environnement de chaîne publique sans autorisation, certaines conceptions de nouvelle génération ont commencé à évoluer vers un mode de communication plus léger : chaque validateur ne communique qu’avec le leader, plutôt qu’avec tous les membres de l’équipe.
Cela a réduit la complexité des messages de n² à n, allégeant ainsi 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 principe de conception est très clair : remplacer le processus de vote complexe de PBFT par une structure de communication plus simple et pilotée par un leader.
La caractéristique clé de HotStuff est ce qu'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 Certificat de Quorum (QC, preuve de majorité légale).
Ce QC est essentiellement une signature collective qui prouve à l'ensemble du réseau : "La plupart des nœuds ont accepté cette proposition."
En comparaison, le mode de communication de PBFT est "broadcast total", tout le monde parle dans le groupe, ce qui rendait la situation très chaotique. Le mode de HotStuff ressemble davantage à "un collecte, un paquet", peu importe combien de personnes il y a dans le réseau, il peut toujours fonctionner de manière efficace.
La figure ci-dessus compare la structure de communication de HotStuff avec le modèle d’interconnexion à l’échelle du réseau de PBFT
Source des données :
En plus de la communication linéaire, HotStuff peut également être mis à niveau vers une version pipelined (HotStuff pipelined) pour améliorer l'efficacité.
Dans le HotStuff original, le même validateur servait de leader pendant plusieurs tours d’affilée jusqu’à ce qu’un bloc soit entièrement confirmé. Le processus se fait « un bloc à la fois », tous les efforts étant concentrés sur l’avancement du processus actuel.
Dans la chaîne de blocs HotStuff, le mécanisme est encore plus flexible : à chaque tour, un nouveau leader est choisi, et chaque leader a deux missions :
Emballer les votes de la dernière ronde en un Quorum Certificate (QC) et les diffuser à l'ensemble du réseau ;
Proposer un nouveau bloc tout en se préparant à ouvrir le prochain tour.
C'est-à-dire qu'il ne s'agit plus de "confirmer un bloc avant de traiter le suivant", mais plutôt d'un processus en chaîne où différents leaders sont responsables à tour de rôle de chaque étape. La personne précédente propose un bloc, la suivante le confirme et continue à proposer de nouveaux blocs, le consensus sur la chaîne se transmet comme dans une course de relais.
C'est l'origine de la métaphore « 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 en parallèle, augmentant l'efficacité du traitement.
En résumé, les protocoles comme HotStuff ont réalisé des avancées significatives par rapport au BFT traditionnel sur deux dimensions :
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 des blocs peuvent être exécutés en parallèle.
Cela a fait de HotStuff un modèle de conception pour de nombreux mécanismes de consensus de blockchain PoS modernes. Cependant, chaque chose a ses avantages et ses 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 plonger dans ce problème central : le Tail Forking.
Problème de bifurcation de queue (Tail-Forking)
Bien que HotStuff – en particulier sa version en pipeline – résolve le problème de l’extensibilité du protocole de consensus, il introduit également de nouveaux défis. L’un des problèmes les plus critiques et les plus négligés est celui de la « bifurcation de la queue ».
Qu'est-ce qu'une bifurcation en queue ? Cela peut être compris simplement comme : une réorganisation inattendue de blocs se produit à la "queue" de la blockchain (reorg).
Plus précisément, il y a un bloc qui est valide, qui a déjà été largement diffusé auprès de la plupart des validateurs et qui a reçu suffisamment de soutiens par vote. 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 nouveau bloc à la même hauteur.
Ce n'est pas un bug, ni une attaque, mais parce qu'il existe une possibilité de "perte de chaîne" dans la structure de conception même du protocole. Cela ne semble-t-il pas un peu injuste ? Alors, comment cela se produit-il ?
Nous avons mentionné précédemment que chaque leader de la chaîne de production HotStuff a deux tâches :
A. Proposer un nouveau bloc (par exemple Bₙ₊₁)
B. Collecter les votes pour les blocs de l'ancien leader, générer QC (par exemple, finaliser la confirmation pour Bₙ)
Ces deux tâches sont parallèles, se relayant tour à tour. Mais le problème se situe ici.
Prenons un exemple : supposons qu'Alice soit la leader, elle a proposé le bloc Bₙ à la hauteur n, ce bloc a reçu un super majorité de votes et est déjà "presque confirmé".
Ensuite, Bob devrait agir en tant que leader pour continuer à avancer le prochain bloc de la chaîne Bₙ₊₁, tout en intégrant le QC de Bₙ (preuve de majorité légale) dans sa proposition afin d'achever la confirmation finale 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'il n'y avait personne pour compléter le QC de l'emballage du bloc d'Alice, l'enregistrement de vote de Bₙ n'a pas pu être propagé, ce bloc qui aurait dû être confirmé a donc été "traité à froid" et a finalement été ignoré par l'ensemble du réseau.
C'est l'essence de la bifurcation finale : le bloc du précédent leader est sauté en raison de la négligence ou de la malveillance du prochain leader.
Pourquoi la bifurcation arrière 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.
Tout d’abord, la récompense est avalée :
Si un bloc est abandonné, son leader ne recevra aucune récompense. Que ce soit la récompense de bloc ou les frais de transaction. Par exemple, si Alice présente un bloc valide et obtient le soutien d'une super majorité des votes, mais que ce bloc n'est pas confirmé en raison d'une erreur de Bob ou d'une manipulation malveillante, Alice ne recevra finalement rien. Cela entraînera une structure d'incitation erronée : des nœuds malveillants comme Bob peuvent "couper" la source de récompense de leurs adversaires en ignorant leurs blocs. Ce comportement ne nécessite pas d'attaque technique, il suffit de "ne pas coopérer" intentionnellement pour affaiblir les gains des concurrents. Si cela se produit à plusieurs reprises, 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’étend :
Un problème plus caché mais grave peut également être causé par la bifurcation à la fin : l'espace pour la manipulation malveillante de l'MEV (valeur maximale pouvant être extraite) s'est élargi. Prenons un exemple : supposons qu'il y ait une transaction d'arbitrage de grande valeur dans le bloc d'Alice. Si Bob a l'intention de faire des problèmes, il peut conspirer avec le prochain leader Carol pour ne pas transmettre le bloc d'Alice. Ensuite, Carol peut reconstruire un nouveau bloc à la même hauteur et « voler » la transaction d'arbitrage d'Alice - transformant les bénéfices de l'MEV en siens. Cette pratique de « réorganisation de la chaîne + détournement de complot » semble toujours 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é », transformant la confirmation des blocs en un jeu de répartition des bénéfices, et non en un service public.
Troisièmement, compromettre la garantie de finalité affecte l'expérience utilisateur :
Comparé aux protocoles de type Nakamoto, un des grands avantages du BFT est la finalité déterministe : une fois qu'un bloc est soumis, il ne peut pas être annulé. Mais les forks tardifs compromettent cette garantie, en particulier pour les blocs qui ont "reçu des votes mais qui n'ont pas encore été formellement confirmés". Certaines dapps à haut débit espèrent généralement pouvoir lire les données immédiatement après le 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 utilisateur - par exemple, des soldes de compte anormaux, des transactions à effet de levier récemment effectuées disparaissant sans raison, ou un état de jeu se réinitialisant soudainement.
Quatrième, cela pourrait provoquer des pannes en chaîne :
En général, une bifurcation à la fin ne peut retarder la confirmation d'un bloc que d'un cycle, l'impact n'est pas très important. Cependant, dans certains scénarios marginaux, si plusieurs leaders consécutifs choisissent de sauter le bloc précédent, le système peut se retrouver dans un état de stagnation, personne n'étant disposé à "prendre" le bloc précédent. L'avancement de toute la chaîne est alors bloqué, jusqu'à ce qu'un leader "prêt à assumer la responsabilité" apparaisse, permettant au réseau de continuer à avancer.
Bien qu'il y ait eu certaines solutions auparavant, comme le mécanisme d'évitement de bifurcation terminal 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 des fork de fin. 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 n'est pas une reconstruction à zéro, mais plutôt une optimisation continue basée sur le cadre central de HotStuff. Il conserve trois caractéristiques clés :
Leader rotatif (rotating leader) : Un nouveau leader est élu à chaque tour 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 validateur n'a besoin de communiquer qu'avec le leader, ce qui permet d'économiser une grande partie des frais de réseau.
Mais avec seulement ces trois points, ce n'est pas assez sûr. Pour combler la faille structurelle de bifurcation à la fin, MonadBFT a ajouté deux mécanismes clés :
Mécanisme de nouvelle proposition (Re-Proposal)
Certificat sans endorsement (NEC, No-Endorsement Certificate)
Mécanisme de Re-Proposition
Dans le protocole BFT, le temps est divisé en tours (appelés view), chaque tour ayant un leader responsable de proposer un nouveau bloc. Si le leader échoue (par exemple, s'il ne propose pas le bloc à temps ou si la proposition est invalide), le système passe au tour suivant et choisit un nouveau leader.
MonadBFT a ajouté un mécanisme qui garantit qu'au cours du changement de vue, aucun bloc proposé honnêtement ne sera "perdu" à cause du changement de leader.
Lorsque le leader actuel échoue, les validateurs émettent 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 équivaut à dire : "Je n'ai pas reçu de proposition valide, voici le dernier bloc que je vois."
Un nouveau leader collectera ces messages de timeout auprès d'une super majorité (2f+1) de validateurs et les combinera en un certificat de timeout (Timeout Certificate, TC). Ce TC représente : lorsqu'un tour précédent échoue, un instantané de la reconnaissance unifiée du "bloc de chaîne" par l'ensemble du réseau. Le nouveau leader sélectionnera le bloc de la plus haute hauteur (ou le dernier numéro de vue), également connu sous le nom de high_tip.
Exigences de MonadBFT : La proposition du nouveau leader doit inclure un TC valide et doit réintroduire 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 presque confirmé disparaisse ainsi.
Prenons un exemple : supposons qu'Alice soit la leader de la vue 5, qu'elle ait proposé un bloc valide et qu'elle ait obtenu la majorité des votes. Ensuite, le leader de la vue 6, Bob, est hors ligne et n'a pas pu faire avancer le processus de la chaîne. Lorsque Carol devient la leader de la vue 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 un à 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 (le mécanisme sera présenté plus loin). (Au maximum f nœuds byzantins peuvent choisir d'ignorer la demande et de ne pas répondre.)
Une fois que Carol a de nouveau proposé le bloc d'Alice, elle recevra une opportunité de proposition supplémentaire, s'assurant qu'elle ne sera pas "puni" en raison de l'échec du précédent leader.
Le rôle de ce mécanisme de proposition de révision est clair : garantir que l'avancement de la chaîne est équitable et qu'aucun travail valide ne sera discrètement abandonné en raison d'un malheur ou de la perturbation de quelqu'un.
Certificat sans endorsement (NEC)
Continuons 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, au moins 2f+1 validateurs répondront :
Soit fournir le bloc d'Alice
Soit envoyer un message NE signé, indiquant qu'il n'a pas reçu le bloc d'Alice.
Dès que Carol reçoit le bloc d'Alice, elle doit le proposer à nouveau selon les 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 n'y a au maximum que f potentiellement malveillants. Si le bloc d'Alice a effectivement reçu un vote de 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 pour prouver que ces personnes n'ont rien reçu. Cela constitue un certificat sans endossement (No-Endorsement Certificate, NEC).
NEC est un certificat de "non-responsabilité" leader : c'est une preuve vérifiable indiquant que le précédent bloc n'est pas encore prêt à être confirmé, et qu'il ne s'agit pas d'un saut malveillant, mais d'un "abandon" justifié.
Nouvelle proposition + Certificat sans endorsement = Résoudre la bifurcation finale
MonadBFT établit un ensemble de règles de traitement de la 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 de la confirmation";
Vous devez fournir suffisamment de preuves pour prouver que ce bloc ne remplit pas encore les 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 de la part du leader ou d'une évitement délibéré.
Les risques structurels liés à la bifurcation à la fin sont systématiquement résolus, et le protocole peut imposer des contraintes claires sur les comportements de contournement inappropriés.
Si un leader tente de sauter un bloc précédent sans raison valable, mais ne parvient pas à fournir de preuves NEC, le protocole identifiera immédiatement et rejettera cette action. Un saut sans preuve cryptographique sera considéré comme illégal et ne bénéficiera pas du soutien du consensus du réseau.
D'un point de vue des incitations économiques, cette conception offre une protection claire aux validateurs :
Tout bloc qui est honnêtement proposé et reçoit un soutien par vote ne sera pas dépouillé de sa récompense en raison d'une défaillance dans les étapes ultérieures ;
Même dans des situations extrêmes, par exemple lorsqu'un nœud saute intentionnellement son tour de proposition pour aider quelqu'un d'autre à s'emparer de l'MEV du bloc précédent, le protocole forcera le leader suivant à proposer à nouveau le bloc d'origine en priorité, empêchant ainsi l'attaquant de tirer un avantage économique en sautant le processus.
Il est encore plus important que MonadBFT n'a pas sacrifié les performances du protocole pour améliorer la sécurité.
Certaines conceptions antérieures pour faire face aux forks de fin, comme le protocole BeeGees, bien qu'elles aient une certaine capacité de protection, reposent souvent sur une complexité de communication élevée (n²) ou nécessitent de réactiver 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 :
Des communications supplémentaires (telles que des messages de délai d'attente, des propositions de bloc) ne sont lancées qu'en cas d'échec de la vue ou d'exception. Sur le chemin normal où la plupart 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 l'évolution du protocole HotStuff et explique en détail comment MonadBFT résout le problème de bifurcation terminale inhérent à HotStuff en termes de structure de couche de protocole.
La bifurcation à la fin peut déformer les incitations économiques des proposeurs de blocs et représente également une menace potentielle pour l'activité du réseau. MonadBFT introduit un mécanisme de nouvelle proposition et des certificats sans endorsement (NEC), garantissant qu'aucun bloc proposé par des leaders honnêtes, et ayant reçu un vote de majorité légale, ne sera abandonné ou sauté.
Dans le prochain article, nous continuerons à explorer deux autres caractéristiques clés de MonadBFT :
1）Finalité spéculative
Réactivité optimiste (Optimistic Responsiveness)
et analyser plus en détail 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 : redéfinir la sécurité du consensus Blockchain, dire adieu au risque de fork en queue.
Auteur : michaellwy
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 situés, dans quel pays ou quel fuseau horaire, tous les participants doivent finalement parvenir à un accord 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 il y a même des personnes qui sabotent intentionnellement. Dans ce cas, comment le système peut-il être "d'accord à l'unanimité" et maintenir la cohérence ?
C'est le problème que le protocole de consensus doit résoudre. Il s'agit essentiellement d'un ensemble de règles visant à guider un groupe de nœuds indépendants, voire pas entièrement fiables, sur la manière de parvenir à un consensus 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 caractéristiques clés, telles que la protection de la propriété numérique, un modèle monétaire anti-inflation, et une structure de coopération sociale évolutive. Mais à condition que le protocole de consensus lui-même doive garantir simultanément deux aspects fondamentaux :
Il ne peut pas y avoir deux blocs conflictuels qui soient tous les deux confirmés;
Le réseau doit continuer d’avancer et ne pas rester bloqué ou arrêté.
MonadBFT est la dernière avancée technologique dans cette direction.
Un aperçu de l'évolution des protocoles de consensus
Le domaine des mécanismes de consensus a en fait été étudié pendant des dizaines d'années. Les premiers protocoles, comme le PBFT (Practical Byzantine Fault Tolerance), sont déjà capables de gérer une situation très réaliste : même si certains nœuds du réseau tombent en panne, agissent mal ou racontent des absurdités, tant qu'ils ne dépassent pas un tiers du total, le système peut encore parvenir à un consensus.
Ces protocoles initiaux étaient conçus de manière relativement "traditionnelle" : un leader est élu à chaque tour, qui initie une proposition, et les autres validateurs votent plusieurs fois sur cette proposition pour confirmer progressivement l'ordre des transactions.
Le processus de vote passe généralement par plusieurs étapes, telles que pre-prepare, prepare, commit, reply. À chaque étape, tous les validateurs doivent communiquer entre eux. En d'autres termes, chacun doit parler à tout le monde, ce qui entraîne une explosion du volume de messages en raison de la nature "maillée".
La complexité de cette structure de communication est n², c’est-à-dire que s’il y a 100 validateurs dans le réseau, chaque cycle de consensus peut transmettre près de 10 000 messages.
Cela ne pose pas de problème dans les petits réseaux, mais une fois que le nombre de validateurs augmente, la charge de communication du système devient rapidement insupportable, et l'efficacité s'effondre directement.
Source des données :
Ce genre de structure de communication secondaire de « tout le monde suit et communique avec tout le monde » est en fait très inefficace. Par exemple, dans un réseau de 100 validateurs, des dizaines de milliers de messages peuvent être traités par cycle de consensus.
Cela peut fonctionner dans un petit cercle, mais une fois mis en réseau sur une chaîne ouverte à l'échelle mondiale, la charge de communication devient immédiatement inacceptable. Ainsi, des protocoles BFT tels que PBFT et Tendermint sont généralement utilisés uniquement dans des scénarios de réseau autorisé (permissioned network) ou dans des systèmes avec un nombre très limité de validateurs, où ils peuvent à peine fonctionner.
Afin d’adapter le protocole BFT à un environnement de chaîne publique sans autorisation, certaines conceptions de nouvelle génération ont commencé à évoluer vers un mode de communication plus léger : chaque validateur ne communique qu’avec le leader, plutôt qu’avec tous les membres de l’équipe.
Cela a réduit la complexité des messages de n² à n, allégeant ainsi 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 principe de conception est très clair : remplacer le processus de vote complexe de PBFT par une structure de communication plus simple et pilotée par un leader.
La caractéristique clé de HotStuff est ce qu'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 Certificat de Quorum (QC, preuve de majorité légale).
Ce QC est essentiellement une signature collective qui prouve à l'ensemble du réseau : "La plupart des nœuds ont accepté cette proposition."
En comparaison, le mode de communication de PBFT est "broadcast total", tout le monde parle dans le groupe, ce qui rendait la situation très chaotique. Le mode de HotStuff ressemble davantage à "un collecte, un paquet", peu importe combien de personnes il y a dans le réseau, il peut toujours fonctionner de manière efficace.
La figure ci-dessus compare la structure de communication de HotStuff avec le modèle d’interconnexion à l’échelle du réseau de PBFT
Source des données :
En plus de la communication linéaire, HotStuff peut également être mis à niveau vers une version pipelined (HotStuff pipelined) pour améliorer l'efficacité.
Dans le HotStuff original, le même validateur servait de leader pendant plusieurs tours d’affilée jusqu’à ce qu’un bloc soit entièrement confirmé. Le processus se fait « un bloc à la fois », tous les efforts étant concentrés sur l’avancement du processus actuel.
Dans la chaîne de blocs HotStuff, le mécanisme est encore plus flexible : à chaque tour, un nouveau leader est choisi, et chaque leader a deux missions :
Emballer les votes de la dernière ronde en un Quorum Certificate (QC) et les diffuser à l'ensemble du réseau ;
Proposer un nouveau bloc tout en se préparant à ouvrir le prochain tour.
C'est-à-dire qu'il ne s'agit plus de "confirmer un bloc avant de traiter le suivant", mais plutôt d'un processus en chaîne où différents leaders sont responsables à tour de rôle de chaque étape. La personne précédente propose un bloc, la suivante le confirme et continue à proposer de nouveaux blocs, le consensus sur la chaîne se transmet comme dans une course de relais.
C'est l'origine de la métaphore « 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 en parallèle, augmentant l'efficacité du traitement.
En résumé, les protocoles comme HotStuff ont réalisé des avancées significatives par rapport au BFT traditionnel sur deux dimensions :
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 des blocs peuvent être exécutés en parallèle.
Cela a fait de HotStuff un modèle de conception pour de nombreux mécanismes de consensus de blockchain PoS modernes. Cependant, chaque chose a ses avantages et ses 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 plonger dans ce problème central : le Tail Forking.
Problème de bifurcation de queue (Tail-Forking)
Bien que HotStuff – en particulier sa version en pipeline – résolve le problème de l’extensibilité du protocole de consensus, il introduit également de nouveaux défis. L’un des problèmes les plus critiques et les plus négligés est celui de la « bifurcation de la queue ».
Qu'est-ce qu'une bifurcation en queue ? Cela peut être compris simplement comme : une réorganisation inattendue de blocs se produit à la "queue" de la blockchain (reorg).
Plus précisément, il y a un bloc qui est valide, qui a déjà été largement diffusé auprès de la plupart des validateurs et qui a reçu suffisamment de soutiens par vote. 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 nouveau bloc à la même hauteur.
Ce n'est pas un bug, ni une attaque, mais parce qu'il existe une possibilité de "perte de chaîne" dans la structure de conception même du protocole. Cela ne semble-t-il pas un peu injuste ? Alors, comment cela se produit-il ?
Nous avons mentionné précédemment que chaque leader de la chaîne de production HotStuff a deux tâches :
A. Proposer un nouveau bloc (par exemple Bₙ₊₁)
B. Collecter les votes pour les blocs de l'ancien leader, générer QC (par exemple, finaliser la confirmation pour Bₙ)
Ces deux tâches sont parallèles, se relayant tour à tour. Mais le problème se situe ici.
Prenons un exemple : supposons qu'Alice soit la leader, elle a proposé le bloc Bₙ à la hauteur n, ce bloc a reçu un super majorité de votes et est déjà "presque confirmé".
Ensuite, Bob devrait agir en tant que leader pour continuer à avancer le prochain bloc de la chaîne Bₙ₊₁, tout en intégrant le QC de Bₙ (preuve de majorité légale) dans sa proposition afin d'achever la confirmation finale 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'il n'y avait personne pour compléter le QC de l'emballage du bloc d'Alice, l'enregistrement de vote de Bₙ n'a pas pu être propagé, ce bloc qui aurait dû être confirmé a donc été "traité à froid" et a finalement été ignoré par l'ensemble du réseau.
C'est l'essence de la bifurcation finale : le bloc du précédent leader est sauté en raison de la négligence ou de la malveillance du prochain leader.
Pourquoi la bifurcation arrière 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.
Tout d’abord, la récompense est avalée :
Si un bloc est abandonné, son leader ne recevra aucune récompense. Que ce soit la récompense de bloc ou les frais de transaction. Par exemple, si Alice présente un bloc valide et obtient le soutien d'une super majorité des votes, mais que ce bloc n'est pas confirmé en raison d'une erreur de Bob ou d'une manipulation malveillante, Alice ne recevra finalement rien. Cela entraînera une structure d'incitation erronée : des nœuds malveillants comme Bob peuvent "couper" la source de récompense de leurs adversaires en ignorant leurs blocs. Ce comportement ne nécessite pas d'attaque technique, il suffit de "ne pas coopérer" intentionnellement pour affaiblir les gains des concurrents. Si cela se produit à plusieurs reprises, 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’étend :
Un problème plus caché mais grave peut également être causé par la bifurcation à la fin : l'espace pour la manipulation malveillante de l'MEV (valeur maximale pouvant être extraite) s'est élargi. Prenons un exemple : supposons qu'il y ait une transaction d'arbitrage de grande valeur dans le bloc d'Alice. Si Bob a l'intention de faire des problèmes, il peut conspirer avec le prochain leader Carol pour ne pas transmettre le bloc d'Alice. Ensuite, Carol peut reconstruire un nouveau bloc à la même hauteur et « voler » la transaction d'arbitrage d'Alice - transformant les bénéfices de l'MEV en siens. Cette pratique de « réorganisation de la chaîne + détournement de complot » semble toujours 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é », transformant la confirmation des blocs en un jeu de répartition des bénéfices, et non en un service public.
Troisièmement, compromettre la garantie de finalité affecte l'expérience utilisateur :
Comparé aux protocoles de type Nakamoto, un des grands avantages du BFT est la finalité déterministe : une fois qu'un bloc est soumis, il ne peut pas être annulé. Mais les forks tardifs compromettent cette garantie, en particulier pour les blocs qui ont "reçu des votes mais qui n'ont pas encore été formellement confirmés". Certaines dapps à haut débit espèrent généralement pouvoir lire les données immédiatement après le 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 utilisateur - par exemple, des soldes de compte anormaux, des transactions à effet de levier récemment effectuées disparaissant sans raison, ou un état de jeu se réinitialisant soudainement.
Quatrième, cela pourrait provoquer des pannes en chaîne :
En général, une bifurcation à la fin ne peut retarder la confirmation d'un bloc que d'un cycle, l'impact n'est pas très important. Cependant, dans certains scénarios marginaux, si plusieurs leaders consécutifs choisissent de sauter le bloc précédent, le système peut se retrouver dans un état de stagnation, personne n'étant disposé à "prendre" le bloc précédent. L'avancement de toute la chaîne est alors bloqué, jusqu'à ce qu'un leader "prêt à assumer la responsabilité" apparaisse, permettant au réseau de continuer à avancer.
Bien qu'il y ait eu certaines solutions auparavant, comme le mécanisme d'évitement de bifurcation terminal 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 des fork de fin. 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 n'est pas une reconstruction à zéro, mais plutôt une optimisation continue basée sur le cadre central de HotStuff. Il conserve trois caractéristiques clés :
Leader rotatif (rotating leader) : Un nouveau leader est élu à chaque tour 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 validateur n'a besoin de communiquer qu'avec le leader, ce qui permet d'économiser une grande partie des frais de réseau.
Mais avec seulement ces trois points, ce n'est pas assez sûr. Pour combler la faille structurelle de bifurcation à la fin, MonadBFT a ajouté deux mécanismes clés :
Mécanisme de nouvelle proposition (Re-Proposal)
Certificat sans endorsement (NEC, No-Endorsement Certificate)
Mécanisme de Re-Proposition
Dans le protocole BFT, le temps est divisé en tours (appelés view), chaque tour ayant un leader responsable de proposer un nouveau bloc. Si le leader échoue (par exemple, s'il ne propose pas le bloc à temps ou si la proposition est invalide), le système passe au tour suivant et choisit un nouveau leader.
MonadBFT a ajouté un mécanisme qui garantit qu'au cours du changement de vue, aucun bloc proposé honnêtement ne sera "perdu" à cause du changement de leader.
Lorsque le leader actuel échoue, les validateurs émettent 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 équivaut à dire : "Je n'ai pas reçu de proposition valide, voici le dernier bloc que je vois."
Un nouveau leader collectera ces messages de timeout auprès d'une super majorité (2f+1) de validateurs et les combinera en un certificat de timeout (Timeout Certificate, TC). Ce TC représente : lorsqu'un tour précédent échoue, un instantané de la reconnaissance unifiée du "bloc de chaîne" par l'ensemble du réseau. Le nouveau leader sélectionnera le bloc de la plus haute hauteur (ou le dernier numéro de vue), également connu sous le nom de high_tip.
Exigences de MonadBFT : La proposition du nouveau leader doit inclure un TC valide et doit réintroduire 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 presque confirmé disparaisse ainsi.
Prenons un exemple : supposons qu'Alice soit la leader de la vue 5, qu'elle ait proposé un bloc valide et qu'elle ait obtenu la majorité des votes. Ensuite, le leader de la vue 6, Bob, est hors ligne et n'a pas pu faire avancer le processus de la chaîne. Lorsque Carol devient la leader de la vue 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 un à 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 (le mécanisme sera présenté plus loin). (Au maximum f nœuds byzantins peuvent choisir d'ignorer la demande et de ne pas répondre.)
Une fois que Carol a de nouveau proposé le bloc d'Alice, elle recevra une opportunité de proposition supplémentaire, s'assurant qu'elle ne sera pas "puni" en raison de l'échec du précédent leader.
Le rôle de ce mécanisme de proposition de révision est clair : garantir que l'avancement de la chaîne est équitable et qu'aucun travail valide ne sera discrètement abandonné en raison d'un malheur ou de la perturbation de quelqu'un.
Certificat sans endorsement (NEC)
Continuons 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, au moins 2f+1 validateurs répondront :
Soit fournir le bloc d'Alice
Soit envoyer un message NE signé, indiquant qu'il n'a pas reçu le bloc d'Alice.
Dès que Carol reçoit le bloc d'Alice, elle doit le proposer à nouveau selon les 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 n'y a au maximum que f potentiellement malveillants. Si le bloc d'Alice a effectivement reçu un vote de 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 pour prouver que ces personnes n'ont rien reçu. Cela constitue un certificat sans endossement (No-Endorsement Certificate, NEC).
NEC est un certificat de "non-responsabilité" leader : c'est une preuve vérifiable indiquant que le précédent bloc n'est pas encore prêt à être confirmé, et qu'il ne s'agit pas d'un saut malveillant, mais d'un "abandon" justifié.
Nouvelle proposition + Certificat sans endorsement = Résoudre la bifurcation finale
MonadBFT établit un ensemble de règles de traitement de la 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 de la confirmation";
Vous devez fournir suffisamment de preuves pour prouver que ce bloc ne remplit pas encore les 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 de la part du leader ou d'une évitement délibéré.
Les risques structurels liés à la bifurcation à la fin sont systématiquement résolus, et le protocole peut imposer des contraintes claires sur les comportements de contournement inappropriés.
Si un leader tente de sauter un bloc précédent sans raison valable, mais ne parvient pas à fournir de preuves NEC, le protocole identifiera immédiatement et rejettera cette action. Un saut sans preuve cryptographique sera considéré comme illégal et ne bénéficiera pas du soutien du consensus du réseau.
D'un point de vue des incitations économiques, cette conception offre une protection claire aux validateurs :
Tout bloc qui est honnêtement proposé et reçoit un soutien par vote ne sera pas dépouillé de sa récompense en raison d'une défaillance dans les étapes ultérieures ;
Même dans des situations extrêmes, par exemple lorsqu'un nœud saute intentionnellement son tour de proposition pour aider quelqu'un d'autre à s'emparer de l'MEV du bloc précédent, le protocole forcera le leader suivant à proposer à nouveau le bloc d'origine en priorité, empêchant ainsi l'attaquant de tirer un avantage économique en sautant le processus.
Il est encore plus important que MonadBFT n'a pas sacrifié les performances du protocole pour améliorer la sécurité.
Certaines conceptions antérieures pour faire face aux forks de fin, comme le protocole BeeGees, bien qu'elles aient une certaine capacité de protection, reposent souvent sur une complexité de communication élevée (n²) ou nécessitent de réactiver 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 :
Des communications supplémentaires (telles que des messages de délai d'attente, des propositions de bloc) ne sont lancées qu'en cas d'échec de la vue ou d'exception. Sur le chemin normal où la plupart 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 l'évolution du protocole HotStuff et explique en détail comment MonadBFT résout le problème de bifurcation terminale inhérent à HotStuff en termes de structure de couche de protocole.
La bifurcation à la fin peut déformer les incitations économiques des proposeurs de blocs et représente également une menace potentielle pour l'activité du réseau. MonadBFT introduit un mécanisme de nouvelle proposition et des certificats sans endorsement (NEC), garantissant qu'aucun bloc proposé par des leaders honnêtes, et ayant reçu un vote de majorité légale, ne sera abandonné ou sauté.
Dans le prochain article, nous continuerons à explorer deux autres caractéristiques clés de MonadBFT :
1）Finalité spéculative
et analyser plus en détail la signification réelle de ces mécanismes pour les validateurs et les développeurs.
À suivre.