Cadre Shoal : comment réduire la latence de Bullshark sur Aptos
Aptos Labs a récemment résolu deux problèmes ouverts importants dans le DAG BFT, Goutte considérablement la latence et a éliminé pour la première fois la nécessité de timeout dans le protocole réel déterministe. Dans l'ensemble, la latence de Bullshark a été améliorée de 40 % en cas de fonctionnement normal et de 80 % en cas de défaillance.
Shoal est un cadre qui améliore tout protocole de consensus basé sur Narwhal ( tel que DAG-Rider, Tusk, Bullshark ) grâce à des pipelines et à la réputation des leaders. Le pipeline réduit la latence de tri des DAG en introduisant un point d'ancrage à chaque tour, tandis que la réputation des leaders améliore encore le problème de latence en s'assurant que les points d'ancrage sont associés aux nœuds de validation les plus rapides. De plus, la réputation des leaders permet à Shoal de tirer parti de la construction de DAG asynchrone pour éliminer les délais dans tous les scénarios. Cela permet à Shoal de fournir une propriété appelée réponse universelle, qui contient généralement la réponse optimiste requise.
Cette technologie est très simple, impliquant l'exécution séquentielle d'instances multiples du protocole sous-jacent. Ainsi, lorsqu'elle est instanciée avec Bullshark, on obtient un groupe de "requins" participant à une course de relais.
Contexte
Dans la quête de haute performance des réseaux blockchain, l'accent a toujours été mis sur la Goutte de la complexité de communication. Cependant, cette approche n'a pas conduit à une amélioration significative du débit. Par exemple, le Hotstuff mis en œuvre dans les premières versions de Diem n'a atteint que 3500 TPS, bien en dessous de l'objectif de 100k+ TPS.
Les récentes percées proviennent de la réalisation que la propagation des données est un principal goulot d'étranglement basé sur le protocole des leaders, et qu'elle peut bénéficier de la parallélisation. Le système Narwhal sépare la propagation des données de la logique de consensus centrale, proposant une architecture où tous les validateurs propagent simultanément les données, tandis que le composant de consensus ne commande qu'un petit nombre de métadonnées. Le document sur Narwhal rapporte un débit de 160 000 TPS.
Dans un article précédent, nous avons présenté Quorum Store, qui est l'implémentation de Narwhal séparant la propagation des données et le consensus, ainsi que la façon de l'utiliser pour étendre le protocole de consensus actuel Jolteon. Jolteon est un protocole basé sur un leader, combinant le chemin rapide linéaire de Tendermint et le changement de vue de style PBFT, permettant de réduire la latence de Hotstuff de 33%. Cependant, les protocoles de consensus basés sur un leader ne peuvent pas tirer pleinement parti du potentiel de débit de Narwhal. Malgré la séparation de la propagation des données et du consensus, à mesure que le débit augmente, le leader de Hotstuff/Jolteon reste limité.
Ainsi, il a été décidé de déployer Bullshark sur Narwhal DAG, qui est un protocole de consensus sans coût de communication. Malheureusement, par rapport à Jolteon, la structure DAG supportant le haut débit de Bullshark entraîne un coût de latence de 50 %.
Cet article présente comment Shoal parvient à réduire considérablement la latence de Bullshark.
Contexte DAG-BFT
Chaque sommet dans le DAG Narwhal est associé à un tour. Pour entrer dans le tour r, un validateur doit d'abord obtenir n-f sommets appartenant au tour r-1. Chaque validateur peut diffuser un sommet par tour, et chaque sommet doit référencer au moins n-f sommets du tour précédent. En raison de l'asynchronisme du réseau, différents validateurs peuvent observer à tout moment des vues locales différentes du DAG.
Une caractéristique clé du DAG est qu'elle est sans ambigüité : si deux nœuds de validation ont le même sommet v dans leur vue locale du DAG, alors ils ont exactement la même histoire causale de v.
Ordre total
Il est possible d'atteindre un consensus sur l'ordre total de tous les sommets dans le DAG sans frais de communication supplémentaires. Pour ce faire, les validateurs dans DAG-Rider, Tusk et Bullshark interprètent la structure du DAG comme un protocole de consensus, où les sommets représentent des propositions et les arêtes représentent des votes.
Bien que la logique d'intersection des groupes sur la structure DAG soit différente, tous les protocoles de consensus basés sur Narwhal existants ont la structure suivante:
Point d'ancrage prévu : tous les quelques tours, il y aura un leader prédéfini, le sommet du leader est appelé point d'ancrage ;
Points d'ancrage de tri : les validateurs décident de manière indépendante mais déterministe quels points d'ancrage commander et lesquels sauter;
Historique de causalité ordonnée : les validateurs traitent un par un leur liste d'ancres ordonnées, et pour chaque ancre, ils classent tous les sommets précédemment désordonnés dans leur historique de causalité selon certaines règles déterministes.
La clé pour garantir la sécurité est de s'assurer qu'à l'étape (2), tous les nœuds de validation honnêtes créent une liste d'ancrage ordonnée, afin que toutes les listes partagent le même préfixe. Dans Shoal, les observations suivantes sont faites sur tous les protocoles :
Tous les validateurs acceptent le premier point d'ancrage ordonné.
Bullshark latence
La latence de Bullshark dépend du nombre de tours entre les points d'ancrage ordonnés dans le DAG. Bien que la version synchrone de Bullshark soit plus pratique et ait une meilleure latence que la version asynchrone, elle est loin d'être optimale.
Problème 1 : latence moyenne des blocs. Dans Bullshark, chaque tour pair a un point d'ancrage, et chaque sommet du tour impair est interprété comme un vote. Dans les cas courants, deux tours de DAG sont nécessaires pour commander les points d'ancrage, cependant, les sommets dans l'historique causal de l'anchor nécessitent plus de tours pour attendre que l'anchor soit trié. Dans les cas courants, les sommets du tour impair nécessitent trois tours, tandis que les sommets non ancrés du tour pair nécessitent quatre tours.
Problème 2 : latence des cas de défaillance, l'analyse de latence ci-dessus s'applique aux situations sans défaillance, d'autre part, si le leader d'un tour ne parvient pas à diffuser suffisamment rapidement le point d'ancrage, il n'est pas possible de trier le point d'ancrage ( et est donc sauté ), par conséquent, tous les sommets non triés des premiers tours doivent attendre que le prochain point d'ancrage soit trié. Cela va considérablement Goutte les performances du réseau de réplication géographique, surtout parce que Bullshark utilise un délai pour attendre le leader.
Cadre Shoal
Shoal a résolu ces deux problèmes de latence en améliorant Bullshark( ou tout autre protocole BFT basé sur Narwhal) par le biais de pipelines, permettant d'avoir un point d'ancrage à chaque tour et réduisant la latence de tous les sommets non ancrés dans le DAG à trois tours. Shoal a également introduit un mécanisme de réputation de leader à zéro coût dans le DAG, ce qui favorise la sélection des leaders rapides.
Défi
Dans le contexte du protocole DAG, les problèmes de pipeline et de réputation des leaders sont considérés comme des questions difficiles pour les raisons suivantes :
Les anciennes chaînes de production tentaient de modifier la logique centrale de Bullshark, mais cela semble fondamentalement impossible.
La réputation des leaders est introduite dans DiemBFT et formalisée dans Carousel, et elle consiste à sélectionner dynamiquement les futurs leaders en fonction des performances passées des validateurs dans l'idée d'ancrer dans Bullshark. Bien que des divergences sur l'identité des leaders ne violent pas la sécurité de ces protocoles, dans Bullshark, cela peut entraîner un ordonnancement totalement différent, ce qui soulève le cœur du problème, à savoir que le choix dynamique et déterministe des ancres de roues est nécessaire pour résoudre le consensus, et que les validateurs doivent s'accorder sur l'historique ordonné pour choisir les futures ancres.
En tant que preuve de la difficulté des problèmes, l'implémentation de Bullshark, y compris celle actuellement en environnement de production, ne prend pas en charge ces fonctionnalités.
Accord
Malgré les défis mentionnés ci-dessus, il s'avère que la solution se cache derrière la simplicité.
Dans Shoal, en s'appuyant sur la capacité d'effectuer des calculs locaux sur le DAG, il a réalisé la capacité de sauvegarder et de réinterpréter les informations des tours précédents. Grâce à la perception centrale selon laquelle tous les validateurs s'accordent sur le premier point d'ancrage ordonné, Shoal combine séquentiellement plusieurs instances de Bullshark pour les traiter en pipeline, ce qui fait que ( le premier point d'ancrage ordonné est le point de basculement des instances, et que ) l'histoire causale des points d'ancrage est utilisée pour calculer la réputation des leaders.
Ligne de production
V qui associe les tours aux leaders. Shoal exécute un par un les instances de Bullshark, de sorte que pour chaque instance, l'ancre est prédéterminée par le mappage F. Chaque instance commande une ancre, ce qui déclenche le passage à l'instance suivante.
Au départ, Shoal a lancé la première instance de Bullshark lors du premier tour du DAG et l'a fait fonctionner jusqu'à ce que le premier point d'ancrage ordonné soit déterminé, par exemple au tour r. Tous les validateurs ont accepté ce point d'ancrage. Ainsi, tous les validateurs peuvent s'accorder de manière certaine pour réinterpréter le DAG à partir du tour r+1. Shoal a simplement lancé une nouvelle instance de Bullshark au tour r+1.
Dans le meilleur des cas, cela permet à Shoal de commander un ancrage à chaque tour. Les points d'ancrage de la première ronde sont triés par première instance. Ensuite, Shoal commence une nouvelle instance au début de la deuxième ronde, qui a elle-même un point d'ancrage, cet ancrage étant trié par cette instance, puis une autre nouvelle instance commande un point d'ancrage lors de la troisième ronde, puis le processus se poursuit.
Réputation des leaders
Lors de la suppression des points d'ancrage pendant le tri de Bullshark, la latence augmente. Dans ce cas, la technique de pipeline est impuissante, car il n'est pas possible de démarrer une nouvelle instance avant que l'instance précédente n'ait commandé le point d'ancrage. Shoal garantit qu'il est peu probable que les leaders correspondants soient choisis à l'avenir pour traiter les points d'ancrage manquants en attribuant un score à chaque nœud de validation en fonction de l'historique des activités récentes de chaque nœud de validation grâce à un mécanisme de réputation. Les validateurs qui répondent et participent au protocole obtiendront un score élevé, sinon, les nœuds de validation se verront attribuer un score bas, car ils peuvent être en panne, lents ou malveillants.
Son principe est de recalculer de manière déterministe le mappage prédéfini F entre le tour et le leader à chaque mise à jour de score, en faveur du leader ayant un score plus élevé. Afin que les validateurs parviennent à un consensus sur le nouveau mappage, ils doivent parvenir à un consensus sur les scores, atteignant ainsi un consensus sur l'historique utilisé pour dériver les scores.
Dans Shoal, la chaîne de blocs et la réputation du leader peuvent se combiner naturellement, car elles utilisent toutes deux la même technologie de base, à savoir la réinterprétation du DAG après avoir atteint un consensus sur le premier point d'ancrage ordonné.
En fait, la seule différence est qu'après avoir trié les ancres au cours du tour r, le validateur n'a qu'à calculer une nouvelle mappage F' à partir du tour r+1 en se basant sur l'historique causal des ancres ordonnées au tour r. Ensuite, les nœuds de validation commencent à utiliser la fonction de sélection d'ancres mise à jour F' pour exécuter une nouvelle instance de Bullshark à partir du tour r+1.
Plus de délais
Le délai joue un rôle crucial dans toutes les implémentations BFT déterministes basées sur un leader. Cependant, la complexité qu'ils introduisent augmente le nombre d'états internes à gérer et à observer, ce qui complique le processus de débogage et nécessite davantage de techniques d'observabilité.
Le temps d'attente augmentera également significativement la latence, car il est très important de les configurer correctement et nécessite souvent des ajustements dynamiques, car cela dépend fortement de l'environnement ( réseau ). Avant de passer au leader suivant, le protocole paie la pénalité complète de latence de temps d'attente pour le leader défaillant. Par conséquent, les paramètres de temps d'attente ne doivent pas être trop conservateurs, mais si le temps d'attente est trop court, le protocole peut passer un bon leader. Par exemple, nous avons observé qu'en cas de forte charge, les leaders de Jolteon/Hotstuff étaient submergés, et le temps d'attente avait expiré avant qu'ils n'obtiennent des avancées.
Malheureusement, les protocoles basés sur le leader ( tels que Hotstuff et Jolteon ) nécessitent essentiellement une latence pour garantir que chaque fois que le leader.
Cette page peut inclure du contenu de tiers fourni à des fins d'information uniquement. Gate ne garantit ni l'exactitude ni la validité de ces contenus, n’endosse pas les opinions exprimées, et ne fournit aucun conseil financier ou professionnel à travers ces informations. Voir la section Avertissement pour plus de détails.
24 J'aime
Récompense
24
7
Reposter
Partager
Commentaire
0/400
AirdropHunter420
· 07-31 01:57
Encore de l'optimisation des performances, hein ?
Voir l'originalRépondre0
BlockchainRetirementHome
· 07-30 23:30
La vitesse a tellement augmenté, c'est incroyable!
Le cadre Shoal a considérablement Goutte la latence de Bullshark sur Aptos, améliorant de 40% à 80%.
Cadre Shoal : comment réduire la latence de Bullshark sur Aptos
Aptos Labs a récemment résolu deux problèmes ouverts importants dans le DAG BFT, Goutte considérablement la latence et a éliminé pour la première fois la nécessité de timeout dans le protocole réel déterministe. Dans l'ensemble, la latence de Bullshark a été améliorée de 40 % en cas de fonctionnement normal et de 80 % en cas de défaillance.
Shoal est un cadre qui améliore tout protocole de consensus basé sur Narwhal ( tel que DAG-Rider, Tusk, Bullshark ) grâce à des pipelines et à la réputation des leaders. Le pipeline réduit la latence de tri des DAG en introduisant un point d'ancrage à chaque tour, tandis que la réputation des leaders améliore encore le problème de latence en s'assurant que les points d'ancrage sont associés aux nœuds de validation les plus rapides. De plus, la réputation des leaders permet à Shoal de tirer parti de la construction de DAG asynchrone pour éliminer les délais dans tous les scénarios. Cela permet à Shoal de fournir une propriété appelée réponse universelle, qui contient généralement la réponse optimiste requise.
Cette technologie est très simple, impliquant l'exécution séquentielle d'instances multiples du protocole sous-jacent. Ainsi, lorsqu'elle est instanciée avec Bullshark, on obtient un groupe de "requins" participant à une course de relais.
Contexte
Dans la quête de haute performance des réseaux blockchain, l'accent a toujours été mis sur la Goutte de la complexité de communication. Cependant, cette approche n'a pas conduit à une amélioration significative du débit. Par exemple, le Hotstuff mis en œuvre dans les premières versions de Diem n'a atteint que 3500 TPS, bien en dessous de l'objectif de 100k+ TPS.
Les récentes percées proviennent de la réalisation que la propagation des données est un principal goulot d'étranglement basé sur le protocole des leaders, et qu'elle peut bénéficier de la parallélisation. Le système Narwhal sépare la propagation des données de la logique de consensus centrale, proposant une architecture où tous les validateurs propagent simultanément les données, tandis que le composant de consensus ne commande qu'un petit nombre de métadonnées. Le document sur Narwhal rapporte un débit de 160 000 TPS.
Dans un article précédent, nous avons présenté Quorum Store, qui est l'implémentation de Narwhal séparant la propagation des données et le consensus, ainsi que la façon de l'utiliser pour étendre le protocole de consensus actuel Jolteon. Jolteon est un protocole basé sur un leader, combinant le chemin rapide linéaire de Tendermint et le changement de vue de style PBFT, permettant de réduire la latence de Hotstuff de 33%. Cependant, les protocoles de consensus basés sur un leader ne peuvent pas tirer pleinement parti du potentiel de débit de Narwhal. Malgré la séparation de la propagation des données et du consensus, à mesure que le débit augmente, le leader de Hotstuff/Jolteon reste limité.
Ainsi, il a été décidé de déployer Bullshark sur Narwhal DAG, qui est un protocole de consensus sans coût de communication. Malheureusement, par rapport à Jolteon, la structure DAG supportant le haut débit de Bullshark entraîne un coût de latence de 50 %.
Cet article présente comment Shoal parvient à réduire considérablement la latence de Bullshark.
Contexte DAG-BFT
Chaque sommet dans le DAG Narwhal est associé à un tour. Pour entrer dans le tour r, un validateur doit d'abord obtenir n-f sommets appartenant au tour r-1. Chaque validateur peut diffuser un sommet par tour, et chaque sommet doit référencer au moins n-f sommets du tour précédent. En raison de l'asynchronisme du réseau, différents validateurs peuvent observer à tout moment des vues locales différentes du DAG.
Une caractéristique clé du DAG est qu'elle est sans ambigüité : si deux nœuds de validation ont le même sommet v dans leur vue locale du DAG, alors ils ont exactement la même histoire causale de v.
Ordre total
Il est possible d'atteindre un consensus sur l'ordre total de tous les sommets dans le DAG sans frais de communication supplémentaires. Pour ce faire, les validateurs dans DAG-Rider, Tusk et Bullshark interprètent la structure du DAG comme un protocole de consensus, où les sommets représentent des propositions et les arêtes représentent des votes.
Bien que la logique d'intersection des groupes sur la structure DAG soit différente, tous les protocoles de consensus basés sur Narwhal existants ont la structure suivante:
Point d'ancrage prévu : tous les quelques tours, il y aura un leader prédéfini, le sommet du leader est appelé point d'ancrage ;
Points d'ancrage de tri : les validateurs décident de manière indépendante mais déterministe quels points d'ancrage commander et lesquels sauter;
Historique de causalité ordonnée : les validateurs traitent un par un leur liste d'ancres ordonnées, et pour chaque ancre, ils classent tous les sommets précédemment désordonnés dans leur historique de causalité selon certaines règles déterministes.
La clé pour garantir la sécurité est de s'assurer qu'à l'étape (2), tous les nœuds de validation honnêtes créent une liste d'ancrage ordonnée, afin que toutes les listes partagent le même préfixe. Dans Shoal, les observations suivantes sont faites sur tous les protocoles :
Tous les validateurs acceptent le premier point d'ancrage ordonné.
Bullshark latence
La latence de Bullshark dépend du nombre de tours entre les points d'ancrage ordonnés dans le DAG. Bien que la version synchrone de Bullshark soit plus pratique et ait une meilleure latence que la version asynchrone, elle est loin d'être optimale.
Problème 1 : latence moyenne des blocs. Dans Bullshark, chaque tour pair a un point d'ancrage, et chaque sommet du tour impair est interprété comme un vote. Dans les cas courants, deux tours de DAG sont nécessaires pour commander les points d'ancrage, cependant, les sommets dans l'historique causal de l'anchor nécessitent plus de tours pour attendre que l'anchor soit trié. Dans les cas courants, les sommets du tour impair nécessitent trois tours, tandis que les sommets non ancrés du tour pair nécessitent quatre tours.
Problème 2 : latence des cas de défaillance, l'analyse de latence ci-dessus s'applique aux situations sans défaillance, d'autre part, si le leader d'un tour ne parvient pas à diffuser suffisamment rapidement le point d'ancrage, il n'est pas possible de trier le point d'ancrage ( et est donc sauté ), par conséquent, tous les sommets non triés des premiers tours doivent attendre que le prochain point d'ancrage soit trié. Cela va considérablement Goutte les performances du réseau de réplication géographique, surtout parce que Bullshark utilise un délai pour attendre le leader.
Cadre Shoal
Shoal a résolu ces deux problèmes de latence en améliorant Bullshark( ou tout autre protocole BFT basé sur Narwhal) par le biais de pipelines, permettant d'avoir un point d'ancrage à chaque tour et réduisant la latence de tous les sommets non ancrés dans le DAG à trois tours. Shoal a également introduit un mécanisme de réputation de leader à zéro coût dans le DAG, ce qui favorise la sélection des leaders rapides.
Défi
Dans le contexte du protocole DAG, les problèmes de pipeline et de réputation des leaders sont considérés comme des questions difficiles pour les raisons suivantes :
Les anciennes chaînes de production tentaient de modifier la logique centrale de Bullshark, mais cela semble fondamentalement impossible.
La réputation des leaders est introduite dans DiemBFT et formalisée dans Carousel, et elle consiste à sélectionner dynamiquement les futurs leaders en fonction des performances passées des validateurs dans l'idée d'ancrer dans Bullshark. Bien que des divergences sur l'identité des leaders ne violent pas la sécurité de ces protocoles, dans Bullshark, cela peut entraîner un ordonnancement totalement différent, ce qui soulève le cœur du problème, à savoir que le choix dynamique et déterministe des ancres de roues est nécessaire pour résoudre le consensus, et que les validateurs doivent s'accorder sur l'historique ordonné pour choisir les futures ancres.
En tant que preuve de la difficulté des problèmes, l'implémentation de Bullshark, y compris celle actuellement en environnement de production, ne prend pas en charge ces fonctionnalités.
Accord
Malgré les défis mentionnés ci-dessus, il s'avère que la solution se cache derrière la simplicité.
Dans Shoal, en s'appuyant sur la capacité d'effectuer des calculs locaux sur le DAG, il a réalisé la capacité de sauvegarder et de réinterpréter les informations des tours précédents. Grâce à la perception centrale selon laquelle tous les validateurs s'accordent sur le premier point d'ancrage ordonné, Shoal combine séquentiellement plusieurs instances de Bullshark pour les traiter en pipeline, ce qui fait que ( le premier point d'ancrage ordonné est le point de basculement des instances, et que ) l'histoire causale des points d'ancrage est utilisée pour calculer la réputation des leaders.
Ligne de production
V qui associe les tours aux leaders. Shoal exécute un par un les instances de Bullshark, de sorte que pour chaque instance, l'ancre est prédéterminée par le mappage F. Chaque instance commande une ancre, ce qui déclenche le passage à l'instance suivante.
Au départ, Shoal a lancé la première instance de Bullshark lors du premier tour du DAG et l'a fait fonctionner jusqu'à ce que le premier point d'ancrage ordonné soit déterminé, par exemple au tour r. Tous les validateurs ont accepté ce point d'ancrage. Ainsi, tous les validateurs peuvent s'accorder de manière certaine pour réinterpréter le DAG à partir du tour r+1. Shoal a simplement lancé une nouvelle instance de Bullshark au tour r+1.
Dans le meilleur des cas, cela permet à Shoal de commander un ancrage à chaque tour. Les points d'ancrage de la première ronde sont triés par première instance. Ensuite, Shoal commence une nouvelle instance au début de la deuxième ronde, qui a elle-même un point d'ancrage, cet ancrage étant trié par cette instance, puis une autre nouvelle instance commande un point d'ancrage lors de la troisième ronde, puis le processus se poursuit.
Réputation des leaders
Lors de la suppression des points d'ancrage pendant le tri de Bullshark, la latence augmente. Dans ce cas, la technique de pipeline est impuissante, car il n'est pas possible de démarrer une nouvelle instance avant que l'instance précédente n'ait commandé le point d'ancrage. Shoal garantit qu'il est peu probable que les leaders correspondants soient choisis à l'avenir pour traiter les points d'ancrage manquants en attribuant un score à chaque nœud de validation en fonction de l'historique des activités récentes de chaque nœud de validation grâce à un mécanisme de réputation. Les validateurs qui répondent et participent au protocole obtiendront un score élevé, sinon, les nœuds de validation se verront attribuer un score bas, car ils peuvent être en panne, lents ou malveillants.
Son principe est de recalculer de manière déterministe le mappage prédéfini F entre le tour et le leader à chaque mise à jour de score, en faveur du leader ayant un score plus élevé. Afin que les validateurs parviennent à un consensus sur le nouveau mappage, ils doivent parvenir à un consensus sur les scores, atteignant ainsi un consensus sur l'historique utilisé pour dériver les scores.
Dans Shoal, la chaîne de blocs et la réputation du leader peuvent se combiner naturellement, car elles utilisent toutes deux la même technologie de base, à savoir la réinterprétation du DAG après avoir atteint un consensus sur le premier point d'ancrage ordonné.
En fait, la seule différence est qu'après avoir trié les ancres au cours du tour r, le validateur n'a qu'à calculer une nouvelle mappage F' à partir du tour r+1 en se basant sur l'historique causal des ancres ordonnées au tour r. Ensuite, les nœuds de validation commencent à utiliser la fonction de sélection d'ancres mise à jour F' pour exécuter une nouvelle instance de Bullshark à partir du tour r+1.
Plus de délais
Le délai joue un rôle crucial dans toutes les implémentations BFT déterministes basées sur un leader. Cependant, la complexité qu'ils introduisent augmente le nombre d'états internes à gérer et à observer, ce qui complique le processus de débogage et nécessite davantage de techniques d'observabilité.
Le temps d'attente augmentera également significativement la latence, car il est très important de les configurer correctement et nécessite souvent des ajustements dynamiques, car cela dépend fortement de l'environnement ( réseau ). Avant de passer au leader suivant, le protocole paie la pénalité complète de latence de temps d'attente pour le leader défaillant. Par conséquent, les paramètres de temps d'attente ne doivent pas être trop conservateurs, mais si le temps d'attente est trop court, le protocole peut passer un bon leader. Par exemple, nous avons observé qu'en cas de forte charge, les leaders de Jolteon/Hotstuff étaient submergés, et le temps d'attente avait expiré avant qu'ils n'obtiennent des avancées.
Malheureusement, les protocoles basés sur le leader ( tels que Hotstuff et Jolteon ) nécessitent essentiellement une latence pour garantir que chaque fois que le leader.