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 pauses dans le protocole pratique déterministe. En général, dans des conditions sans défaillance, la latence de Bullshark a été améliorée de 40 %, et dans des conditions de défaillance, elle a été améliorée de 80 %.
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 un mécanisme de réputation des leaders. Le pipeline réduit la latence de tri DAG en introduisant un point d'ancrage à chaque tour, et la réputation des leaders améliore encore le problème de latence en s'assurant que le point d'ancrage est associé aux nœuds de validation les plus rapides. De plus, la réputation des leaders permet à Shoal d'exploiter la construction DAG asynchrone pour éliminer les délais dans tous les scénarios. Cela permet à Shoal d'offrir ce que nous appelons une propriété de réponse universelle, qui comprend généralement des réponses optimistes.
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.
Motivation
Dans la quête de haute performance des réseaux blockchain, l'accent a toujours été mis sur la réduction de la complexité des communications. Cependant, cette approche 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 deçà de l'objectif de 100k+ TPS.
La récente percée provient de la prise de conscience que la propagation des données est le principal goulot d'étranglement basé sur le protocole des leaders, pouvant bénéficier de la parallélisation. Le système Narwhal dissocie la propagation des données de la logique de consensus centrale, proposant une architecture dans laquelle tous les validateurs propagent les données simultanément, tandis que le composant de consensus ne commande qu'une petite quantité de métadonnées. Le document de Narwhal a rapporté un débit de 160 000 TPS.
Le Quorum Store, présenté précédemment, est une implémentation de Narwhal qui sépare la diffusion des données du consensus, utilisé pour étendre le protocole de consensus actuel, Jolteon. Jolteon est un protocole basé sur un leader qui combine le chemin rapide linéaire de Tendermint et le changement de vue de style PBFT, permettant de réduire le délai 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 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 sur Narwhal DAG, qui est un protocole de consensus sans coût de communication. Malheureusement, par rapport à Jolteon, la structure DAG soutenant Bullshark à haut débit 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 acquérir 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 différentes vues locales du DAG à tout moment.
Une caractéristique clé du DAG est qu'elle 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 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 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 de l'intersection des groupes dans une structure DAG soit différente, tous les protocoles de consensus basés sur Narwhal existants ont la structure suivante :
Point d'ancrage prévu : tous les quelques tours, un leader prédéterminé sera désigné, 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 commander et lesquels sauter ;
Historique causal ordonné : les validateurs traitent un par un la liste des points d'ancrage ordonnés, triant tous les sommets précédemment non ordonnés dans l'historique causal de chaque point d'ancrage.
La clé pour satisfaire 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 les protocoles ci-dessus:
Tous les validateurs conviennent du premier point d'ancrage ordonné.
Bullshark retard
Le délai 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 un meilleur délai que la version asynchrone, elle reste loin d'être optimale.
Question 1 : Délai moyen de bloc. Dans Bullshark, chaque tour pair a un point d'ancrage, et chaque sommet du tour impair est interprété comme un vote. Dans des cas courants, deux tours de DAG sont nécessaires pour commander les points d'ancrage, cependant, les sommets dans l'histoire causale des points d'ancrage nécessitent plus de tours pour attendre que les points d'ancrage soient triés. Dans des 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 : Retard dans les cas de défaillance. L'analyse des retards ci-dessus s'applique aux situations sans défaillance, d'autre part, si le leader d'un tour ne parvient pas à diffuser suffisamment rapidement le point d'ancrage, il est impossible de trier le point d'ancrage ( et donc il est sauté ), ce qui signifie que tous les sommets non triés des tours précédents 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, en particulier parce que Bullshark utilise un délai d'attente pour attendre le leader.
Cadre Shoal
Shoal a amélioré le Bullshark( ou tout autre protocole BFT basé sur Narwhal) grâce à un traitement en pipeline, permettant d'avoir un point d'ancrage à chaque tour et de réduire le délai 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 de leaders rapides.
Défi
Dans le cadre du protocole DAG, le traitement en pipeline et la réputation des leaders sont considérés comme des problèmes difficiles, pour les raisons suivantes :
Les tentatives de traitement en flux précédentes de modifier la logique fondamentale de Bullshark semblent fondamentalement impossibles.
La réputation des leaders est introduite dans DiemBFT et officialisée dans Carousel, selon l'idée de sélectionner dynamiquement les futurs leaders basés sur les performances passées des validateurs dans (Bullshark et l'ancre dans ). Bien qu'il n'y ait pas de violation de la sécurité de ces protocoles en cas de désaccord sur l'identité des leaders, dans Bullshark, cela peut conduire à des ordres complètement différents, 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 sélectionner les futures ancres.
En tant qu'évidence de la difficulté des problèmes, nous notons que 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, 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 conserver et de réinterpréter les informations des tours précédents. Grâce à la compréhension centrale selon laquelle tous les validateurs s'accordent sur le premier point d'ancrage ordonné, Shoal combine de manière séquentielle plusieurs instances de Bullshark pour les traiter en pipeline, ce qui fait que ( le premier point d'ancrage ordonné est le point de basculement des instances, ainsi que ) l'historique causal des points d'ancrage pour le calcul de la réputation des leaders.
Traitement en chaîne
V qui fait correspondre 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 le mappage 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 de DAG et l'a fait fonctionner jusqu'à ce que le premier point d'ancrage ordonné soit déterminé, par exemple au tour r. Tous les validateurs ont convenu de ce point d'ancrage. Par conséquent, tous les validateurs peuvent convenir de manière 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 du premier tour sont triés par le premier exemple. Ensuite, Shoal commence un nouvel exemple au début du deuxième tour, qui a lui-même un point d'ancrage, cet ancrage étant trié par cet exemple, puis un autre nouvel exemple commande un point d'ancrage au troisième tour, puis le processus continue.
Réputation des leaders
Lorsqu'on saute des points d'ancrage pendant le tri Bullshark, le retard 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 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 en fonction de l'historique des activités récentes 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 seront attribués un score bas, car ils peuvent être en panne, lents ou malveillants.
Son concept est de recalculer de manière déterministe la carte prédéfinie F de chaque tour au leader à chaque mise à jour de score, en faveur des leaders ayant un score plus élevé. Pour que les validateurs parviennent à un consensus sur la nouvelle carte, ils doivent parvenir à un consensus sur les scores, afin d'atteindre 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 au cours de la rème ronde, le validateur n'a qu'à calculer un nouveau mappage F' à partir de la r+1ème ronde en se basant sur l'historique causal des points d'ancrage ordonnés de la rème ronde. Ensuite, les nœuds de validation commencent à utiliser la fonction de sélection de points d'ancrage mise à jour F' pour exécuter une nouvelle instance de Bullshark à partir de la r+1ème ronde.
Pas plus de délai
Le dépassement de délai joue un rôle essentiel dans toutes les mises en œuvre BFT déterministes basées sur des leaders. Cependant, la complexité qu'ils introduisent augmente le nombre d'états internes à gérer et à observer, ce qui complique le processus de débogage et nécessite davantage de techniques d'observation.
Les délais d'expiration augmenteront également 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 prochain leader, le protocole paiera la pénalité de délai d'expiration complète pour le leader défaillant. Par conséquent, les paramètres de délai d'expiration ne doivent pas être trop conservateurs, mais si le délai d'expiration est trop court, le protocole peut ignorer de bons leaders. Par exemple, nous avons observé que, dans des conditions de forte charge, les leaders dans Jolteon/Hotstuff étaient submergés et que le temps d'expiration était atteint avant qu'ils ne puissent faire avancer les choses.
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.
21 J'aime
Récompense
21
9
Partager
Commentaire
0/400
RektCoaster
· 08-03 07:00
Latence a baissé autant ? Bull !
Voir l'originalRépondre0
Degen4Breakfast
· 08-02 20:25
Laisse tomber, il n'est pas nécessaire de rendre les choses si compliquées pour être une ancre.
Voir l'originalRépondre0
SatoshiLegend
· 08-02 17:14
L'optimisation du DAG est bonne, mais rester fidèle à ses principes est la clé du succès. Sous le code source, il n'y a pas de secret.
Voir l'originalRépondre0
NonFungibleDegen
· 08-01 16:37
haussier af sur aptos rn... 80% plus rapide? probablement rien ser
Voir l'originalRépondre0
Ser_This_Is_A_Casino
· 07-31 12:48
Réduire la latence peut entraîner un tel résultat.
Voir l'originalRépondre0
BearMarketBro
· 07-31 12:48
Ça a l'air pas mal.
Voir l'originalRépondre0
ApeShotFirst
· 07-31 12:25
Eh bien, Aptos joue encore avec quelque chose de nouveau!
Voir l'originalRépondre0
GasFeeCrybaby
· 07-31 12:25
Quand les frais de gas vont-ils baisser ?
Voir l'originalRépondre0
ImpermanentLossFan
· 07-31 12:24
Enfin, quelqu'un se souvient de mes Actions A Aptos.
Le cadre Shoal améliore considérablement les performances de Bullshark sur la chaîne Aptos, réduisant les délais de jusqu'à 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 pauses dans le protocole pratique déterministe. En général, dans des conditions sans défaillance, la latence de Bullshark a été améliorée de 40 %, et dans des conditions de défaillance, elle a été améliorée de 80 %.
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 un mécanisme de réputation des leaders. Le pipeline réduit la latence de tri DAG en introduisant un point d'ancrage à chaque tour, et la réputation des leaders améliore encore le problème de latence en s'assurant que le point d'ancrage est associé aux nœuds de validation les plus rapides. De plus, la réputation des leaders permet à Shoal d'exploiter la construction DAG asynchrone pour éliminer les délais dans tous les scénarios. Cela permet à Shoal d'offrir ce que nous appelons une propriété de réponse universelle, qui comprend généralement des réponses optimistes.
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.
Motivation
Dans la quête de haute performance des réseaux blockchain, l'accent a toujours été mis sur la réduction de la complexité des communications. Cependant, cette approche 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 deçà de l'objectif de 100k+ TPS.
La récente percée provient de la prise de conscience que la propagation des données est le principal goulot d'étranglement basé sur le protocole des leaders, pouvant bénéficier de la parallélisation. Le système Narwhal dissocie la propagation des données de la logique de consensus centrale, proposant une architecture dans laquelle tous les validateurs propagent les données simultanément, tandis que le composant de consensus ne commande qu'une petite quantité de métadonnées. Le document de Narwhal a rapporté un débit de 160 000 TPS.
Le Quorum Store, présenté précédemment, est une implémentation de Narwhal qui sépare la diffusion des données du consensus, utilisé pour étendre le protocole de consensus actuel, Jolteon. Jolteon est un protocole basé sur un leader qui combine le chemin rapide linéaire de Tendermint et le changement de vue de style PBFT, permettant de réduire le délai 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 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 sur Narwhal DAG, qui est un protocole de consensus sans coût de communication. Malheureusement, par rapport à Jolteon, la structure DAG soutenant Bullshark à haut débit 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 acquérir 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 différentes vues locales du DAG à tout moment.
Une caractéristique clé du DAG est qu'elle 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 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 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 de l'intersection des groupes dans une structure DAG soit différente, tous les protocoles de consensus basés sur Narwhal existants ont la structure suivante :
Point d'ancrage prévu : tous les quelques tours, un leader prédéterminé sera désigné, 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 commander et lesquels sauter ;
Historique causal ordonné : les validateurs traitent un par un la liste des points d'ancrage ordonnés, triant tous les sommets précédemment non ordonnés dans l'historique causal de chaque point d'ancrage.
La clé pour satisfaire 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 les protocoles ci-dessus:
Tous les validateurs conviennent du premier point d'ancrage ordonné.
Bullshark retard
Le délai 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 un meilleur délai que la version asynchrone, elle reste loin d'être optimale.
Question 1 : Délai moyen de bloc. Dans Bullshark, chaque tour pair a un point d'ancrage, et chaque sommet du tour impair est interprété comme un vote. Dans des cas courants, deux tours de DAG sont nécessaires pour commander les points d'ancrage, cependant, les sommets dans l'histoire causale des points d'ancrage nécessitent plus de tours pour attendre que les points d'ancrage soient triés. Dans des 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 : Retard dans les cas de défaillance. L'analyse des retards ci-dessus s'applique aux situations sans défaillance, d'autre part, si le leader d'un tour ne parvient pas à diffuser suffisamment rapidement le point d'ancrage, il est impossible de trier le point d'ancrage ( et donc il est sauté ), ce qui signifie que tous les sommets non triés des tours précédents 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, en particulier parce que Bullshark utilise un délai d'attente pour attendre le leader.
Cadre Shoal
Shoal a amélioré le Bullshark( ou tout autre protocole BFT basé sur Narwhal) grâce à un traitement en pipeline, permettant d'avoir un point d'ancrage à chaque tour et de réduire le délai 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 de leaders rapides.
Défi
Dans le cadre du protocole DAG, le traitement en pipeline et la réputation des leaders sont considérés comme des problèmes difficiles, pour les raisons suivantes :
Les tentatives de traitement en flux précédentes de modifier la logique fondamentale de Bullshark semblent fondamentalement impossibles.
La réputation des leaders est introduite dans DiemBFT et officialisée dans Carousel, selon l'idée de sélectionner dynamiquement les futurs leaders basés sur les performances passées des validateurs dans (Bullshark et l'ancre dans ). Bien qu'il n'y ait pas de violation de la sécurité de ces protocoles en cas de désaccord sur l'identité des leaders, dans Bullshark, cela peut conduire à des ordres complètement différents, 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 sélectionner les futures ancres.
En tant qu'évidence de la difficulté des problèmes, nous notons que 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, 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 conserver et de réinterpréter les informations des tours précédents. Grâce à la compréhension centrale selon laquelle tous les validateurs s'accordent sur le premier point d'ancrage ordonné, Shoal combine de manière séquentielle plusieurs instances de Bullshark pour les traiter en pipeline, ce qui fait que ( le premier point d'ancrage ordonné est le point de basculement des instances, ainsi que ) l'historique causal des points d'ancrage pour le calcul de la réputation des leaders.
Traitement en chaîne
V qui fait correspondre 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 le mappage 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 de DAG et l'a fait fonctionner jusqu'à ce que le premier point d'ancrage ordonné soit déterminé, par exemple au tour r. Tous les validateurs ont convenu de ce point d'ancrage. Par conséquent, tous les validateurs peuvent convenir de manière 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 du premier tour sont triés par le premier exemple. Ensuite, Shoal commence un nouvel exemple au début du deuxième tour, qui a lui-même un point d'ancrage, cet ancrage étant trié par cet exemple, puis un autre nouvel exemple commande un point d'ancrage au troisième tour, puis le processus continue.
Réputation des leaders
Lorsqu'on saute des points d'ancrage pendant le tri Bullshark, le retard 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 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 en fonction de l'historique des activités récentes 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 seront attribués un score bas, car ils peuvent être en panne, lents ou malveillants.
Son concept est de recalculer de manière déterministe la carte prédéfinie F de chaque tour au leader à chaque mise à jour de score, en faveur des leaders ayant un score plus élevé. Pour que les validateurs parviennent à un consensus sur la nouvelle carte, ils doivent parvenir à un consensus sur les scores, afin d'atteindre 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 au cours de la rème ronde, le validateur n'a qu'à calculer un nouveau mappage F' à partir de la r+1ème ronde en se basant sur l'historique causal des points d'ancrage ordonnés de la rème ronde. Ensuite, les nœuds de validation commencent à utiliser la fonction de sélection de points d'ancrage mise à jour F' pour exécuter une nouvelle instance de Bullshark à partir de la r+1ème ronde.
Pas plus de délai
Le dépassement de délai joue un rôle essentiel dans toutes les mises en œuvre BFT déterministes basées sur des leaders. Cependant, la complexité qu'ils introduisent augmente le nombre d'états internes à gérer et à observer, ce qui complique le processus de débogage et nécessite davantage de techniques d'observation.
Les délais d'expiration augmenteront également 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 prochain leader, le protocole paiera la pénalité de délai d'expiration complète pour le leader défaillant. Par conséquent, les paramètres de délai d'expiration ne doivent pas être trop conservateurs, mais si le délai d'expiration est trop court, le protocole peut ignorer de bons leaders. Par exemple, nous avons observé que, dans des conditions de forte charge, les leaders dans Jolteon/Hotstuff étaient submergés et que le temps d'expiration était atteint avant qu'ils ne puissent faire avancer les choses.