Cadre Shoal : réduction significative de la latence de 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 a éliminé pour la première fois le besoin de délais dans les protocoles pratiques déterministes. Dans l'ensemble, en cas de fonctionnement normal, la latence de Bullshark a été améliorée de 40 %, et en cas de défaillance, elle a été améliorée de 80 %.
Shoal est un cadre qui renforce le protocole de consensus basé sur Narwhal ( grâce à un mécanisme de pipeline et de réputation des leaders, comme DAG-Rider, Tusk, Bullshark ). 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 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 des propriétés de réponse universelle, incluant ce qui est généralement nécessaire pour une réponse optimiste.
Cette technologie est très simple, impliquant l'exécution séquentielle de plusieurs instances du protocole sous-jacent. Ainsi, lorsque nous instancions Bullshark, nous obtenons un groupe de "requins" participant à une course de relais.
Contexte
Dans la quête de haute performance des réseaux blockchain, les gens se sont toujours concentrés sur la réduction de la complexité de communication. Cependant, cette approche n'a pas entraîné d'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 deçà de l'objectif de 100 000+ TPS.
Les récentes percées proviennent 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 sépare la propagation des données de la logique de consensus centrale, proposant une architecture où tous les validateurs propagent simultanément les données, tandis que le composant de consensus ne trie qu'un petit nombre de métadonnées. Le document Narwhal rapporte un débit de 160 000 TPS.
Nous avons précédemment présenté Quorum Store, qui est notre implémentation de Narwhal séparant la propagation 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 un 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 propagation des données soit séparée du consensus, l'augmentation du débit limite toujours le leader de Hotstuff/Jolteon.
Ainsi, nous avons 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 prenant en charge le haut débit de Bullshark a entraîné 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, 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 qu'elle n'est pas floue : 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 totalement 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 ce faire, les validateurs dans DAG-Rider, Tusk et Bullshark interprètent la structure du DAG comme un protocole de consensus, où les sommets représentent des propositions et les arêtes représentent des votes.
Bien que la logique d'intersection des groupes sur la structure DAG soit différente, tous les protocoles de consensus basés sur Narwhal existants possèdent la structure suivante :
Point d'ancrage prévu : tous les quelques tours (, comme dans Bullshark où tous les 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 trier et quels points d'ancrage sauter.
Historique des causes ordonnées : 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 son historique des causes selon certaines règles déterministes.
La clé pour garantir la sécurité est de s'assurer qu'à l'étape (2), toutes les listes d'ancrage ordonnées créées par des nœuds de validation honnêtes partagent le même préfixe. Dans Shoal, nous faisons les observations suivantes sur tous ces protocoles:
Tous les validateurs acceptent le premier point d'ancrage ordonné.
Bullshark latence
La latence de Bullshark dépend du nombre de tours entre les points d'ancrage ordonnés dans le DAG. Bien que la version synchronisée de Bullshark soit plus pratique et offre une meilleure latence que la version asynchrone, elle est loin d'être optimale.
Question 1 : latence moyenne des blocs. Dans Bullshark, chaque tour pair a un point d'ancrage, et les sommets des tours impairs sont interprétés comme des votes. Dans les cas courants, deux tours de DAG sont nécessaires pour trier les points d'ancrage, cependant, les sommets dans l'historique causal des points d'ancrage nécessitent plus de tours d'attente pour que les points d'ancrage soient triés. Dans les cas courants, 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 de dysfonctionnement. L'analyse de latence ci-dessus s'applique en cas de fonctionnement normal, d'autre part, si le leader d'un tour ne parvient pas à diffuser suffisamment rapidement le point d'ancrage, il ne sera pas possible de trier ce point d'ancrage (, donc il sera ignoré ), de sorte que 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 les performances du réseau de réplication géographique, d'autant plus que Bullshark utilise des délais pour attendre le leader.
Cadre Shoal
Shoal a résolu ces deux problèmes de latence, il a renforcé Bullshark( ou tout autre protocole BFT basé sur Narwhal) par le biais de pipelines, permettant 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 des leaders sans coût dans le DAG, ce qui favorise le choix des leaders rapides.
Défi
Dans le contexte du protocole DAG, le pipeline et la réputation des leaders sont considérés comme des problèmes difficiles, pour les raisons suivantes :
Les tentatives précédentes de la chaîne de production visaient à modifier la logique core de Bullshark, mais cela semble fondamentalement impossible.
La réputation des leaders est introduite dans DiemBFT et formalisée dans Carousel, ce qui permet de sélectionner dynamiquement les futurs leaders dans (Bullshark en fonction des performances passées des validateurs. Bien que des divergences sur l'identité des leaders ne compromettent pas la sécurité de ces protocoles, dans Bullshark, cela peut conduire à un ordre totalement 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 les validateurs doivent parvenir à un accord sur l'historique ordonné pour sélectionner les futures ancres.
En tant qu'élément de preuve de la difficulté des problèmes, nous avons remarqué que la mise en œuvre de Bullshark, y compris celle actuellement en production, ne prend pas en charge ces fonctionnalités.
![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
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 préserver et de réinterpréter les informations des précédents tours. Grâce à la compréhension fondamentale selon laquelle tous les validateurs s'accordent sur le premier point d'ancrage ordonné, Shoal combine en séquence plusieurs instances de Bullshark pour les traiter en pipeline, rendant ainsi ) le premier point d'ancrage ordonné comme point de basculement des instances, et ( l'historique causale du point d'ancrage utilisé pour calculer la réputation des leaders.
Chaîne de production
V qui mappe les tours aux leaders. Shoal exécute un instance de Bullshark à la fois, de sorte que pour chaque instance, l'ancre est prédéterminée par la correspondance F. Chaque instance trie une ancre, ce qui déclenche le passage à l'instance suivante.
Au début, Shoal a lancé la première instance de Bullshark lors du premier tour de 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 trier un ancrage à chaque tour. Le point d'ancrage du premier tour est trié par la première instance. Ensuite, Shoal commence une nouvelle instance au début du deuxième tour, qui a elle-même un point d'ancrage, cet ancrage étant trié par cette instance, puis une autre nouvelle instance trie le point d'ancrage au troisième tour, 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 de Bullshark, la latence augmente. Dans ce cas, la technologie de pipeline est inefficace, car une nouvelle instance ne peut pas être lancée avant le tri du point d'ancrage de l'instance précédente. Shoal garantit qu'il est peu probable que les leaders correspondants soient choisis à 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 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 de chaque tour au leader lors de chaque mise à jour de score, en faveur des leaders ayant un score plus élevé. Afin que les validateurs parviennent à un consensus sur le nouveau mappage, ils doivent s'accorder sur le score, atteignant ainsi un consensus sur l'historique utilisé pour dériver le score.
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 avoir trié les points d'ancrage lors du tour r, le validateur doit simplement calculer une nouvelle fonction de correspondance F' à partir du tour r+1 en fonction de l'historique causal des points d'ancrage ordonnés au tour r. 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 du tour r+1.
![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 délais
Le délai joue un rôle crucial dans toutes les mises en œuvre BFT déterministes basées sur un leader. Cependant, la complexité qu'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 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 leader suivant, le protocole paiera la pénalité complète du délai d'expiration pour le leader défaillant.
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.
12 J'aime
Récompense
12
6
Partager
Commentaire
0/400
CryptoSurvivor
· Il y a 17h
Bull ! Cette mise à niveau a accéléré Aptos.
Voir l'originalRépondre0
SelfSovereignSteve
· Il y a 17h
Cette mise à jour est bull, une augmentation de 40 % c'est trop fort.
Voir l'originalRépondre0
GasFeeCrier
· Il y a 17h
Steam Sanda, le problème de latence est maintenant stabilisé.
Voir l'originalRépondre0
MissedTheBoat
· Il y a 18h
Trading des cryptomonnaies pigeons a enfin généré des bénéfices.
Voir l'originalRépondre0
Tians
· Il y a 18h
ferme HODL💎
Voir l'originalRépondre0
SneakyFlashloan
· Il y a 18h
incroyable latence directement réduit de plus de la moitié
Le cadre Shoal réduit considérablement la latence de Bullshark sur la Blockchain Aptos.
Cadre Shoal : réduction significative de la latence de 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 a éliminé pour la première fois le besoin de délais dans les protocoles pratiques déterministes. Dans l'ensemble, en cas de fonctionnement normal, la latence de Bullshark a été améliorée de 40 %, et en cas de défaillance, elle a été améliorée de 80 %.
Shoal est un cadre qui renforce le protocole de consensus basé sur Narwhal ( grâce à un mécanisme de pipeline et de réputation des leaders, comme DAG-Rider, Tusk, Bullshark ). 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 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 des propriétés de réponse universelle, incluant ce qui est généralement nécessaire pour une réponse optimiste.
Cette technologie est très simple, impliquant l'exécution séquentielle de plusieurs instances du protocole sous-jacent. Ainsi, lorsque nous instancions Bullshark, nous obtenons un groupe de "requins" participant à une course de relais.
Contexte
Dans la quête de haute performance des réseaux blockchain, les gens se sont toujours concentrés sur la réduction de la complexité de communication. Cependant, cette approche n'a pas entraîné d'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 deçà de l'objectif de 100 000+ TPS.
Les récentes percées proviennent 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 sépare la propagation des données de la logique de consensus centrale, proposant une architecture où tous les validateurs propagent simultanément les données, tandis que le composant de consensus ne trie qu'un petit nombre de métadonnées. Le document Narwhal rapporte un débit de 160 000 TPS.
Nous avons précédemment présenté Quorum Store, qui est notre implémentation de Narwhal séparant la propagation 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 un 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 propagation des données soit séparée du consensus, l'augmentation du débit limite toujours le leader de Hotstuff/Jolteon.
Ainsi, nous avons 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 prenant en charge le haut débit de Bullshark a entraîné 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, 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 qu'elle n'est pas floue : 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 totalement 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 ce faire, les validateurs dans DAG-Rider, Tusk et Bullshark interprètent la structure du DAG comme un protocole de consensus, où les sommets représentent des propositions et les arêtes représentent des votes.
Bien que la logique d'intersection des groupes sur la structure DAG soit différente, tous les protocoles de consensus basés sur Narwhal existants possèdent la structure suivante :
Point d'ancrage prévu : tous les quelques tours (, comme dans Bullshark où tous les 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 trier et quels points d'ancrage sauter.
Historique des causes ordonnées : 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 son historique des causes selon certaines règles déterministes.
La clé pour garantir la sécurité est de s'assurer qu'à l'étape (2), toutes les listes d'ancrage ordonnées créées par des nœuds de validation honnêtes partagent le même préfixe. Dans Shoal, nous faisons les observations suivantes sur tous ces protocoles:
Tous les validateurs acceptent le premier point d'ancrage ordonné.
Bullshark latence
La latence de Bullshark dépend du nombre de tours entre les points d'ancrage ordonnés dans le DAG. Bien que la version synchronisée de Bullshark soit plus pratique et offre une meilleure latence que la version asynchrone, elle est loin d'être optimale.
Question 1 : latence moyenne des blocs. Dans Bullshark, chaque tour pair a un point d'ancrage, et les sommets des tours impairs sont interprétés comme des votes. Dans les cas courants, deux tours de DAG sont nécessaires pour trier les points d'ancrage, cependant, les sommets dans l'historique causal des points d'ancrage nécessitent plus de tours d'attente pour que les points d'ancrage soient triés. Dans les cas courants, 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 de dysfonctionnement. L'analyse de latence ci-dessus s'applique en cas de fonctionnement normal, d'autre part, si le leader d'un tour ne parvient pas à diffuser suffisamment rapidement le point d'ancrage, il ne sera pas possible de trier ce point d'ancrage (, donc il sera ignoré ), de sorte que 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 les performances du réseau de réplication géographique, d'autant plus que Bullshark utilise des délais pour attendre le leader.
Cadre Shoal
Shoal a résolu ces deux problèmes de latence, il a renforcé Bullshark( ou tout autre protocole BFT basé sur Narwhal) par le biais de pipelines, permettant 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 des leaders sans coût dans le DAG, ce qui favorise le choix des leaders rapides.
Défi
Dans le contexte du protocole DAG, le pipeline et la réputation des leaders sont considérés comme des problèmes difficiles, pour les raisons suivantes :
Les tentatives précédentes de la chaîne de production visaient à modifier la logique core de Bullshark, mais cela semble fondamentalement impossible.
La réputation des leaders est introduite dans DiemBFT et formalisée dans Carousel, ce qui permet de sélectionner dynamiquement les futurs leaders dans (Bullshark en fonction des performances passées des validateurs. Bien que des divergences sur l'identité des leaders ne compromettent pas la sécurité de ces protocoles, dans Bullshark, cela peut conduire à un ordre totalement 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 les validateurs doivent parvenir à un accord sur l'historique ordonné pour sélectionner les futures ancres.
En tant qu'élément de preuve de la difficulté des problèmes, nous avons remarqué que la mise en œuvre de Bullshark, y compris celle actuellement en production, ne prend pas en charge ces fonctionnalités.
![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
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 préserver et de réinterpréter les informations des précédents tours. Grâce à la compréhension fondamentale selon laquelle tous les validateurs s'accordent sur le premier point d'ancrage ordonné, Shoal combine en séquence plusieurs instances de Bullshark pour les traiter en pipeline, rendant ainsi ) le premier point d'ancrage ordonné comme point de basculement des instances, et ( l'historique causale du point d'ancrage utilisé pour calculer la réputation des leaders.
Chaîne de production
V qui mappe les tours aux leaders. Shoal exécute un instance de Bullshark à la fois, de sorte que pour chaque instance, l'ancre est prédéterminée par la correspondance F. Chaque instance trie une ancre, ce qui déclenche le passage à l'instance suivante.
Au début, Shoal a lancé la première instance de Bullshark lors du premier tour de 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 trier un ancrage à chaque tour. Le point d'ancrage du premier tour est trié par la première instance. Ensuite, Shoal commence une nouvelle instance au début du deuxième tour, qui a elle-même un point d'ancrage, cet ancrage étant trié par cette instance, puis une autre nouvelle instance trie le point d'ancrage au troisième tour, 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 de Bullshark, la latence augmente. Dans ce cas, la technologie de pipeline est inefficace, car une nouvelle instance ne peut pas être lancée avant le tri du point d'ancrage de l'instance précédente. Shoal garantit qu'il est peu probable que les leaders correspondants soient choisis à 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 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 de chaque tour au leader lors de chaque mise à jour de score, en faveur des leaders ayant un score plus élevé. Afin que les validateurs parviennent à un consensus sur le nouveau mappage, ils doivent s'accorder sur le score, atteignant ainsi un consensus sur l'historique utilisé pour dériver le score.
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 avoir trié les points d'ancrage lors du tour r, le validateur doit simplement calculer une nouvelle fonction de correspondance F' à partir du tour r+1 en fonction de l'historique causal des points d'ancrage ordonnés au tour r. 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 du tour r+1.
![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 délais
Le délai joue un rôle crucial dans toutes les mises en œuvre BFT déterministes basées sur un leader. Cependant, la complexité qu'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 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 leader suivant, le protocole paiera la pénalité complète du délai d'expiration pour le leader défaillant.