Cadre Shoal: Réduction significative de la latence de Bullshark sur Aptos
Aperçu
Aptos labs a résolu deux problèmes ouverts importants dans le DAG BFT, réduisant significativement la latence et éliminant pour la première fois le besoin de délais dans les protocoles déterministes réels. 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 grâce à une pipeline et à la réputation des leaders. La pipeline réduit la latence de tri du 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 garantissant que le point d'ancrage est associé aux nœuds de validation les plus rapides. De plus, la réputation des leaders permet à Shoal d'exploiter la construction de DAG asynchrone pour éliminer les délais dans tous les scénarios. Cela permet à Shoal de fournir des attributs de réponse universelle, y compris la réponse optimiste généralement requise.
Cette technologie est très simple, impliquant l'exécution séquentielle de plusieurs instances du protocole sous-jacent. Ainsi, lorsque nous l'instancions avec Bullshark, nous obtenons un groupe de "requins" participant à une course de relais.
Motivation
Dans la recherche de haute performance des réseaux blockchain, les gens se sont toujours concentrés sur la réduction de la complexité de la communication. Cependant, cette approche n'a pas conduit à une amélioration significative du débit. Par exemple, le Hotstuff implémenté dans les premières versions de Diem n'atteignait que 3500 TPS, bien en dessous de l'objectif de 100k+ TPS.
Les récentes percées proviennent de la compréhension que la propagation des données est le principal goulot d'étranglement basé sur le protocole des leaders, et peut bénéficier de la parallélisation. Le système Narwhal dissocie la propagation des données de la logique de consensus, proposant une architecture où tous les validateurs propagent les données simultanément, tandis que le composant de consensus ne commande qu'une petite quantité de métadonnées. Le document Narwhal rapporte un débit de 160 000 TPS.
Nous avons précédemment présenté Quorum Store, notre implémentation Narwhal qui sépare la diffusion des données du consensus, ainsi que comment 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, réduisant 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. Bien que la diffusion des données soit séparée du consensus, avec l'augmentation du débit, le leader de Hotstuff/Jolteon reste limité.
Ainsi, nous avons décidé de déployer Bullshark, un protocole de consensus sans frais de communication, sur Narwhal DAG. Malheureusement, par rapport à Jolteon, la structure DAG qui prend en charge 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 de 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, chaque sommet référencant au moins n-f sommets du tour précédent. En raison de l'asynchronisme du réseau, différents validateurs peuvent observer des vues locales différentes du DAG à tout moment.
Une propriété clé du DAG n'est pas ambiguë : 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.
Préface
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 réservé : tous les quelques tours, il y a un leader prédéterminé, le sommet du leader est appelé point d'ancrage ;
Points d'ancrage de commande : les validateurs décident de manière indépendante mais déterministe quels points d'ancrage commander et lesquels sauter ;
Commande de l'historique causal : les validateurs traitent un par un la liste des points d'ancrage ordonnée et trient tous les sommets désordonnés précédents dans l'historique causal de chaque point d'ancrage.
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, nous faisons les observations suivantes concernant tous les protocoles mentionnés ci-dessus:
Tous les validateurs s'accordent sur 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 synchronisée de Bullshark soit généralement plus performante en matière de latence que la version asynchrone, elle est loin d'être optimale.
Question 1 : latence moyenne des blocs. Dans Bullshark, chaque ronde paire a un point d'ancrage, et chaque sommet de la ronde impaire est interprété comme un vote. Dans des cas courants, il faut deux rondes de DAG pour ordonner les points d'ancrage, cependant, les sommets dans l'histoire causale des points d'ancrage nécessitent plus de rondes pour attendre que les points d'ancrage soient triés. Dans des cas courants, les sommets de la ronde impaire nécessitent trois rondes, tandis que les sommets non ancrés de la ronde paire nécessitent quatre rondes.
Problème 2 : latence des cas de panne, l'analyse de latence ci-dessus s'applique aux situations sans panne. D'autre part, si le leader d'un tour ne parvient pas à diffuser suffisamment rapidement le point d'ancrage, il est impossible de trier le point d'ancrage (, il est donc sauté ), ce qui signifie que tous les sommets non triés des tours précédents doivent attendre que le prochain point d'ancrage soit trié. Cela réduit considérablement les performances du réseau de réplication géographique, surtout parce que le délai d'attente Bullshark est utilisé 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) grâce à un pipeline, 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 introduit également un mécanisme de réputation des leaders sans frais dans le DAG, ce qui favorise le choix de leaders rapides.
Défi
Dans le contexte du protocole DAG, le pipeline et la réputation des leaders sont considérés comme des problèmes difficiles, pour les raisons suivantes :
Les anciennes tentatives de la chaîne de production ont essayé 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 se base sur la performance passée des validateurs pour sélectionner dynamiquement les futurs leaders dans Bullshark, l'idée étant de choisir des ancres. Bien que des divergences dans l'identité des leaders ne compromettent pas la sécurité de ces protocoles, dans Bullshark, cela peut mener à un classement complètement différent, soulevant le cœur du problème, à savoir que le choix dynamique et déterministe des ancres de roue est nécessaire pour résoudre le consensus, et que les validateurs doivent parvenir à un accord sur l'historique ordonné pour choisir les futures ancres.
En tant que preuve de la difficulté des problèmes, nous avons constaté que l'implémentation de Bullshark, y compris celle actuellement en environnement de production, ne prend pas en charge ces caractéristiques.
Accord
Malgré les défis mentionnés ci-dessus, comme le dit le proverbe, la solution se cache derrière la simplicité.
Dans Shoal, nous nous appuyons sur la capacité d'exécuter des calculs locaux sur le DAG et avons réalisé la capacité de sauvegarder et de réinterpréter les informations des tours précédents. Grâce à la compréhension fondamentale selon laquelle tous les validateurs s'accordent sur le premier point d'ancrage ordonné, Shoal combine de manière séquentielle plusieurs instances de Bullshark pour les traiter en pipeline, rendant ( le premier point d'ancrage ordonné un point de basculement des instances, ainsi que ) l'historique causal du point d'ancrage utilisé pour calculer la réputation des leaders.
Chaîne de montage
V qui associe les tours aux leaders. Shoal exécute les instances de Bullshark une par une, de sorte que pour chaque instance, l'ancre est préalablement 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é le premier instance de Bullshark lors du premier tour de DAG et l'a fait fonctionner jusqu'à ce que le premier point d'ancrage ordonné soit déterminé, comme au tour r. Tous les validateurs ont accepté ce point d'ancrage. Par conséquent, tous les validateurs peuvent convenir de manière certaine de réinterpréter le DAG à partir du tour r+1. Shoal a simplement lancé une nouvelle instance de Bullshark lors du tour r+1.
Dans le meilleur des cas, cela permet à Shoal de commander un ancre à chaque tour. Les points d'ancrage de la première ronde sont triés par le premier exemple. Ensuite, Shoal commence un nouvel exemple au début de la deuxième ronde, qui a elle-même un point d'ancrage, ce point d'ancrage étant trié par cet exemple, puis un autre nouvel exemple commande un point d'ancrage lors de la troisième ronde, puis le processus continue.
Réputation des leaders
Lorsqu'un point d'ancrage est sauté pendant le tri de Bullshark, la latence augmente. Dans ce cas, la technologie de pipeline est impuissante, car une nouvelle instance ne peut pas être lancée avant que le point d'ancrage de l'instance précédente ne soit commandé. Shoal garantit qu'il est peu probable de choisir le leader correspondant pour traiter les points d'ancrage manquants à l'avenir en attribuant un score à chaque nœud de validation basé sur l'historique de l'activité récente de chaque nœud de validation grâce à un mécanisme de réputation. Les validateurs qui répondent et participent au protocole recevront 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 idée est de recalculer de manière déterministe le mappage prédéfini F de chaque tour au leader à chaque mise à jour de score, en faveur des leaders ayant un score plus élevé. Pour que les validateurs parviennent à un consensus sur le nouveau mappage, ils doivent parvenir à un consensus sur le score, atteignant ainsi un consensus sur l'historique utilisé pour dériver le score.
Dans Shoal, la pipeline et la réputation des leaders peuvent s'intégrer 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 lors du tour r, le validateur doit simplement calculer une nouvelle fonction de correspondance F' à partir du tour r+1 en fonction de l'historique causal des ancres ordonnées du 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épassement de délai joue un rôle crucial dans toutes les mises en œuvre 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'observation.
Le dépassement de délai augmentera également considérablement 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 paiera la pénalité complète de latence pour le leader défaillant. Par conséquent, les paramètres de délai ne peuvent pas être trop conservateurs, mais si le temps de dépassement est trop court, le protocole peut ignorer de bons leaders. Par exemple, nous avons observé que, en cas de forte charge, les leaders dans Jolteon/Hotstuff sont accablés et que le délai d'attente est écoulé avant qu'ils ne fassent progresser les choses.
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.
6 J'aime
Récompense
6
5
Partager
Commentaire
0/400
SchrodingersFOMO
· Il y a 8h
latence descend autant bull bull
Voir l'originalRépondre0
SchroedingerMiner
· Il y a 9h
Cette vitesse augmente plus rapidement que la température de mon Rig de minage.
Voir l'originalRépondre0
MEVSandwich
· 08-03 18:14
latence a diminué autant, on dirait que c'est To the moon
Voir l'originalRépondre0
MetaMisfit
· 08-03 17:54
J'attends que l'aptos fasse des merveilles... en attendant
Le cadre Shoal améliore considérablement les performances de Bullshark sur Aptos avec une latence réduite de 40 % à 80 %.
Cadre Shoal: Réduction significative de la latence de Bullshark sur Aptos
Aperçu
Aptos labs a résolu deux problèmes ouverts importants dans le DAG BFT, réduisant significativement la latence et éliminant pour la première fois le besoin de délais dans les protocoles déterministes réels. 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 grâce à une pipeline et à la réputation des leaders. La pipeline réduit la latence de tri du 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 garantissant que le point d'ancrage est associé aux nœuds de validation les plus rapides. De plus, la réputation des leaders permet à Shoal d'exploiter la construction de DAG asynchrone pour éliminer les délais dans tous les scénarios. Cela permet à Shoal de fournir des attributs de réponse universelle, y compris la réponse optimiste généralement requise.
Cette technologie est très simple, impliquant l'exécution séquentielle de plusieurs instances du protocole sous-jacent. Ainsi, lorsque nous l'instancions avec Bullshark, nous obtenons un groupe de "requins" participant à une course de relais.
Motivation
Dans la recherche de haute performance des réseaux blockchain, les gens se sont toujours concentrés sur la réduction de la complexité de la communication. Cependant, cette approche n'a pas conduit à une amélioration significative du débit. Par exemple, le Hotstuff implémenté dans les premières versions de Diem n'atteignait que 3500 TPS, bien en dessous de l'objectif de 100k+ TPS.
Les récentes percées proviennent de la compréhension que la propagation des données est le principal goulot d'étranglement basé sur le protocole des leaders, et peut bénéficier de la parallélisation. Le système Narwhal dissocie la propagation des données de la logique de consensus, proposant une architecture où tous les validateurs propagent les données simultanément, tandis que le composant de consensus ne commande qu'une petite quantité de métadonnées. Le document Narwhal rapporte un débit de 160 000 TPS.
Nous avons précédemment présenté Quorum Store, notre implémentation Narwhal qui sépare la diffusion des données du consensus, ainsi que comment 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, réduisant 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. Bien que la diffusion des données soit séparée du consensus, avec l'augmentation du débit, le leader de Hotstuff/Jolteon reste limité.
Ainsi, nous avons décidé de déployer Bullshark, un protocole de consensus sans frais de communication, sur Narwhal DAG. Malheureusement, par rapport à Jolteon, la structure DAG qui prend en charge 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 de 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, chaque sommet référencant au moins n-f sommets du tour précédent. En raison de l'asynchronisme du réseau, différents validateurs peuvent observer des vues locales différentes du DAG à tout moment.
Une propriété clé du DAG n'est pas ambiguë : 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.
Préface
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 réservé : tous les quelques tours, il y a un leader prédéterminé, le sommet du leader est appelé point d'ancrage ;
Points d'ancrage de commande : les validateurs décident de manière indépendante mais déterministe quels points d'ancrage commander et lesquels sauter ;
Commande de l'historique causal : les validateurs traitent un par un la liste des points d'ancrage ordonnée et trient tous les sommets désordonnés précédents dans l'historique causal de chaque point d'ancrage.
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, nous faisons les observations suivantes concernant tous les protocoles mentionnés ci-dessus:
Tous les validateurs s'accordent sur 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 synchronisée de Bullshark soit généralement plus performante en matière de latence que la version asynchrone, elle est loin d'être optimale.
Question 1 : latence moyenne des blocs. Dans Bullshark, chaque ronde paire a un point d'ancrage, et chaque sommet de la ronde impaire est interprété comme un vote. Dans des cas courants, il faut deux rondes de DAG pour ordonner les points d'ancrage, cependant, les sommets dans l'histoire causale des points d'ancrage nécessitent plus de rondes pour attendre que les points d'ancrage soient triés. Dans des cas courants, les sommets de la ronde impaire nécessitent trois rondes, tandis que les sommets non ancrés de la ronde paire nécessitent quatre rondes.
Problème 2 : latence des cas de panne, l'analyse de latence ci-dessus s'applique aux situations sans panne. D'autre part, si le leader d'un tour ne parvient pas à diffuser suffisamment rapidement le point d'ancrage, il est impossible de trier le point d'ancrage (, il est donc sauté ), ce qui signifie que tous les sommets non triés des tours précédents doivent attendre que le prochain point d'ancrage soit trié. Cela réduit considérablement les performances du réseau de réplication géographique, surtout parce que le délai d'attente Bullshark est utilisé 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) grâce à un pipeline, 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 introduit également un mécanisme de réputation des leaders sans frais dans le DAG, ce qui favorise le choix de leaders rapides.
Défi
Dans le contexte du protocole DAG, le pipeline et la réputation des leaders sont considérés comme des problèmes difficiles, pour les raisons suivantes :
Les anciennes tentatives de la chaîne de production ont essayé 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 se base sur la performance passée des validateurs pour sélectionner dynamiquement les futurs leaders dans Bullshark, l'idée étant de choisir des ancres. Bien que des divergences dans l'identité des leaders ne compromettent pas la sécurité de ces protocoles, dans Bullshark, cela peut mener à un classement complètement différent, soulevant le cœur du problème, à savoir que le choix dynamique et déterministe des ancres de roue est nécessaire pour résoudre le consensus, et que les validateurs doivent parvenir à un accord sur l'historique ordonné pour choisir les futures ancres.
En tant que preuve de la difficulté des problèmes, nous avons constaté que l'implémentation de Bullshark, y compris celle actuellement en environnement de production, ne prend pas en charge ces caractéristiques.
Accord
Malgré les défis mentionnés ci-dessus, comme le dit le proverbe, la solution se cache derrière la simplicité.
Dans Shoal, nous nous appuyons sur la capacité d'exécuter des calculs locaux sur le DAG et avons réalisé la capacité de sauvegarder et de réinterpréter les informations des tours précédents. Grâce à la compréhension fondamentale selon laquelle tous les validateurs s'accordent sur le premier point d'ancrage ordonné, Shoal combine de manière séquentielle plusieurs instances de Bullshark pour les traiter en pipeline, rendant ( le premier point d'ancrage ordonné un point de basculement des instances, ainsi que ) l'historique causal du point d'ancrage utilisé pour calculer la réputation des leaders.
Chaîne de montage
V qui associe les tours aux leaders. Shoal exécute les instances de Bullshark une par une, de sorte que pour chaque instance, l'ancre est préalablement 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é le premier instance de Bullshark lors du premier tour de DAG et l'a fait fonctionner jusqu'à ce que le premier point d'ancrage ordonné soit déterminé, comme au tour r. Tous les validateurs ont accepté ce point d'ancrage. Par conséquent, tous les validateurs peuvent convenir de manière certaine de réinterpréter le DAG à partir du tour r+1. Shoal a simplement lancé une nouvelle instance de Bullshark lors du tour r+1.
Dans le meilleur des cas, cela permet à Shoal de commander un ancre à chaque tour. Les points d'ancrage de la première ronde sont triés par le premier exemple. Ensuite, Shoal commence un nouvel exemple au début de la deuxième ronde, qui a elle-même un point d'ancrage, ce point d'ancrage étant trié par cet exemple, puis un autre nouvel exemple commande un point d'ancrage lors de la troisième ronde, puis le processus continue.
Réputation des leaders
Lorsqu'un point d'ancrage est sauté pendant le tri de Bullshark, la latence augmente. Dans ce cas, la technologie de pipeline est impuissante, car une nouvelle instance ne peut pas être lancée avant que le point d'ancrage de l'instance précédente ne soit commandé. Shoal garantit qu'il est peu probable de choisir le leader correspondant pour traiter les points d'ancrage manquants à l'avenir en attribuant un score à chaque nœud de validation basé sur l'historique de l'activité récente de chaque nœud de validation grâce à un mécanisme de réputation. Les validateurs qui répondent et participent au protocole recevront 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 idée est de recalculer de manière déterministe le mappage prédéfini F de chaque tour au leader à chaque mise à jour de score, en faveur des leaders ayant un score plus élevé. Pour que les validateurs parviennent à un consensus sur le nouveau mappage, ils doivent parvenir à un consensus sur le score, atteignant ainsi un consensus sur l'historique utilisé pour dériver le score.
Dans Shoal, la pipeline et la réputation des leaders peuvent s'intégrer 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 lors du tour r, le validateur doit simplement calculer une nouvelle fonction de correspondance F' à partir du tour r+1 en fonction de l'historique causal des ancres ordonnées du 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épassement de délai joue un rôle crucial dans toutes les mises en œuvre 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'observation.
Le dépassement de délai augmentera également considérablement 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 paiera la pénalité complète de latence pour le leader défaillant. Par conséquent, les paramètres de délai ne peuvent pas être trop conservateurs, mais si le temps de dépassement est trop court, le protocole peut ignorer de bons leaders. Par exemple, nous avons observé que, en cas de forte charge, les leaders dans Jolteon/Hotstuff sont accablés et que le délai d'attente est écoulé avant qu'ils ne fassent progresser les choses.
malheureux