Cadre Shoal : comment Goutte la latence de Bullshark sur Aptos ?
Aperçu
Aptos labs a résolu deux problèmes ouverts importants dans le DAG BFT, réduisant considérablement la latence, et a éliminé pour la première fois le besoin de délais dans les protocoles pratiques 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.
Shoal est un cadre qui renforce le protocole de consensus basé sur Narwhal ( grâce à des pipelines et à la réputation des leaders, tel que DAG-Rider, Tusk, Bullshark ). Le pipeline réduit la latence de tri du DAG en introduisant un point d'ancrage à chaque tour, et la réputation des leaders améliore davantage le problème de 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 de DAG asynchrone pour éliminer les délais dans tous les scénarios. Cela permet à Shoal d'offrir une propriété appelée réponse universelle, qui contient la réponse optimiste généralement nécessaire.
Cette technologie est très simple, impliquant l'exécution séquentielle de plusieurs instances du protocole sous-jacent. Ainsi, lorsque nous instancions avec Bullshark, nous obtenons un groupe de "requins" participant à une course de relais.
Motivation
Dans la quête d'une haute performance des réseaux blockchain, les gens se sont toujours concentrés sur la Goutte de la complexité de communication. Cependant, cette approche 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 atteint que 3500 TPS, bien en dessous de l'objectif de 100k+ TPS.
La percée récente provient de la prise de conscience que la propagation des données est le principal goulet d'étranglement basé sur les protocoles de leadership, et qu'elle peut bénéficier de la parallélisation. Le système Narwhal dissocie la propagation des données de la logique de consensus de base, proposant une architecture où tous les validateurs propagent les données simultanément, tandis que le composant de consensus ne commande qu'une petite quantité de métadonnées. Le document Narwhal rapporte un débit de 160 000 TPS.
Dans un 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, combinant le chemin rapide linéaire de Tendermint et le changement 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 tirer pleinement parti du potentiel de débit de Narwhal. Bien que la propagation 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 au-dessus de Narwhal DAG, qui est un protocole de consensus sans coût de communication. Malheureusement, par rapport à Jolteon, la structure DAG prenant en charge Bullshark à haut débit entraîne un coût de latence de 50 %.
Cet article présente comment Shoal parvient à Goutte 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 différentes vues locales du DAG à tout moment.
Une caractéristique clé du DAG est qu'elle n'est pas ambiguë : si deux nœuds de validation ont le même sommet v dans leur vue locale du DAG, alors ils ont exactement la même histoire causale de v.
Classement général
Il est possible d'atteindre un consensus sur l'ordre total de tous les sommets dans le DAG sans frais de communication supplémentaires. Pour cela, les validateurs de 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 dans la structure DAG soit différente, tous les protocoles de consensus basés sur Narwhal existants ont la structure suivante :
Point d'ancrage prévu : tous les quelques tours ( par exemple, dans Bullshark, deux tours ) auront un leader prédéfini, 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 ;
Histoire de causalité ordonnée : les validateurs traitent un à un leur liste d'ancrages ordonnée, et pour chaque ancrage, ils trient tous les sommets précédemment non ordonnés dans leur histoire causale selon certaines 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 ci-dessus:
Tous les validateurs conviennent du 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 tour impair est interprété comme un vote. Dans des cas courants, il faut deux tours de DAG pour commander les points d'ancrage, cependant, les sommets dans l'historique causal des points d'ancrage nécessitent plus de tours pour attendre que le point d'ancrage soit trié. Dans des 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 n'est pas assez rapide pour diffuser le point d'ancrage, il ne peut pas être trié ( et est donc ignoré ). 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 réduira considérablement les performances du réseau de réplication géographique, en particulier en raison du délai Bullshark utilisé 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 sans coût dans le DAG, ce qui favorise le choix de leaders rapides.
Défi
Dans le contexte du protocole DAG, la réputation des pipelines et des leaders est considérée comme un problème difficile, pour les raisons suivantes :
Les anciennes chaînes de production ont tenté de modifier la logique centrale de Bullshark, mais cela semble fondamentalement impossible.
La réputation des leaders est introduite dans DiemBFT et formalisée dans Carousel, selon l'idée de sélectionner dynamiquement les futurs leaders en fonction des performances passées des validateurs dans l'ancre de Bullshark (. Bien que des divergences sur l'identité des leaders ne violent pas la sécurité de ces protocoles, dans Bullshark, cela peut conduire à des ordres complètement différents, ce qui soulève le cœur du problème, à savoir que choisir dynamiquement et de manière déterministe l'ancre de la roue est nécessaire pour résoudre le consensus, et les validateurs doivent parvenir à un consensus sur l'historique ordonné pour choisir les futures ancres.
En tant que preuve de la difficulté du problème, nous avons remarqué que l'implémentation de Bullshark, y compris celle actuellement en production, ne prend pas en charge ces caractéristiques.
![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(
Protocole
Malgré les défis mentionnés ci-dessus, comme le dit le proverbe, la solution se trouve dans la simplicité.
Dans Shoal, nous nous appuyons sur la capacité d'exécuter des calculs locaux sur le DAG et avons réalisé la capacité de conserver et de réinterpréter les informations des tours précédents. Grâce à l'insight fondamental selon lequel 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, faisant de ) le premier point d'ancrage ordonné le point de basculement des instances, ainsi que ( l'historique causale du point d'ancrage utilisé pour calculer la réputation des leaders.
Chaîne de production
Comme Bullshark, les validateurs parviennent a priori à un consensus sur les points d'ancrage potentiels, c'est-à-dire qu'il existe un mapping connu F : R -\u003e V qui mappe les tours aux leaders. Shoal exécute un par un les instances de Bullshark, de sorte que pour chaque instance, l'ancre est prédéterminée par le mapping F. Chaque instance commande une ancre, ce qui déclenche le passage à l'instance suivante.
Au départ, Shoal a lancé le premier instance de Bullshark lors de la première ronde du DAG et l'a exécuté jusqu'à ce que le premier point d'ancrage ordonné soit déterminé, par exemple lors de la ronde 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 de la ronde r+1. Shoal a simplement lancé une nouvelle instance de Bullshark lors de la ronde 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 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 lors de la troisième ronde, puis le processus se poursuit.
![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(
Réputation des leaders
Lorsque vous sautez un point d'ancrage pendant le tri de 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 garantit qu'il est peu probable que le leader correspondant soit choisi à l'avenir pour traiter les points d'ancrage manquants en attribuant un score à chaque nœud de validation en fonction de l'historique des activités récentes de chaque nœud de validation grâce à un mécanisme de réputation. Les validateurs qui répondent et participent au protocole obtiendront un score élevé, sinon, les nœuds de validation se verront attribuer un score bas, car ils peuvent être en panne, lents ou malveillants.
Son principe est de recalculer de manière déterministe la fonction de mapping prédéfinie F entre les tours et le leader à chaque mise à jour des scores, en faveur des leaders ayant un score plus élevé. Pour que les validateurs parviennent à un consensus sur le nouveau mapping, ils doivent s'accorder sur les scores, atteignant ainsi 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 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 du tour r, les validateurs n'ont qu'à calculer le nouveau mapping F' à partir du tour r+1 en se basant sur l'historique causale des points d'ancrage ordonnés lors du tour r. Ensuite, les nœuds de validation exécutent une nouvelle instance de Bullshark en utilisant la fonction de sélection de points d'ancrage mise à jour F' à partir du tour r+1.
![Explication détaillée du cadre Shoal : comment réduire la latence de Bullshark sur Aptos ?])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Pas de délai supplémentaire
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'observation.
Le dépassement de temps augmentera également considérablement la latence, car il est très important de les configurer correctement, et il est souvent nécessaire de les ajuster dynamiquement, car il dépend fortement de l'environnement ) réseau (. Avant de passer au prochain leader, le protocole paiera la pénalité de latence complète pour le leader en panne. Par conséquent, les paramètres de dépassement de temps ne peuvent pas être trop conservateurs, mais si
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.
13 J'aime
Récompense
13
6
Reposter
Partager
Commentaire
0/400
SlowLearnerWang
· Il y a 8h
latence réduite de 40%... Ce bug a été corrigé de manière tellement bull, non?
Voir l'originalRépondre0
NFTArchaeologis
· Il y a 8h
Tout comme les inscriptions sur les os oraculaires marquent les maillons de la chaîne numérique, le cadre de Shoal innove en période de turbidité.
Voir l'originalRépondre0
PumpDetector
· Il y a 8h
hmm bullshark devient plus rapide mais je lis toujours entre les lignes... quelque chose semble étrange pour être honnête
Voir l'originalRépondre0
SerumSquirrel
· Il y a 8h
Une augmentation de 40% c'est aussi fou?
Voir l'originalRépondre0
DegenWhisperer
· Il y a 8h
Combien cela va-t-il coûter pour optimiser la latence ?
Optimisation du cadre Shoal pour le Consensus Aptos, Goutte considérable de la latence Bullshark.
Cadre Shoal : comment Goutte la latence de Bullshark sur Aptos ?
Aperçu
Aptos labs a résolu deux problèmes ouverts importants dans le DAG BFT, réduisant considérablement la latence, et a éliminé pour la première fois le besoin de délais dans les protocoles pratiques 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.
Shoal est un cadre qui renforce le protocole de consensus basé sur Narwhal ( grâce à des pipelines et à la réputation des leaders, tel que DAG-Rider, Tusk, Bullshark ). Le pipeline réduit la latence de tri du DAG en introduisant un point d'ancrage à chaque tour, et la réputation des leaders améliore davantage le problème de 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 de DAG asynchrone pour éliminer les délais dans tous les scénarios. Cela permet à Shoal d'offrir une propriété appelée réponse universelle, qui contient la réponse optimiste généralement nécessaire.
Cette technologie est très simple, impliquant l'exécution séquentielle de plusieurs instances du protocole sous-jacent. Ainsi, lorsque nous instancions avec Bullshark, nous obtenons un groupe de "requins" participant à une course de relais.
Motivation
Dans la quête d'une haute performance des réseaux blockchain, les gens se sont toujours concentrés sur la Goutte de la complexité de communication. Cependant, cette approche 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 atteint que 3500 TPS, bien en dessous de l'objectif de 100k+ TPS.
La percée récente provient de la prise de conscience que la propagation des données est le principal goulet d'étranglement basé sur les protocoles de leadership, et qu'elle peut bénéficier de la parallélisation. Le système Narwhal dissocie la propagation des données de la logique de consensus de base, proposant une architecture où tous les validateurs propagent les données simultanément, tandis que le composant de consensus ne commande qu'une petite quantité de métadonnées. Le document Narwhal rapporte un débit de 160 000 TPS.
Dans un 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, combinant le chemin rapide linéaire de Tendermint et le changement 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 tirer pleinement parti du potentiel de débit de Narwhal. Bien que la propagation 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 au-dessus de Narwhal DAG, qui est un protocole de consensus sans coût de communication. Malheureusement, par rapport à Jolteon, la structure DAG prenant en charge Bullshark à haut débit entraîne un coût de latence de 50 %.
Cet article présente comment Shoal parvient à Goutte 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 différentes vues locales du DAG à tout moment.
Une caractéristique clé du DAG est qu'elle n'est pas ambiguë : si deux nœuds de validation ont le même sommet v dans leur vue locale du DAG, alors ils ont exactement la même histoire causale de v.
Classement général
Il est possible d'atteindre un consensus sur l'ordre total de tous les sommets dans le DAG sans frais de communication supplémentaires. Pour cela, les validateurs de 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 dans la structure DAG soit différente, tous les protocoles de consensus basés sur Narwhal existants ont la structure suivante :
Point d'ancrage prévu : tous les quelques tours ( par exemple, dans Bullshark, deux tours ) auront un leader prédéfini, 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 ;
Histoire de causalité ordonnée : les validateurs traitent un à un leur liste d'ancrages ordonnée, et pour chaque ancrage, ils trient tous les sommets précédemment non ordonnés dans leur histoire causale selon certaines 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 ci-dessus:
Tous les validateurs conviennent du 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 tour impair est interprété comme un vote. Dans des cas courants, il faut deux tours de DAG pour commander les points d'ancrage, cependant, les sommets dans l'historique causal des points d'ancrage nécessitent plus de tours pour attendre que le point d'ancrage soit trié. Dans des 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 n'est pas assez rapide pour diffuser le point d'ancrage, il ne peut pas être trié ( et est donc ignoré ). 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 réduira considérablement les performances du réseau de réplication géographique, en particulier en raison du délai Bullshark utilisé 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 sans coût dans le DAG, ce qui favorise le choix de leaders rapides.
Défi
Dans le contexte du protocole DAG, la réputation des pipelines et des leaders est considérée comme un problème difficile, pour les raisons suivantes :
Les anciennes chaînes de production ont tenté de modifier la logique centrale de Bullshark, mais cela semble fondamentalement impossible.
La réputation des leaders est introduite dans DiemBFT et formalisée dans Carousel, selon l'idée de sélectionner dynamiquement les futurs leaders en fonction des performances passées des validateurs dans l'ancre de Bullshark (. Bien que des divergences sur l'identité des leaders ne violent pas la sécurité de ces protocoles, dans Bullshark, cela peut conduire à des ordres complètement différents, ce qui soulève le cœur du problème, à savoir que choisir dynamiquement et de manière déterministe l'ancre de la roue est nécessaire pour résoudre le consensus, et les validateurs doivent parvenir à un consensus sur l'historique ordonné pour choisir les futures ancres.
En tant que preuve de la difficulté du problème, nous avons remarqué que l'implémentation de Bullshark, y compris celle actuellement en production, ne prend pas en charge ces caractéristiques.
![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(
Protocole
Malgré les défis mentionnés ci-dessus, comme le dit le proverbe, la solution se trouve dans la simplicité.
Dans Shoal, nous nous appuyons sur la capacité d'exécuter des calculs locaux sur le DAG et avons réalisé la capacité de conserver et de réinterpréter les informations des tours précédents. Grâce à l'insight fondamental selon lequel 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, faisant de ) le premier point d'ancrage ordonné le point de basculement des instances, ainsi que ( l'historique causale du point d'ancrage utilisé pour calculer la réputation des leaders.
Chaîne de production
Comme Bullshark, les validateurs parviennent a priori à un consensus sur les points d'ancrage potentiels, c'est-à-dire qu'il existe un mapping connu F : R -\u003e V qui mappe les tours aux leaders. Shoal exécute un par un les instances de Bullshark, de sorte que pour chaque instance, l'ancre est prédéterminée par le mapping F. Chaque instance commande une ancre, ce qui déclenche le passage à l'instance suivante.
Au départ, Shoal a lancé le premier instance de Bullshark lors de la première ronde du DAG et l'a exécuté jusqu'à ce que le premier point d'ancrage ordonné soit déterminé, par exemple lors de la ronde 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 de la ronde r+1. Shoal a simplement lancé une nouvelle instance de Bullshark lors de la ronde 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 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 lors de la troisième ronde, puis le processus se poursuit.
![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(
Réputation des leaders
Lorsque vous sautez un point d'ancrage pendant le tri de 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 garantit qu'il est peu probable que le leader correspondant soit choisi à l'avenir pour traiter les points d'ancrage manquants en attribuant un score à chaque nœud de validation en fonction de l'historique des activités récentes de chaque nœud de validation grâce à un mécanisme de réputation. Les validateurs qui répondent et participent au protocole obtiendront un score élevé, sinon, les nœuds de validation se verront attribuer un score bas, car ils peuvent être en panne, lents ou malveillants.
Son principe est de recalculer de manière déterministe la fonction de mapping prédéfinie F entre les tours et le leader à chaque mise à jour des scores, en faveur des leaders ayant un score plus élevé. Pour que les validateurs parviennent à un consensus sur le nouveau mapping, ils doivent s'accorder sur les scores, atteignant ainsi 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 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 du tour r, les validateurs n'ont qu'à calculer le nouveau mapping F' à partir du tour r+1 en se basant sur l'historique causale des points d'ancrage ordonnés lors du tour r. Ensuite, les nœuds de validation exécutent une nouvelle instance de Bullshark en utilisant la fonction de sélection de points d'ancrage mise à jour F' à partir du tour r+1.
![Explication détaillée du cadre Shoal : comment réduire la latence de Bullshark sur Aptos ?])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
Pas de délai supplémentaire
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'observation.
Le dépassement de temps augmentera également considérablement la latence, car il est très important de les configurer correctement, et il est souvent nécessaire de les ajuster dynamiquement, car il dépend fortement de l'environnement ) réseau (. Avant de passer au prochain leader, le protocole paiera la pénalité de latence complète pour le leader en panne. Par conséquent, les paramètres de dépassement de temps ne peuvent pas être trop conservateurs, mais si