Le cadre Shoal réduit considérablement le délai d'Aptos sur Bullshark, tandis que le pipeline et le mécanisme de réputation améliorent significativement les performances.
Cadre Shoal : Amélioration du délai Bullshark sur Aptos
Aptos Labs a récemment résolu deux problèmes ouverts importants dans le DAG BFT, réduisant significativement la latence et éliminant pour la première fois le besoin de pauses dans un protocole pratique déterministe. Dans l'ensemble, la latence de Bullshark s'est améliorée de 40 % en cas de fonctionnement sans erreur et de 80 % en cas d'erreur.
Shoal est un cadre qui améliore tout protocole de consensus basé sur Narwhal ( tel que DAG-Rider, Tusk, Bullshark ) par le biais de pipelines et de la réputation des leaders. Le pipeline réduit la latence de tri du 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 le point d'ancrage est associé aux nœuds de validation les plus rapides. De plus, la réputation des leaders permet à Shoal d'utiliser des constructions DAG asynchrones pour éliminer les délais dans tous les scénarios. Cela permet à Shoal de fournir ce que nous appelons des propriétés de réponse universelle, qui incluent les réponses optimistes généralement requises.
Techniquement, Shoal exécute plusieurs instances de protocoles sous-jacents en séquence. Ainsi, lorsque nous instancions Bullshark, nous obtenons un groupe de "requins" participant à une course de relais.
Motivation
Lors de la recherche d'une haute performance des réseaux blockchain, les gens se sont toujours concentrés sur la réduction de la complexité de communication. Cependant, cette méthode n'a pas entraîné d'améliorations significatives du débit. Par exemple, le Hotstuff implémenté dans les premières versions de Diem n'atteignait que 3500 TPS, bien en deçà de l'objectif de 100k+ TPS.
Récemment, la percée provient de la prise de conscience que la propagation des données est le principal goulot d'étranglement basé sur des protocoles de 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, proposant une architecture où tous les validateurs propagent des données simultanément, tandis que le composant de consensus ne trie qu'un nombre limité de métadonnées. Le document de Narwhal rapporte un débit de 160 000 TPS.
Auparavant, nous avons présenté Quorum Store, qui est une réalisation de Narwhal, séparant la diffusion des données et le consensus, ainsi que comment l'utiliser 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 peut réduire le délai de Hotstuff de 33%. Cependant, les protocoles de consensus basés sur un leader ne peuvent clairement pas tirer pleinement parti du potentiel de débit de Narwhal. Bien que la diffusion des données et le consensus soient séparés, à mesure que le débit augmente, le leader de Hotstuff/Jolteon reste limité.
Ainsi, nous avons décidé de déployer Bullshark, un protocole de consensus sans frais de communication, sur le Narwhal DAG. Malheureusement, par rapport à Jolteon, la structure DAG supportant un haut débit pour Bullshark entraîne un coût de latence de 50 %.
Cet article présente comment Shoal réduit considérablement le délai 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'asynchronisme du réseau, différents validateurs peuvent observer à tout moment des vues locales différentes du DAG.
Une propriété 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.
Préface
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 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 dans une structure DAG soit différente, tous les protocoles de consensus basés sur Narwhal existants possèdent la structure suivante:
Point d'ancrage prévu : tous les quelques tours (, comme dans Bullshark où chaque 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 trier et lesquels sauter ;
Historique des causes ordonnées : les validateurs traitent une par une la liste des points d'ancrage ordonnés, et pour chaque point d'ancrage, trient tous les sommets précédemment désordonnés dans son historique causal selon des règles déterministes.
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 faisons les observations suivantes sur tous les protocoles ci-dessus :
Tous les validateurs s'accordent sur le premier point d'ancrage ordonné.
Bullshark délai
Le délai 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 un meilleur délai que la version asynchrone, elle reste loin d'être optimale.
Question 1 : Délai moyen de bloc. Dans Bullshark, chaque ronde paire a un point d'ancrage, et les sommets de chaque ronde impaire 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 de l'ancre nécessitent plus de tours d'attente pour que l'ancre soit triée. Dans les cas courants, les sommets dans les rondes impaires nécessitent trois tours, tandis que les sommets non ancrés dans les rondes paires nécessitent quatre tours.
Problème 2 : Retard dans les cas de défaillance. L'analyse des retards ci-dessus s'applique en l'absence de défaillance. D'autre part, si le leader d'un tour ne parvient pas à diffuser suffisamment rapidement 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éduit considérablement les performances du réseau de réplication géographique, surtout parce que Bullshark utilise un temps d'attente de dépassement pour le leader.
Cadre Shoal
Shoal a résolu ces deux problèmes de latence, il a renforcé le 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 rend le choix biaisé en faveur des leaders rapides.
Défi
Dans le contexte du protocole DAG, les problèmes de pipeline et de réputation des leaders sont considérés comme difficiles pour les raisons suivantes :
Il semble fondamentalement impossible de modifier la logique centrale de Bullshark, même si les anciennes chaînes de production ont tenté de le faire.
La réputation des leaders est introduite dans DiemBFT et formalisée dans Carousel, basée sur la sélection dynamique des futurs leaders en fonction des performances passées des validateurs, l'idée de l'ancre dans Bullshark (. Bien que des divergences dans l'identité des leaders ne compromettent pas la sécurité de ces protocoles, dans Bullshark, cela pourrait entraîner un ordre totalement différent, ce qui soulève le cœur du problème, à savoir que le choix dynamique et déterministe des ancres de cycle 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 qu'évidence de la difficulté des problèmes, nous avons remarqué que la mise en œuvre de Bullshark, y compris celle actuellement en production, ne prend pas en charge ces fonctionnalités.
![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(
Accord
Bien que les défis mentionnés ci-dessus existent, il s'avère que la solution se cache 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 à la compréhension fondamentale selon laquelle 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, de sorte que ) le premier point d'ancrage ordonné soit le point de basculement des instances, et ( l'historique causal des points d'ancrage soit utilisé pour calculer la réputation des leaders.
Chaîne de production
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épart, Shoal a lancé le premier instance de Bullshark lors de la première ronde de DAG et l'a fait fonctionner 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 être d'accord pour 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 trier une ancre à chaque tour. Les points d'ancrage du premier tour sont triés par la première instance. Ensuite, Shoal commence une nouvelle instance au deuxième tour, qui a elle-même un point d'ancrage, et cette ancre est triée par cette instance, puis une autre nouvelle 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-859e732e16c3eee0e2c93422474debc2.webp(
Réputation des leaders
En sautant les points d'ancrage pendant le tri de Bullshark, le délai augmente. Dans ce cas, la technologie de pipeline est impuissante, car il est impossible de lancer une nouvelle instance avant le tri du point d'ancrage de l'instance précédente. Shoal assure qu'il est peu probable que les leaders correspondants soient choisis 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 concept est de recalculer de manière déterministe le mappage prédéfini F de chaque tour au leader lors de chaque mise à jour de score, en faveur des leaders ayant obtenu des scores plus élevés. Pour que les validateurs parviennent à un consensus sur la nouvelle mappage, ils doivent parvenir à un consensus sur les scores, réalisant ainsi 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 atteint un consensus sur le premier point d'ancrage ordonné.
En fait, la seule différence est qu'après le tri des ancrages lors du tour r, les validateurs n'ont qu'à calculer le nouveau mappage F' à partir du tour r+1 en se basant sur l'historique causal des ancrages ordonnés du tour r. Ensuite, les nœuds de validation commencent à utiliser la fonction de sélection d'ancrages mise à jour F' pour exécuter une nouvelle instance de Bullshark à 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(
Plus de délais
Le timeout joue un rôle crucial dans toutes les implémentations 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'observation.
Le délai d'attente peut également augmenter considérablement la latence, car il est très important de les configurer correctement et nécessite souvent un ajustement dynamique, car il dépend fortement de l'environnement ) réseau (. Avant de passer au leader suivant, le protocole paie une pénalité de délai d'attente complète pour le leader défaillant. Par conséquent, les paramètres de délai ne doivent pas être trop conservateurs, mais si le délai est trop court, le protocole peut sauter de bons leaders. Par exemple, nous avons observé qu'en cas de forte charge, les leaders dans Jolteon/Hotstuff étaient accablés et que le délai d'attente avait expiré avant qu'ils n'effectuent des progrès.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
16 J'aime
Récompense
16
4
Partager
Commentaire
0/400
DeFiChef
· Il y a 6h
Cette augmentation de performance de 40% est agréable.
Voir l'originalRépondre0
TokenEconomist
· 07-02 09:36
en fait, l'architecture de shoal est un chef-d'œuvre de théorie des jeux. pensez-y comme à un équilibre de Nash où les validateurs optimisent la réputation = f(vitesse, fiabilité)...
Voir l'originalRépondre0
WhaleSurfer
· 07-02 09:33
bull bull bull a dépassé la limite
Voir l'originalRépondre0
TokenSleuth
· 07-02 09:24
Aptos cette optimisation bull ah latence réduite autant
Le cadre Shoal réduit considérablement le délai d'Aptos sur Bullshark, tandis que le pipeline et le mécanisme de réputation améliorent significativement les performances.
Cadre Shoal : Amélioration du délai Bullshark sur Aptos
Aptos Labs a récemment résolu deux problèmes ouverts importants dans le DAG BFT, réduisant significativement la latence et éliminant pour la première fois le besoin de pauses dans un protocole pratique déterministe. Dans l'ensemble, la latence de Bullshark s'est améliorée de 40 % en cas de fonctionnement sans erreur et de 80 % en cas d'erreur.
Shoal est un cadre qui améliore tout protocole de consensus basé sur Narwhal ( tel que DAG-Rider, Tusk, Bullshark ) par le biais de pipelines et de la réputation des leaders. Le pipeline réduit la latence de tri du 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 le point d'ancrage est associé aux nœuds de validation les plus rapides. De plus, la réputation des leaders permet à Shoal d'utiliser des constructions DAG asynchrones pour éliminer les délais dans tous les scénarios. Cela permet à Shoal de fournir ce que nous appelons des propriétés de réponse universelle, qui incluent les réponses optimistes généralement requises.
Techniquement, Shoal exécute plusieurs instances de protocoles sous-jacents en séquence. Ainsi, lorsque nous instancions Bullshark, nous obtenons un groupe de "requins" participant à une course de relais.
Motivation
Lors de la recherche d'une haute performance des réseaux blockchain, les gens se sont toujours concentrés sur la réduction de la complexité de communication. Cependant, cette méthode n'a pas entraîné d'améliorations significatives du débit. Par exemple, le Hotstuff implémenté dans les premières versions de Diem n'atteignait que 3500 TPS, bien en deçà de l'objectif de 100k+ TPS.
Récemment, la percée provient de la prise de conscience que la propagation des données est le principal goulot d'étranglement basé sur des protocoles de 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, proposant une architecture où tous les validateurs propagent des données simultanément, tandis que le composant de consensus ne trie qu'un nombre limité de métadonnées. Le document de Narwhal rapporte un débit de 160 000 TPS.
Auparavant, nous avons présenté Quorum Store, qui est une réalisation de Narwhal, séparant la diffusion des données et le consensus, ainsi que comment l'utiliser 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 peut réduire le délai de Hotstuff de 33%. Cependant, les protocoles de consensus basés sur un leader ne peuvent clairement pas tirer pleinement parti du potentiel de débit de Narwhal. Bien que la diffusion des données et le consensus soient séparés, à mesure que le débit augmente, le leader de Hotstuff/Jolteon reste limité.
Ainsi, nous avons décidé de déployer Bullshark, un protocole de consensus sans frais de communication, sur le Narwhal DAG. Malheureusement, par rapport à Jolteon, la structure DAG supportant un haut débit pour Bullshark entraîne un coût de latence de 50 %.
Cet article présente comment Shoal réduit considérablement le délai 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'asynchronisme du réseau, différents validateurs peuvent observer à tout moment des vues locales différentes du DAG.
Une propriété 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.
Préface
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 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 dans une structure DAG soit différente, tous les protocoles de consensus basés sur Narwhal existants possèdent la structure suivante:
Point d'ancrage prévu : tous les quelques tours (, comme dans Bullshark où chaque 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 trier et lesquels sauter ;
Historique des causes ordonnées : les validateurs traitent une par une la liste des points d'ancrage ordonnés, et pour chaque point d'ancrage, trient tous les sommets précédemment désordonnés dans son historique causal selon des règles déterministes.
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 faisons les observations suivantes sur tous les protocoles ci-dessus :
Tous les validateurs s'accordent sur le premier point d'ancrage ordonné.
Bullshark délai
Le délai 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 un meilleur délai que la version asynchrone, elle reste loin d'être optimale.
Question 1 : Délai moyen de bloc. Dans Bullshark, chaque ronde paire a un point d'ancrage, et les sommets de chaque ronde impaire 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 de l'ancre nécessitent plus de tours d'attente pour que l'ancre soit triée. Dans les cas courants, les sommets dans les rondes impaires nécessitent trois tours, tandis que les sommets non ancrés dans les rondes paires nécessitent quatre tours.
Problème 2 : Retard dans les cas de défaillance. L'analyse des retards ci-dessus s'applique en l'absence de défaillance. D'autre part, si le leader d'un tour ne parvient pas à diffuser suffisamment rapidement 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éduit considérablement les performances du réseau de réplication géographique, surtout parce que Bullshark utilise un temps d'attente de dépassement pour le leader.
Cadre Shoal
Shoal a résolu ces deux problèmes de latence, il a renforcé le 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 rend le choix biaisé en faveur des leaders rapides.
Défi
Dans le contexte du protocole DAG, les problèmes de pipeline et de réputation des leaders sont considérés comme difficiles pour les raisons suivantes :
Il semble fondamentalement impossible de modifier la logique centrale de Bullshark, même si les anciennes chaînes de production ont tenté de le faire.
La réputation des leaders est introduite dans DiemBFT et formalisée dans Carousel, basée sur la sélection dynamique des futurs leaders en fonction des performances passées des validateurs, l'idée de l'ancre dans Bullshark (. Bien que des divergences dans l'identité des leaders ne compromettent pas la sécurité de ces protocoles, dans Bullshark, cela pourrait entraîner un ordre totalement différent, ce qui soulève le cœur du problème, à savoir que le choix dynamique et déterministe des ancres de cycle 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 qu'évidence de la difficulté des problèmes, nous avons remarqué que la mise en œuvre de Bullshark, y compris celle actuellement en production, ne prend pas en charge ces fonctionnalités.
![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(
Accord
Bien que les défis mentionnés ci-dessus existent, il s'avère que la solution se cache 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 à la compréhension fondamentale selon laquelle 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, de sorte que ) le premier point d'ancrage ordonné soit le point de basculement des instances, et ( l'historique causal des points d'ancrage soit utilisé pour calculer la réputation des leaders.
Chaîne de production
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épart, Shoal a lancé le premier instance de Bullshark lors de la première ronde de DAG et l'a fait fonctionner 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 être d'accord pour 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 trier une ancre à chaque tour. Les points d'ancrage du premier tour sont triés par la première instance. Ensuite, Shoal commence une nouvelle instance au deuxième tour, qui a elle-même un point d'ancrage, et cette ancre est triée par cette instance, puis une autre nouvelle 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-859e732e16c3eee0e2c93422474debc2.webp(
Réputation des leaders
En sautant les points d'ancrage pendant le tri de Bullshark, le délai augmente. Dans ce cas, la technologie de pipeline est impuissante, car il est impossible de lancer une nouvelle instance avant le tri du point d'ancrage de l'instance précédente. Shoal assure qu'il est peu probable que les leaders correspondants soient choisis 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 concept est de recalculer de manière déterministe le mappage prédéfini F de chaque tour au leader lors de chaque mise à jour de score, en faveur des leaders ayant obtenu des scores plus élevés. Pour que les validateurs parviennent à un consensus sur la nouvelle mappage, ils doivent parvenir à un consensus sur les scores, réalisant ainsi 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 atteint un consensus sur le premier point d'ancrage ordonné.
En fait, la seule différence est qu'après le tri des ancrages lors du tour r, les validateurs n'ont qu'à calculer le nouveau mappage F' à partir du tour r+1 en se basant sur l'historique causal des ancrages ordonnés du tour r. Ensuite, les nœuds de validation commencent à utiliser la fonction de sélection d'ancrages mise à jour F' pour exécuter une nouvelle instance de Bullshark à 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(
Plus de délais
Le timeout joue un rôle crucial dans toutes les implémentations 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'observation.
Le délai d'attente peut également augmenter considérablement la latence, car il est très important de les configurer correctement et nécessite souvent un ajustement dynamique, car il dépend fortement de l'environnement ) réseau (. Avant de passer au leader suivant, le protocole paie une pénalité de délai d'attente complète pour le leader défaillant. Par conséquent, les paramètres de délai ne doivent pas être trop conservateurs, mais si le délai est trop court, le protocole peut sauter de bons leaders. Par exemple, nous avons observé qu'en cas de forte charge, les leaders dans Jolteon/Hotstuff étaient accablés et que le délai d'attente avait expiré avant qu'ils n'effectuent des progrès.
Malheureusement, basé sur le leadership