Cadre Shoal : Goutte importante de la latence de Bullshark sur Aptos
Aptos Labs a récemment résolu deux problèmes ouverts importants dans le DAG BFT, ce qui a considérablement Goutte la latence et a, pour la première fois, éliminé le besoin de délais dans le protocole pratique déterministe. En général, dans des conditions sans défaillance, la latence de Bullshark s'est améliorée de 40 %, et dans des conditions de défaillance, elle s'est 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 à des pipelines et à la réputation des leaders. Les pipelines réduisent la latence de tri DAG en introduisant un point d'ancrage à chaque tour, tandis que la réputation des leaders améliore encore la latence en s'assurant 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 DAG asynchrone pour éliminer les délais d'attente dans tous les scénarios. Cela permet à Shoal d'offrir ce que nous appelons la propriété de réponse universelle, qui comprend les réponses optimistes généralement nécessaires.
Notre technologie est très simple, impliquant l'exécution de plusieurs instances du protocole sous-jacent les unes après les autres. Ainsi, lorsque nous instancions Bullshark, nous obtenons un groupe de "requins" participant à une course de relais.
Motivation
Dans la recherche de haute performance pour les réseaux blockchain, les gens se sont toujours concentrés sur la Goutte de la complexité de communication. Cependant, cette méthode n'a pas conduit à une amélioration significative du débit. Par exemple, le Hotstuff implémenté dans les premières versions de Diem n'a réalisé que 3500 TPS, bien en deçà de notre objectif de 100k+ TPS.
Cependant, la percée récente provient de la compréhension 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 de base et propose une architecture où tous les validateurs propagent simultanément les données, tandis que le composant de consensus ne commande qu'une petite quantité de métadonnées. Le document Narwhal rapporte un débit de 160 000 TPS.
Dans l'article précédent, nous avons présenté Quorum Store. Notre implémentation Narwhal sépare la propagation des données du consensus, et comment nous l'utilisons 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 la latence de Hotstuff de 33 %. Cependant, il est clair que les protocoles de consensus basés sur un leader ne peuvent pas pleinement exploiter le potentiel de débit de Narwhal. Bien que la propagation des données et le consensus soient séparés, avec l'augmentation du débit, le leader de Hotstuff/Jolteon est toujours limité.
Ainsi, nous avons décidé de déployer Bullshark, un protocole de consensus sans coût de communication, sur le Narwhal DAG. Malheureusement, par rapport à Jolteon, la structure DAG prenant en charge un haut débit pour Bullshark entraîne un coût de latence de 50 %.
Dans cet article, nous présentons comment Shoal parvient à réduire considérablement la latence de Bullshark.
Contexte DAG-BFT
Commençons par comprendre le contexte pertinent de cet article.
Chaque sommet dans le DAG de Narwhal est associé à un tour. Pour entrer dans le tour r, le 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'asynchronisme du réseau, différents validateurs peuvent observer à tout moment des vues locales différentes du DAG.
Une caractéristique clé du DAG 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.
Tri général
Il est possible d'atteindre un consensus sur l'ordre total de tous les sommets dans le DAG sans frais de communication supplémentaires. Pour ce faire, les validateurs dans DAG-Rider, Tusk et Bullshark interprètent la structure du DAG comme un protocole de consensus, où les sommets représentent des propositions et les arêtes représentent des votes.
Bien que la logique d'intersection des groupes basée sur la structure DAG soit différente, tous les protocoles de consensus basés sur Narwhal existants présentent la structure suivante :
Point d'ancrage prévu : tous les quelques tours ( par exemple, dans Bullshark, tous les deux tours ), il y aura 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;
Ordonnancement de l'historique causale : les validateurs traitent un par un leur liste d'ancrages ordonnée, et pour chaque ancrage, ils ordonnent tous les sommets précédemment désordonnés dans son historique causale selon certaines règles déterministes.
La clé pour satisfaire à la sécurité est de s'assurer qu'à l'étape ci-dessus (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 concernant tous les protocoles mentionnés ci-dessus:
Tous les validateurs acceptent 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, et chaque sommet du tour impair est interprété comme un vote. Dans des cas courants, deux tours de DAG sont nécessaires pour ordonner les points d'ancrage, cependant, les sommets dans l'historique causal des points d'ancrage nécessitent plus de tours pour que les points d'ancrage soient ordonné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 : latence des cas de panne, l'analyse de latence ci-dessus s'applique aux situations sans panne. D'autre part, si le leader d'un tour ne parvient pas à diffuser les points d'ancrage assez rapidement, il n'est pas possible de les trier (, ils sont donc ignorés ). Par conséquent, tous les sommets non triés des tours précédents doivent attendre que le prochain point d'ancrage soit trié. Cela va considérablement Goutte les performances du réseau de réplication géographique, en particulier parce que le délai d'attente de Bullshark est utilisé pour attendre le leader.
Cadre Shoal
Shoal a résolu ces deux problèmes de latence, en améliorant Bullshark( ou tout autre protocole BFT basé sur Narwhal) par des pipelines, permettant ainsi d'avoir un point d'ancrage à chaque tour et de réduire la latence de tous les sommets non ancrés dans le DAG à trois tours. Shoal a également introduit un mécanisme de réputation des leaders sans frais dans le DAG, ce qui favorise le choix des leaders rapides.
Défi
Dans le contexte du protocole DAG, les questions de pipeline et de réputation des leaders sont considérées comme des problèmes difficiles, pour les raisons suivantes :
Les anciens pipelines ont tenté de modifier la logique centrale de Bullshark, mais cela semble fondamentalement impossible.
La réputation des leaders est introduite dans DiemBFT et officialisée dans Carousel, elle est basée sur la performance passée des validateurs pour sélectionner dynamiquement les futurs leaders dans l'idée des ancres de Bullshark (. Bien qu'il n'y ait pas de violation de la sécurité de ces protocoles en raison de désaccords sur l'identité des leaders, dans Bullshark, cela pourrait entraîner des ordonnancements 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 roue est nécessaire pour résoudre le consensus, et que les validateurs doivent s'accorder sur un historique ordonné pour choisir les futures ancres.
En tant que preuve de la difficulté de la question, nous avons remarqué 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, comme le dit le proverbe, la solution se cache derrière 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 sauvegarder et de réinterpréter les informations des tours précédents. Grâce à l'idée fondamentale 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, rendant ) le premier point d'ancrage ordonné le point de basculement des instances, ainsi que ( l'histoire causale du point d'ancrage utilisée 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 production
V qui mappe les tours aux leaders. Shoal exécute un à un les instances de Bullshark, de sorte que pour chaque instance, l'ancre est prédéterminée par le mappage F. Chaque instance commande une ancre, ce qui déclenche le passage à l'instance suivante.
Au début, Shoal a lancé le premier instance de Bullshark lors du premier tour de DAG et l'a exécuté jusqu'à ce que le premier point d'ancrage ordonné soit déterminé, par exemple lors du 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 lors du tour r+1.
Dans le meilleur des cas, cela permet à Shoal de commander une ancre à chaque tour. Les points d'ancrage de la première ronde sont triés par le premier exemple. Ensuite, Shoal commence un nouvel exemple au début de la deuxième ronde, qui a elle-même un point d'ancrage, cette ancre étant triée par cet exemple, puis un autre nouvel exemple commande un point d'ancrage dans la troisième ronde, puis 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'on saute des points d'ancrage pendant le tri Bullshark, la latence augmente. Dans ce cas, la technologie de pipeline ne peut rien faire, 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 s'assure 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 recevront un score élevé, sinon, les nœuds de validation se verront attribuer un score bas, car ils peuvent échouer, être lents ou malveillants.
Son principe est de recalculer de manière déterministe la cartographie prédéfinie 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 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 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 convenu du 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-ième ronde, les validateurs n'ont besoin de calculer le nouveau mappage F' qu'à partir de la r+1-ième ronde, en se basant sur l'historique causal des points d'ancrage ordonnés de la r-ième ronde. Ensuite, les nœuds de validation exécutent une nouvelle instance de Bullshark à partir de la r+1-ième ronde en utilisant la fonction de sélection des 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(
Pas de temps d'attente supplémentaire
Le dépassement de délai joue un rôle crucial dans toutes les implémentations BFT déterministes basées sur un leader. Cependant, la complexité qu'ils introduisent augmente le nombre d'états internes à gérer et à observer, ce qui accroît la complexité du processus de débogage et nécessite davantage de techniques d'observabilité.
Les délais vont également augmenter considérablement la latence, car il est très important de les configurer correctement et qu'elles nécessitent souvent des ajustements dynamiques, car elles dépendent fortement de l'environnement ) réseau (. Avant de passer au leader suivant, le protocole paie la pénalité de latence de délai complet pour le leader défaillant. Par conséquent, les paramètres de délai ne doivent pas être trop conservateurs, mais si le temps de délai est trop court, le protocole peut passer de bons leaders. Par exemple, nous observons
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
6
Partager
Commentaire
0/400
FortuneTeller42
· 07-29 06:41
C'est trop puissant, une amélioration de 80 %.
Voir l'originalRépondre0
StableGeniusDegen
· 07-27 13:52
Technologie hardcore ! La hausse est à venir.
Voir l'originalRépondre0
EthSandwichHero
· 07-26 07:15
latence Goutte ? bull ah bull ah, c'est comme ça To the moon
Voir l'originalRépondre0
GasOptimizer
· 07-26 07:14
80% latence optimisée, c'est mieux que n'importe quel frais de gas.
Voir l'originalRépondre0
ContractSurrender
· 07-26 06:55
Aptos bull revient au bull, c'est juste trop cher.
Le cadre Shoal améliore considérablement les performances du réseau Aptos, la latence de Bullshark est réduite de 80%.
Cadre Shoal : Goutte importante de la latence de Bullshark sur Aptos
Aptos Labs a récemment résolu deux problèmes ouverts importants dans le DAG BFT, ce qui a considérablement Goutte la latence et a, pour la première fois, éliminé le besoin de délais dans le protocole pratique déterministe. En général, dans des conditions sans défaillance, la latence de Bullshark s'est améliorée de 40 %, et dans des conditions de défaillance, elle s'est 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 à des pipelines et à la réputation des leaders. Les pipelines réduisent la latence de tri DAG en introduisant un point d'ancrage à chaque tour, tandis que la réputation des leaders améliore encore la latence en s'assurant 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 DAG asynchrone pour éliminer les délais d'attente dans tous les scénarios. Cela permet à Shoal d'offrir ce que nous appelons la propriété de réponse universelle, qui comprend les réponses optimistes généralement nécessaires.
Notre technologie est très simple, impliquant l'exécution de plusieurs instances du protocole sous-jacent les unes après les autres. Ainsi, lorsque nous instancions Bullshark, nous obtenons un groupe de "requins" participant à une course de relais.
Motivation
Dans la recherche de haute performance pour les réseaux blockchain, les gens se sont toujours concentrés sur la Goutte de la complexité de communication. Cependant, cette méthode n'a pas conduit à une amélioration significative du débit. Par exemple, le Hotstuff implémenté dans les premières versions de Diem n'a réalisé que 3500 TPS, bien en deçà de notre objectif de 100k+ TPS.
Cependant, la percée récente provient de la compréhension 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 de base et propose une architecture où tous les validateurs propagent simultanément les données, tandis que le composant de consensus ne commande qu'une petite quantité de métadonnées. Le document Narwhal rapporte un débit de 160 000 TPS.
Dans l'article précédent, nous avons présenté Quorum Store. Notre implémentation Narwhal sépare la propagation des données du consensus, et comment nous l'utilisons 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 la latence de Hotstuff de 33 %. Cependant, il est clair que les protocoles de consensus basés sur un leader ne peuvent pas pleinement exploiter le potentiel de débit de Narwhal. Bien que la propagation des données et le consensus soient séparés, avec l'augmentation du débit, le leader de Hotstuff/Jolteon est toujours limité.
Ainsi, nous avons décidé de déployer Bullshark, un protocole de consensus sans coût de communication, sur le Narwhal DAG. Malheureusement, par rapport à Jolteon, la structure DAG prenant en charge un haut débit pour Bullshark entraîne un coût de latence de 50 %.
Dans cet article, nous présentons comment Shoal parvient à réduire considérablement la latence de Bullshark.
Contexte DAG-BFT
Commençons par comprendre le contexte pertinent de cet article.
Chaque sommet dans le DAG de Narwhal est associé à un tour. Pour entrer dans le tour r, le 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'asynchronisme du réseau, différents validateurs peuvent observer à tout moment des vues locales différentes du DAG.
Une caractéristique clé du DAG 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.
Tri général
Il est possible d'atteindre un consensus sur l'ordre total de tous les sommets dans le DAG sans frais de communication supplémentaires. Pour ce faire, les validateurs dans DAG-Rider, Tusk et Bullshark interprètent la structure du DAG comme un protocole de consensus, où les sommets représentent des propositions et les arêtes représentent des votes.
Bien que la logique d'intersection des groupes basée sur la structure DAG soit différente, tous les protocoles de consensus basés sur Narwhal existants présentent la structure suivante :
Point d'ancrage prévu : tous les quelques tours ( par exemple, dans Bullshark, tous les deux tours ), il y aura 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;
Ordonnancement de l'historique causale : les validateurs traitent un par un leur liste d'ancrages ordonnée, et pour chaque ancrage, ils ordonnent tous les sommets précédemment désordonnés dans son historique causale selon certaines règles déterministes.
La clé pour satisfaire à la sécurité est de s'assurer qu'à l'étape ci-dessus (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 concernant tous les protocoles mentionnés ci-dessus:
Tous les validateurs acceptent 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, et chaque sommet du tour impair est interprété comme un vote. Dans des cas courants, deux tours de DAG sont nécessaires pour ordonner les points d'ancrage, cependant, les sommets dans l'historique causal des points d'ancrage nécessitent plus de tours pour que les points d'ancrage soient ordonné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 : latence des cas de panne, l'analyse de latence ci-dessus s'applique aux situations sans panne. D'autre part, si le leader d'un tour ne parvient pas à diffuser les points d'ancrage assez rapidement, il n'est pas possible de les trier (, ils sont donc ignorés ). Par conséquent, tous les sommets non triés des tours précédents doivent attendre que le prochain point d'ancrage soit trié. Cela va considérablement Goutte les performances du réseau de réplication géographique, en particulier parce que le délai d'attente de Bullshark est utilisé pour attendre le leader.
Cadre Shoal
Shoal a résolu ces deux problèmes de latence, en améliorant Bullshark( ou tout autre protocole BFT basé sur Narwhal) par des pipelines, permettant ainsi d'avoir un point d'ancrage à chaque tour et de réduire la latence de tous les sommets non ancrés dans le DAG à trois tours. Shoal a également introduit un mécanisme de réputation des leaders sans frais dans le DAG, ce qui favorise le choix des leaders rapides.
Défi
Dans le contexte du protocole DAG, les questions de pipeline et de réputation des leaders sont considérées comme des problèmes difficiles, pour les raisons suivantes :
Les anciens pipelines ont tenté de modifier la logique centrale de Bullshark, mais cela semble fondamentalement impossible.
La réputation des leaders est introduite dans DiemBFT et officialisée dans Carousel, elle est basée sur la performance passée des validateurs pour sélectionner dynamiquement les futurs leaders dans l'idée des ancres de Bullshark (. Bien qu'il n'y ait pas de violation de la sécurité de ces protocoles en raison de désaccords sur l'identité des leaders, dans Bullshark, cela pourrait entraîner des ordonnancements 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 roue est nécessaire pour résoudre le consensus, et que les validateurs doivent s'accorder sur un historique ordonné pour choisir les futures ancres.
En tant que preuve de la difficulté de la question, nous avons remarqué 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, comme le dit le proverbe, la solution se cache derrière 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 sauvegarder et de réinterpréter les informations des tours précédents. Grâce à l'idée fondamentale 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, rendant ) le premier point d'ancrage ordonné le point de basculement des instances, ainsi que ( l'histoire causale du point d'ancrage utilisée 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 production
V qui mappe les tours aux leaders. Shoal exécute un à un les instances de Bullshark, de sorte que pour chaque instance, l'ancre est prédéterminée par le mappage F. Chaque instance commande une ancre, ce qui déclenche le passage à l'instance suivante.
Au début, Shoal a lancé le premier instance de Bullshark lors du premier tour de DAG et l'a exécuté jusqu'à ce que le premier point d'ancrage ordonné soit déterminé, par exemple lors du 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 lors du tour r+1.
Dans le meilleur des cas, cela permet à Shoal de commander une ancre à chaque tour. Les points d'ancrage de la première ronde sont triés par le premier exemple. Ensuite, Shoal commence un nouvel exemple au début de la deuxième ronde, qui a elle-même un point d'ancrage, cette ancre étant triée par cet exemple, puis un autre nouvel exemple commande un point d'ancrage dans la troisième ronde, puis 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'on saute des points d'ancrage pendant le tri Bullshark, la latence augmente. Dans ce cas, la technologie de pipeline ne peut rien faire, 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 s'assure 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 recevront un score élevé, sinon, les nœuds de validation se verront attribuer un score bas, car ils peuvent échouer, être lents ou malveillants.
Son principe est de recalculer de manière déterministe la cartographie prédéfinie 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 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 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 convenu du 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-ième ronde, les validateurs n'ont besoin de calculer le nouveau mappage F' qu'à partir de la r+1-ième ronde, en se basant sur l'historique causal des points d'ancrage ordonnés de la r-ième ronde. Ensuite, les nœuds de validation exécutent une nouvelle instance de Bullshark à partir de la r+1-ième ronde en utilisant la fonction de sélection des 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(
Pas de temps d'attente supplémentaire
Le dépassement de délai joue un rôle crucial dans toutes les implémentations BFT déterministes basées sur un leader. Cependant, la complexité qu'ils introduisent augmente le nombre d'états internes à gérer et à observer, ce qui accroît la complexité du processus de débogage et nécessite davantage de techniques d'observabilité.
Les délais vont également augmenter considérablement la latence, car il est très important de les configurer correctement et qu'elles nécessitent souvent des ajustements dynamiques, car elles dépendent fortement de l'environnement ) réseau (. Avant de passer au leader suivant, le protocole paie la pénalité de latence de délai complet pour le leader défaillant. Par conséquent, les paramètres de délai ne doivent pas être trop conservateurs, mais si le temps de délai est trop court, le protocole peut passer de bons leaders. Par exemple, nous observons