Cadre Shoal: Goutte importante de la latence Bullshark sur Aptos
Aptos Labs a récemment résolu deux problèmes ouverts importants dans le DAG BFT, ce qui a considérablement Goutte la latence et a éliminé pour la première fois le besoin de délais dans un protocole pratique déterministe. Dans l'ensemble, la latence de Bullshark a été améliorée de 40 % en cas de fonctionnement sans faute 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 à un pipeline et à la réputation des leaders. Le 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 davantage la 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 asynchrone du DAG pour éliminer les délais d'attente dans tous les scénarios. Cela permet à Shoal d'offrir ce qu'on appelle une réactivité universelle, qui inclut la réactivité optimiste généralement requise.
Cette technologie est assez simple, impliquant l'exécution de plusieurs instances du protocole sous-jacent dans un ordre donné. Ainsi, lorsque nous l'instancions avec Bullshark, nous obtenons un groupe de "requins" participant à une course de relais.
Motivation
Dans la quête de haute performance des réseaux blockchain, l'accent a toujours été mis sur la Goutte de la complexité de la communication. Cependant, cette approche n'a pas conduit à une augmentation significative du débit. Par exemple, le Hotstuff implémenté dans les premières versions de Diem n'a réalisé que 3500 TPS, bien en dessous de notre objectif de 100k+ TPS.
La récente percée provient de la reconnaissance 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 sépare la propagation des données de la logique de consensus centrale, proposant une architecture où tous les validateurs propagent les données simultanément, les composants de consensus ne commandent qu'un petit nombre de métadonnées. Le document Narwhal rapporte un débit de 160 000 TPS.
Dans un article précédent, nous avons présenté Quorum Store. Notre implémentation de Narwhal sépare la propagation des données du consensus, ainsi que la manière 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, il est évident que les protocoles de consensus basés sur un leader ne peuvent pas exploiter pleinement le potentiel de débit de Narwhal. Bien que la propagation des données soit séparée du consensus, avec l'augmentation du débit, le leader de Hotstuff/Jolteon reste toujours limité.
Ainsi, nous avons décidé de déployer Bullshark sur Narwhal DAG, un protocole de consensus sans coût de communication. Malheureusement, par rapport à Jolteon, la structure DAG qui supporte le haut débit de Bullshark entraîne un coût de latence de 50 %.
Cet article présente comment Shoal réussit à Goutte 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 propriété clé du DAG est qu'elle 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 une histoire causale de v complètement identique.
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 cela, 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 de groupe 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 ( par exemple, dans Bullshark, chaque deux tours ), il y a un leader prédéterminé, 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 ;
Histoire causale ordonnée : les validateurs traitent un par un la liste des points d'ancrage ordonnés, et pour chaque point d'ancrage, ils trient tous les sommets précédemment désordonnés dans son histoire causale selon certaines règles déterministes.
La clé de 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 sur tous les protocoles mentionnés ci-dessus:
Tous les validateurs conviennent du 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 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 round pair a un point d'ancrage, et les sommets de chaque round impair sont interprétés comme des votes. Dans des conditions normales, il faut deux tours de DAG pour commander les points d'ancrage, cependant, les sommets dans l'histoire causale de l'ancre nécessitent plus de tours pour attendre que l'ancre soit classée. Dans des conditions normales, les sommets dans les tours impairs nécessitent trois tours, tandis que les sommets non ancrés dans les tours pairs 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 (, donc il est sauté ). Par conséquent, tous les sommets non triés des premiers tours doivent attendre que le prochain point d'ancrage soit trié. Cela réduira considérablement les performances du réseau de réplication géographique, notamment parce que Bullshark utilise un délai d'attente pour attendre le leader.
Cadre Shoal
Shoal a résolu ces deux problèmes de latence, en renforçant Bullshark( ou tout autre protocole BFT basé sur Narwhal) par le biais d'une 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 a également introduit un mécanisme de réputation de leader sans coût dans le DAG, ce qui favorise le choix d'un leader rapide.
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 tentatives précédentes 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, elle est basée sur le choix dynamique des futurs leaders en fonction des performances passées des validateurs, l'idée des ancres dans Bullshark. Bien qu'il y ait des divergences sur l'identité des leaders, cela ne compromet pas la sécurité de ces protocoles, mais dans Bullshark, cela pourrait entraîner un classement complètement différent, ce qui soulève le cœur du problème, à savoir que le choix dynamique et déterministe des ancres de rotation est nécessaire pour résoudre le consensus, et les validateurs doivent s'accorder sur l'historique ordonné pour choisir les futures ancres.
En tant que preuve de la difficulté des problèmes, nous remarquons que l'implémentation de Bullshark, y compris celle actuellement en production, ne prend pas en charge ces caractéristiques.
Accord
Malgré les défis mentionnés ci-dessus, il s'avère que la solution se cache dans 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 conserver 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 séquentiellement 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'histoire causale du point d'ancrage utilisée pour calculer la réputation des leaders.
Chaîne de production
V qui mappe les tours aux leaders. Shoal exécute des instances de Bullshark les unes après les autres, de sorte que pour chaque instance, l'ancre est déterminée à l'avance par la fonction 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é, par exemple au tour r. Tous les validateurs ont convenu de 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é un nouvel instance de Bullshark au 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, et cette ancre est triée par cet exemple, puis un autre nouvel exemple commande un point d'ancrage lors de la troisième ronde, et le processus se poursuit.
Réputation des leaders
Lors de la suppression des points d'ancrage pendant le tri Bullshark, la latence augmente. Dans ce cas, la technique 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 moins probable que le leader correspondant soit choisi à l'avenir pour traiter les points d'ancrage manquants en attribuant un score à chaque nœud de validation en fonction de l'historique de l'activité récente de chaque nœud de validation via 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 seront attribués un score faible, 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 du tour au leader à chaque mise à jour de score, en faveur des leaders ayant des scores plus élevés. Pour que les validateurs parviennent à un consensus sur le nouveau mappage, ils doivent parvenir à un consensus sur le score, afin d'établir un consensus sur l'historique utilisé pour dériver les scores.
Dans Shoal, la chaîne de production et la réputation des leaders 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 le tri des points d'ancrage lors de la rème ronde, les validateurs n'ont qu'à calculer le nouveau mappage F' à partir de la r+1ère ronde en se basant sur l'histoire causale des points d'ancrage ordonnés de la rème ronde. Ensuite, les nœuds de validation commencent à utiliser la fonction de sélection des points d'ancrage mise à jour F' pour exécuter une nouvelle instance de Bullshark à partir de la r+1ère ronde.
Plus de délai
Le dépassement de 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'observation.
Le délai d'attente peut également augmenter significativement la latence, car il est très important de les configurer correctement et qu'il nécessite souvent des ajustements dynamiques, car il dépend fortement de l'environnement ( réseau ). Avant de passer au prochain leader, le protocole paie une pénalité de délai d'attente complète pour un leader défaillant. Par conséquent, les paramètres de délai d'attente ne peuvent pas être trop conservateurs, mais si le temps de délai d'attente est trop court, le protocole peut sauter de bons leaders. Par exemple, nous avons observé que, en cas de forte charge, Jolteon/
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.
22 J'aime
Récompense
22
5
Partager
Commentaire
0/400
BlockchainFries
· 07-21 02:44
Attendez, 40% et 80%, êtes-vous sûr que ce n'est pas juste une promesse en l'air ?
Voir l'originalRépondre0
YouMustMakeBigMoneyEvery
· 07-20 12:23
Pas encore créé une forte impulsion. Trop d'ennuis. Augmenter la position au-dessus de 6 yuans.
Voir l'originalRépondre0
HalfBuddhaMoney
· 07-20 09:59
latence a tellement diminué, Aptos est à attendre avec impatience !
Voir l'originalRépondre0
SleepyArbCat
· 07-20 09:58
Cette nuit est presque terminée, Aptos a enfin créé une forte impulsion, miaou... Si la latence pouvait encore diminuer, je pourrais manger gratuitement.
Le cadre Shoal Goutte Aptos Bullshark latence de 40%-80%
Cadre Shoal: Goutte importante de la latence Bullshark sur Aptos
Aptos Labs a récemment résolu deux problèmes ouverts importants dans le DAG BFT, ce qui a considérablement Goutte la latence et a éliminé pour la première fois le besoin de délais dans un protocole pratique déterministe. Dans l'ensemble, la latence de Bullshark a été améliorée de 40 % en cas de fonctionnement sans faute 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 à un pipeline et à la réputation des leaders. Le 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 davantage la 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 asynchrone du DAG pour éliminer les délais d'attente dans tous les scénarios. Cela permet à Shoal d'offrir ce qu'on appelle une réactivité universelle, qui inclut la réactivité optimiste généralement requise.
Cette technologie est assez simple, impliquant l'exécution de plusieurs instances du protocole sous-jacent dans un ordre donné. Ainsi, lorsque nous l'instancions avec Bullshark, nous obtenons un groupe de "requins" participant à une course de relais.
Motivation
Dans la quête de haute performance des réseaux blockchain, l'accent a toujours été mis sur la Goutte de la complexité de la communication. Cependant, cette approche n'a pas conduit à une augmentation significative du débit. Par exemple, le Hotstuff implémenté dans les premières versions de Diem n'a réalisé que 3500 TPS, bien en dessous de notre objectif de 100k+ TPS.
La récente percée provient de la reconnaissance 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 sépare la propagation des données de la logique de consensus centrale, proposant une architecture où tous les validateurs propagent les données simultanément, les composants de consensus ne commandent qu'un petit nombre de métadonnées. Le document Narwhal rapporte un débit de 160 000 TPS.
Dans un article précédent, nous avons présenté Quorum Store. Notre implémentation de Narwhal sépare la propagation des données du consensus, ainsi que la manière 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, il est évident que les protocoles de consensus basés sur un leader ne peuvent pas exploiter pleinement le potentiel de débit de Narwhal. Bien que la propagation des données soit séparée du consensus, avec l'augmentation du débit, le leader de Hotstuff/Jolteon reste toujours limité.
Ainsi, nous avons décidé de déployer Bullshark sur Narwhal DAG, un protocole de consensus sans coût de communication. Malheureusement, par rapport à Jolteon, la structure DAG qui supporte le haut débit de Bullshark entraîne un coût de latence de 50 %.
Cet article présente comment Shoal réussit à Goutte 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 propriété clé du DAG est qu'elle 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 une histoire causale de v complètement identique.
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 cela, 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 de groupe 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 ( par exemple, dans Bullshark, chaque deux tours ), il y a un leader prédéterminé, 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 ;
Histoire causale ordonnée : les validateurs traitent un par un la liste des points d'ancrage ordonnés, et pour chaque point d'ancrage, ils trient tous les sommets précédemment désordonnés dans son histoire causale selon certaines règles déterministes.
La clé de 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 sur tous les protocoles mentionnés ci-dessus:
Tous les validateurs conviennent du 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 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 round pair a un point d'ancrage, et les sommets de chaque round impair sont interprétés comme des votes. Dans des conditions normales, il faut deux tours de DAG pour commander les points d'ancrage, cependant, les sommets dans l'histoire causale de l'ancre nécessitent plus de tours pour attendre que l'ancre soit classée. Dans des conditions normales, les sommets dans les tours impairs nécessitent trois tours, tandis que les sommets non ancrés dans les tours pairs 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 (, donc il est sauté ). Par conséquent, tous les sommets non triés des premiers tours doivent attendre que le prochain point d'ancrage soit trié. Cela réduira considérablement les performances du réseau de réplication géographique, notamment parce que Bullshark utilise un délai d'attente pour attendre le leader.
Cadre Shoal
Shoal a résolu ces deux problèmes de latence, en renforçant Bullshark( ou tout autre protocole BFT basé sur Narwhal) par le biais d'une 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 a également introduit un mécanisme de réputation de leader sans coût dans le DAG, ce qui favorise le choix d'un leader rapide.
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 tentatives précédentes 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, elle est basée sur le choix dynamique des futurs leaders en fonction des performances passées des validateurs, l'idée des ancres dans Bullshark. Bien qu'il y ait des divergences sur l'identité des leaders, cela ne compromet pas la sécurité de ces protocoles, mais dans Bullshark, cela pourrait entraîner un classement complètement différent, ce qui soulève le cœur du problème, à savoir que le choix dynamique et déterministe des ancres de rotation est nécessaire pour résoudre le consensus, et les validateurs doivent s'accorder sur l'historique ordonné pour choisir les futures ancres.
En tant que preuve de la difficulté des problèmes, nous remarquons que l'implémentation de Bullshark, y compris celle actuellement en production, ne prend pas en charge ces caractéristiques.
Accord
Malgré les défis mentionnés ci-dessus, il s'avère que la solution se cache dans 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 conserver 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 séquentiellement 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'histoire causale du point d'ancrage utilisée pour calculer la réputation des leaders.
Chaîne de production
V qui mappe les tours aux leaders. Shoal exécute des instances de Bullshark les unes après les autres, de sorte que pour chaque instance, l'ancre est déterminée à l'avance par la fonction 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é, par exemple au tour r. Tous les validateurs ont convenu de 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é un nouvel instance de Bullshark au 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, et cette ancre est triée par cet exemple, puis un autre nouvel exemple commande un point d'ancrage lors de la troisième ronde, et le processus se poursuit.
Réputation des leaders
Lors de la suppression des points d'ancrage pendant le tri Bullshark, la latence augmente. Dans ce cas, la technique 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 moins probable que le leader correspondant soit choisi à l'avenir pour traiter les points d'ancrage manquants en attribuant un score à chaque nœud de validation en fonction de l'historique de l'activité récente de chaque nœud de validation via 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 seront attribués un score faible, 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 du tour au leader à chaque mise à jour de score, en faveur des leaders ayant des scores plus élevés. Pour que les validateurs parviennent à un consensus sur le nouveau mappage, ils doivent parvenir à un consensus sur le score, afin d'établir un consensus sur l'historique utilisé pour dériver les scores.
Dans Shoal, la chaîne de production et la réputation des leaders 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 le tri des points d'ancrage lors de la rème ronde, les validateurs n'ont qu'à calculer le nouveau mappage F' à partir de la r+1ère ronde en se basant sur l'histoire causale des points d'ancrage ordonnés de la rème ronde. Ensuite, les nœuds de validation commencent à utiliser la fonction de sélection des points d'ancrage mise à jour F' pour exécuter une nouvelle instance de Bullshark à partir de la r+1ère ronde.
Plus de délai
Le dépassement de 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'observation.
Le délai d'attente peut également augmenter significativement la latence, car il est très important de les configurer correctement et qu'il nécessite souvent des ajustements dynamiques, car il dépend fortement de l'environnement ( réseau ). Avant de passer au prochain leader, le protocole paie une pénalité de délai d'attente complète pour un leader défaillant. Par conséquent, les paramètres de délai d'attente ne peuvent pas être trop conservateurs, mais si le temps de délai d'attente est trop court, le protocole peut sauter de bons leaders. Par exemple, nous avons observé que, en cas de forte charge, Jolteon/