Cadre Shoal : Comment réduire la latence de Bullshark sur Aptos
Aperçu
Aptos Labs a 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 déterministes réels. En général, 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 le protocole de consensus basé sur Narwhal ( grâce à des pipelines et à la réputation des leaders, tel que DAG-Rider, Tusk, Bullshark ). Le pipeline réduit la latence de tri du DAG en introduisant un point d'ancrage à chaque tour, et la réputation des leaders améliore encore la 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 des constructions de DAG asynchrones pour éliminer les délais dans tous les scénarios. Cela permet à Shoal d'offrir ce que nous appelons la propriété de réponse universelle, qui contient généralement les réponses optimistes nécessaires.
Cette technologie est très simple, impliquant l'exécution de plusieurs instances du protocole sous-jacent les unes après les autres. Ainsi, lorsque nous instancions avec Bullshark, nous obtenons un groupe de "requins" en train de faire une course de relais.
Motivation
Dans la recherche de haute performance des réseaux blockchain, l'accent a toujours été mis sur la réduction de la complexité de la communication. Cependant, cette méthode n'a pas entraîné d'amélioration significative du débit. Par exemple, Hotstuff, implémenté 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 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 dans laquelle tous les validateurs propagent simultanément les données, tandis que le composant de consensus ne traite qu'une quantité réduite de métadonnées. Le document Narwhal rapporte un débit de 160 000 TPS.
Dans une précédente introduction, nous avons présenté Quorum Store, c'est-à-dire que l'implémentation de Narwhal sépare la diffusion des données et le 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 clair que les protocoles de consensus basés sur un leader ne peuvent pas pleinement exploiter le 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, il a été décidé de déployer Bullshark, un protocole de consensus sans coût de communication, au-dessus de Narwhal DAG. 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 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, et chaque sommet doit faire référence à au moins n-f sommets du tour précédent. En raison de l'asynchronisme du réseau, différents validateurs peuvent observer différentes vues locales 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 une histoire causale de v complètement identique.
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 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 communautaire 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 cycles, 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 commander et lesquels sauter ;
Historique causale ordonnée : les validateurs traitent un par un leur liste d'ancrages ordonnés et trient tous les sommets précédemment non ordonnés dans l'historique causale de chaque 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 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 concernant tous les protocoles 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 que la version asynchrone, elle est encore loin d'être optimale.
Problème 1 : Latence moyenne des blocs. Dans Bullshark, chaque round pair a un point d'ancrage, et chaque round impair est interprété comme un vote. Dans des cas courants, deux rounds de DAG sont nécessaires pour ordonner les points d'ancrage, cependant, les sommets dans l'histoire causale de l'anchor nécessitent plus de rounds pour attendre que l'anchor soit trié. Dans des cas courants, les sommets dans les rounds impairs nécessitent trois rounds, tandis que les sommets non ancrés dans les rounds pairs nécessitent quatre rounds.
Question 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 n'est pas assez rapide pour diffuser le point d'ancrage, il n'est pas possible de trier le point d'ancrage ( et donc il est ignoré ), par conséquent tous les sommets non triés des premiers tours 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 Bullshark utilise un délai pour attendre le leader.
Cadre Shoal
Shoal a amélioré Bullshark( ou tout autre protocole BFT basé sur Narwhal) grâce à des pipelines, permettant d'avoir un point d'ancrage à chaque tour et de réduire 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 rend le choix en faveur des leaders rapides.
Défi
Dans le cadre du protocole DAG, les problèmes de pipeline et de réputation des leaders sont considérés comme difficiles pour les raisons suivantes :
Les anciennes chaînes de production ont tenté de modifier la logique de base de Bullshark, mais cela semble fondamentalement impossible.
La réputation des leaders est introduite dans DiemBFT et formalisée dans Carousel, en sélectionnant dynamiquement les futurs leaders selon les performances passées des validateurs dans l'idée de l'ancre 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, ce qui soulève le cœur du problème, à savoir que le choix dynamique et déterministe des ancres de cycle est nécessaire pour résoudre le consensus, et que les validateurs doivent parvenir à un consensus sur l'historique ordonné pour choisir les futures ancres.
En tant que preuve de la difficulté des problèmes, l'implémentation de Bullshark ) n'inclut pas les fonctionnalités actuellement prises en charge dans l'environnement de production (.
![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(
Accord
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 à l'insight fondamental selon lequel 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 commutation des instances, ainsi que ( l'histoire causale des points d'ancrage utilisée pour calculer la réputation des leaders.
Chaîne de montage
Comme Bullshark, les validateurs parviennent a priori à un consensus sur les points d'ancrage potentiels, c'est-à-dire qu'il existe une correspondance connue F : R -\u003e V qui associe les tours aux leaders. Shoal exécute un à un les instances de Bullshark, de sorte que pour chaque instance, l'ancre est préalablement déterminée par la correspondance 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 exécutée 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é 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 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, cet 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.
![Explication détaillée du cadre Shoal : comment réduire la latence de Bullshark sur Aptos ?])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Réputation des leaders
Lors du saut des points d'ancrage pendant le tri des Bullsharks, la latence augmente. Dans ce cas, la technologie de pipeline ne peut rien faire, car il est impossible de démarrer une nouvelle instance avant que le point d'ancrage de l'instance précédente ne soit commandé. Shoal garantit qu'il est peu 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 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 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 les scores, permettant ainsi d'atteindre un consensus sur l'historique utilisé pour dériver les scores.
Dans Shoal, les pipelines et la réputation des leaders 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 le tri des points d'ancrage lors de la r-ème ronde, les validateurs n'ont qu'à calculer un nouveau mappage F' à partir de la r+1-ème ronde en fonction de l'historique causal des points d'ancrage ordonnés de la r-ème ronde. Ensuite, les nœuds de validation commencent à exécuter une nouvelle instance de Bullshark à partir de la r+1-ème ronde en utilisant la fonction de sélection de points d'ancrage mise à jour F'.
![Explication détaillée du cadre Shoal : Comment réduire la latence de Bullshark sur Aptos ?])https://img-cdn.gateio.im/webp-social/moments-1baf540693f376d93cb18ef3193593cc.webp(
Plus de temps d'attente
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'elles introduisent augmente le nombre d'états internes à gérer et à observer, ce qui accroît la complexité du processus de débogage et nécessite davantage de techniques d'observabilité.
Le dépassement de délai augmentera considérablement la latence, car il est très important de les configurer correctement, et cela 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 une pénalité de latence complète pour le leader défaillant. 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. Par exemple, nous observons
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.
Le cadre Shoal réduit considérablement la latence du consensus Bullshark sur Aptos, améliorant de 40 % à 80 %.
Cadre Shoal : Comment réduire la latence de Bullshark sur Aptos
Aperçu
Aptos Labs a 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 déterministes réels. En général, 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 le protocole de consensus basé sur Narwhal ( grâce à des pipelines et à la réputation des leaders, tel que DAG-Rider, Tusk, Bullshark ). Le pipeline réduit la latence de tri du DAG en introduisant un point d'ancrage à chaque tour, et la réputation des leaders améliore encore la 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 des constructions de DAG asynchrones pour éliminer les délais dans tous les scénarios. Cela permet à Shoal d'offrir ce que nous appelons la propriété de réponse universelle, qui contient généralement les réponses optimistes nécessaires.
Cette technologie est très simple, impliquant l'exécution de plusieurs instances du protocole sous-jacent les unes après les autres. Ainsi, lorsque nous instancions avec Bullshark, nous obtenons un groupe de "requins" en train de faire une course de relais.
Motivation
Dans la recherche de haute performance des réseaux blockchain, l'accent a toujours été mis sur la réduction de la complexité de la communication. Cependant, cette méthode n'a pas entraîné d'amélioration significative du débit. Par exemple, Hotstuff, implémenté 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 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 dans laquelle tous les validateurs propagent simultanément les données, tandis que le composant de consensus ne traite qu'une quantité réduite de métadonnées. Le document Narwhal rapporte un débit de 160 000 TPS.
Dans une précédente introduction, nous avons présenté Quorum Store, c'est-à-dire que l'implémentation de Narwhal sépare la diffusion des données et le 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 clair que les protocoles de consensus basés sur un leader ne peuvent pas pleinement exploiter le 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, il a été décidé de déployer Bullshark, un protocole de consensus sans coût de communication, au-dessus de Narwhal DAG. 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 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, et chaque sommet doit faire référence à au moins n-f sommets du tour précédent. En raison de l'asynchronisme du réseau, différents validateurs peuvent observer différentes vues locales 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 une histoire causale de v complètement identique.
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 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 communautaire 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 cycles, 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 commander et lesquels sauter ;
Historique causale ordonnée : les validateurs traitent un par un leur liste d'ancrages ordonnés et trient tous les sommets précédemment non ordonnés dans l'historique causale de chaque 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 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 concernant tous les protocoles 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 que la version asynchrone, elle est encore loin d'être optimale.
Problème 1 : Latence moyenne des blocs. Dans Bullshark, chaque round pair a un point d'ancrage, et chaque round impair est interprété comme un vote. Dans des cas courants, deux rounds de DAG sont nécessaires pour ordonner les points d'ancrage, cependant, les sommets dans l'histoire causale de l'anchor nécessitent plus de rounds pour attendre que l'anchor soit trié. Dans des cas courants, les sommets dans les rounds impairs nécessitent trois rounds, tandis que les sommets non ancrés dans les rounds pairs nécessitent quatre rounds.
Question 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 n'est pas assez rapide pour diffuser le point d'ancrage, il n'est pas possible de trier le point d'ancrage ( et donc il est ignoré ), par conséquent tous les sommets non triés des premiers tours 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 Bullshark utilise un délai pour attendre le leader.
Cadre Shoal
Shoal a amélioré Bullshark( ou tout autre protocole BFT basé sur Narwhal) grâce à des pipelines, permettant d'avoir un point d'ancrage à chaque tour et de réduire 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 rend le choix en faveur des leaders rapides.
Défi
Dans le cadre du protocole DAG, les problèmes de pipeline et de réputation des leaders sont considérés comme difficiles pour les raisons suivantes :
Les anciennes chaînes de production ont tenté de modifier la logique de base de Bullshark, mais cela semble fondamentalement impossible.
La réputation des leaders est introduite dans DiemBFT et formalisée dans Carousel, en sélectionnant dynamiquement les futurs leaders selon les performances passées des validateurs dans l'idée de l'ancre 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, ce qui soulève le cœur du problème, à savoir que le choix dynamique et déterministe des ancres de cycle est nécessaire pour résoudre le consensus, et que les validateurs doivent parvenir à un consensus sur l'historique ordonné pour choisir les futures ancres.
En tant que preuve de la difficulté des problèmes, l'implémentation de Bullshark ) n'inclut pas les fonctionnalités actuellement prises en charge dans l'environnement de production (.
![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(
Accord
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 à l'insight fondamental selon lequel 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 commutation des instances, ainsi que ( l'histoire causale des points d'ancrage utilisée pour calculer la réputation des leaders.
Chaîne de montage
Comme Bullshark, les validateurs parviennent a priori à un consensus sur les points d'ancrage potentiels, c'est-à-dire qu'il existe une correspondance connue F : R -\u003e V qui associe les tours aux leaders. Shoal exécute un à un les instances de Bullshark, de sorte que pour chaque instance, l'ancre est préalablement déterminée par la correspondance 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 exécutée 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é 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 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, cet 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.
![Explication détaillée du cadre Shoal : comment réduire la latence de Bullshark sur Aptos ?])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Réputation des leaders
Lors du saut des points d'ancrage pendant le tri des Bullsharks, la latence augmente. Dans ce cas, la technologie de pipeline ne peut rien faire, car il est impossible de démarrer une nouvelle instance avant que le point d'ancrage de l'instance précédente ne soit commandé. Shoal garantit qu'il est peu 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 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 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 les scores, permettant ainsi d'atteindre un consensus sur l'historique utilisé pour dériver les scores.
Dans Shoal, les pipelines et la réputation des leaders 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 le tri des points d'ancrage lors de la r-ème ronde, les validateurs n'ont qu'à calculer un nouveau mappage F' à partir de la r+1-ème ronde en fonction de l'historique causal des points d'ancrage ordonnés de la r-ème ronde. Ensuite, les nœuds de validation commencent à exécuter une nouvelle instance de Bullshark à partir de la r+1-ème ronde en utilisant la fonction de sélection de points d'ancrage mise à jour F'.
![Explication détaillée du cadre Shoal : Comment réduire la latence de Bullshark sur Aptos ?])https://img-cdn.gateio.im/webp-social/moments-1baf540693f376d93cb18ef3193593cc.webp(
Plus de temps d'attente
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'elles introduisent augmente le nombre d'états internes à gérer et à observer, ce qui accroît la complexité du processus de débogage et nécessite davantage de techniques d'observabilité.
Le dépassement de délai augmentera considérablement la latence, car il est très important de les configurer correctement, et cela 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 une pénalité de latence complète pour le leader défaillant. 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. Par exemple, nous observons