Cadre Shoal : comment Goutte la latence de Bullshark sur Aptos
Aptos Labs a résolu deux problèmes ouverts importants dans le DAG BFT, ce qui a considérablement Goutte la latence, et a éliminé pour la première fois le besoin de délais dans un protocole pratique déterministe. Dans l'ensemble, la latence du Bullshark a été améliorée de 40 % en cas de fonctionnement normal et de 80 % en cas de panne.
Shoal est un cadre qui améliore tout protocole de consensus basé sur Narwhal ( tel que DAG-Rider, Tusk, Bullshark ) grâce à des pipelines et à la réputation des leaders. Les pipelines réduisent la latence de tri DAG en introduisant des points d'ancrage à chaque tour, et la réputation des leaders améliore encore le problème de 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'utiliser une construction 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, y compris la réponse optimiste généralement requise.
Cette technologie est très simple, impliquant l'exécution en séquence 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 hautes performances pour les 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, Hotstuff, implémenté dans les premières versions de Diem, n'a atteint que 3500 TPS, bien en dessous de l'objectif de 100k+ TPS.
La récente percée provient de la reconnaissance que la propagation des données est le principal goulot d'étranglement basé sur le protocole de leader, et peut bénéficier de la parallélisation. Le système Narwhal dissocie la propagation des données de la logique de consensus centrale, proposant que tous les validateurs propagent les données simultanément, tandis que le composant de consensus ne commande qu'un petit nombre de métadonnées. Le document Narwhal a rapporté un débit de 160 000 TPS.
Le Quorum Store précédemment présenté est une implémentation de Narwhal, qui dissocie la diffusion des données et le consensus, afin d'étendre le protocole de consensus actuel Jolteon. Jolteon est un protocole basé sur un leader, combinant le chemin linéaire rapide de Tendermint et le changement de vue de style PBFT, réduisant la Goutte de Hotstuff de 33%. Cependant, le protocole de consensus basé sur un leader ne peut pas exploiter pleinement le potentiel de débit de Narwhal.
Ainsi, il a été décidé de déployer Bullshark sur le DAG Narwhal, qui est 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 peut considérablement réduire la latence de Bullshark.
Contexte DAG-BFT
Chaque sommet dans le DAG de Narwhal est associé à un cycle. Pour entrer dans le cycle r, un validateur doit d'abord obtenir n-f sommets du cycle r-1. Chaque validateur peut diffuser un sommet par cycle, et chaque sommet doit référencer au moins n-f sommets du cycle précédent. En raison de l'asynchronisme du réseau, différents validateurs peuvent observer à tout moment des vues locales différentes du DAG.
Une caractéristique clé du DAG est la non-ambiguïté : si deux nœuds de validation ont le même sommet v dans la vue locale du DAG, alors ils ont une histoire causale de v entièrement identique.
Ordre total
Il est possible d'atteindre un consensus total sur tous les sommets du 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.
Tous les protocoles de consensus basés sur Narwhal existants ont la structure suivante :
Point d'ancrage réservé : tous les quelques 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 commander et lesquels sauter.
Historique causal ordonné : les validateurs traitent un par un la liste des points d'ancrage ordonnés, en ordonnant tous les sommets désordonnés précédents dans l'historique causal de chaque point d'ancrage selon des règles de déterminisme.
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 les nœuds de validation honnêtes partagent le même préfixe. Shoal fait les observations suivantes sur tous ces protocoles:
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 certaines versions synchronisées aient une latence meilleure que les versions asynchrones, elles sont loin d'être optimales.
Problème 1 : latence moyenne des blocs. Dans Bullshark, chaque point d'ancrage est présent à chaque round pair, et chaque sommet de round impair est interprété comme un vote. Dans des cas courants, deux rounds de DAG sont nécessaires pour ordonner les points d'ancrage, cependant, les sommets dans l'historique causale des points d'ancrage nécessitent plus de rounds pour attendre l'ordre des points d'ancrage. En général, les sommets de round impair nécessitent trois rounds, tandis que les sommets non ancrés de round pair nécessitent quatre rounds.
Problème 2 : latence des cas de défaillance. Si un leader de round n'arrive pas à diffuser suffisamment rapidement le point d'ancrage, il devient impossible de trier le point d'ancrage (, qui est sauté ), et tous les sommets non triés des rounds précédents doivent attendre le prochain tri du point d'ancrage. Cela réduit considérablement les performances du réseau de réplication géographique, en particulier parce que Bullshark utilise un temps d'attente pour le leader.
Cadre Shoal
Shoal améliore Bullshark( ou tout autre protocole BFT basé sur Narwhal) grâce à des pipelines, permettant d'avoir un point d'ancrage à chaque round, réduisant la latence de tous les sommets non ancrés dans le DAG à trois rounds. Shoal introduit également un mécanisme de réputation de leader sans coût dans le DAG, privilégiant le choix des leaders rapides.
Défi
Dans le cadre du protocole DAG, les problèmes de pipeline et de réputation des leaders sont considérés comme difficiles, pour les raisons suivantes :
Les tentatives précédentes de modifier la logique principale de Bullshark dans la chaîne de production semblent en fait impossibles.
La réputation des leaders est introduite dans DiemBFT et formalisée dans Carousel, sélectionnant dynamiquement les futurs leaders en fonction des performances passées des validateurs dans l'ancre de (Bullshark. Bien qu'il y ait des divergences concernant l'identité des leaders qui ne compromettent pas la sécurité de ces protocoles, cela peut entraîner des ordonnancements complètement différents dans Bullshark, ce qui soulève le cœur du problème : le choix déterministe dynamique des ancres de cycle est nécessaire pour résoudre le consensus, et les validateurs doivent parvenir à un accord sur l'historique ordonné pour choisir les futures ancres.
En tant que preuve de la difficulté des problèmes, la mise en œuvre de Bullshark ) inclut actuellement des caractéristiques qui ne sont pas prises en charge dans l'environnement de production.
Protocole
Shoal s'appuie sur la capacité d'exécuter des calculs locaux sur le DAG, permettant de sauvegarder et de réinterpréter les informations des tours précédents. Grâce à l'accord de tous les validateurs sur la première ancre ordonnée, Shoal combine de manière séquentielle plusieurs instances de Bullshark pour un traitement en pipeline, faisant de ( le premier point de commutation d'instance, et ) l'historique causale de l'ancre est utilisé pour calculer la réputation des leaders.
( chaîne de production
V qui associe les tours aux leaders. Shoal exécute une instance Bullshark après l'autre, chaque instance ayant un ancrage déterminé à l'avance par le mappage F. Chaque instance commande un ancrage, déclenchant le passage à l'instance suivante.
Au début, Shoal a lancé le premier exemple de Bullshark lors du premier tour de DAG et a fonctionné jusqu'à ce que le premier point d'ancrage ordonné soit déterminé, par exemple lors du tour r. Tous les validateurs ont accepté ce point d'ancrage. Par conséquent, tous les validateurs peuvent convenir de réinterpréter le DAG à partir du tour r+1. Shoal a simplement lancé un nouvel exemple de Bullshark lors du tour r+1.
Dans le meilleur des cas, cela permet à Shoal de commander un ancrage à chaque tour. Le premier point d'ancrage 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 commande un point d'ancrage au troisième tour, et le processus continue.
![Explication détaillée du cadre Shoal : comment réduire la Goutte Bullshark sur Aptos ?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
) réputation des leaders
Lorsqu'un point d'ancrage est sauté pendant le tri Bullshark, la latence augmente. Dans ce cas, la pipeline est impuissante, car il est impossible de démarrer une nouvelle instance avant que le point d'ancrage de l'instance précédente ne soit commandé. Shoal s'assure qu'il est peu probable que le leader correspondant soit choisi pour traiter les points d'ancrage manquants à l'avenir, en attribuant des scores en fonction de l'historique d'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 obtiennent un score élevé, sinon un score bas est attribué, car ils peuvent être en panne, lents ou malveillants.
Le 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 favorisant les leaders ayant des scores plus élevés. Pour que les validateurs parviennent à un consensus sur le nouveau mappage, ils doivent parvenir à un consensus sur les scores, afin d'atteindre un consensus sur l'historique utilisé pour dériver les scores.
Dans Shoal, les pipelines et la réputation des leaders peuvent se combiner naturellement, car ils utilisent tous deux la même technologie de base, à savoir la réinterprétation du DAG après avoir convenu du premier point d'ancrage ordonné.
La seule différence est qu'après le classement des points d'ancrage lors de la rème ronde, le validateur doit simplement calculer une nouvelle fonction de mappage F' à partir de la r+1ère 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ère ronde.
![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(
) sans délai
Le dépassement de délai joue un rôle clé dans toutes les implémentations BFT déterministes basées sur un leader. Cependant, la complexité qu'ils introduisent augmente le nombre d'états internes à gérer et à observer, ce qui accroît la complexité du débogage et nécessite davantage de techniques d'observation.
Le dépassement de temps augmentera également significativement la latence, car il est important de les configurer correctement, nécessitant souvent des ajustements dynamiques, fortement dépendants de l'environnement ### réseau (. Avant de passer au leader suivant, le protocole paiera la pénalité complète de latence de dépassement de temps pour le leader défaillant. Par conséquent, les paramètres de dépassement de temps ne peuvent pas être trop conservateurs, mais s'ils sont trop courts, le protocole peut sauter de bons leaders. Par exemple, nous avons observé qu'en cas de forte charge, les leaders dans Jolteon/Hotstuff sont accablés, et le dépassement de temps est déjà expiré avant de faire avancer les choses.
Malheureusement, le protocole basé sur les leaders ) tels que Hotstuff et Jolteon### nécessite essentiellement une Goutte de latence pour garantir que le protocole progresse chaque fois qu'un leader échoue. Sans Goutte, même les leaders en panne peuvent arrêter le protocole indéfiniment. Étant donné qu'il est impossible de distinguer un leader en panne d'un leader lent pendant une latence asynchrone, la Goutte peut amener les nœuds de validation à changer tous les leaders sans activité de consensus.
Dans Bullshark, le temps d'attente est utilisé pour la construction du DAG, afin de garantir qu'au cours de la synchronisation, les leaders honnêtes ajoutent les points d'ancrage au DAG suffisamment rapidement pour le tri.
Nous avons observé que la construction de DAG fournit un "horloge" pour estimer la vitesse du réseau. En l'absence de pauses, tant que n-f validateurs honnêtes continuent d'ajouter des sommets au DAG, le tour continuera d'avancer. Bien que Bullshark ne puisse peut-être pas trier ( à la vitesse du réseau en raison de problèmes de leadership ), le DAG continue de croître à la vitesse du réseau, même si certains leaders rencontrent des problèmes ou que le réseau est asynchrone. Finalement, lorsque des leaders sans faute diffusent des points d'ancrage suffisamment rapidement, l'ensemble de l'histoire causale des points d'ancrage sera trié.
Dans notre évaluation, nous avons comparé Bullshark en cas de latence ou non :
Leader rapide : au moins plus rapide que les autres validateurs. Les deux méthodes offrent la même latence, car les ancres sont ordonnées et n'utilisent pas de délai.
Leaders erronés : Bullshark sans timeout offre une meilleure latence, car les nœuds de validation contournent immédiatement leur
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.
10 J'aime
Récompense
10
4
Reposter
Partager
Commentaire
0/400
HashRateHermit
· Il y a 5h
latence améliorée de 80 % ? Ce bull, wow
Voir l'originalRépondre0
SelfRugger
· Il y a 5h
80% latence réduite, Maître Ma a crié bull.
Voir l'originalRépondre0
CommunitySlacker
· Il y a 5h
bull bière latence optimisée de 80%
Voir l'originalRépondre0
Hash_Bandit
· Il y a 5h
putain, c'est comme quand nous avons optimisé la difficulté du minage de btc en 2013... gains de hashrate majeurs fr
Cadre Shoal : Optimisation de la latence Bullshark sur Aptos
Cadre Shoal : comment Goutte la latence de Bullshark sur Aptos
Aptos Labs a résolu deux problèmes ouverts importants dans le DAG BFT, ce qui a considérablement Goutte la latence, et a éliminé pour la première fois le besoin de délais dans un protocole pratique déterministe. Dans l'ensemble, la latence du Bullshark a été améliorée de 40 % en cas de fonctionnement normal et de 80 % en cas de panne.
Shoal est un cadre qui améliore tout protocole de consensus basé sur Narwhal ( tel que DAG-Rider, Tusk, Bullshark ) grâce à des pipelines et à la réputation des leaders. Les pipelines réduisent la latence de tri DAG en introduisant des points d'ancrage à chaque tour, et la réputation des leaders améliore encore le problème de 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'utiliser une construction 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, y compris la réponse optimiste généralement requise.
Cette technologie est très simple, impliquant l'exécution en séquence 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 hautes performances pour les 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, Hotstuff, implémenté dans les premières versions de Diem, n'a atteint que 3500 TPS, bien en dessous de l'objectif de 100k+ TPS.
La récente percée provient de la reconnaissance que la propagation des données est le principal goulot d'étranglement basé sur le protocole de leader, et peut bénéficier de la parallélisation. Le système Narwhal dissocie la propagation des données de la logique de consensus centrale, proposant que tous les validateurs propagent les données simultanément, tandis que le composant de consensus ne commande qu'un petit nombre de métadonnées. Le document Narwhal a rapporté un débit de 160 000 TPS.
Le Quorum Store précédemment présenté est une implémentation de Narwhal, qui dissocie la diffusion des données et le consensus, afin d'étendre le protocole de consensus actuel Jolteon. Jolteon est un protocole basé sur un leader, combinant le chemin linéaire rapide de Tendermint et le changement de vue de style PBFT, réduisant la Goutte de Hotstuff de 33%. Cependant, le protocole de consensus basé sur un leader ne peut pas exploiter pleinement le potentiel de débit de Narwhal.
Ainsi, il a été décidé de déployer Bullshark sur le DAG Narwhal, qui est 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 peut considérablement réduire la latence de Bullshark.
Contexte DAG-BFT
Chaque sommet dans le DAG de Narwhal est associé à un cycle. Pour entrer dans le cycle r, un validateur doit d'abord obtenir n-f sommets du cycle r-1. Chaque validateur peut diffuser un sommet par cycle, et chaque sommet doit référencer au moins n-f sommets du cycle précédent. En raison de l'asynchronisme du réseau, différents validateurs peuvent observer à tout moment des vues locales différentes du DAG.
Une caractéristique clé du DAG est la non-ambiguïté : si deux nœuds de validation ont le même sommet v dans la vue locale du DAG, alors ils ont une histoire causale de v entièrement identique.
Ordre total
Il est possible d'atteindre un consensus total sur tous les sommets du 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.
Tous les protocoles de consensus basés sur Narwhal existants ont la structure suivante :
Point d'ancrage réservé : tous les quelques 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 commander et lesquels sauter.
Historique causal ordonné : les validateurs traitent un par un la liste des points d'ancrage ordonnés, en ordonnant tous les sommets désordonnés précédents dans l'historique causal de chaque point d'ancrage selon des règles de déterminisme.
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 les nœuds de validation honnêtes partagent le même préfixe. Shoal fait les observations suivantes sur tous ces protocoles:
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 certaines versions synchronisées aient une latence meilleure que les versions asynchrones, elles sont loin d'être optimales.
Problème 1 : latence moyenne des blocs. Dans Bullshark, chaque point d'ancrage est présent à chaque round pair, et chaque sommet de round impair est interprété comme un vote. Dans des cas courants, deux rounds de DAG sont nécessaires pour ordonner les points d'ancrage, cependant, les sommets dans l'historique causale des points d'ancrage nécessitent plus de rounds pour attendre l'ordre des points d'ancrage. En général, les sommets de round impair nécessitent trois rounds, tandis que les sommets non ancrés de round pair nécessitent quatre rounds.
Problème 2 : latence des cas de défaillance. Si un leader de round n'arrive pas à diffuser suffisamment rapidement le point d'ancrage, il devient impossible de trier le point d'ancrage (, qui est sauté ), et tous les sommets non triés des rounds précédents doivent attendre le prochain tri du point d'ancrage. Cela réduit considérablement les performances du réseau de réplication géographique, en particulier parce que Bullshark utilise un temps d'attente pour le leader.
Cadre Shoal
Shoal améliore Bullshark( ou tout autre protocole BFT basé sur Narwhal) grâce à des pipelines, permettant d'avoir un point d'ancrage à chaque round, réduisant la latence de tous les sommets non ancrés dans le DAG à trois rounds. Shoal introduit également un mécanisme de réputation de leader sans coût dans le DAG, privilégiant le choix des leaders rapides.
Défi
Dans le cadre du protocole DAG, les problèmes de pipeline et de réputation des leaders sont considérés comme difficiles, pour les raisons suivantes :
Les tentatives précédentes de modifier la logique principale de Bullshark dans la chaîne de production semblent en fait impossibles.
La réputation des leaders est introduite dans DiemBFT et formalisée dans Carousel, sélectionnant dynamiquement les futurs leaders en fonction des performances passées des validateurs dans l'ancre de (Bullshark. Bien qu'il y ait des divergences concernant l'identité des leaders qui ne compromettent pas la sécurité de ces protocoles, cela peut entraîner des ordonnancements complètement différents dans Bullshark, ce qui soulève le cœur du problème : le choix déterministe dynamique des ancres de cycle est nécessaire pour résoudre le consensus, et les validateurs doivent parvenir à un accord sur l'historique ordonné pour choisir les futures ancres.
En tant que preuve de la difficulté des problèmes, la mise en œuvre de Bullshark ) inclut actuellement des caractéristiques qui ne sont pas prises en charge dans l'environnement de production.
Protocole
Shoal s'appuie sur la capacité d'exécuter des calculs locaux sur le DAG, permettant de sauvegarder et de réinterpréter les informations des tours précédents. Grâce à l'accord de tous les validateurs sur la première ancre ordonnée, Shoal combine de manière séquentielle plusieurs instances de Bullshark pour un traitement en pipeline, faisant de ( le premier point de commutation d'instance, et ) l'historique causale de l'ancre est utilisé pour calculer la réputation des leaders.
( chaîne de production
V qui associe les tours aux leaders. Shoal exécute une instance Bullshark après l'autre, chaque instance ayant un ancrage déterminé à l'avance par le mappage F. Chaque instance commande un ancrage, déclenchant le passage à l'instance suivante.
Au début, Shoal a lancé le premier exemple de Bullshark lors du premier tour de DAG et a fonctionné jusqu'à ce que le premier point d'ancrage ordonné soit déterminé, par exemple lors du tour r. Tous les validateurs ont accepté ce point d'ancrage. Par conséquent, tous les validateurs peuvent convenir de réinterpréter le DAG à partir du tour r+1. Shoal a simplement lancé un nouvel exemple de Bullshark lors du tour r+1.
Dans le meilleur des cas, cela permet à Shoal de commander un ancrage à chaque tour. Le premier point d'ancrage 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 commande un point d'ancrage au troisième tour, et le processus continue.
![Explication détaillée du cadre Shoal : comment réduire la Goutte Bullshark sur Aptos ?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
) réputation des leaders
Lorsqu'un point d'ancrage est sauté pendant le tri Bullshark, la latence augmente. Dans ce cas, la pipeline est impuissante, car il est impossible de démarrer une nouvelle instance avant que le point d'ancrage de l'instance précédente ne soit commandé. Shoal s'assure qu'il est peu probable que le leader correspondant soit choisi pour traiter les points d'ancrage manquants à l'avenir, en attribuant des scores en fonction de l'historique d'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 obtiennent un score élevé, sinon un score bas est attribué, car ils peuvent être en panne, lents ou malveillants.
Le 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 favorisant les leaders ayant des scores plus élevés. Pour que les validateurs parviennent à un consensus sur le nouveau mappage, ils doivent parvenir à un consensus sur les scores, afin d'atteindre un consensus sur l'historique utilisé pour dériver les scores.
Dans Shoal, les pipelines et la réputation des leaders peuvent se combiner naturellement, car ils utilisent tous deux la même technologie de base, à savoir la réinterprétation du DAG après avoir convenu du premier point d'ancrage ordonné.
La seule différence est qu'après le classement des points d'ancrage lors de la rème ronde, le validateur doit simplement calculer une nouvelle fonction de mappage F' à partir de la r+1ère 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ère ronde.
![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(
) sans délai
Le dépassement de délai joue un rôle clé dans toutes les implémentations BFT déterministes basées sur un leader. Cependant, la complexité qu'ils introduisent augmente le nombre d'états internes à gérer et à observer, ce qui accroît la complexité du débogage et nécessite davantage de techniques d'observation.
Le dépassement de temps augmentera également significativement la latence, car il est important de les configurer correctement, nécessitant souvent des ajustements dynamiques, fortement dépendants de l'environnement ### réseau (. Avant de passer au leader suivant, le protocole paiera la pénalité complète de latence de dépassement de temps pour le leader défaillant. Par conséquent, les paramètres de dépassement de temps ne peuvent pas être trop conservateurs, mais s'ils sont trop courts, le protocole peut sauter de bons leaders. Par exemple, nous avons observé qu'en cas de forte charge, les leaders dans Jolteon/Hotstuff sont accablés, et le dépassement de temps est déjà expiré avant de faire avancer les choses.
Malheureusement, le protocole basé sur les leaders ) tels que Hotstuff et Jolteon### nécessite essentiellement une Goutte de latence pour garantir que le protocole progresse chaque fois qu'un leader échoue. Sans Goutte, même les leaders en panne peuvent arrêter le protocole indéfiniment. Étant donné qu'il est impossible de distinguer un leader en panne d'un leader lent pendant une latence asynchrone, la Goutte peut amener les nœuds de validation à changer tous les leaders sans activité de consensus.
Dans Bullshark, le temps d'attente est utilisé pour la construction du DAG, afin de garantir qu'au cours de la synchronisation, les leaders honnêtes ajoutent les points d'ancrage au DAG suffisamment rapidement pour le tri.
Nous avons observé que la construction de DAG fournit un "horloge" pour estimer la vitesse du réseau. En l'absence de pauses, tant que n-f validateurs honnêtes continuent d'ajouter des sommets au DAG, le tour continuera d'avancer. Bien que Bullshark ne puisse peut-être pas trier ( à la vitesse du réseau en raison de problèmes de leadership ), le DAG continue de croître à la vitesse du réseau, même si certains leaders rencontrent des problèmes ou que le réseau est asynchrone. Finalement, lorsque des leaders sans faute diffusent des points d'ancrage suffisamment rapidement, l'ensemble de l'histoire causale des points d'ancrage sera trié.
Dans notre évaluation, nous avons comparé Bullshark en cas de latence ou non :
Leader rapide : au moins plus rapide que les autres validateurs. Les deux méthodes offrent la même latence, car les ancres sont ordonnées et n'utilisent pas de délai.
Leaders erronés : Bullshark sans timeout offre une meilleure latence, car les nœuds de validation contournent immédiatement leur