Cadre Shoal : optimisation de la latence du consensus Bullshark sur Aptos
Aptos Labs a récemment résolu deux problèmes ouverts importants dans le DAG BFT, réduisant considérablement la latence et éliminant pour la première fois le besoin de délais dans les protocoles réels déterministes. 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 panne.
Shoal est un cadre qui améliore le protocole de consensus basé sur Narwhal ( grâce à un traitement en pipeline et un mécanisme de réputation des leaders comme DAG-Rider, Tusk, Bullshark ). Le pipeline réduit la latence de tri DAG en introduisant un point d'ancrage à chaque tour, et la réputation des leaders améliore encore le problème de latence en s'assurant 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'utiliser la construction DAG asynchrone pour éliminer les délais dans tous les scénarios. Cela permet à Shoal d'offrir des caractéristiques de réponse universelle, incluant celles qui nécessitent généralement une réponse optimiste.
La technologie de Shoal est relativement simple, fonctionnant principalement en exécutant plusieurs instances des protocoles sous-jacents les unes après les autres. Lorsqu'elle est instanciée avec Bullshark, cela forme un groupe de "requins" participant à une course de relais.
Contexte et motivation
Dans la quête de haute performance des réseaux blockchain, la réduction de la complexité de communication a toujours été un point de préoccupation. Cependant, cette méthode n'a pas entraîné d'amélioration significative du débit. Par exemple, le Hotstuff mis en œuvre dans les premières versions de Diem n'atteignait que 3500 TPS, bien en dessous de l'objectif de 100k+ TPS.
La récente percée provient de la prise de conscience 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 de base, proposant une architecture où tous les validateurs propagent simultanément les données, tandis que le composant de consensus ne trie qu'une petite quantité de métadonnées. Le document Narwhal rapporte un débit de 160 000 TPS.
Aptos a précédemment présenté Quorum Store, qui est l'implémentation de Narwhal, séparant la diffusion des données et le 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, 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 tirer pleinement parti du potentiel de débit de Narwhal. Bien que la diffusion des données et le consensus soient séparés, avec l'augmentation du débit, les leaders de Hotstuff/Jolteon restent limités.
Ainsi, Aptos a décidé de déployer Bullshark, un protocole de consensus sans frais de communication, sur le DAG Narwhal. Malheureusement, par rapport à Jolteon, la structure DAG qui supporte le haut débit de Bullshark entraîne un coût de latence de 50%.
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'asynchronicité du réseau, différents validateurs peuvent observer à tout moment des vues locales différentes du DAG.
Une caractéristique clé du DAG est l'absence d'ambiguïté : 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 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 des intersections de groupes dans 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, toutes les deux tours ) il y aura 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 trier et lesquels sauter.
Historique de causalité trié : les validateurs traitent un par un la liste des points d'ancrage ordonnés. Pour chaque point d'ancrage, ils trient tous les sommets précédemment désordonnés dans leur historique de causalité selon des 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 de points d'ancrage ordonnée, afin que toutes les listes partagent le même préfixe. Dans Shoal, les observations suivantes peuvent être faites sur tous les protocoles susmentionnés : 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 synchrone de Bullshark soit plus pratique et ait une meilleure latence que la version asynchrone, elle reste encore loin d'être optimale.
Il existe principalement deux problèmes :
Latence moyenne des blocs : Dans Bullshark, chaque ronde paire a un point d'ancrage, et chaque sommet des rondes impaires est interprété comme un vote. Dans des cas courants, il faut deux rondes de DAG pour trier les points d'ancrage, cependant, les sommets dans l'historique causal 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 dans les rondes impaires nécessitent trois rondes, tandis que les sommets non ancrés dans les rondes paires nécessitent quatre rondes.
Cas de défaillance latence : Si un 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é ). Tous les sommets non triés des tours précédents doivent attendre que le prochain point d'ancrage soit trié. Cela réduira considérablement la performance du réseau de réplication géographique, en particulier parce que Bullshark utilise un délai pour attendre le leader.
Cadre Shoal
Shoal a amélioré le Bullshark( ou tout autre protocole BFT basé sur Narwhal) grâce à un traitement en 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 à coût nul dans le DAG, favorisant le choix des leaders rapides.
Défi
Dans le contexte du protocole DAG, le traitement en pipeline et la réputation des leaders sont considérés comme des problèmes difficiles, pour les raisons suivantes :
Les tentatives de traitement en ligne précédentes de modifier la logique centrale de Bullshark semblent fondamentalement impossibles.
La réputation des leaders est introduite dans DiemBFT et formalisée dans Carousel, ce qui permet de sélectionner dynamiquement les futurs leaders en fonction des performances passées des validateurs dans l'idée des ancres dans Bullshark (. Bien qu'il n'y ait pas de violation de la sécurité de ces protocoles en raison de divergences sur l'identité des leaders, dans Bullshark, cela peut entraîner un ordre complètement différent. Cela soulève 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.
Protocole
Malgré les défis mentionnés ci-dessus, la solution se cache dans la simplicité. Dans Shoal, la capacité d'exécuter des calculs locaux sur le DAG est exploitée, permettant de conserver et de réinterpréter les informations des précédents tours. Grâce à l'idée centrale 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 un traitement en pipeline, ce qui permet :
Le premier point d'ancrage ordonné est le point de basculement de l'instance.
L'historique causale des points d'ancrage est utilisé pour calculer la réputation des leaders.
) traitement en pipeline
V qui associe les tours aux leaders. Shoal exécute un à un les exemples de Bullshark, de sorte que pour chaque exemple, l'ancre est préalablement déterminée par le mappage F. Chaque exemple trie une ancre, ce qui déclenche le passage à l'exemple suivant.
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 déterminée de 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 trier un ancre à chaque tour. Les points d'ancrage de la première ronde sont triés par la 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 ancre étant trié par cette instance, puis une autre nouvelle instance trie le point d'ancrage lors de la troisième ronde, puis le processus continue.
![Explication détaillée du cadre Shoal : Comment réduire la latence Bullshark sur Aptos ?]###https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
) réputation des leaders
Lorsqu'un point d'ancrage est ignoré pendant le tri Bullshark, la latence augmente. Dans ce cas, la technologie de traitement en pipeline ne peut rien faire, car une nouvelle instance ne peut pas être lancée avant le tri du point d'ancrage de l'instance précédente. Shoal assure qu'il est peu probable que les leaders correspondants soient choisis pour traiter les points d'ancrage manquants à l'avenir en attribuant un score à chaque nœud de validation en fonction de l'historique de ses activités récentes 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 concept est de recalculer de manière déterministe la cartographie prédéfinie F allant du 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 la nouvelle cartographie, ils doivent parvenir à un consensus sur le score, afin d’atteindre un consensus sur l’historique utilisé pour dériver le score.
Dans Shoal, le traitement en pipeline et la gestion de la réputation peuvent se combiner naturellement, car ils utilisent tous 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 points d'ancrage lors de la rème ronde, les validateurs n'ont besoin de calculer le nouveau mappage F' qu'à partir de la r+1ère ronde, en se basant sur l'historique causale des points d'ancrage ordonnés dans la rème ronde. Ensuite, les nœuds de validation commencent à utiliser la fonction de sélection de points d'ancrage mise à jour F' pour exécuter une nouvelle instance de Bullshark à partir de la r+1ère ronde.
![Explication détaillée du cadre Shoal : Comment réduire la latence de Bullshark sur Aptos ?]###https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
) Pas de délai
Le dépassement de délai joue un rôle essentiel 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 dépassement de délai 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 prochain leader, le protocole paiera une pénalité de délai de dépassement complète pour les leaders défaillants. Par conséquent, les paramètres de délai ne doivent pas être trop conservateurs, mais si le temps de dépassement est trop court, le protocole pourrait sauter de bons leaders.
Malheureusement, les protocoles basés sur le leader ) comme Hotstuff et Jolteon ( nécessitent essentiellement des délais pour garantir que le protocole progresse chaque fois qu'un leader échoue. En l'absence de délai, même un leader en panne peut arrêter le protocole indéfiniment. Étant donné qu'il est impossible de distinguer un leader en panne d'un leader lent pendant les périodes asynchrones, un délai peut amener les nœuds de validation à envisager de changer tous les leaders sans latence de consensus.
Dans Bullshark, le délai est utilisé pour la construction du DAG, afin de garantir qu'un leader honnête ajoutera un point d'ancrage au DA pendant la synchronisation.
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.
10 J'aime
Récompense
10
6
Partager
Commentaire
0/400
LiquidatedNotStirred
· Il y a 16h
C'est en ligne, cette technologie a beaucoup de potentiel.
Voir l'originalRépondre0
UncleWhale
· 07-16 04:39
Compris, l'ancien aptos est toujours en compétition.
Cadre Shoal innovant d'Aptos : apporte une optimisation de latence de 40 à 80 % pour le consensus Bullshark.
Cadre Shoal : optimisation de la latence du consensus Bullshark sur Aptos
Aptos Labs a récemment résolu deux problèmes ouverts importants dans le DAG BFT, réduisant considérablement la latence et éliminant pour la première fois le besoin de délais dans les protocoles réels déterministes. 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 panne.
Shoal est un cadre qui améliore le protocole de consensus basé sur Narwhal ( grâce à un traitement en pipeline et un mécanisme de réputation des leaders comme DAG-Rider, Tusk, Bullshark ). Le pipeline réduit la latence de tri DAG en introduisant un point d'ancrage à chaque tour, et la réputation des leaders améliore encore le problème de latence en s'assurant 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'utiliser la construction DAG asynchrone pour éliminer les délais dans tous les scénarios. Cela permet à Shoal d'offrir des caractéristiques de réponse universelle, incluant celles qui nécessitent généralement une réponse optimiste.
La technologie de Shoal est relativement simple, fonctionnant principalement en exécutant plusieurs instances des protocoles sous-jacents les unes après les autres. Lorsqu'elle est instanciée avec Bullshark, cela forme un groupe de "requins" participant à une course de relais.
Contexte et motivation
Dans la quête de haute performance des réseaux blockchain, la réduction de la complexité de communication a toujours été un point de préoccupation. Cependant, cette méthode n'a pas entraîné d'amélioration significative du débit. Par exemple, le Hotstuff mis en œuvre dans les premières versions de Diem n'atteignait que 3500 TPS, bien en dessous de l'objectif de 100k+ TPS.
La récente percée provient de la prise de conscience 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 de base, proposant une architecture où tous les validateurs propagent simultanément les données, tandis que le composant de consensus ne trie qu'une petite quantité de métadonnées. Le document Narwhal rapporte un débit de 160 000 TPS.
Aptos a précédemment présenté Quorum Store, qui est l'implémentation de Narwhal, séparant la diffusion des données et le 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, 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 tirer pleinement parti du potentiel de débit de Narwhal. Bien que la diffusion des données et le consensus soient séparés, avec l'augmentation du débit, les leaders de Hotstuff/Jolteon restent limités.
Ainsi, Aptos a décidé de déployer Bullshark, un protocole de consensus sans frais de communication, sur le DAG Narwhal. Malheureusement, par rapport à Jolteon, la structure DAG qui supporte le haut débit de Bullshark entraîne un coût de latence de 50%.
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'asynchronicité du réseau, différents validateurs peuvent observer à tout moment des vues locales différentes du DAG.
Une caractéristique clé du DAG est l'absence d'ambiguïté : 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 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 des intersections de groupes dans 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, toutes les deux tours ) il y aura 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 trier et lesquels sauter.
Historique de causalité trié : les validateurs traitent un par un la liste des points d'ancrage ordonnés. Pour chaque point d'ancrage, ils trient tous les sommets précédemment désordonnés dans leur historique de causalité selon des 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 de points d'ancrage ordonnée, afin que toutes les listes partagent le même préfixe. Dans Shoal, les observations suivantes peuvent être faites sur tous les protocoles susmentionnés : 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 synchrone de Bullshark soit plus pratique et ait une meilleure latence que la version asynchrone, elle reste encore loin d'être optimale.
Il existe principalement deux problèmes :
Latence moyenne des blocs : Dans Bullshark, chaque ronde paire a un point d'ancrage, et chaque sommet des rondes impaires est interprété comme un vote. Dans des cas courants, il faut deux rondes de DAG pour trier les points d'ancrage, cependant, les sommets dans l'historique causal 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 dans les rondes impaires nécessitent trois rondes, tandis que les sommets non ancrés dans les rondes paires nécessitent quatre rondes.
Cas de défaillance latence : Si un 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é ). Tous les sommets non triés des tours précédents doivent attendre que le prochain point d'ancrage soit trié. Cela réduira considérablement la performance du réseau de réplication géographique, en particulier parce que Bullshark utilise un délai pour attendre le leader.
Cadre Shoal
Shoal a amélioré le Bullshark( ou tout autre protocole BFT basé sur Narwhal) grâce à un traitement en 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 à coût nul dans le DAG, favorisant le choix des leaders rapides.
Défi
Dans le contexte du protocole DAG, le traitement en pipeline et la réputation des leaders sont considérés comme des problèmes difficiles, pour les raisons suivantes :
Les tentatives de traitement en ligne précédentes de modifier la logique centrale de Bullshark semblent fondamentalement impossibles.
La réputation des leaders est introduite dans DiemBFT et formalisée dans Carousel, ce qui permet de sélectionner dynamiquement les futurs leaders en fonction des performances passées des validateurs dans l'idée des ancres dans Bullshark (. Bien qu'il n'y ait pas de violation de la sécurité de ces protocoles en raison de divergences sur l'identité des leaders, dans Bullshark, cela peut entraîner un ordre complètement différent. Cela soulève 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.
Protocole
Malgré les défis mentionnés ci-dessus, la solution se cache dans la simplicité. Dans Shoal, la capacité d'exécuter des calculs locaux sur le DAG est exploitée, permettant de conserver et de réinterpréter les informations des précédents tours. Grâce à l'idée centrale 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 un traitement en pipeline, ce qui permet :
) traitement en pipeline
V qui associe les tours aux leaders. Shoal exécute un à un les exemples de Bullshark, de sorte que pour chaque exemple, l'ancre est préalablement déterminée par le mappage F. Chaque exemple trie une ancre, ce qui déclenche le passage à l'exemple suivant.
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 déterminée de 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 trier un ancre à chaque tour. Les points d'ancrage de la première ronde sont triés par la 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 ancre étant trié par cette instance, puis une autre nouvelle instance trie le point d'ancrage lors de la troisième ronde, puis le processus continue.
![Explication détaillée du cadre Shoal : Comment réduire la latence Bullshark sur Aptos ?]###https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
) réputation des leaders
Lorsqu'un point d'ancrage est ignoré pendant le tri Bullshark, la latence augmente. Dans ce cas, la technologie de traitement en pipeline ne peut rien faire, car une nouvelle instance ne peut pas être lancée avant le tri du point d'ancrage de l'instance précédente. Shoal assure qu'il est peu probable que les leaders correspondants soient choisis pour traiter les points d'ancrage manquants à l'avenir en attribuant un score à chaque nœud de validation en fonction de l'historique de ses activités récentes 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 concept est de recalculer de manière déterministe la cartographie prédéfinie F allant du 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 la nouvelle cartographie, ils doivent parvenir à un consensus sur le score, afin d’atteindre un consensus sur l’historique utilisé pour dériver le score.
Dans Shoal, le traitement en pipeline et la gestion de la réputation peuvent se combiner naturellement, car ils utilisent tous 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 points d'ancrage lors de la rème ronde, les validateurs n'ont besoin de calculer le nouveau mappage F' qu'à partir de la r+1ère ronde, en se basant sur l'historique causale des points d'ancrage ordonnés dans la rème ronde. Ensuite, les nœuds de validation commencent à utiliser la fonction de sélection de points d'ancrage mise à jour F' pour exécuter une nouvelle instance de Bullshark à partir de la r+1ère ronde.
![Explication détaillée du cadre Shoal : Comment réduire la latence de Bullshark sur Aptos ?]###https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
) Pas de délai
Le dépassement de délai joue un rôle essentiel 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 dépassement de délai 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 prochain leader, le protocole paiera une pénalité de délai de dépassement complète pour les leaders défaillants. Par conséquent, les paramètres de délai ne doivent pas être trop conservateurs, mais si le temps de dépassement est trop court, le protocole pourrait sauter de bons leaders.
Malheureusement, les protocoles basés sur le leader ) comme Hotstuff et Jolteon ( nécessitent essentiellement des délais pour garantir que le protocole progresse chaque fois qu'un leader échoue. En l'absence de délai, même un leader en panne peut arrêter le protocole indéfiniment. Étant donné qu'il est impossible de distinguer un leader en panne d'un leader lent pendant les périodes asynchrones, un délai peut amener les nœuds de validation à envisager de changer tous les leaders sans latence de consensus.
Dans Bullshark, le délai est utilisé pour la construction du DAG, afin de garantir qu'un leader honnête ajoutera un point d'ancrage au DA pendant la synchronisation.