Cadre Shoal : comment Goutte la latence de Bullshark sur Aptos
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 pratiques déterministes. Dans l'ensemble, le cadre Shoal a amélioré la latence de Bullshark de 40 % en cas de fonctionnement sans défaut et de 80 % en cas de défaillance.
Shoal est un cadre qui renforce le protocole de consensus basé sur Narwhal ( grâce à une pipeline et à la réputation des leaders, comme DAG-Rider, Tusk, Bullshark ). La pipeline réduit la latence de tri DAG en introduisant un point d'ancrage à chaque tour, tandis que la réputation des leaders améliore encore le problème de latence en s'assurant que les points d'ancrage sont associés aux nœuds de validation les plus rapides. De plus, la réputation des leaders permet à Shoal d'exploiter la construction de DAG asynchrone 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 les réponses optimistes généralement nécessaires.
La technologie de Shoal est très simple, elle consiste à exécuter plusieurs instances du protocole sous-jacent l'une après l'autre. Ainsi, lorsque nous instancions Bullshark, nous obtenons un groupe de "requins" qui participent à une course de relais.
Contexte
Dans la quête de haute performance des réseaux blockchain, l'accent a toujours été mis sur la Goutte de la complexité de communication. Cependant, cette approche n'a pas conduit à une augmentation 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 réalisation que la propagation des données est le principal Goutte du protocole des leaders et qu'elle peut bénéficier de la parallélisation. Le système Narwhal sépare la propagation des données de la logique de consensus centrale, proposant une architecture où tous les validateurs propagent simultanément des données, tandis que le composant de consensus ne trie qu'un nombre réduit 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 leur mise en œuvre Narwhal, séparant la propagation des données du consensus et utilisé pour étendre le protocole de consensus actuel Jolteon. Jolteon est un protocole basé sur un leader, combinant le chemin linéaire rapide de Tendermint et les changements de vue de style PBFT, capable de réduire la latence de Hotstuff de 33 %. Cependant, les protocoles de consensus basés sur un leader ne peuvent pas tirer pleinement parti du potentiel de débit de Narwhal. 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 limité.
Ainsi, Aptos a décidé de déployer Bullshark, un protocole de consensus sans coût de communication, sur le DAG Narwhal. Malheureusement, par rapport à Jolteon, la structure DAG supportant un haut débit pour Bullshark entraîne un coût de latence de 50 %.
Cet article présente comment Shoal réduit 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érant 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 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.
Ordre de séquence
Il est possible d'atteindre un consensus sur l'ordre total de tous les sommets dans le DAG sans coûts de communication supplémentaires. Pour cela, les validateurs de 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 une structure DAG soit différente, tous les protocoles de consensus basés sur Narwhal existants ont la structure suivante :
Point d'ancrage préétabli : après quelques tours, ( comme dans Bullshark, un leader prédéterminé sera désigné tous les deux tours, et 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.
tri de l'historique causale : les validateurs traitent un par un leur liste d'ancrages ordonnée, et pour chaque ancrage, ils trient tous les sommets précédemment désordonnés dans leur historique causale selon certaines règles déterministes.
La clé de la satisfaction des exigences de sécurité est de s'assurer que, dans les étapes ci-dessus )2(, tous les nœuds de validation honnêtes créent une liste d'ancrage ordonnée, afin que toutes les listes partagent le même préfixe. Dans Shoal, les observations suivantes peuvent être faites concernant tous les protocoles mentionnés ci-dessus:
Tous les validateurs conviennent du premier point d'ancrage ordonné.
![Explication détaillée du cadre Shoal : comment réduire la latence de Bullshark sur Aptos ?])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
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 ronde paire a un point d'ancrage, et les sommets de chaque ronde impaire sont interprétés comme un vote. Dans les cas courants, il faut deux rondes de DAG pour trier les points d'ancrage, cependant, les sommets dans l'historique causal de l'anchor nécessitent plus de rondes pour attendre que l'anchor soit trié. Dans les 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.
Question 2 : latence des cas de défaillance, l'analyse de latence ci-dessus s'applique à des situations sans défaillance. D'autre part, si le leader d'un tour échoue à diffuser suffisamment rapidement le point d'ancrage, il ne sera pas possible de trier le point d'ancrage ) et sera donc ignoré (. En conséquence, tous les sommets non triés des tours précédents doivent attendre que le prochain point d'ancrage soit trié. Cela va considérablement Goutte les performances du réseau de réplication géographique, en particulier parce que Bullshark utilise un délai pour attendre le leader.
![Explication détaillée de l'image Shoal : Comment réduire la latence de Bullshark sur Aptos ?])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
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 au 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, 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 montage ont tenté de modifier la logique core de Bullshark, mais cela semble fondamentalement impossible.
La réputation des leaders est introduite dans DiemBFT et officialisée dans Carousel, selon la sélection dynamique des futurs leaders basée sur les performances passées des validateurs dans l'idée des ancres dans Bullshark ). Bien que les divergences sur l'identité des leaders ne compromettent pas la sécurité de ces protocoles, dans Bullshark, cela peut conduire à des ordres totalement différents, ce qui soulève le cœur du problème, à savoir que le choix dynamique et déterministe des ancres cycliques est nécessaire pour résoudre le consensus, et que les validateurs doivent s'accorder sur un historique ordonné pour choisir les futures ancres.
En tant que preuve de la difficulté des problèmes, l'implémentation de Bullshark, y compris celle actuellement en production, ne prend pas en charge ces fonctionnalités.
Accord
Malgré les défis mentionnés ci-dessus, comme le dit le dicton, la solution se cache derrière la simplicité.
Dans Shoal, nous nous appuyons sur la capacité d'effectuer 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 perception 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é le point de basculement des instances, ainsi que ) l'historique causale du point d'ancrage utilisé pour calculer la réputation du leader.
( chaîne de production
V qui associe les tours aux leaders. Shoal exécute une instance de Bullshark l'une après l'autre, de sorte que pour chaque instance, l'ancre est déterminée à l'avance par le mappage F. Chaque instance trie 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 du DAG et l'a exécuté jusqu'à ce que le premier point d'ancrage ordonné soit déterminé, par exemple lors du 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 lors du tour r+1.
Dans le meilleur des cas, cela permet à Shoal de trier un ancre à chaque tour. Le premier point d'ancrage est trié par la première instance. Ensuite, Shoal commence une nouvelle instance au deuxième tour, 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 au troisième tour, et 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-859e732e16c3eee0e2c93422474debc2.webp(
) réputation des leaders
Lorsqu'on saute des points d'ancrage pendant le tri de Bullshark, la latence augmente. Dans ce cas, la technique de pipeline est impuissante car une nouvelle instance ne peut pas être lancée avant le tri du point d'ancrage de l'instance précédente. Shoal s'assure qu'il est moins probable de sélectionner les leaders correspondants pour traiter les points d'ancrage manquants à l'avenir 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 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 le mappage prédéfini F de chaque tour au leader à chaque mise à jour du score, en favorisant les leaders ayant un score plus élevé. Pour que les validateurs parviennent à un consensus sur la nouvelle carte, ils doivent parvenir à un consensus sur le score, afin d'atteindre un consensus sur l'historique utilisé pour dériver le score.
Dans Shoal, la chaîne de processus et la réputation de leadership peuvent se combiner naturellement, car elles utilisent toutes deux la même technologie de base, à savoir la réinterprétation du DAG après avoir atteint un consensus sur le premier point d'ancrage ordonné.
En fait, la seule différence est qu'après avoir trié les points d'ancrage lors de la r-ème ronde, les validateurs n'ont qu'à calculer le nouveau mappage F' à partir de la r+1-ème ronde en se basant sur l'historique causale des points d'ancrage ordonnés de la r-ème ronde. Ensuite, les nœuds de validation commencent à exécuter la nouvelle instance de Bullshark à partir de la r+1-ème ronde en utilisant la fonction de sélection des 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-9f789cb669f6fcc244ea7ff7648e48b4.webp(
) n'a 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 complique le processus de débogage et nécessite davantage de techniques d'observabilité.
Le Timeout peut également augmenter considérablement la latence, car il est très important de les configurer correctement et cela nécessite souvent un ajustement dynamique, car il dépend fortement de l'environnement ### réseau (. Avant de passer au leader suivant, le protocole paiera la pénalité de latence complète pour le leader défaillant. Par conséquent, les paramètres de timeout ne doivent pas être trop conservateurs, mais si le temps de timeout est trop court, le protocole peut
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.
9 J'aime
Récompense
9
7
Partager
Commentaire
0/400
just_here_for_vibes
· 07-27 18:20
Une telle amélioration des performances ? Enroule ça.
Voir l'originalRépondre0
BridgeNomad
· 07-26 20:35
hmm... la latence améliorée a l'air bonne mais il faut encore valider ces vecteurs de confiance pour être honnête
Voir l'originalRépondre0
BearMarketHustler
· 07-26 20:30
Wow, Aptos est vraiment capable !
Voir l'originalRépondre0
Whale_Whisperer
· 07-26 20:28
Cette amélioration est incroyable, stockons d'abord un peu d'apt.
Voir l'originalRépondre0
CryptoMotivator
· 07-26 20:17
Aptos gogo～latence 80% c'est vraiment énorme
Voir l'originalRépondre0
StakeHouseDirector
· 07-26 20:17
pro ah cette optimisation de performance est vraiment incroyable
Voir l'originalRépondre0
Layer2Observer
· 07-26 20:08
latence augmentée de 80%, c'est un peu hardcore. J'attends les données de test.
Le cadre Shoal réduit considérablement la latence Bullshark sur Aptos off-chain.
Cadre Shoal : comment Goutte la latence de Bullshark sur Aptos
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 pratiques déterministes. Dans l'ensemble, le cadre Shoal a amélioré la latence de Bullshark de 40 % en cas de fonctionnement sans défaut et de 80 % en cas de défaillance.
Shoal est un cadre qui renforce le protocole de consensus basé sur Narwhal ( grâce à une pipeline et à la réputation des leaders, comme DAG-Rider, Tusk, Bullshark ). La pipeline réduit la latence de tri DAG en introduisant un point d'ancrage à chaque tour, tandis que la réputation des leaders améliore encore le problème de latence en s'assurant que les points d'ancrage sont associés aux nœuds de validation les plus rapides. De plus, la réputation des leaders permet à Shoal d'exploiter la construction de DAG asynchrone 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 les réponses optimistes généralement nécessaires.
La technologie de Shoal est très simple, elle consiste à exécuter plusieurs instances du protocole sous-jacent l'une après l'autre. Ainsi, lorsque nous instancions Bullshark, nous obtenons un groupe de "requins" qui participent à une course de relais.
Contexte
Dans la quête de haute performance des réseaux blockchain, l'accent a toujours été mis sur la Goutte de la complexité de communication. Cependant, cette approche n'a pas conduit à une augmentation 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 réalisation que la propagation des données est le principal Goutte du protocole des leaders et qu'elle peut bénéficier de la parallélisation. Le système Narwhal sépare la propagation des données de la logique de consensus centrale, proposant une architecture où tous les validateurs propagent simultanément des données, tandis que le composant de consensus ne trie qu'un nombre réduit 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 leur mise en œuvre Narwhal, séparant la propagation des données du consensus et utilisé pour étendre le protocole de consensus actuel Jolteon. Jolteon est un protocole basé sur un leader, combinant le chemin linéaire rapide de Tendermint et les changements de vue de style PBFT, capable de réduire la latence de Hotstuff de 33 %. Cependant, les protocoles de consensus basés sur un leader ne peuvent pas tirer pleinement parti du potentiel de débit de Narwhal. 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 limité.
Ainsi, Aptos a décidé de déployer Bullshark, un protocole de consensus sans coût de communication, sur le DAG Narwhal. Malheureusement, par rapport à Jolteon, la structure DAG supportant un haut débit pour Bullshark entraîne un coût de latence de 50 %.
Cet article présente comment Shoal réduit 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érant 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 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.
Ordre de séquence
Il est possible d'atteindre un consensus sur l'ordre total de tous les sommets dans le DAG sans coûts de communication supplémentaires. Pour cela, les validateurs de 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 une structure DAG soit différente, tous les protocoles de consensus basés sur Narwhal existants ont la structure suivante :
Point d'ancrage préétabli : après quelques tours, ( comme dans Bullshark, un leader prédéterminé sera désigné tous les deux tours, et 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.
tri de l'historique causale : les validateurs traitent un par un leur liste d'ancrages ordonnée, et pour chaque ancrage, ils trient tous les sommets précédemment désordonnés dans leur historique causale selon certaines règles déterministes.
La clé de la satisfaction des exigences de sécurité est de s'assurer que, dans les étapes ci-dessus )2(, tous les nœuds de validation honnêtes créent une liste d'ancrage ordonnée, afin que toutes les listes partagent le même préfixe. Dans Shoal, les observations suivantes peuvent être faites concernant tous les protocoles mentionnés ci-dessus:
Tous les validateurs conviennent du premier point d'ancrage ordonné.
![Explication détaillée du cadre Shoal : comment réduire la latence de Bullshark sur Aptos ?])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
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 ronde paire a un point d'ancrage, et les sommets de chaque ronde impaire sont interprétés comme un vote. Dans les cas courants, il faut deux rondes de DAG pour trier les points d'ancrage, cependant, les sommets dans l'historique causal de l'anchor nécessitent plus de rondes pour attendre que l'anchor soit trié. Dans les 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.
Question 2 : latence des cas de défaillance, l'analyse de latence ci-dessus s'applique à des situations sans défaillance. D'autre part, si le leader d'un tour échoue à diffuser suffisamment rapidement le point d'ancrage, il ne sera pas possible de trier le point d'ancrage ) et sera donc ignoré (. En conséquence, tous les sommets non triés des tours précédents doivent attendre que le prochain point d'ancrage soit trié. Cela va considérablement Goutte les performances du réseau de réplication géographique, en particulier parce que Bullshark utilise un délai pour attendre le leader.
![Explication détaillée de l'image Shoal : Comment réduire la latence de Bullshark sur Aptos ?])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
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 au 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, 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 montage ont tenté de modifier la logique core de Bullshark, mais cela semble fondamentalement impossible.
La réputation des leaders est introduite dans DiemBFT et officialisée dans Carousel, selon la sélection dynamique des futurs leaders basée sur les performances passées des validateurs dans l'idée des ancres dans Bullshark ). Bien que les divergences sur l'identité des leaders ne compromettent pas la sécurité de ces protocoles, dans Bullshark, cela peut conduire à des ordres totalement différents, ce qui soulève le cœur du problème, à savoir que le choix dynamique et déterministe des ancres cycliques est nécessaire pour résoudre le consensus, et que les validateurs doivent s'accorder sur un historique ordonné pour choisir les futures ancres.
En tant que preuve de la difficulté des problèmes, l'implémentation de Bullshark, y compris celle actuellement en production, ne prend pas en charge ces fonctionnalités.
Accord
Malgré les défis mentionnés ci-dessus, comme le dit le dicton, la solution se cache derrière la simplicité.
Dans Shoal, nous nous appuyons sur la capacité d'effectuer 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 perception 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é le point de basculement des instances, ainsi que ) l'historique causale du point d'ancrage utilisé pour calculer la réputation du leader.
( chaîne de production
V qui associe les tours aux leaders. Shoal exécute une instance de Bullshark l'une après l'autre, de sorte que pour chaque instance, l'ancre est déterminée à l'avance par le mappage F. Chaque instance trie 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 du DAG et l'a exécuté jusqu'à ce que le premier point d'ancrage ordonné soit déterminé, par exemple lors du 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 lors du tour r+1.
Dans le meilleur des cas, cela permet à Shoal de trier un ancre à chaque tour. Le premier point d'ancrage est trié par la première instance. Ensuite, Shoal commence une nouvelle instance au deuxième tour, 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 au troisième tour, et 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-859e732e16c3eee0e2c93422474debc2.webp(
) réputation des leaders
Lorsqu'on saute des points d'ancrage pendant le tri de Bullshark, la latence augmente. Dans ce cas, la technique de pipeline est impuissante car une nouvelle instance ne peut pas être lancée avant le tri du point d'ancrage de l'instance précédente. Shoal s'assure qu'il est moins probable de sélectionner les leaders correspondants pour traiter les points d'ancrage manquants à l'avenir 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 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 le mappage prédéfini F de chaque tour au leader à chaque mise à jour du score, en favorisant les leaders ayant un score plus élevé. Pour que les validateurs parviennent à un consensus sur la nouvelle carte, ils doivent parvenir à un consensus sur le score, afin d'atteindre un consensus sur l'historique utilisé pour dériver le score.
Dans Shoal, la chaîne de processus et la réputation de leadership peuvent se combiner naturellement, car elles utilisent toutes deux la même technologie de base, à savoir la réinterprétation du DAG après avoir atteint un consensus sur le premier point d'ancrage ordonné.
En fait, la seule différence est qu'après avoir trié les points d'ancrage lors de la r-ème ronde, les validateurs n'ont qu'à calculer le nouveau mappage F' à partir de la r+1-ème ronde en se basant sur l'historique causale des points d'ancrage ordonnés de la r-ème ronde. Ensuite, les nœuds de validation commencent à exécuter la nouvelle instance de Bullshark à partir de la r+1-ème ronde en utilisant la fonction de sélection des 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-9f789cb669f6fcc244ea7ff7648e48b4.webp(
) n'a 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 complique le processus de débogage et nécessite davantage de techniques d'observabilité.
Le Timeout peut également augmenter considérablement la latence, car il est très important de les configurer correctement et cela nécessite souvent un ajustement dynamique, car il dépend fortement de l'environnement ### réseau (. Avant de passer au leader suivant, le protocole paiera la pénalité de latence complète pour le leader défaillant. Par conséquent, les paramètres de timeout ne doivent pas être trop conservateurs, mais si le temps de timeout est trop court, le protocole peut