Dans la première partie, nous avons étudié le fonctionnement du consensus classique PBFT (tolérance aux fautes byzantines pratique) et la manière dont les premières versions de HotStuff fonctionnaient. Nous avons également appris comment MonadBFT résout le problème de fork de fin de HotStuff, c'est-à-dire le problème où des blocs valides peuvent parfois être abandonnés dans un système en pipeline.
Ce problème de fork entraîne deux problèmes majeurs : 1) Il perturbe les récompenses des constructeurs de blocs honnêtes, 2) Il peut entraîner un arrêt du réseau.
MonadBFT a introduit des règles de ré-proposition et un mécanisme de vote sans approbation pour éliminer le problème des forks finaux, garantissant que tout Bloc correctement approuvé provenant de proposeurs honnêtes puisse entrer dans la chaîne.
Dans la deuxième partie, nous allons explorer deux autres caractéristiques de MonadBFT : 1) la finalité spéculative et 2) la réactivité optimiste. Nous examinerons également l'impact de MonadBFT sur les développeurs.
finalité de la spéculation à un tour
En plus de résister aux forks de la queue, une autre caractéristique principale de MonadBFT est la finalité spéculative en un seul tour.
Dans la pratique, cela signifie que les clients et les utilisateurs peuvent recevoir une confirmation de transaction immédiatement après que le bloc a obtenu la majorité des votes, même avant la fin du prochain tour.
Rappelons qu'avec le protocole HotStuff de base, un bloc doit généralement passer par au moins deux étapes (comme Fast-Hotstuff et Diem-BFT) avant d'être considéré comme finalisé (irréversible) : une étape pour obtenir un certificat de majorité (QC) (en verrouillant le bloc avec ≥2f+1 votes), la deuxième étape est que le prochain leader construit et soumet le bloc basé sur ce certificat de majorité (QC).
Ce processus de soumission en deux étapes est nécessaire pour assurer la sécurité : une fois qu'un nombre suffisant de nœuds honnêtes a verrouillé un bloc, le bloc en conflit ne peut pas obtenir le nombre requis de votes, et le prochain tour de soumission le rendra permanent. Par conséquent, le client doit généralement attendre la génération du prochain bloc ou du prochain tour pour savoir si la transaction précédente est finalisée.
MonadBFT permet essentiellement que les transactions soient considérées comme suffisamment finales (opérables en toute sécurité) 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 est alors dans un état de vote (verrouillé par le nombre légal de personnes). Dans MonadBFT, dès qu'un validateur forme le QC, il exécute immédiatement les transactions de ce bloc et peut même envoyer une confirmation préliminaire au client, indiquant que ce bloc est (spéculativement) accepté. C'est comme dire "Nous avons la grande majorité des gens qui acceptent ce bloc. À moins qu'il ne se produise une situation très inattendue, ce bloc peut être considéré comme confirmé."
Cette confirmation instantanée est optimiste. Le bloc n'a pas encore été soumis au registre. Cela se produira lorsque la prochaine proposition apparaîtra et que celle-ci sera confirmée (QC-on QC), mais en règle générale, rien ne pourra l'annuler. La seule situation pouvant annuler l'exécution spéculative d'un bloc est qu'un leader subisse une attaque équivalente (c'est-à-dire proposer deux blocs différents à la même hauteur pour disperser les votes).
Vous pouvez considérer la finalité spéculative comme un excellent sous-produit de la résistance aux forks de queue. La résistance aux forks de queue garantit que, même si le prochain leader s'effondre, la proposition actuelle ne sera pas abandonnée (grâce aux règles de réproposition et de NEC). La seule situation dans laquelle un bloc d'exécution spéculative est abandonné est lorsque le proposeur original subit une attaque équivalente (une erreur de double signature démontrable malveillante), et ce cas : 1) peut être détecté par un QC de conflit ; 2) peut être puni ; 3) est extrêmement rare.
Dans le protocole précédent, ils ne garantissent pas que le prochain leader va redéposer le dernier Bloc, donc un fork à la fin est possible, ce qui rompt l'hypothèse spéculative.
réactivité optimiste
Dans la plupart des protocoles de consensus, il existe une attente intégrée après chaque tour, telle qu’une période de tampon ou un délai d’expiration. Il s’agit de s’assurer que tous les messages sont arrivés avant d’aller de l’avant. Il s’agit d’un mécanisme de protection conçu pour faire face au pire des scénarios, comme le crash d’un leader ou l’absence totale d’envoi de messages.
Ces délais sont souvent trop conservateurs. Si le réseau fonctionne normalement et que tous les validateurs agissent correctement, alors une attente fixe devient une dépense inutile. Les blocs auraient pu être complétés plus rapidement, mais le protocole a choisi de retarder par précaution.
MonadBFT introduit une réactivité optimiste, ce qui signifie que le protocole peut avancer immédiatement en fonction des informations du réseau, plutôt que de toujours dépendre de minuteurs fixes. Le principe de conception ici peut être résumé par "aller vite si possible, être patient seulement quand c'est nécessaire".
La conception de MonadBFT lui permet, dans des conditions normales et même lors de la récupération d'erreurs, de ne pas suspendre l'attente du délai prédéterminé, sauf si cela est nécessaire.
Sur le chemin de la joie (ce qui signifie que nous avons un leader honnête) : il n'y a pas de délai intégré dans la proposition ou le vote. Une fois que c'est au tour du leader, il propose un bloc. Dès que le validateur reçoit une proposition valide, il vote immédiatement. Lorsque le leader (ou plus précisément, le prochain leader, car dans le pipeline HotStuff, le vote est envoyé au prochain proposeur) collecte 2f+1 votes, le QC se forme et peut être propagé. Dans une conception de réactivité optimiste, cela déclenche immédiatement la prochaine étape.
Dans la pratique, cela signifie que si le délai réseau entre les nœuds est de 100 millisecondes, le Consensus peut ne prendre que quelques centaines de millisecondes pour compléter un tour (ajouté aux frais de calcul et d'agrégation).
S'il n'est pas nécessaire, il ne attendra pas, par exemple, un "temps de créneau" d'une seconde entière. Cela diffère du modèle de créneau et d'époque adopté par le réseau principal d'Ethereum. Sur Ethereum, l'intervalle de temps pour la production de blocs est fixé à 12 secondes. Même si tout le monde est prêt à l'avance, le protocole attendra.
La méthode MonadBFT élimine les délais inutiles. Elle conserve la structure HotStuff en pipeline, mais supprime la règle stricte selon laquelle il "faut attendre Δ secondes" dans des conditions normales. Cela signifie qu'elle peut, sans sacrifier la sécurité, surpasser les systèmes à contraintes temporelles en termes de réactivité.
Sur le chemin malheureux (échec du leader) : Dans de nombreux protocoles de consensus, lorsqu’un leader ne parvient pas à proposer un bloc, les autres nœuds ne s’en rendent compte qu’après un délai d’attente Δ. Par exemple, si Δ est égal à 1 seconde, alors ce temps est essentiellement perdu. MonadBFT est traité différemment. Lorsque les validateurs détectent qu’une proposition est manquante, ils diffusent immédiatement un message de timeout (TC ou Timeout Certificate). Dès qu’il y a un temps mort 2f+1, le leader suivant prend le relais. La transition vers une nouvelle perspective est déclenchée par des preuves fondées sur un quorum, et non sur une horloge.
Comparaison avec le consensus de la famille hotstuff
MonadBFT est construit sur la base des protocoles de consensus de la série HotStuff, mais se distingue en réalisant une combinaison d'une série de caractéristiques idéales. Les protocoles antérieurs étaient généralement optimisés pour certaines dimensions, telles que le débit de pipeline ou la communication linéaire, mais devaient sacrifier d'autres aspects. MonadBFT combine de manière unique la complexité des messages linéaires, la soumission en pipeline, une forte résistance à la bifurcation à la fin, une réactivité instantanée sans délai fixe et un mécanisme de récupération efficace, tout en conservant une finalité rapide et des garanties de haute disponibilité. Le tableau ci-dessous résume la comparaison de MonadBFT avec d'autres protocoles BFT à leadership tournant sur ces dimensions clés :
Qu'est-ce que cela signifie pour les développeurs et les utilisateurs ?
Pour les développeurs, MonadBFT signifie plusieurs choses :
Un modèle de finalité plus simple : Avec MonadBFT, vous pouvez considérer les blocs avec QC (vote de la majorité absolue) comme effectivement finalisés, car le protocole les finalisera ou imposera des pénalités. Les développeurs peuvent opérer avec une grande confiance en toute sécurité avec 1 confirmation de bloc.
Améliorer l'expérience utilisateur de l'application : Si vous construisez une application à fort débit (échange, jeu, etc.), la faible latence et la résistance aux forks de MonadBFT se traduiront par une expérience utilisateur plus fluide. Les utilisateurs peuvent presque instantanément voir leurs opérations confirmées et ne rencontrent pas souvent de réorganisations ou de rollbacks déroutants. Ainsi, vous pouvez concevoir des applications avec une finalité et des mises à jour rapides.
Comportement déterministe : les règles plus strictes de MonadBFT (comme l'exigence de nouvelle proposition) réduisent l'incertitude de l'inclusion des blocs. Grâce à des subtilités temporelles telles que le fait de savoir si les votes ou les délais atteignent d'abord le leader, il y a moins de "cas limites" où un bloc est inclus ou sauté. MonadBFT remplace cette ambiguïté sensible au temps par des règles claires et des preuves vérifiables. Cela rend plus facile la raison de la correction du protocole et des tests. Cela fournit également une base claire pour identifier les nœuds défaillants (par exemple, si quelqu'un échoue à proposer à nouveau ou propose un bloc en conflit, vous savez qu'ils ont enfreint le protocole).
Espace de scalabilité : Si vous êtes un développeur soucieux de la scalabilité, MonadBFT vous offre plus d'espace avant d'atteindre un goulot d'étranglement. Comparé aux protocoles de seconde couche, il vous est plus facile d'augmenter la taille des blocs ou le nombre de validateurs. De plus, des fonctionnalités comme la propagation de blocs par codage d'effacement signifient que vous pouvez pousser d'importantes quantités de données à travers le réseau sans trop solliciter un seul nœud. Cela rend possible l'objectif d'un débit plus élevé, ouvrant l'espace de conception pour des applications on-chain plus ambitieuses.
Pour les utilisateurs finaux : Les utilisateurs ordinaires ne comprendront rien de ce que nous discutons ici, mais ils ressentiront son impact. Avec MonadBFT comme base de la chaîne Monad, les utilisateurs peuvent s'attendre à toutes les bonnes caractéristiques suivantes sans sacrifier la décentralisation et la résistance à la censure.
Confirmation plus rapide : les transactions (comme l'envoi de jetons, l'échange d'actifs, la création de NFT, l'exécution de transactions) seront rapidement confirmées.
Réduire les imprévus : La cohérence de l'état de la chaîne est plus élevée, car des éléments comme les forks de fin sont éliminés, ce qui relève en fait de la réorganisation.
Équité et transparence : L'amélioration du consensus signifie indirectement que le fonctionnement de la chaîne est plus équitable. Aucun validateur individuel ne peut facilement examiner les transactions ou manipuler le tri entre les blocs.
Conclusion
En résumé, MonadBFT introduit quatre innovations clés sur la base du consensus de style HotStuff en pipeline :
Résistance aux forks de fin : MonadBFT est le premier protocole BFT en pipeline à éliminer les attaques de fork de fin. Il y parvient en permettant au prochain leader de redéposer le bloc du dernier vote en cas d'échec du précédent leader, ou de présenter un certificat sans endorsement (NEC), prouvant que ce bloc manque de soutien. Cela garantit que tout bloc ayant obtenu un soutien écrasant ne sera pas abandonné, protégeant ainsi les récompenses des leaders honnêtes et empêchant la réorganisation malveillante et l'extraction MEV inter-blocs.
Finalité de la spéculation à un tour : Les validateurs peuvent confirmer un Bloc après une communication à un tour (une proposition et un vote d'un leader), fournissant ainsi une garantie d'inclusion instantanée aux clients. Cette confirmation spéculative ne sera rétablie que lors d'une attaque équivalente du leader (un comportement pouvant être prouvé et puni), ce qui en fait une hypothèse de sécurité en pratique.
Réactivité optimiste : Le protocole fonctionne à la vitesse du réseau, sans délai inhérent. Le leader fait avancer le consensus immédiatement après avoir reçu les votes nécessaires, et les changements de vue se produisent immédiatement après l'expiration du quorum observé, au lieu d'attendre une intervalle fixe de temps. Ce design de réactivité optimiste minimise le temps d'attente et maximise le débit, tout en étant capable de gérer de manière robuste en cas d'asynchronie et de pannes.
Communication linéaire : Sur le chemin joyeux (c'est-à-dire que le leader est honnête), la complexité des messages et des validations a une relation linéaire avec le nombre de validateurs. MonadBFT conserve le mode de communication efficace de HotStuff, utilisant des signatures agrégées et un simple leader pour diffuser aux validateurs, permettant au protocole de s'étendre à des centaines de validateurs sans engendrer de goulets d'étranglement de performance.
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.
Analyse de MonadBFT (2) : Qu'est-ce que cela signifie pour les développeurs et les utilisateurs
Dans la première partie, nous avons étudié le fonctionnement du consensus classique PBFT (tolérance aux fautes byzantines pratique) et la manière dont les premières versions de HotStuff fonctionnaient. Nous avons également appris comment MonadBFT résout le problème de fork de fin de HotStuff, c'est-à-dire le problème où des blocs valides peuvent parfois être abandonnés dans un système en pipeline.
Ce problème de fork entraîne deux problèmes majeurs : 1) Il perturbe les récompenses des constructeurs de blocs honnêtes, 2) Il peut entraîner un arrêt du réseau.
MonadBFT a introduit des règles de ré-proposition et un mécanisme de vote sans approbation pour éliminer le problème des forks finaux, garantissant que tout Bloc correctement approuvé provenant de proposeurs honnêtes puisse entrer dans la chaîne.
Dans la deuxième partie, nous allons explorer deux autres caractéristiques de MonadBFT : 1) la finalité spéculative et 2) la réactivité optimiste. Nous examinerons également l'impact de MonadBFT sur les développeurs.
finalité de la spéculation à un tour
En plus de résister aux forks de la queue, une autre caractéristique principale de MonadBFT est la finalité spéculative en un seul tour.
Dans la pratique, cela signifie que les clients et les utilisateurs peuvent recevoir une confirmation de transaction immédiatement après que le bloc a obtenu la majorité des votes, même avant la fin du prochain tour.
Rappelons qu'avec le protocole HotStuff de base, un bloc doit généralement passer par au moins deux étapes (comme Fast-Hotstuff et Diem-BFT) avant d'être considéré comme finalisé (irréversible) : une étape pour obtenir un certificat de majorité (QC) (en verrouillant le bloc avec ≥2f+1 votes), la deuxième étape est que le prochain leader construit et soumet le bloc basé sur ce certificat de majorité (QC).
Ce processus de soumission en deux étapes est nécessaire pour assurer la sécurité : une fois qu'un nombre suffisant de nœuds honnêtes a verrouillé un bloc, le bloc en conflit ne peut pas obtenir le nombre requis de votes, et le prochain tour de soumission le rendra permanent. Par conséquent, le client doit généralement attendre la génération du prochain bloc ou du prochain tour pour savoir si la transaction précédente est finalisée.
MonadBFT permet essentiellement que les transactions soient considérées comme suffisamment finales (opérables en toute sécurité) 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 est alors dans un état de vote (verrouillé par le nombre légal de personnes). Dans MonadBFT, dès qu'un validateur forme le QC, il exécute immédiatement les transactions de ce bloc et peut même envoyer une confirmation préliminaire au client, indiquant que ce bloc est (spéculativement) accepté. C'est comme dire "Nous avons la grande majorité des gens qui acceptent ce bloc. À moins qu'il ne se produise une situation très inattendue, ce bloc peut être considéré comme confirmé."
Cette confirmation instantanée est optimiste. Le bloc n'a pas encore été soumis au registre. Cela se produira lorsque la prochaine proposition apparaîtra et que celle-ci sera confirmée (QC-on QC), mais en règle générale, rien ne pourra l'annuler. La seule situation pouvant annuler l'exécution spéculative d'un bloc est qu'un leader subisse une attaque équivalente (c'est-à-dire proposer deux blocs différents à la même hauteur pour disperser les votes).
Vous pouvez considérer la finalité spéculative comme un excellent sous-produit de la résistance aux forks de queue. La résistance aux forks de queue garantit que, même si le prochain leader s'effondre, la proposition actuelle ne sera pas abandonnée (grâce aux règles de réproposition et de NEC). La seule situation dans laquelle un bloc d'exécution spéculative est abandonné est lorsque le proposeur original subit une attaque équivalente (une erreur de double signature démontrable malveillante), et ce cas : 1) peut être détecté par un QC de conflit ; 2) peut être puni ; 3) est extrêmement rare.
Dans le protocole précédent, ils ne garantissent pas que le prochain leader va redéposer le dernier Bloc, donc un fork à la fin est possible, ce qui rompt l'hypothèse spéculative.
réactivité optimiste
Dans la plupart des protocoles de consensus, il existe une attente intégrée après chaque tour, telle qu’une période de tampon ou un délai d’expiration. Il s’agit de s’assurer que tous les messages sont arrivés avant d’aller de l’avant. Il s’agit d’un mécanisme de protection conçu pour faire face au pire des scénarios, comme le crash d’un leader ou l’absence totale d’envoi de messages.
Ces délais sont souvent trop conservateurs. Si le réseau fonctionne normalement et que tous les validateurs agissent correctement, alors une attente fixe devient une dépense inutile. Les blocs auraient pu être complétés plus rapidement, mais le protocole a choisi de retarder par précaution.
MonadBFT introduit une réactivité optimiste, ce qui signifie que le protocole peut avancer immédiatement en fonction des informations du réseau, plutôt que de toujours dépendre de minuteurs fixes. Le principe de conception ici peut être résumé par "aller vite si possible, être patient seulement quand c'est nécessaire".
La conception de MonadBFT lui permet, dans des conditions normales et même lors de la récupération d'erreurs, de ne pas suspendre l'attente du délai prédéterminé, sauf si cela est nécessaire.
Sur le chemin de la joie (ce qui signifie que nous avons un leader honnête) : il n'y a pas de délai intégré dans la proposition ou le vote. Une fois que c'est au tour du leader, il propose un bloc. Dès que le validateur reçoit une proposition valide, il vote immédiatement. Lorsque le leader (ou plus précisément, le prochain leader, car dans le pipeline HotStuff, le vote est envoyé au prochain proposeur) collecte 2f+1 votes, le QC se forme et peut être propagé. Dans une conception de réactivité optimiste, cela déclenche immédiatement la prochaine étape.
Dans la pratique, cela signifie que si le délai réseau entre les nœuds est de 100 millisecondes, le Consensus peut ne prendre que quelques centaines de millisecondes pour compléter un tour (ajouté aux frais de calcul et d'agrégation).
S'il n'est pas nécessaire, il ne attendra pas, par exemple, un "temps de créneau" d'une seconde entière. Cela diffère du modèle de créneau et d'époque adopté par le réseau principal d'Ethereum. Sur Ethereum, l'intervalle de temps pour la production de blocs est fixé à 12 secondes. Même si tout le monde est prêt à l'avance, le protocole attendra.
La méthode MonadBFT élimine les délais inutiles. Elle conserve la structure HotStuff en pipeline, mais supprime la règle stricte selon laquelle il "faut attendre Δ secondes" dans des conditions normales. Cela signifie qu'elle peut, sans sacrifier la sécurité, surpasser les systèmes à contraintes temporelles en termes de réactivité.
Sur le chemin malheureux (échec du leader) : Dans de nombreux protocoles de consensus, lorsqu’un leader ne parvient pas à proposer un bloc, les autres nœuds ne s’en rendent compte qu’après un délai d’attente Δ. Par exemple, si Δ est égal à 1 seconde, alors ce temps est essentiellement perdu. MonadBFT est traité différemment. Lorsque les validateurs détectent qu’une proposition est manquante, ils diffusent immédiatement un message de timeout (TC ou Timeout Certificate). Dès qu’il y a un temps mort 2f+1, le leader suivant prend le relais. La transition vers une nouvelle perspective est déclenchée par des preuves fondées sur un quorum, et non sur une horloge.
Comparaison avec le consensus de la famille hotstuff
MonadBFT est construit sur la base des protocoles de consensus de la série HotStuff, mais se distingue en réalisant une combinaison d'une série de caractéristiques idéales. Les protocoles antérieurs étaient généralement optimisés pour certaines dimensions, telles que le débit de pipeline ou la communication linéaire, mais devaient sacrifier d'autres aspects. MonadBFT combine de manière unique la complexité des messages linéaires, la soumission en pipeline, une forte résistance à la bifurcation à la fin, une réactivité instantanée sans délai fixe et un mécanisme de récupération efficace, tout en conservant une finalité rapide et des garanties de haute disponibilité. Le tableau ci-dessous résume la comparaison de MonadBFT avec d'autres protocoles BFT à leadership tournant sur ces dimensions clés :
Qu'est-ce que cela signifie pour les développeurs et les utilisateurs ?
Pour les développeurs, MonadBFT signifie plusieurs choses :
Un modèle de finalité plus simple : Avec MonadBFT, vous pouvez considérer les blocs avec QC (vote de la majorité absolue) comme effectivement finalisés, car le protocole les finalisera ou imposera des pénalités. Les développeurs peuvent opérer avec une grande confiance en toute sécurité avec 1 confirmation de bloc.
Améliorer l'expérience utilisateur de l'application : Si vous construisez une application à fort débit (échange, jeu, etc.), la faible latence et la résistance aux forks de MonadBFT se traduiront par une expérience utilisateur plus fluide. Les utilisateurs peuvent presque instantanément voir leurs opérations confirmées et ne rencontrent pas souvent de réorganisations ou de rollbacks déroutants. Ainsi, vous pouvez concevoir des applications avec une finalité et des mises à jour rapides.
Comportement déterministe : les règles plus strictes de MonadBFT (comme l'exigence de nouvelle proposition) réduisent l'incertitude de l'inclusion des blocs. Grâce à des subtilités temporelles telles que le fait de savoir si les votes ou les délais atteignent d'abord le leader, il y a moins de "cas limites" où un bloc est inclus ou sauté. MonadBFT remplace cette ambiguïté sensible au temps par des règles claires et des preuves vérifiables. Cela rend plus facile la raison de la correction du protocole et des tests. Cela fournit également une base claire pour identifier les nœuds défaillants (par exemple, si quelqu'un échoue à proposer à nouveau ou propose un bloc en conflit, vous savez qu'ils ont enfreint le protocole).
Espace de scalabilité : Si vous êtes un développeur soucieux de la scalabilité, MonadBFT vous offre plus d'espace avant d'atteindre un goulot d'étranglement. Comparé aux protocoles de seconde couche, il vous est plus facile d'augmenter la taille des blocs ou le nombre de validateurs. De plus, des fonctionnalités comme la propagation de blocs par codage d'effacement signifient que vous pouvez pousser d'importantes quantités de données à travers le réseau sans trop solliciter un seul nœud. Cela rend possible l'objectif d'un débit plus élevé, ouvrant l'espace de conception pour des applications on-chain plus ambitieuses.
Pour les utilisateurs finaux : Les utilisateurs ordinaires ne comprendront rien de ce que nous discutons ici, mais ils ressentiront son impact. Avec MonadBFT comme base de la chaîne Monad, les utilisateurs peuvent s'attendre à toutes les bonnes caractéristiques suivantes sans sacrifier la décentralisation et la résistance à la censure.
Confirmation plus rapide : les transactions (comme l'envoi de jetons, l'échange d'actifs, la création de NFT, l'exécution de transactions) seront rapidement confirmées.
Réduire les imprévus : La cohérence de l'état de la chaîne est plus élevée, car des éléments comme les forks de fin sont éliminés, ce qui relève en fait de la réorganisation.
Équité et transparence : L'amélioration du consensus signifie indirectement que le fonctionnement de la chaîne est plus équitable. Aucun validateur individuel ne peut facilement examiner les transactions ou manipuler le tri entre les blocs.
Conclusion
En résumé, MonadBFT introduit quatre innovations clés sur la base du consensus de style HotStuff en pipeline :
Résistance aux forks de fin : MonadBFT est le premier protocole BFT en pipeline à éliminer les attaques de fork de fin. Il y parvient en permettant au prochain leader de redéposer le bloc du dernier vote en cas d'échec du précédent leader, ou de présenter un certificat sans endorsement (NEC), prouvant que ce bloc manque de soutien. Cela garantit que tout bloc ayant obtenu un soutien écrasant ne sera pas abandonné, protégeant ainsi les récompenses des leaders honnêtes et empêchant la réorganisation malveillante et l'extraction MEV inter-blocs.
Finalité de la spéculation à un tour : Les validateurs peuvent confirmer un Bloc après une communication à un tour (une proposition et un vote d'un leader), fournissant ainsi une garantie d'inclusion instantanée aux clients. Cette confirmation spéculative ne sera rétablie que lors d'une attaque équivalente du leader (un comportement pouvant être prouvé et puni), ce qui en fait une hypothèse de sécurité en pratique.
Réactivité optimiste : Le protocole fonctionne à la vitesse du réseau, sans délai inhérent. Le leader fait avancer le consensus immédiatement après avoir reçu les votes nécessaires, et les changements de vue se produisent immédiatement après l'expiration du quorum observé, au lieu d'attendre une intervalle fixe de temps. Ce design de réactivité optimiste minimise le temps d'attente et maximise le débit, tout en étant capable de gérer de manière robuste en cas d'asynchronie et de pannes.
Communication linéaire : Sur le chemin joyeux (c'est-à-dire que le leader est honnête), la complexité des messages et des validations a une relation linéaire avec le nombre de validateurs. MonadBFT conserve le mode de communication efficace de HotStuff, utilisant des signatures agrégées et un simple leader pour diffuser aux validateurs, permettant au protocole de s'étendre à des centaines de validateurs sans engendrer de goulets d'étranglement de performance.