Réduire le délai de Bullshark sur Aptos: Détails sur le cadre Shoal
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 les protocoles déterministes. Dans l'ensemble, la latence de Bullshark a été améliorée de 40 % en cas de fonctionnement normal et de 80 % en cas de défaillance.
Le cadre Shoal renforce le protocole de consensus basé sur Narwhal ( grâce à un pipeline et à un mécanisme de réputation des leaders, tel que DAG-Rider, Tusk, Bullshark ). Le pipeline introduit un point d'ancrage à chaque tour pour réduire le délai de tri de DAG, tandis que la réputation des leaders garantit que le point d'ancrage est associé au nœud de validation le plus rapide, améliorant ainsi davantage le délai. 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, réalisant ainsi une propriété de réponse universelle.
La technologie de Shoal est très simple, elle exécute plusieurs instances du protocole sous-jacent dans l'ordre. Lorsqu'elle est instanciée avec Bullshark, c'est comme un groupe de "requins" en train de participer à une course de relais.
Contexte
Lors de la recherche d'une haute performance des réseaux blockchain, l'accent a toujours été mis sur la réduction de la complexité de la communication, mais cela n'a pas conduit à une augmentation significative du débit. Par exemple, le Hotstuff implémenté dans le premier Diem n'a atteint que 3500 TPS, bien en dessous de l'objectif de 100k+ TPS.
Récemment, la percée provient de la reconnaissance 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 central, tous les validateurs diffusent des données simultanément, les composants de consensus ne classent qu'un petit nombre de métadonnées. Le document Narwhal a rapporté un débit de 160 000 TPS.
Aptos a précédemment présenté Quorum Store, c'est-à-dire l'implémentation Narwhal, qui sépare la propagation des données et le consensus, et qui est utilisée pour étendre le protocole de consensus actuel Jolteon. Jolteon combine le chemin rapide linéaire de Tendermint et le changement de vue de style PBFT, réduisant ainsi 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.
Ainsi, Aptos a décidé de déployer Bullshark, un protocole de consensus sans coût de communication, sur le DAG Narwhal. Malheureusement, la structure DAG soutenant le haut débit de Bullshark entraîne un coût de latence de 50 %.
Cet article présente comment Shoal réduit considérablement la latence de Bullshark.
Contexte DAG-BFT
Dans le DAG Narwhal, chaque sommet est associé à un tour. Pour entrer au tour r, un validateur doit obtenir n-f sommets du 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'asynchronisme du réseau, différents validateurs peuvent observer différentes vues locales 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 exactement la même histoire causale de v.
Ordre de tri
Il est possible d'atteindre un consensus sur l'ordre total de tous les sommets dans le DAG sans coûts de communication supplémentaires. Les validateurs dans DAG-Rider, Tusk et Bullshark interprètent la structure du DAG comme un protocole de consensus, les sommets représentant des propositions et les arêtes représentant des votes.
Bien que la logique d'intersection des groupes sur une structure DAG soit différente, tous les protocoles de consensus basés sur Narwhal ont la structure suivante :
Point d'ancrage prévu : tous les quelques tours, il y a 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.
Historique de causalité ordonné : les validateurs traitent un par un la liste des points d'ancrage ordonnés, en triant les sommets désordonnés précédents dans l'historique de causalité de chaque point d'ancrage.
La clé pour satisfaire à la sécurité est de s'assurer que dans l'étape (2), toutes les listes de points d'ancrage ordonnés créées par les nœuds de validation honnêtes partagent le même préfixe. Dans Shoal, nous avons observé :
Tous les validateurs s'accordent sur le 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. Les versions de synchronisation partielle ont un délai meilleur que les versions asynchrones, mais ne sont toujours pas optimales.
Question 1: Délai moyen de bloc. Dans Bullshark, chaque round pair a un point d'ancrage, et les sommets des rounds 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, mais les sommets dans l'historique causale des points d'ancrage nécessitent des tours supplémentaires pour attendre que les points d'ancrage soient triés. Dans les cas courants, les sommets des rounds impairs nécessitent trois tours, tandis que les sommets non ancrés des rounds pairs nécessitent quatre tours.
Problème 2 : Délai de défaillance. Si un leader ne parvient pas à diffuser l'ancre à temps, il ne peut pas être trié ( est sauté ), 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, surtout parce que Bullshark utilise un temps d'attente pour le leader.
Cadre Shoal
Shoal améliore Bullshark( ou tout protocole BFT basé sur Narwhal) grâce à une chaîne de production, permettant à chaque tour d'avoir un point d'ancrage, réduisant le délai de tous les sommets non ancrés dans le DAG à trois tours. Shoal introduit également un mécanisme de réputation des leaders sans coût dans le DAG, favorisant le choix des leaders rapides.
défi
Dans le protocole DAG, les problèmes de pipeline et de réputation des leaders sont considérés comme des problèmes difficiles pour les raisons suivantes :
Les tentatives précédentes de modification de la logique centrale de Bullshark semblent fondamentalement 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 que les divergences d'identité des leaders ne compromettent pas la sécurité de ces protocoles, elles peuvent entraîner des classements complètement différents dans Bullshark, soulevant le cœur du problème : choisir dynamiquement et de manière déterministe les ancres de rotation est nécessaire pour résoudre le consensus, les validateurs doivent s'accorder sur un historique ordonné pour sélectionner les futures ancres.
En tant que preuve de la difficulté des problèmes, l'implémentation de Bullshark ) inclut les ( dans l'environnement de production actuel qui ne prend pas en charge ces caractéristiques.
) accord
Bien qu'il existe des défis mentionnés ci-dessus, la solution se cache dans la simplicité.
Shoal s'appuie sur la capacité d'exécuter des calculs locaux sur le DAG pour réaliser la sauvegarde et la réinterprétation des informations des tours précédents. Basé sur l'accord de tous les validateurs sur la première ancre ordonnée, Shoal combine séquentiellement plusieurs instances de Bullshark pour un traitement en pipeline, faisant de ### le point de commutation des instances de la première ancre ordonnée, ( l'histoire causale de l'ancre est utilisée pour calculer la réputation des leaders.
) ligne de production
V qui associe les tours aux leaders. Shoal exécute des instances Bullshark en séquence, chaque ancre de l'instance étant déterminée à l'avance par le mappage F. Chaque instance trie une ancre, déclenchant le passage à l'instance suivante.
Au début, Shoal a lancé la première instance de Bullshark lors du premier tour de DAG, fonctionnant jusqu'à ce que le premier point d'ancrage ordonné ( soit déterminé comme le tour r ). Tous les validateurs ont convenu de ce point d'ancrage, il est donc possible de convenir de manière définitive de la réinterprétation du DAG à partir du tour r+1. Shoal a lancé une nouvelle instance de Bullshark au tour r+1.
Dans le meilleur des cas, cela permet à Shoal de trier un ancrage par 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 son propre point d'ancrage et est trié par cette instance, puis une autre nouvelle instance trie le point d'ancrage au troisième tour, et cela continue ainsi.
![Explication détaillée du cadre Shoal : comment réduire le délai de Bullshark sur Aptos ?]###https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
) Réputation des leaders
Lorsque le tri Bullshark saute un point d'ancrage, le délai augmente. Dans ce cas, le pipeline est impuissant, car il n'est pas possible de démarrer une nouvelle instance avant le point d'ancrage de tri de l'instance précédente. Shoal attribue des scores à chaque nœud de validation par le biais d'un mécanisme de réputation, garantissant qu'il est peu probable que les leaders correspondants soient choisis à l'avenir pour traiter les points d'ancrage manquants, en fonction de leur historique d'activités récentes. Les validateurs qui répondent et participent au protocole obtiennent des scores élevés, sinon des scores faibles ( peuvent s'effondrer, être lents ou agir de manière malveillante ).
Le concept consiste à recalculer de manière déterministe la cartographie prédéfinie F du tour au leader à chaque mise à jour de score, en faveur des leaders ayant des scores élevés. Pour que les validateurs parviennent à un consensus sur la nouvelle cartographie, ils doivent parvenir à un consensus sur les scores, afin d'atteindre un consensus sur l'historique utilisé pour dériver les scores.
Dans Shoal, la chaîne de blocs et la réputation des leaders se combinent naturellement, car elles utilisent la même technologie de base : réinterpréter le DAG après avoir atteint un consensus sur le premier point d'ancrage ordonné.
La seule différence est qu'après le point d'ancrage trié à la r-ème ronde, les validateurs calculent une nouvelle correspondance 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 utilisent la fonction de sélection de point d'ancrage mise à jour F' pour exécuter une nouvelle instance de Bullshark à partir de la r+1-ème ronde.
![Explication détaillée du cadre Shoal : comment réduire le délai de Bullshark sur Aptos ?]###https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
) Pas besoin de plus de temps d'attente
Le dépassement de temps est 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 augmente également considérablement la latence, car il est important de les configurer correctement, ce qui nécessite souvent un ajustement dynamique, fortement dépendant de l'environnement ( réseau ). Avant de passer au leader suivant, le protocole paie la pénalité complète de délai pour les leaders défaillants. Par conséquent, les paramètres de dépassement de délai ne doivent pas être trop conservateurs, mais s'ils sont trop courts, le protocole peut sauter de bons leaders. Par exemple, nous avons observé que sous une forte charge, les leaders dans Jolteon/Hotstuff étaient accablés, le dépassement de délai étant déjà atteint avant de pouvoir faire avancer les choses.
Malheureusement, les protocoles de leader basés sur ### comme Hotstuff et Jolteon( nécessitent essentiellement un délai d'attente pour garantir que le protocole progresse chaque fois qu'un leader échoue. Sans délai, même un leader en panne peut arrêter le protocole indéfiniment. Étant donné qu'il est impossible de distinguer un leader en panne d'un leader lent pendant les périodes asynchrones, le délai d'attente peut amener les nœuds de validation à envisager de changer tous les leaders sans activité de consensus.
Dans Bullshark, le délai est utilisé pour la construction de DAG afin de s'assurer qu'au cours de la synchronisation, les leaders honnêtes ajoutent des points d'ancrage au DAG assez rapidement pour qu'ils puissent être triés.
Nous avons observé que la construction de DAG fournit une "horloge" pour estimer la vitesse du réseau. Sans interruption, tant que n-f validateurs honnêtes continuent d'ajouter des sommets au DAG, les tours continueront d'avancer. Bien que Bullshark puisse ne pas être en mesure de 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 ont des problèmes ou si le réseau est asynchrone. Finalement, lorsque des leaders sans défaut diffusent des points d'ancrage suffisamment rapidement, l'ensemble de l'historique causale des points d'ancrage sera trié.
En cours d'évaluation, nous avons comparé si Bullshark a un dépassement de délai dans les cas suivants :
Leader rapide, au moins plus rapide que les autres validateurs. Dans ce cas, les deux méthodes offrent la même latence, car l'ancre est ordonnée et n'utilise pas de délai.
Un leader erroné, dans ce cas, le Bullshark sans pause offre un meilleur délai, car les nœuds de validation sauteront immédiatement leur point d'ancrage, tandis que les validateurs avec pause devront attendre leur expiration avant de continuer.
Leader lent, c'est le seul cas où Bullshark a de meilleures performances en temps d'attente. Car sans pause, le point d'ancrage peut être sauté, car le leader ne peut pas le diffuser assez rapidement, tandis qu'avec une pause, les validateurs attendront le point d'ancrage.
Dans Shoal, éviter les délais est étroitement lié à la réputation du leader. Attendre à nouveau.
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.
14 J'aime
Récompense
14
7
Partager
Commentaire
0/400
MEVictim
· Il y a 3h
L'optimisation a considérablement amélioré l'efficacité.
Voir l'originalRépondre0
LiquidationWatcher
· Il y a 3h
L'optimisation des performances est très efficace.
Aptos introduit le cadre Shoal, ce qui Goutte de manière significative la latence de Bullshark et élimine les exigences de délai d'attente.
Réduire le délai de Bullshark sur Aptos: Détails sur le cadre Shoal
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 les protocoles déterministes. Dans l'ensemble, la latence de Bullshark a été améliorée de 40 % en cas de fonctionnement normal et de 80 % en cas de défaillance.
Le cadre Shoal renforce le protocole de consensus basé sur Narwhal ( grâce à un pipeline et à un mécanisme de réputation des leaders, tel que DAG-Rider, Tusk, Bullshark ). Le pipeline introduit un point d'ancrage à chaque tour pour réduire le délai de tri de DAG, tandis que la réputation des leaders garantit que le point d'ancrage est associé au nœud de validation le plus rapide, améliorant ainsi davantage le délai. 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, réalisant ainsi une propriété de réponse universelle.
La technologie de Shoal est très simple, elle exécute plusieurs instances du protocole sous-jacent dans l'ordre. Lorsqu'elle est instanciée avec Bullshark, c'est comme un groupe de "requins" en train de participer à une course de relais.
Contexte
Lors de la recherche d'une haute performance des réseaux blockchain, l'accent a toujours été mis sur la réduction de la complexité de la communication, mais cela n'a pas conduit à une augmentation significative du débit. Par exemple, le Hotstuff implémenté dans le premier Diem n'a atteint que 3500 TPS, bien en dessous de l'objectif de 100k+ TPS.
Récemment, la percée provient de la reconnaissance 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 central, tous les validateurs diffusent des données simultanément, les composants de consensus ne classent qu'un petit nombre de métadonnées. Le document Narwhal a rapporté un débit de 160 000 TPS.
Aptos a précédemment présenté Quorum Store, c'est-à-dire l'implémentation Narwhal, qui sépare la propagation des données et le consensus, et qui est utilisée pour étendre le protocole de consensus actuel Jolteon. Jolteon combine le chemin rapide linéaire de Tendermint et le changement de vue de style PBFT, réduisant ainsi 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.
Ainsi, Aptos a décidé de déployer Bullshark, un protocole de consensus sans coût de communication, sur le DAG Narwhal. Malheureusement, la structure DAG soutenant le haut débit de Bullshark entraîne un coût de latence de 50 %.
Cet article présente comment Shoal réduit considérablement la latence de Bullshark.
Contexte DAG-BFT
Dans le DAG Narwhal, chaque sommet est associé à un tour. Pour entrer au tour r, un validateur doit obtenir n-f sommets du 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'asynchronisme du réseau, différents validateurs peuvent observer différentes vues locales 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 exactement la même histoire causale de v.
Ordre de tri
Il est possible d'atteindre un consensus sur l'ordre total de tous les sommets dans le DAG sans coûts de communication supplémentaires. Les validateurs dans DAG-Rider, Tusk et Bullshark interprètent la structure du DAG comme un protocole de consensus, les sommets représentant des propositions et les arêtes représentant des votes.
Bien que la logique d'intersection des groupes sur une structure DAG soit différente, tous les protocoles de consensus basés sur Narwhal ont la structure suivante :
Point d'ancrage prévu : tous les quelques tours, il y a 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.
Historique de causalité ordonné : les validateurs traitent un par un la liste des points d'ancrage ordonnés, en triant les sommets désordonnés précédents dans l'historique de causalité de chaque point d'ancrage.
La clé pour satisfaire à la sécurité est de s'assurer que dans l'étape (2), toutes les listes de points d'ancrage ordonnés créées par les nœuds de validation honnêtes partagent le même préfixe. Dans Shoal, nous avons observé :
Tous les validateurs s'accordent sur le 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. Les versions de synchronisation partielle ont un délai meilleur que les versions asynchrones, mais ne sont toujours pas optimales.
Question 1: Délai moyen de bloc. Dans Bullshark, chaque round pair a un point d'ancrage, et les sommets des rounds 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, mais les sommets dans l'historique causale des points d'ancrage nécessitent des tours supplémentaires pour attendre que les points d'ancrage soient triés. Dans les cas courants, les sommets des rounds impairs nécessitent trois tours, tandis que les sommets non ancrés des rounds pairs nécessitent quatre tours.
Problème 2 : Délai de défaillance. Si un leader ne parvient pas à diffuser l'ancre à temps, il ne peut pas être trié ( est sauté ), 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, surtout parce que Bullshark utilise un temps d'attente pour le leader.
Cadre Shoal
Shoal améliore Bullshark( ou tout protocole BFT basé sur Narwhal) grâce à une chaîne de production, permettant à chaque tour d'avoir un point d'ancrage, réduisant le délai de tous les sommets non ancrés dans le DAG à trois tours. Shoal introduit également un mécanisme de réputation des leaders sans coût dans le DAG, favorisant le choix des leaders rapides.
défi
Dans le protocole DAG, les problèmes de pipeline et de réputation des leaders sont considérés comme des problèmes difficiles pour les raisons suivantes :
Les tentatives précédentes de modification de la logique centrale de Bullshark semblent fondamentalement 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 que les divergences d'identité des leaders ne compromettent pas la sécurité de ces protocoles, elles peuvent entraîner des classements complètement différents dans Bullshark, soulevant le cœur du problème : choisir dynamiquement et de manière déterministe les ancres de rotation est nécessaire pour résoudre le consensus, les validateurs doivent s'accorder sur un historique ordonné pour sélectionner les futures ancres.
En tant que preuve de la difficulté des problèmes, l'implémentation de Bullshark ) inclut les ( dans l'environnement de production actuel qui ne prend pas en charge ces caractéristiques.
) accord
Bien qu'il existe des défis mentionnés ci-dessus, la solution se cache dans la simplicité.
Shoal s'appuie sur la capacité d'exécuter des calculs locaux sur le DAG pour réaliser la sauvegarde et la réinterprétation des informations des tours précédents. Basé sur l'accord de tous les validateurs sur la première ancre ordonnée, Shoal combine séquentiellement plusieurs instances de Bullshark pour un traitement en pipeline, faisant de ### le point de commutation des instances de la première ancre ordonnée, ( l'histoire causale de l'ancre est utilisée pour calculer la réputation des leaders.
) ligne de production
V qui associe les tours aux leaders. Shoal exécute des instances Bullshark en séquence, chaque ancre de l'instance étant déterminée à l'avance par le mappage F. Chaque instance trie une ancre, déclenchant le passage à l'instance suivante.
Au début, Shoal a lancé la première instance de Bullshark lors du premier tour de DAG, fonctionnant jusqu'à ce que le premier point d'ancrage ordonné ( soit déterminé comme le tour r ). Tous les validateurs ont convenu de ce point d'ancrage, il est donc possible de convenir de manière définitive de la réinterprétation du DAG à partir du tour r+1. Shoal a lancé une nouvelle instance de Bullshark au tour r+1.
Dans le meilleur des cas, cela permet à Shoal de trier un ancrage par 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 son propre point d'ancrage et est trié par cette instance, puis une autre nouvelle instance trie le point d'ancrage au troisième tour, et cela continue ainsi.
![Explication détaillée du cadre Shoal : comment réduire le délai de Bullshark sur Aptos ?]###https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
) Réputation des leaders
Lorsque le tri Bullshark saute un point d'ancrage, le délai augmente. Dans ce cas, le pipeline est impuissant, car il n'est pas possible de démarrer une nouvelle instance avant le point d'ancrage de tri de l'instance précédente. Shoal attribue des scores à chaque nœud de validation par le biais d'un mécanisme de réputation, garantissant qu'il est peu probable que les leaders correspondants soient choisis à l'avenir pour traiter les points d'ancrage manquants, en fonction de leur historique d'activités récentes. Les validateurs qui répondent et participent au protocole obtiennent des scores élevés, sinon des scores faibles ( peuvent s'effondrer, être lents ou agir de manière malveillante ).
Le concept consiste à recalculer de manière déterministe la cartographie prédéfinie F du tour au leader à chaque mise à jour de score, en faveur des leaders ayant des scores élevés. Pour que les validateurs parviennent à un consensus sur la nouvelle cartographie, ils doivent parvenir à un consensus sur les scores, afin d'atteindre un consensus sur l'historique utilisé pour dériver les scores.
Dans Shoal, la chaîne de blocs et la réputation des leaders se combinent naturellement, car elles utilisent la même technologie de base : réinterpréter le DAG après avoir atteint un consensus sur le premier point d'ancrage ordonné.
La seule différence est qu'après le point d'ancrage trié à la r-ème ronde, les validateurs calculent une nouvelle correspondance 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 utilisent la fonction de sélection de point d'ancrage mise à jour F' pour exécuter une nouvelle instance de Bullshark à partir de la r+1-ème ronde.
![Explication détaillée du cadre Shoal : comment réduire le délai de Bullshark sur Aptos ?]###https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
) Pas besoin de plus de temps d'attente
Le dépassement de temps est 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 augmente également considérablement la latence, car il est important de les configurer correctement, ce qui nécessite souvent un ajustement dynamique, fortement dépendant de l'environnement ( réseau ). Avant de passer au leader suivant, le protocole paie la pénalité complète de délai pour les leaders défaillants. Par conséquent, les paramètres de dépassement de délai ne doivent pas être trop conservateurs, mais s'ils sont trop courts, le protocole peut sauter de bons leaders. Par exemple, nous avons observé que sous une forte charge, les leaders dans Jolteon/Hotstuff étaient accablés, le dépassement de délai étant déjà atteint avant de pouvoir faire avancer les choses.
Malheureusement, les protocoles de leader basés sur ### comme Hotstuff et Jolteon( nécessitent essentiellement un délai d'attente pour garantir que le protocole progresse chaque fois qu'un leader échoue. Sans délai, même un leader en panne peut arrêter le protocole indéfiniment. Étant donné qu'il est impossible de distinguer un leader en panne d'un leader lent pendant les périodes asynchrones, le délai d'attente peut amener les nœuds de validation à envisager de changer tous les leaders sans activité de consensus.
Dans Bullshark, le délai est utilisé pour la construction de DAG afin de s'assurer qu'au cours de la synchronisation, les leaders honnêtes ajoutent des points d'ancrage au DAG assez rapidement pour qu'ils puissent être triés.
Nous avons observé que la construction de DAG fournit une "horloge" pour estimer la vitesse du réseau. Sans interruption, tant que n-f validateurs honnêtes continuent d'ajouter des sommets au DAG, les tours continueront d'avancer. Bien que Bullshark puisse ne pas être en mesure de 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 ont des problèmes ou si le réseau est asynchrone. Finalement, lorsque des leaders sans défaut diffusent des points d'ancrage suffisamment rapidement, l'ensemble de l'historique causale des points d'ancrage sera trié.
En cours d'évaluation, nous avons comparé si Bullshark a un dépassement de délai dans les cas suivants :
Leader rapide, au moins plus rapide que les autres validateurs. Dans ce cas, les deux méthodes offrent la même latence, car l'ancre est ordonnée et n'utilise pas de délai.
Un leader erroné, dans ce cas, le Bullshark sans pause offre un meilleur délai, car les nœuds de validation sauteront immédiatement leur point d'ancrage, tandis que les validateurs avec pause devront attendre leur expiration avant de continuer.
Leader lent, c'est le seul cas où Bullshark a de meilleures performances en temps d'attente. Car sans pause, le point d'ancrage peut être sauté, car le leader ne peut pas le diffuser assez rapidement, tandis qu'avec une pause, les validateurs attendront le point d'ancrage.
Dans Shoal, éviter les délais est étroitement lié à la réputation du leader. Attendre à nouveau.