DansPartie 1,nous avons examiné le fonctionnement du consensus classique PBFT et celui des premières versions de HotStuff. Nous avons également examiné comment MonadBFT résout le problème de tail-forking de HotStuff, où des blocs valides sont parfois laissés en arrière dans les systèmes en pipeline.

Ce problème de fork en queue crée deux gros problèmes : 1) il perturbe les récompenses des constructeurs de blocs honnêtes et 2) peut potentiellement bloquer le réseau.

MonadBFT introduit la règle de Reproposal et les mécanismes de vote No-Endorsement pour éliminer le problème de tail-forking, garantissant que tout bloc correctement approuvé par un proposant honnête fera toujours partie de la chaîne.

Dans la deuxième partie, nous explorerons les deux autres caractéristiques de MonadBFT qui sont 1) la finalité spéculative et 2) la réactivité optimiste. Nous explorerons également les implications de MonadBFT pour les développeurs.

Finalité spéculative à un tour

Outre la résistance à la fourchette de queue, une autre caractéristique majeure de MonadBFT est la finalité spéculative dans un seul round.

En termes pratiques, cela signifie que les clients et les utilisateurs peuvent recevoir une confirmation de leur transaction immédiatement après qu'un bloc reçoit une majorité absolue de votes, même avant que le tour suivant ne se termine.

Rappelez-vous que dans les protocoles baseline HotStuff, un bloc n'est généralement pas considéré comme final (irréversible) tant qu'il n'a pas traversé au moins deux phases (par exemple Fast-Hotstuff & Diem-BFT) : une phase pour obtenir un certificat de quorum (verrouiller le bloc avec ≥2f+1 votes), et une deuxième phase où le prochain leader s'appuie sur ce CQ et s'engage sur le bloc.

Ce commit à deux phases est nécessaire pour garantir la sécurité : une fois que suffisamment de nœuds honnêtes ont verrouillé un bloc, aucun bloc conflictuel ne peut rassembler un quorum, et le commit au tour suivant le rend permanent. Ainsi, normalement, un client pourrait devoir attendre que le prochain bloc ou le prochain tour soit produit avant de savoir si la transaction précédente est définitive.

MonadBFT permet essentiellement à une transaction d'être considérée comme suffisamment finale (sûre d'agir) après juste un tour de vote. Cela s'appelle la finalité spéculative.

Lorsqu'un leader propose un bloc et que les validateurs votent pour former un QC pour ce bloc, ce bloc est maintenant dans un état Voté (il est verrouillé par un quorum). Dans MonadBFT, les validateurs exécuteront les transactions du bloc dès qu'ils formeront le QC et enverront même une confirmation préliminaire aux clients indiquant que le bloc est (spéculativement) accepté. C'est un peu comme dire : « Nous avons une supermajorité d'accord sur ce bloc. À moins qu'il ne se produise quelque chose de très inattendu, considérez ce bloc comme confirmé. »

Cette confirmation immédiate est optimiste. Le bloc n'a pas encore été validé dans le grand livre. Cela se produira lorsque la prochaine proposition viendra le finaliser (QC-on QC), mais dans des conditions normales, rien ne l'annulera. Le seul scénario qui peut annuler un bloc exécuté de manière spéculative est si le leader s'est rétracté (c'est-à-dire a proposé deux blocs différents à la même hauteur pour diviser le vote).

On peut penser à la finalité spéculative comme un agréable sous-produit de la résistance au tail-forking. La résistance au tail-forking garantit que même si le prochain leader plante, la proposition actuelle ne sera pas abandonnée (grâce aux règles de reproposition et de NEC). Ainsi, le seul moment où un bloc exécuté de manière spéculative est abandonné est si le proposant original a fait une équivoque (faute de double-signature qui est de manière prouvable malveillante), ce qui est : 1) détectable via des QC conflictuels, 2) punissable par la perte de fonds et 3) extrêmement rare.

Dans les protocoles précédents, ils ne garantissaient pas que le prochain leader repropose le bloc précédent, ce qui rendait possible le tail-forking, brisant ainsi les hypothèses de spéculation.

Réactivité optimiste

Dans la plupart des protocoles de consensus, il y a une attente intégrée après chaque tour, comme une période tampon ou un délai d'attente. Cela permet de s'assurer que tous les messages sont arrivés avant de passer à l'étape suivante. Il s'agit d'un mécanisme de protection destiné à gérer le pire des cas, comme lorsque le leader plante ou n'envoie rien du tout.

Ces délais d'attente sont souvent trop conservateurs. Si le réseau fonctionne normalement et que tous les validateurs se comportent correctement, cette attente fixe devient un surdébit inutile. Les blocs auraient pu être finalisés plus rapidement, mais le protocole a préféré attendre au cas où.

