Analyse de MonadBFT (2/2) : ce que cela signifie pour les développeurs et les utilisateurs
TechFlow SélectionTechFlow Sélection
Analyse de MonadBFT (2/2) : ce que cela signifie pour les développeurs et les utilisateurs
MonadBFT introduit quatre innovations fondamentales basées sur le consensus de style HotStuff en pipeline : résistance au fork terminal, finalité spéculative en un seul tour, réactivité optimiste et communication linéaire.
Dédié à des analyses Web3 approfondiesDans la première partie, nous avons examiné le fonctionnement du consensus PBFT (Practical Byzantine Fault Tolerance) classique et la manière dont les premières versions de HotStuff opéraient. Nous avons également vu comment MonadBFT résout le problème de la fourchette terminale de HotStuff, où des blocs valides sont parfois abandonnés dans un système en pipeline.
Ce problème de fourchette terminale pose deux principaux inconvénients : 1) il perturbe la récompense des proposants honnêtes, 2) il peut entraîner un blocage du réseau.
MonadBFT introduit une règle de re-proposition et un mécanisme de vote sans endorsement afin d'éliminer le problème de la fourchette terminale, garantissant que tout bloc correctement approuvé provenant d’un proposant honnête soit intégré à la chaîne.
Dans cette deuxième partie, nous allons explorer deux autres caractéristiques de MonadBFT : 1) la finalité spéculative en un tour, et 2) la réactivité optimiste. Nous examinerons également l'impact de MonadBFT sur les développeurs.
Finalité spéculative en un tour
Outre sa résistance à la fourchette terminale, une autre caractéristique majeure de MonadBFT est la finalité spéculative en un tour.
En pratique, cela signifie que les clients et utilisateurs peuvent recevoir immédiatement une confirmation de transaction dès qu’un bloc obtient la majorité des votes, même avant la fin du prochain tour.
Rappelons que dans le protocole HotStuff de base, un bloc doit généralement traverser au moins deux phases (comme Fast-Hotstuff ou Diem-BFT) pour être considéré comme définitivement confirmé (irréversible) : une première phase permet d’obtenir un certificat de quorum (QC) (verrouillant le bloc avec ≥2f+1 votes), puis une seconde phase intervient lorsque le prochain leader construit et soumet un bloc basé sur ce certificat de quorum (QC).
Cette validation en deux phases est nécessaire pour assurer la sécurité : une fois qu’un nombre suffisant de nœuds honnêtes a verrouillé un bloc, aucun bloc conflictuel ne peut obtenir de quorum, et la validation suivante le rend permanent. Par conséquent, les clients doivent généralement attendre la création du bloc ou du tour suivant pour savoir si leur transaction précédente est bien finale.
MonadBFT permet essentiellement de considérer une transaction comme suffisamment finale (sûre à manipuler) après un seul tour de vote. C’est ce qu’on appelle la finalité spéculative.
Lorsqu’un leader propose un bloc et que les validateurs votent pour former le QC de ce bloc, celui-ci entre dans un état voté (verrouillé par le quorum). Dans MonadBFT, dès que le QC est formé, les validateurs exécutent immédiatement les transactions du bloc, voire envoient aux clients une confirmation préliminaire indiquant que le bloc est accepté (de façon spéculative). C’est comme dire « Nous avons l’accord de la grande majorité sur ce bloc. À moins qu’un événement très improbable ne survienne, ce bloc peut être considéré comme confirmé. »
Cette confirmation immédiate est optimiste. Le bloc n’est pas encore soumis au grand livre. Ce sera fait lors du prochain tour, quand un nouveau bloc viendra confirmer ce QC (QC-on-QC), mais dans des conditions normales, rien ne l’annulera. La seule situation pouvant annuler un bloc exécuté de façon spéculative est une attaque d’équivalence par le leader (c’est-à-dire proposer deux blocs différents à la même hauteur afin de diviser les votes).
Vous pouvez voir la finalité spéculative comme un excellent effet secondaire de la résistance à la fourchette terminale. La résistance à la fourchette terminale garantit que même si le prochain leader tombe en panne, la proposition actuelle ne sera pas abandonnée (grâce aux règles de re-proposition et de NEC). Le seul cas où un bloc exécuté de façon spéculative serait abandonné est une attaque d’équivalence par le proposant initial (erreur prouvée de double signature, malveillante), ce qui : 1) peut être détecté via des QC conflictuels ; 2) peut être sanctionné ; 3) est extrêmement rare.
Dans les protocoles antérieurs, il n’était pas garanti que le prochain leader reprenne le bloc précédent, rendant ainsi possible la fourchette terminale, ce qui brise l’hypothèse spéculative.
Réactivité optimiste
Dans la plupart des protocoles de consensus, une attente intégrée, telle qu’un délai tampon ou un timeout, suit chaque tour. Cela sert à s’assurer que tous les messages sont bien arrivés avant de continuer. Il s’agit d’un mécanisme de protection conçu pour gérer les pires scénarios, comme la panne du leader ou son absence totale de communication.
Ces timeouts sont généralement trop conservateurs. Si le réseau fonctionne normalement et que tous les validateurs agissent correctement, alors cette attente fixe devient un coût inutile. Les blocs pourraient être finalisés plus vite, mais le protocole retarde tout de même par précaution.
MonadBFT introduit la réactivité optimiste, ce qui signifie que le protocole peut avancer immédiatement selon les informations du réseau, plutôt que de dépendre systématiquement de minuteries fixes. Le principe de conception peut se résumer par « allez vite quand vous le pouvez, soyez patient seulement quand c’est nécessaire ».
MonadBFT est conçu pour, dans les conditions normales et même lors de récupération après panne, ne pas interrompre le processus pour attendre un timeout prédéfini s’il n’est pas nécessaire.
- Sur le chemin heureux (c’est-à-dire avec un leader honnête) : aucune latence intégrée dans la proposition ou le vote. Dès que c’est au tour du leader, il propose un bloc. Les validateurs votent immédiatement dès réception d’une proposition valide. Lorsque le leader (ou plus précisément, le prochain leader, car dans HotStuff en pipeline, les votes sont envoyés au prochain proposant) collecte 2f+1 votes, le QC est formé et peut être diffusé. Dans la conception de réactivité optimiste, cela déclenche immédiatement la phase suivante.
En pratique, cela signifie que si la latence réseau entre les nœuds est de 100 millisecondes, le consensus pourrait achever un tour en quelques centaines de millisecondes (hors calculs et coûts d’agrégation).
Il n’attend pas inutilement, par exemple, une « période de slot » entière d’une seconde. Cela contraste avec le modèle slot-and-epoch adopté par le réseau principal d’Ethereum. Sur Ethereum, l’intervalle de production de blocs est fixé à 12 secondes. Même si tout le monde est prêt plus tôt, le protocole attend.
L’approche de MonadBFT élimine les retards inutiles. Elle conserve la structure en pipeline de HotStuff, mais supprime l’exigence rigide de « attendre Δ secondes » dans les conditions normales. Cela signifie qu’elle peut surpasser les systèmes à contrainte temporelle en termes de réactivité, sans compromettre la sécurité.
- Sur le chemin non heureux (panne du leader) : dans de nombreux protocoles de consensus, lorsque le leader ne parvient pas à proposer un bloc, les autres nœuds ne s’en rendent compte qu’après un timeout Δ. Par exemple, si Δ vaut 1 seconde, ce temps est essentiellement perdu. MonadBFT gère cela différemment. Lorsque les validateurs détectent une absence de proposition, ils diffusent immédiatement un message de timeout (TC ou certificat de timeout). Une fois que 2f+1 timeouts sont atteints, le prochain leader prend le relais. La transition vers la nouvelle vue est déclenchée par une preuve basée sur le quorum, et non par l’horloge.
Comparaison avec les consensus de la famille HotStuff
MonadBFT s’appuie sur les protocoles de consensus de la famille HotStuff, mais se distingue en combinant un ensemble de propriétés idéales. Les protocoles antérieurs étaient souvent optimisés pour certaines dimensions, comme le débit en pipeline ou la communication linéaire, mais devaient sacrifier d'autres aspects. MonadBFT combine de manière unique la complexité linéaire des messages, la validation en pipeline, une forte résistance à la fourchette terminale, une réactivité immédiate sans délai fixe, et un mécanisme de récupération efficace, tout en conservant des garanties de finalité rapide et de haute disponibilité. Le tableau ci-dessous résume la comparaison entre MonadBFT et d’autres protocoles BFT à rotation de leader sur ces dimensions clés :
Que signifie cela pour les développeurs et les utilisateurs ?
Pour les développeurs, MonadBFT implique plusieurs points :
- Un modèle de finalité plus simple : avec MonadBFT, vous pouvez considérer un bloc doté d’un QC (majorité des votes) comme effectivement finalisé, car le protocole le finalisera ou imposera une sanction. Les développeurs peuvent opérer en toute confiance avec une confirmation de bloc unique.
- Amélioration de l’expérience utilisateur des applications : si vous développez une application à haut débit (bourse, jeu, etc.), les faibles latences et la résistance aux fourchettes de MonadBFT se traduiront par une expérience utilisateur plus fluide. Les utilisateurs verront presque immédiatement leurs actions confirmées, sans subir fréquemment des réorganisations ou annulations déroutantes. Vous pouvez ainsi concevoir des applications avec finalité et mise à jour rapide.
- Comportement déterministe : les règles plus strictes de MonadBFT (comme l’exigence de re-proposition) réduisent l’incertitude d’inclusion des blocs. Moins de « cas limites » où un bloc est inclus ou sauté selon des facteurs subtils de timing, comme l’arrivée du vote ou du timeout au leader. MonadBFT remplace cette ambiguïté sensible au temps par des règles claires et des preuves vérifiables. Cela facilite le raisonnement sur la correction du protocole et les tests. Cela fournit aussi une base claire pour identifier les nœuds défaillants (par exemple, si quelqu’un ne re-propose pas ou propose un bloc conflictuel, vous savez qu’il viole le protocole).
- Espace d’extensibilité : si vous êtes un développeur soucieux de l’extensibilité, MonadBFT vous offre plus de marge avant d’atteindre un goulot d’étranglement. Comparé aux protocoles quadratiques, vous pouvez augmenter plus facilement la taille des blocs ou le nombre de validateurs. Et des fonctionnalités comme la diffusion de blocs avec codage d’effacement signifient que vous pouvez transmettre beaucoup de données via le réseau sans surcharger un nœud individuel. Cela rend possible des débits plus élevés, ouvrant l’espace de conception à des applications blockchain plus ambitieuses.
Pour les utilisateurs finaux : les utilisateurs ordinaires ne comprendront pas ce dont nous parlons ici, mais ils ressentiront ses effets. Avec MonadBFT comme fondement de la chaîne Monad, les utilisateurs peuvent s’attendre à toutes ces qualités positives sans sacrifier la décentralisation ni la résistance à la censure.
- Confirmations plus rapides : les transactions (envoi de jetons, échange d’actifs, frappe de NFT, exécution d’ordres) seront confirmées rapidement.
- Moins de surprises : l’état de la chaîne est plus cohérent, car des phénomènes comme la fourchette terminale, qui sont essentiellement des réorganisations, sont éliminés.
- Équité et transparence : l’amélioration du consensus signifie indirectement que la chaîne fonctionne plus équitablement. Aucun validateur unique ne peut facilement censurer des transactions ou manipuler l’ordre entre les blocs.
Conclusion
Pour résumer, MonadBFT introduit quatre innovations fondamentales basées sur le consensus de style HotStuff en pipeline :
Résistance à la fourchette terminale : MonadBFT est le premier protocole BFT en pipeline à éliminer l’attaque de fourchette terminale. Il y parvient en obligeant le prochain leader, si le précédent échoue, à re-proposer le bloc précédemment voté, ou à fournir un certificat sans endorsement (NEC) prouvant que le bloc manque de soutien. Cela garantit que tout bloc bénéficiant de la majorité absolue ne sera pas abandonné, protégeant ainsi la récompense des leaders honnêtes, et empêchant les réorganisations malveillantes et l’extraction de MEV inter-blocs.
Finalité spéculative en un tour : les validateurs peuvent confirmer un bloc après une seule ronde de communication (proposition d’un leader et votes), offrant aux clients une garantie immédiate d’inclusion. Cette confirmation spéculative n’est annulée que dans le cas d’une attaque d’équivalence par le leader (comportement prouvable et sanctionnable), ce qui en fait une hypothèse sûre en pratique.
Réactivité optimiste : le protocole fonctionne à la vitesse du réseau, sans délai intrinsèque. Le leader fait avancer le consensus immédiatement après réception des votes nécessaires, et le changement de vue se produit immédiatement après observation d’un quorum de timeouts, plutôt que d’attendre un intervalle de timeout fixe. Cette conception à réactivité optimiste minimise les temps d’attente et maximise le débit, tout en restant robuste face à l’asynchronie et aux pannes.
Communication linéaire : dans le cas nominal (c’est-à-dire avec un leader honnête), la complexité des messages et des validations est linéaire par rapport au nombre de validateurs. MonadBFT conserve le modèle de communication efficace de HotStuff, utilisant des signatures agrégées et une simple diffusion du leader vers les validateurs, permettant ainsi au protocole de s’étendre à des centaines de validateurs sans goulot de performance.
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
