Cadre Shoal : Goutte significative de la latence de Bullshark sur Aptos
Aptos labs a récemment résolu deux problèmes ouverts importants dans le DAG BFT, réduisant considérablement la latence, et a éliminé pour la première fois le besoin de délais dans un protocole pratique déterministe. Dans l'ensemble, le cadre Shoal a amélioré la latence de Bullshark de 40 % en cas de fonctionnement normal 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 mécanisme de pipeline et de réputation des leaders. Le pipeline réduit la latence du tri DAG en introduisant des points d'ancrage à chaque tour, tandis que 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 asynchrone de DAG pour éliminer les délais dans tous les scénarios. Cela permet à Shoal d'offrir une caractéristique appelée réponse universelle, qui comprend généralement la réponse optimiste requise.
L'idée centrale de Shoal est très simple : il s'agit d'exécuter plusieurs instances du protocole sous-jacent dans l'ordre. Ainsi, lorsque nous instancions avec Bullshark, nous obtenons un groupe de "requins" participant à un relais.
Motivation
Dans la quête de hautes performances des réseaux blockchain, l'accent a toujours été mis sur la Goutte de la complexité de la communication. Cependant, cette approche n'a pas conduit à une augmentation significative du débit. Par exemple, le Hotstuff implémenté dans les premières versions de Diem n'a atteint que 3500 TPS, bien en deçà de l'objectif de 100 000+ TPS.
Les percées récentes proviennent de la reconnaissance que la propagation des données est le principal goulot d'étranglement basé sur le protocole de leader, 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 simultanément les données, tandis que le composant de consensus ne trie qu'un nombre limité de métadonnées. Le document Narwhal rapporte un débit de 160 000 TPS.
Dans un article précédent, nous avons présenté Quorum Store - notre implémentation de Narwhal, qui sépare la diffusion des données du consensus, ainsi que la manière 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 les changements de vue de style PBFT, ce qui permet de réduire la latence de Hotstuff de 33%. Cependant, il est clair que les protocoles de consensus basés sur un leader ne peuvent pas exploiter pleinement le 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, nous avons décidé de déployer Bullshark sur le Narwhal DAG, qui est un protocole de consensus sans frais de communication. Malheureusement, par rapport à Jolteon, la structure DAG qui supporte Bullshark avec un haut débit entraîne un coût de latence de 50 %.
Cet article présente comment Shoal parvient à réduire considérablement la latence de Bullshark.
Contexte DAG-BFT
Chaque sommet dans le DAG de Narwhal est associé à un tour. Pour entrer dans le tour r, un validateur doit d'abord obtenir n-f sommets appartenant au tour r-1. Chaque validateur peut diffuser un sommet par tour, et chaque sommet doit référencer au moins n-f sommets du tour précédent. En raison de l'asynchronicité du réseau, différents validateurs peuvent observer à tout moment différentes vues locales du DAG.
Une caractéristique clé du DAG est l'univocité : 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.
Préface
Il est possible de parvenir à 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 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 : après quelques tours, (, comme dans Bullshark, chaque deux tours, ), il y aura un leader prévu, le sommet du leader est appelé point d'ancrage.
Points d'ancrage de tri : les validateurs décident de manière indépendante mais déterministe quels points d'ancrage trier et lesquels sauter.
Tri de l'histoire causale : les validateurs traitent un par un la liste des points d'ancrage ordonnés, pour chaque point d'ancrage, ils trient tous les sommets désordonnés précédents dans son histoire causale selon des règles déterministes.
La clé pour satisfaire à la sécurité est de s'assurer qu'à l'étape (2), tous les nœuds de validation honnêtes créent une liste d'ancrage ordonnée, afin que toutes les listes 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 ait une meilleure latence que la version asynchrone, elle est loin d'être optimale.
Problème 1 : latence moyenne des blocs. Dans Bullshark, chaque tour pair a un point d'ancrage, tandis que les sommets de chaque tour impair sont interprétés comme des votes. Dans les cas courants, deux tours de DAG sont nécessaires pour trier les points d'ancrage, cependant, les sommets dans l'historique causal des points d'ancrage nécessitent plus de tours pour attendre que les points d'ancrage soient triés. Dans les cas courants, les sommets dans les tours impairs nécessitent trois tours, tandis que les sommets non ancrés dans les tours pairs nécessitent quatre tours.
Problème 2 : latence des cas de défaillance. L'analyse de latence ci-dessus s'applique aux situations sans défaillance, d'autre part, si le leader d'un tour échoue à diffuser suffisamment rapidement le point d'ancrage, il n'est pas possible de trier le point d'ancrage ( et donc il est sauté ), 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 va considérablement Goutte les performances du réseau de réplication géographique, en particulier parce que Bullshark utilise un délai pour attendre le leader.
Cadre Shoal
Shoal a résolu ces deux problèmes de latence, en renforçant Bullshark( ou tout autre protocole BFT basé sur Narwhal) par le biais de pipelines, permettant d'avoir un point d'ancrage à chaque tour et réduisant la latence de tous les sommets non ancrés dans le DAG à trois tours. Shoal a également introduit un mécanisme de réputation de leader à coût nul dans le DAG, ce qui favorise le choix des leaders rapides.
Défi
Dans le contexte du protocole DAG, le pipeline et la réputation des leaders sont considérés comme des problèmes difficiles, pour les raisons suivantes :
Les tentatives précédentes de la chaîne de production de modifier la logique fondamentale de Bullshark semblent, en essence, impossibles.
La réputation des leaders est introduite dans DiemBFT et formalisée dans Carousel, et elle est basée sur la performance passée des validateurs pour sélectionner dynamiquement les futurs leaders. L'idée des ancres dans Bullshark est de (. Bien que des divergences sur l'identité des leaders ne violent pas la sécurité de ces protocoles, dans Bullshark, cela peut conduire à un classement complètement différent, ce qui soulève le cœur du problème, à savoir que le choix dynamique et déterministe des ancres de roue est nécessaire pour résoudre le consensus, et les validateurs doivent parvenir à un accord sur l'historique ordonné pour sélectionner les futures ancres.
En tant que preuve de la difficulté du problème, nous remarquons que l'implémentation de Bullshark, y compris celle actuellement en production, ne prend pas en charge ces fonctionnalités.
Protocole
Malgré les défis mentionnés ci-dessus, il s'avère que la solution se cache dans la simplicité.
Dans Shoal, nous comptons sur la capacité d'effectuer des calculs locaux sur le DAG et 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 où tous les validateurs s'accordent sur le premier point d'ancrage ordonné, Shoal combine séquentiellement 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 du point d'ancrage utilisé pour calculer la réputation du 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-46d37add0d9e81b2f295edf8eddd907f.webp(
Chaîne de montage
V qui associe les tours aux leaders. Shoal exécute des instances de Bullshark les unes après les autres, de sorte que pour chaque instance, l'ancre est prédéterminée par le mappage F. Chaque instance trie une ancre, ce qui déclenche le passage à l'instance suivante.
Au début, Shoal a lancé le premier instance de Bullshark dans le 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 trier un ancrage à chaque tour. Le point d'ancrage du premier tour est trié par le premier instance. Ensuite, Shoal commence un nouvel instance au deuxième tour, qui a lui-même un point d'ancrage, cet ancrage étant trié par cette instance, puis un autre nouvel 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
Lorsqu'un point d'ancrage est sauté pendant le tri Bullshark, la latence augmente. Dans ce cas, la technique de pipeline est impuissante, car une nouvelle instance ne peut pas être lancée avant que le point d'ancrage de l'instance précédente ne soit trié. Shoal s'assure qu'il est peu probable de choisir le leader correspondant pour traiter les points d'ancrage manquants à l'avenir en attribuant un score à chaque nœud de validation en fonction de l'historique de l'activité récente de chaque nœud de validation grâce à un mécanisme de réputation. Les validateurs qui répondent et participent au protocole recevront un score élevé, sinon, les nœuds de validation se verront attribuer un score bas, car ils peuvent s'effondrer, être lents ou agir de manière malveillante.
Son principe est de recalculer de manière déterministe le mappage prédéfini F du tour au leader à chaque mise à jour des scores, en faveur des 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, la chaîne de production et la réputation des leaders peuvent se combiner naturellement, car elles utilisent toutes 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 le 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 exécutent une nouvelle instance de Bullshark à partir de la (r+1)-ème ronde en utilisant la fonction de sélection de points d'ancrage mise à jour F'.
![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(
Plus de temps d'attente
Le dépassement de délai joue un rôle crucial dans toutes les mises en œuvre BFT déterministes basées sur un leader. Cependant, la complexité qu'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'observabilité.
Le dépassement de délai augmentera également considérablement la latence, car il est très important de les configurer correctement et nécessite souvent des ajustements dynamiques, car cela dépend fortement de l'environnement ) réseau (. Avant de passer au leader suivant, le protocole paiera la pénalité de latence complète pour le leader défaillant. Par conséquent, les réglages de dépassement de délai ne doivent pas être trop conservateurs, mais si le temps de dépassement est trop court, le protocole pourrait ignorer de bons leaders. Par exemple, nous avons observé que dans des conditions de forte charge, les leaders dans Jolteon/Hotstuff étaient surchargés et le temps d'attente avait expiré avant qu'ils ne fassent des progrès.
Malheureusement, basé sur le protocole de leader ) comme Hotstuff
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.
16 J'aime
Récompense
16
10
Reposter
Partager
Commentaire
0/400
TokenomicsTrapper
· 07-16 23:24
classic vc fumée et miroirs... 40% ne signifie rien si la latence de base était nulle à vrai dire
Voir l'originalRépondre0
rekt_but_resilient
· 07-16 17:01
latence réduite de 80 % ? To the moon
Voir l'originalRépondre0
NestedFox
· 07-16 09:09
L'amélioration à quatre-vingts degrés est incroyable.
Voir l'originalRépondre0
Blockwatcher9000
· 07-15 13:37
Encore en train de surmonter la latence, super !
Voir l'originalRépondre0
GasFeePhobia
· 07-14 02:57
40 pas 80 c'est trop fort ? L'effet est bon.
Voir l'originalRépondre0
MEVHunterBearish
· 07-14 02:55
Ça a encore quelle utilité ? Nous sommes juste haussiers, pas baissiers.
Voir l'originalRépondre0
WalletsWatcher
· 07-14 02:55
Ah, ça y est, la latence est enfin réglée.
Voir l'originalRépondre0
CryptoFortuneTeller
· 07-14 02:45
Acheter aptos acheter aptos il n'y en a presque plus
Voir l'originalRépondre0
MetamaskMechanic
· 07-14 02:43
J'ai commencé à me connecter, quelqu'un a encore optimisé la latence.
Voir l'originalRépondre0
LeverageAddict
· 07-14 02:42
Bullshark bull ah peut courir plus vite maintenant
Le cadre Shoal réduit considérablement la latence de Bullshark sur Aptos, permettant un consensus déterministe sans dépassement de délai.
Cadre Shoal : Goutte significative de la latence de Bullshark sur Aptos
Aptos labs a récemment résolu deux problèmes ouverts importants dans le DAG BFT, réduisant considérablement la latence, et a éliminé pour la première fois le besoin de délais dans un protocole pratique déterministe. Dans l'ensemble, le cadre Shoal a amélioré la latence de Bullshark de 40 % en cas de fonctionnement normal 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 mécanisme de pipeline et de réputation des leaders. Le pipeline réduit la latence du tri DAG en introduisant des points d'ancrage à chaque tour, tandis que 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 asynchrone de DAG pour éliminer les délais dans tous les scénarios. Cela permet à Shoal d'offrir une caractéristique appelée réponse universelle, qui comprend généralement la réponse optimiste requise.
L'idée centrale de Shoal est très simple : il s'agit d'exécuter plusieurs instances du protocole sous-jacent dans l'ordre. Ainsi, lorsque nous instancions avec Bullshark, nous obtenons un groupe de "requins" participant à un relais.
Motivation
Dans la quête de hautes performances des réseaux blockchain, l'accent a toujours été mis sur la Goutte de la complexité de la communication. Cependant, cette approche n'a pas conduit à une augmentation significative du débit. Par exemple, le Hotstuff implémenté dans les premières versions de Diem n'a atteint que 3500 TPS, bien en deçà de l'objectif de 100 000+ TPS.
Les percées récentes proviennent de la reconnaissance que la propagation des données est le principal goulot d'étranglement basé sur le protocole de leader, 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 simultanément les données, tandis que le composant de consensus ne trie qu'un nombre limité de métadonnées. Le document Narwhal rapporte un débit de 160 000 TPS.
Dans un article précédent, nous avons présenté Quorum Store - notre implémentation de Narwhal, qui sépare la diffusion des données du consensus, ainsi que la manière 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 les changements de vue de style PBFT, ce qui permet de réduire la latence de Hotstuff de 33%. Cependant, il est clair que les protocoles de consensus basés sur un leader ne peuvent pas exploiter pleinement le 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, nous avons décidé de déployer Bullshark sur le Narwhal DAG, qui est un protocole de consensus sans frais de communication. Malheureusement, par rapport à Jolteon, la structure DAG qui supporte Bullshark avec un haut débit entraîne un coût de latence de 50 %.
Cet article présente comment Shoal parvient à réduire considérablement la latence de Bullshark.
Contexte DAG-BFT
Chaque sommet dans le DAG de Narwhal est associé à un tour. Pour entrer dans le tour r, un validateur doit d'abord obtenir n-f sommets appartenant au tour r-1. Chaque validateur peut diffuser un sommet par tour, et chaque sommet doit référencer au moins n-f sommets du tour précédent. En raison de l'asynchronicité du réseau, différents validateurs peuvent observer à tout moment différentes vues locales du DAG.
Une caractéristique clé du DAG est l'univocité : 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.
Préface
Il est possible de parvenir à 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 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 : après quelques tours, (, comme dans Bullshark, chaque deux tours, ), il y aura un leader prévu, le sommet du leader est appelé point d'ancrage.
Points d'ancrage de tri : les validateurs décident de manière indépendante mais déterministe quels points d'ancrage trier et lesquels sauter.
Tri de l'histoire causale : les validateurs traitent un par un la liste des points d'ancrage ordonnés, pour chaque point d'ancrage, ils trient tous les sommets désordonnés précédents dans son histoire causale selon des règles déterministes.
La clé pour satisfaire à la sécurité est de s'assurer qu'à l'étape (2), tous les nœuds de validation honnêtes créent une liste d'ancrage ordonnée, afin que toutes les listes 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 ait une meilleure latence que la version asynchrone, elle est loin d'être optimale.
Problème 1 : latence moyenne des blocs. Dans Bullshark, chaque tour pair a un point d'ancrage, tandis que les sommets de chaque tour impair sont interprétés comme des votes. Dans les cas courants, deux tours de DAG sont nécessaires pour trier les points d'ancrage, cependant, les sommets dans l'historique causal des points d'ancrage nécessitent plus de tours pour attendre que les points d'ancrage soient triés. Dans les cas courants, les sommets dans les tours impairs nécessitent trois tours, tandis que les sommets non ancrés dans les tours pairs nécessitent quatre tours.
Problème 2 : latence des cas de défaillance. L'analyse de latence ci-dessus s'applique aux situations sans défaillance, d'autre part, si le leader d'un tour échoue à diffuser suffisamment rapidement le point d'ancrage, il n'est pas possible de trier le point d'ancrage ( et donc il est sauté ), 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 va considérablement Goutte les performances du réseau de réplication géographique, en particulier parce que Bullshark utilise un délai pour attendre le leader.
Cadre Shoal
Shoal a résolu ces deux problèmes de latence, en renforçant Bullshark( ou tout autre protocole BFT basé sur Narwhal) par le biais de pipelines, permettant d'avoir un point d'ancrage à chaque tour et réduisant la latence de tous les sommets non ancrés dans le DAG à trois tours. Shoal a également introduit un mécanisme de réputation de leader à coût nul dans le DAG, ce qui favorise le choix des leaders rapides.
Défi
Dans le contexte du protocole DAG, le pipeline et la réputation des leaders sont considérés comme des problèmes difficiles, pour les raisons suivantes :
Les tentatives précédentes de la chaîne de production de modifier la logique fondamentale de Bullshark semblent, en essence, impossibles.
La réputation des leaders est introduite dans DiemBFT et formalisée dans Carousel, et elle est basée sur la performance passée des validateurs pour sélectionner dynamiquement les futurs leaders. L'idée des ancres dans Bullshark est de (. Bien que des divergences sur l'identité des leaders ne violent pas la sécurité de ces protocoles, dans Bullshark, cela peut conduire à un classement complètement différent, ce qui soulève le cœur du problème, à savoir que le choix dynamique et déterministe des ancres de roue est nécessaire pour résoudre le consensus, et les validateurs doivent parvenir à un accord sur l'historique ordonné pour sélectionner les futures ancres.
En tant que preuve de la difficulté du problème, nous remarquons que l'implémentation de Bullshark, y compris celle actuellement en production, ne prend pas en charge ces fonctionnalités.
Protocole
Malgré les défis mentionnés ci-dessus, il s'avère que la solution se cache dans la simplicité.
Dans Shoal, nous comptons sur la capacité d'effectuer des calculs locaux sur le DAG et 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 où tous les validateurs s'accordent sur le premier point d'ancrage ordonné, Shoal combine séquentiellement 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 du point d'ancrage utilisé pour calculer la réputation du 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-46d37add0d9e81b2f295edf8eddd907f.webp(
Chaîne de montage
V qui associe les tours aux leaders. Shoal exécute des instances de Bullshark les unes après les autres, de sorte que pour chaque instance, l'ancre est prédéterminée par le mappage F. Chaque instance trie une ancre, ce qui déclenche le passage à l'instance suivante.
Au début, Shoal a lancé le premier instance de Bullshark dans le 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 trier un ancrage à chaque tour. Le point d'ancrage du premier tour est trié par le premier instance. Ensuite, Shoal commence un nouvel instance au deuxième tour, qui a lui-même un point d'ancrage, cet ancrage étant trié par cette instance, puis un autre nouvel 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
Lorsqu'un point d'ancrage est sauté pendant le tri Bullshark, la latence augmente. Dans ce cas, la technique de pipeline est impuissante, car une nouvelle instance ne peut pas être lancée avant que le point d'ancrage de l'instance précédente ne soit trié. Shoal s'assure qu'il est peu probable de choisir le leader correspondant pour traiter les points d'ancrage manquants à l'avenir en attribuant un score à chaque nœud de validation en fonction de l'historique de l'activité récente de chaque nœud de validation grâce à un mécanisme de réputation. Les validateurs qui répondent et participent au protocole recevront un score élevé, sinon, les nœuds de validation se verront attribuer un score bas, car ils peuvent s'effondrer, être lents ou agir de manière malveillante.
Son principe est de recalculer de manière déterministe le mappage prédéfini F du tour au leader à chaque mise à jour des scores, en faveur des 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, la chaîne de production et la réputation des leaders peuvent se combiner naturellement, car elles utilisent toutes 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 le 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 exécutent une nouvelle instance de Bullshark à partir de la (r+1)-ème ronde en utilisant la fonction de sélection de points d'ancrage mise à jour F'.
![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(
Plus de temps d'attente
Le dépassement de délai joue un rôle crucial dans toutes les mises en œuvre BFT déterministes basées sur un leader. Cependant, la complexité qu'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'observabilité.
Le dépassement de délai augmentera également considérablement la latence, car il est très important de les configurer correctement et nécessite souvent des ajustements dynamiques, car cela dépend fortement de l'environnement ) réseau (. Avant de passer au leader suivant, le protocole paiera la pénalité de latence complète pour le leader défaillant. Par conséquent, les réglages de dépassement de délai ne doivent pas être trop conservateurs, mais si le temps de dépassement est trop court, le protocole pourrait ignorer de bons leaders. Par exemple, nous avons observé que dans des conditions de forte charge, les leaders dans Jolteon/Hotstuff étaient surchargés et le temps d'attente avait expiré avant qu'ils ne fassent des progrès.
Malheureusement, basé sur le protocole de leader ) comme Hotstuff