MonadBFT introduit une réactivité optimiste, ce qui signifie que le protocole peut avancer immédiatement en fonction des messages du réseau, au lieu de toujours s'appuyer sur des minuteries fixes. Le principe de conception ici peut être résumé comme "rapide quand c'est possible, patient quand c'est nécessaire".

MonadBFT est conçu de telle sorte que dans le cas normal et même en cas de récupération d'une défaillance, il ne s'arrête pas pour un délai prédéterminé s'il n'est pas obligé de le faire.

• Dans le scénario idéal (ce qui signifie que nous avons un leader honnête) : Il n'y a aucun délai intégré pour proposer ou voter. Dès qu'un leader a la main, il propose un bloc. Dès que les validateurs reçoivent une proposition valide, ils votent. Au moment où le leader (ou plutôt, le prochain leader, puisque les votes vont au prochain proposeur dans HotStuff en mode pipeliné) rassemble 2f+1 votes, un QC est formé et peut être diffusé. Dans une conception réactive optimiste, cela déclenche immédiatement la phase suivante.

En pratique, cela signifie que si la latence du réseau entre les nœuds est, disons, de 100 ms, le consensus peut potentiellement terminer un tour en seulement quelques centaines de millisecondes (plus les frais de calcul et d'agrégation).

Il n'attend pas, par exemple, une seconde complète de "temps de slot" s'il n'en a pas besoin. Cela contraste avec le réseau principal d'Ethereum qui suit unmodèle de slot-et-epochSur Ethereum, la production de blocs est fixée à des intervalles de 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 pipelinée de HotStuff mais supprime la règle rigide "vous devez attendre Δ secondes" dans le cas normal. Cela signifie qu'elle peut surpasser les systèmes limités dans le temps en termes de réactivité sans sacrifier la sécurité.

• Dans le cas de figure malheureux (défaillance du leader) : Dans de nombreux protocoles de consensus, lorsque le leader échoue à proposer un bloc, les autres nœuds ne s'en rendent compte qu'après l'expiration d'un délai Δ. Si Δ est, par exemple, de 1 seconde, ce temps est essentiellement perdu. MonadBFT gère cela différemment. Lorsque les validateurs détectent une proposition manquante, ils diffusent immédiatement des messages de temporisation (TC ou Certificat d'Expiration). Dès que 2f+1 de ces temporisations sont observées, le prochain leader prend le relais. La transition vers la nouvelle vue est déclenchée par des preuves basées sur le quorum, et non par l'horloge.

Comparaison avec le consensus de la famille hotstuff

MonadBFT s'appuie sur la lignée des protocoles de consensus de la famille HotStuff, mais se distingue en parvenant à combiner des propriétés souhaitables que aucune conception précédente n'a pu intégrer pleinement sans compromis. Les protocoles précédents étaient souvent optimisés pour certaines dimensions telles que le débit en pipeline ou la communication linéaire mais devaient sacrifier d'autres aspects. MonadBFT parvient de manière unique à combiner une complexité de messagerie linéaire, des engagements en pipeline, une forte résistance aux forkings de queue, une réactivité instantanée sans délais fixes et des mécanismes de récupération efficaces, tout en préservant une finalité rapide et des garanties de haute vivacité. Le tableau ci-dessous résume comment MonadBFT se compare aux autres protocoles BFT à leader tournant sur ces dimensions critiques.

Que cela signifie-t-il pour les développeurs et les utilisateurs?

Pour les développeurs, MonadBFT signifie plusieurs choses :

• Modèle de finalité plus simple : Avec MonadBFT, vous pouvez considérer un bloc qui a un QC (vote à la majorité) comme effectivement finalisé pour la plupart des usages, car le protocole le finalisera ou le réduira en cas de besoin. Les développeurs peuvent agir en toute sécurité sur des confirmations à 1 bloc avec une grande confiance.
• Expérience utilisateur améliorée pour les applications : Si vous développez une application à haut débit (échange, jeu, etc.), la faible latence et la résistance aux forks de MonadBFT se traduisent par une expérience utilisateur plus fluide. Les utilisateurs voient leurs actions confirmées presque instantanément et ne rencontrent pas souvent de réorganisations ou d'annulations déroutantes. Cela vous permet de concevoir des applications qui supposent la finalité et des mises à jour rapides.
• Comportement déterministe : les règles plus strictes de MonadBFT (comme l'exigence de re-proposition) réduisent le non-déterminisme dans l'inclusion des blocs. Il y a moins de scénarios "limite" où un bloc pourrait être inclus ou sauté en fonction du timing subtil, par exemple si un vote ou un délai atteint le leader en premier. MonadBFT remplace une telle ambiguïté sensible au timing par des règles explicites et des preuves vérifiables. Cela rend plus facile de raisonner sur la correction du protocole et de le tester. Cela fournit également des bases claires pour identifier les nœuds défectueux (par exemple, si quelqu'un ne parvient pas à re-proposer ou propose un bloc en conflit, vous savez qu'ils ont violé le protocole).
• Marge de scalabilité : Si vous êtes un développeur préoccupé par la mise à l'échelle, MonadBFT vous offre plus de marge de manœuvre avant de rencontrer des goulots d'étranglement. Vous pouvez augmenter les tailles de blocs ou le nombre de validateurs de manière plus confortable que sur un protocole quadratique. Et des fonctionnalités telles que la dissémination de blocs à code d'effacement signifient que vous pouvez faire passer beaucoup de données à travers le réseau sans surcharger les nœuds individuels. Cela permet de viser un débit plus élevé, ouvrant ainsi de nouveaux espaces de conception pour des applications on-chain plus ambitieuses.

Pour les utilisateurs finaux : Un utilisateur lambda ne saura rien de tout ce dont nous avons discuté ici, mais il ressent ses effets. Avec MonadBFT à la base de Monad, les utilisateurs peuvent s'attendre à toutes les belles qualités ci-dessous sans sacrifier la décentralisation et la résistance à la censure.

• Confirmations plus rapides : Les transactions (comme l'envoi de jetons, l'échange d'actifs, la création de NFT, l'exécution de transactions) se confirmeront très rapidement.
• Moins de surprises : la cohérence de l'état de la chaîne est plus élevée car des éléments tels que le tail-forking, qui est essentiellement une réorganisation, sont éliminés
• Équité et transparence : Les améliorations apportées au consensus signifient indirectement que le fonctionnement de la chaîne est plus équitable. Aucun validateur unique ne peut facilement censurer les transactions ou manipuler l'ordre des blocs.

Conclusion

Pour récapituler, MonadBFT introduit quatre innovations majeures sur le consensus de style HotStuff en mode pipeline :

Résistance à la bifurcation de la queue : MonadBFT est le premier protocole BFT en pipeline à éliminer les attaques de bifurcation de queue. Il y parvient en exigeant que le prochain leader reproposera le dernier bloc voté si le leader précédent a échoué, ou montrera autrement un certificat de non-approbation (NEC) comme preuve que le bloc manquait de soutien. Cela garantit qu'aucun bloc soutenu par une supermajorité ne sera abandonné, protégeant ainsi les récompenses des leaders honnêtes et empêchant les réorganisations malveillantes et l'extraction de MEV entre blocs.

Finalité spéculative en une ronde : les validateurs peuvent confirmer un bloc après une seule ronde de communication (une proposition de leader et des votes), donnant aux clients une assurance immédiate de l'inclusion. Cette confirmation spéculative ne sera annulée que si le leader fait acte de duplicité (un acte pouvant être prouvé et puni), ce qui en fait une hypothèse sûre en pratique.

Réactivité Optimiste : Le protocole fonctionne à la vitesse du réseau sans retards inhérents. Les leaders font avancer le consensus dès que les votes nécessaires sont reçus, et les changements de vue se produisent dès qu'un quorum de délais d'attente est observé, plutôt que d'attendre un intervalle de temps fixe. Cette conception réactive de manière optimiste réduit au minimum les temps d'attente et maximise le débit, tout en gérant de manière robuste l'asynchronie et les défauts lorsqu'ils se produisent.

Communication linéaire : Sur le chemin heureux (ce qui signifie que le leader est honnête), la complexité du message et de l'authentification est linéaire par rapport au nombre de validateurs. MonadBFT conserve le schéma de communication efficace de HotStuff, en utilisant des signatures agrégées et des diffusions simples du leader aux validateurs, ce qui permet au protocole de s'étendre à des centaines de validateurs sans goulots d'étranglement de performance.

Avertissement：

1. Cet article est repris de [michael_lwy]. Tous les droits d'auteur appartiennent à l'auteur original [michael_lwy]. Si des objections existent à cette réimpression, veuillez contacter leGate Learnéquipe, et ils s'en occuperont rapidement.
2. Clause de non-responsabilité : Les points de vue et opinions exprimés dans cet article sont uniquement ceux de l'auteur et ne constituent aucun conseil en investissement.
3. Les traductions de l'article dans d'autres langues sont effectuées par l'équipe Gate Learn. Sauf mention contraire, la copie, la distribution ou le plagiat des articles traduits est interdit.