Cadre Shoal : une solution innovante pour réduire la latence de Bullshark sur Aptos
Aptos Labs a récemment réalisé des percées majeures dans le domaine du DAG BFT, résolvant deux problèmes clés, réduisant considérablement la latence et éliminant pour la première fois la nécessité de délais dans les protocoles déterministes. Dans l'ensemble, la latence de Bullshark a été améliorée de 40 % en cas de fonctionnement sans faille, et de 80 % en cas de défaillance.
Shoal est un cadre qui améliore tout protocole de consensus basé sur Narwhal ( tel que DAG-Rider, Tusk, Bullshark ) grâce à un traitement en pipeline et à la réputation des leaders. Le traitement en pipeline réduit la latence de tri du DAG en introduisant des points d'ancrage à chaque tour, et la réputation des leaders améliore encore la latence en garantissant 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 d'attente dans tous les scénarios. Cela permet à Shoal d'offrir ce que nous appelons une "réactivité universelle", qui comprend la réactivité optimiste généralement requise.
Notre technologie est très simple, elle consiste essentiellement à exécuter plusieurs instances du protocole sous-jacent en séquence. Ainsi, lors de l'instanciation de Bullshark, nous obtenons un groupe de "requins" qui courent dans une course de relais.
Contexte et motivation
Dans la quête de hautes performances des réseaux blockchain, la réduction de la complexité de communication a toujours été au centre des préoccupations, mais cette approche n'a pas entraîné d'amélioration significative du débit. Par exemple, la version précoce de Diem, qui a mis en œuvre Hotstuff, n'a atteint que 3500 TPS, bien en dessous de l'objectif de 100 000+ TPS.
Les récentes avancées proviennent de la prise de conscience que la propagation des données est le principal goulet d'étranglement basé sur le 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 les données simultanément, les composants de consensus se contentant de trier un petit nombre de métadonnées. Le papier Narwhal rapporte un débit de 160 000 TPS.
Nous avons précédemment présenté Quorum Store, notre mise en œuvre de Narwhal qui sépare la propagation des données du consensus, ainsi que la façon dont nous l'utilisons 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, capable de réduire la latence de Hotstuff de 33 %. Cependant, les protocoles de consensus basés sur un leader ne peuvent manifestement pas exploiter pleinement le potentiel de débit de Narwhal. Bien que la séparation de la propagation des données et du consensus soit effectuée, avec l'augmentation du débit, le leader de Hotstuff/Jolteon reste limité.
Ainsi, nous avons décidé de déployer Bullshark sur Narwhal DAG, un protocole de consensus sans frais de communication. Malheureusement, la structure DAG qui supporte le haut débit de Bullshark entraîne un coût de latence de 50 % par rapport à Jolteon.
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 du tour r-1. Chaque valideur 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 des vues locales différentes du DAG à tout moment.
Une propriété 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.
Ordre général
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 ont la structure suivante :
Point d'ancrage prévu : toutes les quelques rondes (, comme dans Bullshark, il y aura un leader prédéterminé, dont le sommet 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.
Histoire causale ordonnée : les validateurs traitent un par un la liste des points d'ancrage ordonnée, pour chaque point d'ancrage, ils trient tous les sommets précédemment non ordonnés dans son histoire causale selon certaines règles déterministes.
La clé pour garantir la sécurité est de s'assurer que dans l'étape )2(, toutes les listes d'ancrage ordonnées créées par les nœuds de validation honnêtes partagent le même préfixe. Dans Shoal, nous faisons les observations suivantes sur tous les protocoles mentionnés ci-dessus:
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 synchronisée de Bullshark soit plus pratique et présente 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 chaque sommet du tour impair est interprété comme un vote. Dans les cas courants, deux tours de DAG sont nécessaires pour trier les points d'ancrage, cependant, les sommets de l'histoire causale des points d'ancrage nécessitent plus de tours pour attendre que les points d'ancrage soient triés. Dans les cas courants, les sommets du tour impair nécessitent trois tours, tandis que les sommets non ancrés du tour pair nécessitent quatre tours.
Problème 2 : latence des cas de panne. L'analyse de latence ci-dessus s'applique aux situations sans pannes, d'autre part, si le leader d'un tour ne parvient pas à diffuser les points d'ancrage suffisamment rapidement, il n'est pas possible de trier les points d'ancrage ), ils sont donc sautés (, par conséquent, 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, surtout parce que Bullshark utilise des délais pour attendre le leader.
![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(
Cadre Shoal
Shoal a amélioré 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 de réduire la latence de tous les sommets non ancrés dans le DAG à trois tours. Shoal a également introduit dans le DAG un mécanisme de réputation de leader sans coût, ce qui favorise le choix vers 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 précédentes de modifier la logique principale de Bullshark dans la chaîne de production semblaient en effet impossibles.
La réputation des leaders est introduite dans DiemBFT et formalisée dans Carousel, basée sur la sélection dynamique des futurs leaders en fonction des performances passées des validateurs, l'idée étant d'ancrer dans Bullshark ). Bien que des divergences sur l'identité des leaders ne violent pas la sécurité de ces protocoles, dans Bullshark, cela peut entraîner un classement complètement différent, soulevant 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, nous notons que l'implémentation de Bullshark, y compris celle actuellement en environnement de production, ne prend pas en charge ces fonctionnalités.
Accord
Malgré les défis mentionnés ci-dessus, 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 nous avons réalisé la capacité de sauvegarder et de réinterpréter les informations des tours précédents. Grâce à la compréhension fondamentale que 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, de sorte que ( le premier point d'ancrage ordonné soit le point de basculement des instances, et que ) l'histoire causale des points d'ancrage soit utilisée pour calculer la réputation des leaders.
( traitement en flux
V qui associe les tours aux leaders. Shoal exécute les instances de Bullshark une par une, de sorte que pour chaque instance, l'ancre est prédéterminée par le mapping F. Chaque instance ordonne une ancre, ce qui déclenche le passage à l'instance suivante.
Au départ, Shoal a lancé le premier instance de Bullshark lors du premier tour de DAG et l'a fait fonctionner jusqu'à ce que le premier point d'ancrage ordonné soit déterminé, par exemple au tour r. Tous les validateurs ont convenu de ce point d'ancrage. Par conséquent, tous les validateurs peuvent déterminer avec certitude qu'ils peuvent 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. 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 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-0b0928cb6240e994c1514c75e080a4b2.webp(
) réputation des leaders
Lors du saut d'un point d'ancrage pendant le tri de Bullshark, la latence augmente. Dans ce cas, la technique de traitement en pipeline est impuissante, car il n'est pas possible de démarrer une nouvelle instance avant que le point d'ancrage de l'instance précédente ne soit trié. Shoal s'assure qu'il est peu probable que les leaders correspondants soient sélectionnés à 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 obtiendront un score élevé, sinon, les nœuds de validation se verront attribuer un score bas, car ils pourraient échouer, être lents ou malveillants.
L'idée est de recalculer de manière déterministe le mappage prédefini F de chaque tour au leader lors de 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 s'accorder sur les scores, atteignant ainsi un consensus sur l'historique utilisé pour dériver les scores.
Dans Shoal, le traitement en pipeline 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 de la rème ronde, les validateurs n'ont qu'à calculer un nouveau mappage F' à partir de la r+1ère ronde en fonction de l'historique causal des points d'ancrage ordonnés de la rème ronde. Ensuite, les nœuds de validation exécutent une nouvelle instance de Bullshark à partir de la r+1ère ronde en utilisant la fonction de sélection de points d'ancrage mise à jour F'.
![Détails complets sur le cadre Shoal : comment réduire la latence de Bullshark sur Aptos ?]###https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
) n'a plus de latence
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 dépassement de délai augmentera également significativement la latence, car il est très important de les configurer correctement et qu'elles nécessitent souvent un ajustement dynamique, car cela dépend fortement de l'environnement ### réseau (. Avant de passer au prochain leader, le protocole paie une pénalité complète de délai pour le leader défaillant. Par conséquent, les paramètres de délai ne peuvent pas être trop conservateurs, mais si le temps de dépassement est trop court, le protocole pourrait sauter de bons leaders. Par exemple, nous avons observé que, dans des conditions de forte charge, les leaders dans Jolteon/Hotstuff étaient débordés et que le délai avait expiré avant qu'ils n'avancent.
Malheureusement, les protocoles de leader ) tels que Hotstuff et Jolteon### nécessitent essentiellement une latence, afin de garantir qu'à chaque fois qu'un leader échoue
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.
13 J'aime
Récompense
13
6
Reposter
Partager
Commentaire
0/400
SandwichDetector
· Il y a 14h
La performance est vraiment bull, une augmentation de 80% c'est incroyable.
Voir l'originalRépondre0
NFTRegretful
· Il y a 14h
Ça a l'air correct, mais la vitesse n'est pas encore assez rapide.
Voir l'originalRépondre0
BearMarketSurvivor
· Il y a 15h
latence Goutte 80% Cela représente une véritable force sur le champ de bataille, j'attends avec impatience la performance en situation réelle.
Voir l'originalRépondre0
CoinBasedThinking
· Il y a 15h
Un projet fiable de mise à niveau technologique. J'espère qu'il ne se terminera pas en eau de boudin.
Voir l'originalRépondre0
MeaninglessGwei
· Il y a 15h
latence réduite de 80 % ? Aptos est vraiment bull.
Le cadre Shoal améliore l'efficacité du consensus Aptos et réduit la latence de Bullshark de 80 %.
Cadre Shoal : une solution innovante pour réduire la latence de Bullshark sur Aptos
Aptos Labs a récemment réalisé des percées majeures dans le domaine du DAG BFT, résolvant deux problèmes clés, réduisant considérablement la latence et éliminant pour la première fois la nécessité de délais dans les protocoles déterministes. Dans l'ensemble, la latence de Bullshark a été améliorée de 40 % en cas de fonctionnement sans faille, et de 80 % en cas de défaillance.
Shoal est un cadre qui améliore tout protocole de consensus basé sur Narwhal ( tel que DAG-Rider, Tusk, Bullshark ) grâce à un traitement en pipeline et à la réputation des leaders. Le traitement en pipeline réduit la latence de tri du DAG en introduisant des points d'ancrage à chaque tour, et la réputation des leaders améliore encore la latence en garantissant 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 d'attente dans tous les scénarios. Cela permet à Shoal d'offrir ce que nous appelons une "réactivité universelle", qui comprend la réactivité optimiste généralement requise.
Notre technologie est très simple, elle consiste essentiellement à exécuter plusieurs instances du protocole sous-jacent en séquence. Ainsi, lors de l'instanciation de Bullshark, nous obtenons un groupe de "requins" qui courent dans une course de relais.
Contexte et motivation
Dans la quête de hautes performances des réseaux blockchain, la réduction de la complexité de communication a toujours été au centre des préoccupations, mais cette approche n'a pas entraîné d'amélioration significative du débit. Par exemple, la version précoce de Diem, qui a mis en œuvre Hotstuff, n'a atteint que 3500 TPS, bien en dessous de l'objectif de 100 000+ TPS.
Les récentes avancées proviennent de la prise de conscience que la propagation des données est le principal goulet d'étranglement basé sur le 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 les données simultanément, les composants de consensus se contentant de trier un petit nombre de métadonnées. Le papier Narwhal rapporte un débit de 160 000 TPS.
Nous avons précédemment présenté Quorum Store, notre mise en œuvre de Narwhal qui sépare la propagation des données du consensus, ainsi que la façon dont nous l'utilisons 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, capable de réduire la latence de Hotstuff de 33 %. Cependant, les protocoles de consensus basés sur un leader ne peuvent manifestement pas exploiter pleinement le potentiel de débit de Narwhal. Bien que la séparation de la propagation des données et du consensus soit effectuée, avec l'augmentation du débit, le leader de Hotstuff/Jolteon reste limité.
Ainsi, nous avons décidé de déployer Bullshark sur Narwhal DAG, un protocole de consensus sans frais de communication. Malheureusement, la structure DAG qui supporte le haut débit de Bullshark entraîne un coût de latence de 50 % par rapport à Jolteon.
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 du tour r-1. Chaque valideur 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 des vues locales différentes du DAG à tout moment.
Une propriété 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.
Ordre général
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 ont la structure suivante :
Point d'ancrage prévu : toutes les quelques rondes (, comme dans Bullshark, il y aura un leader prédéterminé, dont le sommet 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.
Histoire causale ordonnée : les validateurs traitent un par un la liste des points d'ancrage ordonnée, pour chaque point d'ancrage, ils trient tous les sommets précédemment non ordonnés dans son histoire causale selon certaines règles déterministes.
La clé pour garantir la sécurité est de s'assurer que dans l'étape )2(, toutes les listes d'ancrage ordonnées créées par les nœuds de validation honnêtes partagent le même préfixe. Dans Shoal, nous faisons les observations suivantes sur tous les protocoles mentionnés ci-dessus:
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 synchronisée de Bullshark soit plus pratique et présente 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 chaque sommet du tour impair est interprété comme un vote. Dans les cas courants, deux tours de DAG sont nécessaires pour trier les points d'ancrage, cependant, les sommets de l'histoire causale des points d'ancrage nécessitent plus de tours pour attendre que les points d'ancrage soient triés. Dans les cas courants, les sommets du tour impair nécessitent trois tours, tandis que les sommets non ancrés du tour pair nécessitent quatre tours.
Problème 2 : latence des cas de panne. L'analyse de latence ci-dessus s'applique aux situations sans pannes, d'autre part, si le leader d'un tour ne parvient pas à diffuser les points d'ancrage suffisamment rapidement, il n'est pas possible de trier les points d'ancrage ), ils sont donc sautés (, par conséquent, 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, surtout parce que Bullshark utilise des délais pour attendre le leader.
![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(
Cadre Shoal
Shoal a amélioré 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 de réduire la latence de tous les sommets non ancrés dans le DAG à trois tours. Shoal a également introduit dans le DAG un mécanisme de réputation de leader sans coût, ce qui favorise le choix vers 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 précédentes de modifier la logique principale de Bullshark dans la chaîne de production semblaient en effet impossibles.
La réputation des leaders est introduite dans DiemBFT et formalisée dans Carousel, basée sur la sélection dynamique des futurs leaders en fonction des performances passées des validateurs, l'idée étant d'ancrer dans Bullshark ). Bien que des divergences sur l'identité des leaders ne violent pas la sécurité de ces protocoles, dans Bullshark, cela peut entraîner un classement complètement différent, soulevant 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, nous notons que l'implémentation de Bullshark, y compris celle actuellement en environnement de production, ne prend pas en charge ces fonctionnalités.
Accord
Malgré les défis mentionnés ci-dessus, 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 nous avons réalisé la capacité de sauvegarder et de réinterpréter les informations des tours précédents. Grâce à la compréhension fondamentale que 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, de sorte que ( le premier point d'ancrage ordonné soit le point de basculement des instances, et que ) l'histoire causale des points d'ancrage soit utilisée pour calculer la réputation des leaders.
( traitement en flux
V qui associe les tours aux leaders. Shoal exécute les instances de Bullshark une par une, de sorte que pour chaque instance, l'ancre est prédéterminée par le mapping F. Chaque instance ordonne une ancre, ce qui déclenche le passage à l'instance suivante.
Au départ, Shoal a lancé le premier instance de Bullshark lors du premier tour de DAG et l'a fait fonctionner jusqu'à ce que le premier point d'ancrage ordonné soit déterminé, par exemple au tour r. Tous les validateurs ont convenu de ce point d'ancrage. Par conséquent, tous les validateurs peuvent déterminer avec certitude qu'ils peuvent 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. 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 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-0b0928cb6240e994c1514c75e080a4b2.webp(
) réputation des leaders
Lors du saut d'un point d'ancrage pendant le tri de Bullshark, la latence augmente. Dans ce cas, la technique de traitement en pipeline est impuissante, car il n'est pas possible de démarrer une nouvelle instance avant que le point d'ancrage de l'instance précédente ne soit trié. Shoal s'assure qu'il est peu probable que les leaders correspondants soient sélectionnés à 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 obtiendront un score élevé, sinon, les nœuds de validation se verront attribuer un score bas, car ils pourraient échouer, être lents ou malveillants.
L'idée est de recalculer de manière déterministe le mappage prédefini F de chaque tour au leader lors de 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 s'accorder sur les scores, atteignant ainsi un consensus sur l'historique utilisé pour dériver les scores.
Dans Shoal, le traitement en pipeline 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 de la rème ronde, les validateurs n'ont qu'à calculer un nouveau mappage F' à partir de la r+1ère ronde en fonction de l'historique causal des points d'ancrage ordonnés de la rème ronde. Ensuite, les nœuds de validation exécutent une nouvelle instance de Bullshark à partir de la r+1ère ronde en utilisant la fonction de sélection de points d'ancrage mise à jour F'.
![Détails complets sur le cadre Shoal : comment réduire la latence de Bullshark sur Aptos ?]###https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
) n'a plus de latence
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 dépassement de délai augmentera également significativement la latence, car il est très important de les configurer correctement et qu'elles nécessitent souvent un ajustement dynamique, car cela dépend fortement de l'environnement ### réseau (. Avant de passer au prochain leader, le protocole paie une pénalité complète de délai pour le leader défaillant. Par conséquent, les paramètres de délai ne peuvent pas être trop conservateurs, mais si le temps de dépassement est trop court, le protocole pourrait sauter de bons leaders. Par exemple, nous avons observé que, dans des conditions de forte charge, les leaders dans Jolteon/Hotstuff étaient débordés et que le délai avait expiré avant qu'ils n'avancent.
Malheureusement, les protocoles de leader ) tels que Hotstuff et Jolteon### nécessitent essentiellement une latence, afin de garantir qu'à chaque fois qu'un leader échoue