MonadBFT : redéfinir la sécurité du consensus blockchain, dire adieu aux risques de fourchette arrière
TechFlow SélectionTechFlow Sélection
MonadBFT : redéfinir la sécurité du consensus blockchain, dire adieu aux risques de fourchette arrière
MonadBFT est un protocole de consensus de nouvelle génération spécialement conçu pour résoudre le problème du fork final.
Dédié à des analyses Web3 approfondiesAuteur : michaellwy
Le cœur de la blockchain réside dans la mise en œuvre d'un consensus global strict : quelle que soit la localisation géographique ou le fuseau horaire des nœuds du réseau, tous les participants doivent parvenir à un accord sur un ensemble de résultats objectifs.
Mais les réseaux distribués du monde réel ne sont pas idéaux : certains nœuds tombent en panne, d'autres mentent, voire cherchent délibérément à perturber le système. Comment, dans ces conditions, le système parvient-il à rester « unanime » et cohérent ?
C’est précisément ce que cherche à résoudre le protocole de consensus. Il s’agit essentiellement d’un ensemble de règles qui guident un groupe de nœuds indépendants, voire partiellement non fiables, afin qu’ils s’accordent sur l’ordre et le contenu de chaque transaction.
Une fois ce « consensus strict » établi, la blockchain peut activer plusieurs fonctionnalités clés, telles que la garantie de propriété numérique, des modèles monétaires résistants à l’inflation, ainsi que des structures de collaboration sociale extensibles. Mais à une condition : que le protocole de consensus lui-même assure deux fondamentaux :
-
Deux blocs mutuellement contradictoires ne peuvent pas être confirmés simultanément ;
-
Le réseau doit continuer à progresser sans jamais se bloquer ni s’arrêter.
MonadBFT représente la toute dernière percée technologique dans cette direction.
Révision succincte de l’évolution des protocoles de consensus
Le domaine des mécanismes de consensus a fait l’objet de recherches pendant des décennies. Les premiers protocoles, comme PBFT (Practical Byzantine Fault Tolerance), étaient déjà capables de gérer une situation très réaliste : même si une partie des nœuds du réseau tombe en panne, agit malicieusement ou propage de fausses informations, tant que leur proportion ne dépasse pas 1/3 du total, le système peut tout de même parvenir à un consensus.
L’approche de conception de ces premiers protocoles était plutôt « traditionnelle » : à chaque tour, un leader est élu pour proposer un bloc, puis les autres validateurs votent en plusieurs étapes pour confirmer progressivement l’ordre des transactions.
Le processus de vote implique généralement plusieurs phases, comme pre-prepare, prepare, commit et reply. À chaque étape, tous les validateurs doivent communiquer entre eux. Autrement dit, chacun doit envoyer un message à tous les autres, entraînant une explosion du volume de messages en structure « maillée ».
La complexité de communication est en n² — par exemple, avec 100 validateurs, près de 10 000 messages peuvent être transmis à chaque tour de consensus.
Cela reste acceptable dans un petit réseau, mais dès que le nombre de validateurs augmente, la charge de communication devient rapidement insoutenable, faisant chuter l’efficacité du système.
Source :
https://medium.com/coinmonks/pbft-understanding-the-algorithm-b7a7869650ae
Cette structure de communication quadratique, où « chaque nœud doit parler à chaque autre nœud », est extrêmement inefficace. Par exemple, dans un réseau de 100 validateurs, chaque tour de consensus pourrait nécessiter des dizaines de milliers de messages.
Dans un petit cercle fermé, cela reste gérable, mais dans un réseau ouvert à l’échelle mondiale, la charge de communication devient immédiatement inacceptable. C’est pourquoi des protocoles BFT comme PBFT ou Tendermint ne sont généralement utilisés que dans des environnements contrôlés (réseaux autorisés) ou avec un très petit nombre de validateurs.
Pour permettre aux protocoles BFT de s’adapter aux blockchains publiques et sans permission, de nouvelles conceptions ont commencé à adopter des modes de communication plus légers : chaque validateur communique uniquement avec le leader, au lieu d’échanger des messages avec tous les autres.
Cela réduit la complexité de communication de n² à n — allégeant considérablement la charge du système.
Le protocole HotStuff a été introduit en 2018 précisément pour résoudre ce problème d’extensibilité. Son objectif est clair : remplacer le processus de vote complexe de PBFT par une structure de communication plus simple, pilotée par le leader.
La caractéristique clé de HotStuff est sa communication linéaire. Dans ce mécanisme, chaque validateur n’a besoin que d’envoyer son vote au leader actuel, qui regroupe ensuite ces votes pour générer un Quorum Certificate (QC), une preuve de majorité collective.
Un QC est essentiellement une signature collective prouvant à tout le réseau : « la majorité des nœuds a approuvé cette proposition. »
Contrairement à PBFT, dont le modèle repose sur une diffusion généralisée où chaque nœud parle à tous les autres, créant un chaos organisationnel, HotStuff suit un modèle « un seul collecteur, un seul paquet », restant efficace peu importe la taille du réseau.
L’image ci-dessus compare la structure de communication en éventail de HotStuff avec le modèle entièrement interconnecté de PBFT.
Source :
https://www.mdpi.com/1424-8220/24/16/5417
Au-delà de la communication linéaire, HotStuff peut être amélioré en version pipeline (pipelined HotStuff) pour encore mieux optimiser l’efficacité.
Dans la version initiale de HotStuff, le même validateur reste leader pendant plusieurs tours jusqu’à la confirmation complète d’un bloc. Ce processus suit un modèle « un bloc par tour », toute l’attention étant concentrée sur l’avancement d’un seul bloc à la fois.
Dans la version pipeline de HotStuff, le mécanisme devient plus flexible : un nouveau leader est désigné à chaque tour, et chaque leader a deux tâches :
-
Regrouper les votes du tour précédent en un Quorum Certificate (QC) et le diffuser au réseau ;
-
Proposer un nouveau bloc, amorçant ainsi le prochain tour.
Ainsi, on ne traite plus les blocs un par un selon une séquence stricte. Au contraire, comme sur une chaîne de montage, chaque leader gère un maillon différent du processus. Le premier propose un bloc, le suivant le valide tout en proposant un nouveau bloc, et ainsi de suite, comme un relais.
C’est de là que vient l’analogie du « pipeline » : tandis qu’un bloc est encore en cours de confirmation, le suivant est déjà en préparation, permettant un traitement parallèle et augmentant le débit global.
En résumé, HotStuff apporte deux améliorations majeures par rapport aux anciens protocoles BFT :
-
Une communication plus légère : chaque validateur n’a besoin que de communiquer avec le leader ;
-
Une efficacité accrue : plusieurs processus de confirmation peuvent avancer en parallèle.
Ces avantages font de HotStuff un modèle de conception privilégié pour de nombreuses blockchains PoS modernes. Pourtant, tout gain a son revers : bien que la structure en pipeline offre de hautes performances, elle introduit subtilement un risque structurel souvent négligé.
Nous allons maintenant approfondir ce problème central : la bifurcation terminale (Tail Forking).
Le problème de la bifurcation terminale (Tail Forking)
Bien que HotStuff — surtout sa version en pipeline — ait résolu le problème d’extensibilité des protocoles de consensus, il a aussi introduit de nouveaux défis. Le plus critique, et le plus souvent ignoré, est le fameux problème de « bifurcation terminale » (Tail Forking).
Qu’est-ce que la bifurcation terminale ? On peut la comprendre simplement comme une restructuration inattendue (reorg) à l’extrémité de la chaîne.
Plus précisément, un bloc valide, correctement diffusé à la majorité des validateurs et ayant recueilli suffisamment de votes, devrait normalement être confirmé et intégré à la chaîne principale. Pourtant, il finit par être « sauté », abandonné (orphaned), remplacé par un autre bloc à la même hauteur.
Il ne s’agit ni d’un bug ni d’une attaque, mais d’une possibilité inhérente à la structure même du protocole. Cela semble injuste — alors comment cela arrive-t-il ?
Rappelons que dans HotStuff en pipeline, chaque leader a deux missions :
-
A. Proposer un nouveau bloc (par exemple Bₙ₊₁)
-
B. Collecter les votes pour le bloc du leader précédent, et générer un QC (par exemple finaliser Bₙ)
Ces deux tâches s’exécutent en parallèle, comme un relais. Mais c’est là que réside le problème.
Imaginons : Alice est leader au tour n, elle propose le bloc Bₙ, qui obtient une large majorité de votes et est presque confirmé.
Bob devient ensuite leader et devrait non seulement proposer Bₙ₊₁, mais aussi inclure le QC de Bₙ dans sa proposition, achevant ainsi sa confirmation.
Mais si Bob est déconnecté, ou pire, refuse délibérément de soumettre le QC de Bₙ, un problème surgit.
Personne ne finalise le QC de Bₙ, donc les votes pour ce bloc ne sont pas propagés. Le bloc, pourtant sur le point d’être validé, est ainsi « ignoré », puis complètement oublié par le réseau.
C’est là l’essence de la bifurcation terminale : le bloc d’un leader est ignoré parce que le leader suivant a failli à son devoir, sciemment ou non.
Pourquoi la bifurcation terminale est-elle grave ?
Les conséquences de la bifurcation terminale sont doubles : 1) Elle corrompt les incitations économiques, 2) Elle menace l’activité (liveness) du système.
Premièrement, suppression des récompenses :
Si un bloc est abandonné, son leader ne touche aucune récompense — ni celle de création de bloc, ni les frais de transaction. Par exemple, Alice produit un bloc légitime et recueille une supermajorité de votes, mais à cause d’une erreur ou d’un acte malveillant de Bob, son bloc n’est pas confirmé. Résultat : Alice ne touche rien. Cela crée une distorsion des incitations : un nœud malveillant comme Bob peut « couper » les revenus d’un concurrent simplement en refusant de coopérer. Aucune attaque technique n’est nécessaire — juste une omission stratégique. Si cela se reproduit, cela décourage la participation, nuit à l’équité, et peut encourager des collusions entre nœuds.
Deuxièmement, expansion des attaques MEV :
La bifurcation terminale ouvre également une porte à une manipulation sournoise de la MEV (Maximum Extractable Value). Supposons que le bloc d’Alice contienne une transaction d’arbitrage très lucrative. Bob, complice du prochain leader Carol, peut choisir de ne pas diffuser le bloc d’Alice. Carol peut alors construire un nouveau bloc à la même hauteur, copiant la transaction d’arbitrage pour s’approprier la MEV. Cette pratique de « réorganisation + détournement collusif » respecte formellement les règles, mais constitue un pillage orchestré. Pire encore, elle encourage la formation de réseaux de collusion entre leaders, transformant la validation en jeu de redistribution des profits plutôt qu’en service public.
Troisièmement, compromission de la finalité, impact sur l’expérience utilisateur :
Comparé aux protocoles de type Nakamoto, l’un des atouts majeurs des protocoles BFT est leur finalité déterministe : une fois un bloc confirmé, il ne peut pas être annulé. La bifurcation terminale affaiblit cette garantie, surtout pour les blocs « déjà votés mais pas encore confirmés ». Certaines dApps à haut débit veulent lire les données juste après le vote pour réduire la latence. Si le bloc est soudainement abandonné, cela peut entraîner un retour arrière de l’état utilisateur — solde incorrect, transaction à effet de levier perdue, état de jeu réinitialisé, etc.
Quatrièmement, risque de défaillance en cascade :
En général, une bifurcation terminale retarde un bloc d’un seul tour, ce qui n’est pas dramatique. Mais dans des cas extrêmes, si plusieurs leaders successifs choisissent de sauter le bloc précédent, le réseau peut se figer. Personne ne veut « reprendre » le bloc en suspens. La chaîne reste bloquée jusqu’à l’apparition d’un leader suffisamment honnête pour assumer cette responsabilité.
Des solutions existent déjà, comme le mécanisme d’évitement proposé par BeeGees, mais elles coûtent souvent cher en performance, par exemple en réintroduisant une complexité de communication quadratique — un prix trop élevé.
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. Son innovation majeure est d’éliminer ce risque structurel sans sacrifier les gains de performance offerts par HotStuff en pipeline. En d’autres termes, MonadBFT n’abandonne pas le cadre de HotStuff, mais l’améliore. Il conserve trois caractéristiques clés :
1) Rotation des leaders (rotating leader) : un nouveau leader est élu à chaque tour pour faire avancer la chaîne ;
2) Validation en pipeline (pipelined commits) : plusieurs processus de confirmation peuvent se chevaucher ;
3) Communication linéaire (linear messaging) : chaque validateur ne communique qu’avec le leader, réduisant fortement la charge réseau.
Mais ces trois éléments ne suffisent pas à assurer la sécurité. Pour colmater la faille structurelle de la bifurcation terminale, MonadBFT ajoute deux mécanismes cruciaux :
1) Mécanisme de reproposition obligatoire (Re-Proposal)
2) Certificat d’absence d’approbation (NEC, No-Endorsement Certificate)
Mécanisme de reproposition (Re-Proposal)
Dans les protocoles BFT, le temps est divisé en tours (appelés view), chaque tour ayant un leader chargé de proposer un bloc. Si le leader échoue (par exemple, ne propose pas de bloc ou propose un bloc invalide), le système passe au tour suivant et élit un nouveau leader.
MonadBFT ajoute un mécanisme garantissant qu’aucun bloc honnêtement proposé ne sera perdu à cause d’un changement de leader.
Lorsqu’un leader courant échoue, les validateurs envoient un message de changement de vue signé (view change), indiquant que le tour a expiré.
Spécificité importante : ce message ne signale pas seulement « timeout », mais doit aussi contenir l’information du dernier bloc pour lequel le validateur a voté, comme pour dire : « je n’ai pas reçu de proposition valide, voici le bloc le plus récent que j’ai vu. »
Le nouveau leader collecte ces messages de timeout auprès d’une supermajorité (2f+1) de validateurs et les agrège en un certificat de timeout (Timeout Certificate, TC). Ce TC représente la vision collective du réseau sur le bloc de tête lorsque le tour précédent échoue. Le nouveau leader sélectionne alors le bloc suspendu le plus haut (high_tip).
MonadBFT exige que la proposition du nouveau leader inclue un TC valide et reproposera obligatoirement le bloc le plus haut identifié dans le TC, donnant ainsi une nouvelle chance de confirmation à ce bloc.
Pourquoi ? Comme mentionné précédemment : nous ne voulons pas qu’un bloc presque confirmé disparaisse.
Exemple : Alice est leader au view 5, propose un bloc valide et obtient une majorité de votes. Bob, leader au view 6, est hors ligne. Quand Carol devient leader au view 7, selon les règles de MonadBFT, elle doit inclure le TC et reproposer le bloc d’Alice. Ainsi, le travail honnête d’Alice n’est pas perdu.
Si Carol n’a pas le bloc d’Alice, elle peut le demander aux autres nœuds. Ceux-ci peuvent :
-
Fournir le bloc, ou
-
Renvoyer un message signé « pas d’approbation » (No-Endorsement, NE), indiquant qu’ils n’ont pas ce bloc (mécanisme expliqué plus bas). (Au maximum f nœuds byzantins peuvent ignorer la requête.)
Dès que Carol reproposera le bloc d’Alice, elle obtiendra une opportunité supplémentaire de proposition, évitant ainsi d’être pénalisée par l’échec du leader précédent.
L’objectif du mécanisme de reproposition est clair : assurer une progression équitable de la chaîne, où aucun travail valide n’est perdu par malchance ou sabotage.
Certificat d’absence d’approbation (NEC)
Reprenons l’exemple : après le timeout de Bob, Carol demande aux validateurs le bloc high_tip (celui d’Alice). Au moins 2f+1 validateurs répondront :
-
Soit en fournissant le bloc d’Alice,
-
Soit en envoyant un message NE signé, affirmant ne pas avoir reçu le bloc.
S’il obtient le bloc d’Alice, Carol doit le reproposer conformément à la règle. Seulement si au moins f+1 validateurs ont signé un message NE, Carol peut ignorer ce bloc et en proposer un nouveau.
Pourquoi f+1 ? Dans un système BFT composé de 3f+1 validateurs, au plus f peuvent être malveillants. Si le bloc d’Alice a obtenu une supermajorité de votes, alors au moins 2f+1 nœuds honnêtes l’ont reçu.
Ainsi, si Carol affirme « je ne peux pas obtenir le bloc d’Alice », elle doit présenter f+1 signatures prouvant que ces validateurs ne l’ont pas reçu. Cela forme un No-Endorsement Certificate (NEC).
Le NEC est un justificatif d’exemption pour le leader : une preuve vérifiable que le bloc précédent n’était pas prêt à être confirmé, et que le saut n’est pas malveillant, mais justifié.
Reproposition + NEC = fin de la bifurcation terminale
Grâce au mécanisme de reproposition et au certificat NEC, MonadBFT établit des règles strictes et claires pour traiter le bloc de tête :
Soit finaliser le bloc « presque confirmé » ;
Soit fournir une preuve suffisante qu’il n’est pas encore prêt à être confirmé ;
Sinon, il est interdit de sauter ou remplacer le bloc précédent.
Ce mécanisme garantit : tout bloc ayant obtenu une majorité légale de votes ne peut être abandonné à cause d’une erreur ou d’un acte malveillant du leader.
Le risque structurel de bifurcation terminale est systématiquement éliminé, et le protocole impose des contraintes claires contre les sauts abusifs.
Si un leader tente de sauter un bloc sans fournir de NEC, le protocole détecte immédiatement et rejette cette action. Tout saut sans preuve cryptographique est illégal et ne reçoit pas le soutien du consensus.
Sur le plan des incitations économiques, ce design protège clairement les validateurs :
-
Tout bloc honnêtement proposé et soutenu par des votes conservera ses récompenses même en cas de dysfonctionnement ultérieur ;
-
Même dans des cas extrêmes, si un nœud saute intentionnellement son tour pour aider un autre à s’approprier la MEV d’un bloc précédent, le protocole force le leader suivant à le reproposer en priorité, empêchant ainsi tout gain économique issu du saut.
Encore plus important, MonadBFT n’a pas sacrifié la performance pour renforcer la sécurité.
Certaines solutions antérieures (comme BeeGees) offraient une certaine protection, mais au prix d’une complexité de communication élevée (n²) ou de redémarrages fréquents de communication, ce qui alourdit inutilement le système.
La stratégie de MonadBFT est plus élégante :
Les communications supplémentaires (messages de timeout, repropositions) ne sont activées que lors d’échecs ou d’anomalies. Sur le chemin normal, où les leaders sont honnêtes et produisent des blocs en continu, le protocole reste léger et efficace.
Cet équilibre dynamique entre performance et sécurité constitue l’un des principaux avantages de MonadBFT par rapport aux générations précédentes.
Résumé
Cet article a passé en revue les mécanismes fondamentaux de PBFT, retracé l’évolution du protocole HotStuff, et expliqué en détail comment MonadBFT corrige structurellement le problème de bifurcation terminale inhérent au HotStuff en pipeline.
La bifurcation terminale dénature les incitations économiques des validateurs et menace potentiellement l’activité du réseau. Grâce aux mécanismes de reproposition et de certificat NEC, MonadBFT garantit que tout bloc honnêtement proposé et soutenu par une majorité légale ne sera ni abandonné ni ignoré.
Dans le prochain article, nous explorerons deux autres caractéristiques fondamentales de MonadBFT :
1) Finalité spéculative (Speculative Finality)
2) Réactivité optimiste (Optimistic Responsiveness)
Et nous analyserons leurs implications concrètes pour les validateurs et les développeurs.
À suivre.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
