Optimisation du consensus DAG : comment le cadre Shoal réduit 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 éliminant pour la première fois le besoin de délais dans les protocoles asynchrones déterministes. Dans l'ensemble, le cadre Shoal a amélioré la latence de Bullshark de 40 % en cas de fonctionnement sans faute et de 80 % en cas de défaillance.
Shoal est un cadre qui renforce le protocole de consensus basé sur Narwhal ( grâce à une pipeline et à la réputation des leaders, comme DAG-Rider, Tusk, Bullshark ). La pipeline réduit la latence de tri de 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é au nœud de validation le plus rapide. De plus, la réputation des leaders permet à Shoal d'utiliser la construction de DAG asynchrone pour éliminer les délais dans tous les scénarios. Cela permet à Shoal d'offrir une réactivité universelle, incluant la réactivité optimiste généralement requise.
La technologie de Shoal est relativement simple, impliquant plusieurs instances du protocole sous-jacent exécutées en séquence. Lors de l'instanciation de Bullshark, nous obtenons un groupe de "requins" participant à une course de relais.
Motif
Dans la quête d'une haute performance des réseaux blockchain, l'accent a toujours été mis sur la réduction de la complexité de 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'atteignait que 3500 TPS, bien en dessous de l'objectif de 100k+ TPS.
Récemment, la percée provient de la reconnaissance que la propagation des données est le principal goulot d'étranglement basé sur un protocole de leader, et peut bénéficier de la parallélisation. Le système Narwhal dissocie 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 petit nombre 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 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, permettant une réduction de latence de 33% pour Hotstuff. Cependant, les protocoles de consensus basés sur un leader ne peuvent manifestement pas exploiter pleinement le 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 du DAG Narwhal, un protocole de consensus sans frais de communication. Malheureusement, par rapport à Jolteon, la structure DAG qui prend en charge un haut débit pour Bullshark entraîne un coût de latence de 50 %.
Cet article présente comment Shoal a considérablement réduit 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'asynchronisme du réseau, différents validateurs peuvent observer différentes vues locales du DAG à tout moment.
Une caractéristique clé du DAG est la non-ambiguïté : si deux nœuds de validation ont le même sommet v dans la vue locale du DAG, alors ils ont la même histoire causale de v.
Ordre total
Il est possible d'atteindre un consensus sur un 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 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, il y a un leader prédéterminé, dont le sommet est appelé point d'ancrage.
Points d'ancrage de tri : les validateurs décident de manière indépendante mais déterministe quels points d'ancrage trier et lesquels sauter.
Tri de l'historique causal : les validateurs traitent un par un la liste des points d'ancrage ordonnés, en triant tous les sommets désordonnés précédents dans l'historique causal de chaque point d'ancrage.
La clé pour garantir la sécurité est de s'assurer que, dans l'étape (2), toutes les listes de points d'ancrage ordonnés créées par des nœuds de validation honnêtes partagent le même préfixe. Dans Shoal, nous faisons les observations suivantes sur tous ces protocoles :
Tous les validateurs s'accordent sur le premier point d'ancrage ordonné.
Bullshark latence
Le latence de Bullshark dépend du nombre de tours entre les ancrages ordonnés dans le DAG. Bien que la version synchronisée de Bullshark soit plus pratique que la version asynchrone, elle est loin d'être optimale.
Question 1 : latence moyenne des blocs. Dans Bullshark, chaque tour pair a un point d'ancrage, et le sommet de chaque tour impair est interprété comme un vote. Dans les cas courants, il faut deux tours de DAG pour trier les points d'ancrage, cependant, les sommets dans l'historique causale des points d'ancrage nécessitent plus de tours pour que les points d'ancrage soient triés. En général, 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 de la situation de défaillance. Si le leader d'un tour ne parvient pas à diffuser assez rapidement le point d'ancrage, il est impossible de trier le point d'ancrage (, il est donc ignoré ). Tous les sommets non triés des tours précédents doivent attendre que le prochain point d'ancrage soit trié. Cela peut considérablement Goutte la performance du réseau de réplication géographique, en particulier parce que Bullshark utilise un délai d'attente pour le leader.
Cadre Shoal
Shoal a amélioré Bullshark( ou tout autre protocole BFT basé sur Narwhal) grâce à une chaîne de montage, permettant à chaque tour d'avoir un point d'ancrage 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, rendant le choix favorable aux leaders rapides.
Défi
Dans le contexte du protocole DAG, les pipelines 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 pour modifier la logique centrale de Bullshark semblent être essentiellement impossibles.
La réputation des leaders est introduite dans DiemBFT et officialisée dans Carousel, en fonction de la performance passée des validateurs pour sélectionner dynamiquement les leaders futurs, l'idée des ancres dans (Bullshark. Bien que le désaccord sur l'identité des leaders ne compromette pas la sécurité de ces protocoles, cela pourrait entraîner un classement complètement différent dans Bullshark, ce qui soulève le cœur du problème : choisir dynamiquement et de manière déterministe les ancres de rotation est nécessaire pour résoudre le Consensus, et les validateurs doivent parvenir à un accord sur l'historique ordonné pour sélectionner les futures ancres.
En tant que preuve de la difficulté des problèmes, nous avons noté que l'implémentation de Bullshark, y compris celle actuellement en production, ne prend pas en charge ces caractéristiques.
Protocole
Malgré les défis mentionnés ci-dessus, 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 centrale 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 un traitement en pipeline, rendant ) le premier point d'ancrage ordonné comme point de commutation des instances, ainsi que ( l'historique causal des points d'ancrage utilisé pour calculer la réputation des leaders.
![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(
Pipeline
V qui associe les tours aux leaders. Shoal exécute les instances Bullshark les unes après les autres, de sorte que pour chaque instance, l'ancre est préalablement déterminée par le mappage F. Chaque instance ordonne une ancre, déclenchant le passage à l'instance suivante.
Au départ, Shoal a lancé la première instance de Bullshark lors du premier tour du DAG et a fonctionné jusqu'à ce que le premier point d'ancrage ordonné soit déterminé, comme 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 trier un ancêtre à chaque tour. Le premier ancêtre est trié par la première instance. Ensuite, Shoal commence une nouvelle instance au début du second tour, qui a elle-même un ancêtre, cet ancêtre étant trié par cette instance, puis une autre nouvelle instance trie l'ancêtre au troisième tour, après quoi le processus se poursuit.
![Analyse 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 technique de pipeline est inefficace, car une nouvelle instance ne peut pas être lancée avant que le point d'ancrage de l'instance précédente soit trié. Shoal s'assure qu'il est peu probable que le leader correspondant soit choisi pour traiter les points d'ancrage manquants à l'avenir, en attribuant des scores à chaque nœud de validation en fonction de l'historique d'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 obtiendront des scores élevés, sinon, les nœuds de validation se verront attribuer de faibles scores, car ils peuvent être en panne, lents ou malveillants.
Son concept est de recalculer de manière déterministe la correspondance prédéfinie F du tour au leader à chaque mise à jour de score, en faveur des leaders ayant des scores plus élevés. Pour que les validateurs parviennent à un consensus sur la nouvelle correspondance, ils doivent s'accorder 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 atteint un consensus sur le premier point d'ancrage ordonné.
En fait, la seule différence est qu'après le classement des points d'ancrage lors du tour r, le validateur n'a qu'à calculer un nouveau mappage F' à partir du tour r+1 en se basant sur l'historique causal des points d'ancrage ordonnés au tour r. Ensuite, les nœuds de validation commencent à utiliser la fonction de sélection de points d'ancrage 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 Bullshark sur Aptos ?])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.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'observabilité.
Les délais excessifs augmentent également significativement la latence, car il est très important de les configurer correctement et qu'ils nécessitent souvent des ajustements dynamiques, car cela dépend fortement de l'environnement ) réseau (. Avant de passer au prochain leader, le protocole impose une pénalité de latence 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 temps de délai est trop court, le protocole peut passer de bons leaders. Par exemple, nous avons observé que, en cas de forte charge, les leaders dans Jolteon/Hotstuff étaient submergés et que le délai avait expiré avant qu'ils ne puissent faire avancer les choses.
Malheureusement, les protocoles basés sur les leaders ) tels que Hotstuff et Jolteon ( nécessitent essentiellement un Goutte pour garantir que le protocole progresse chaque fois qu'un leader échoue. Sans Goutte, même un leader en panne pourrait arrêter le protocole indéfiniment. Étant donné qu'il est impossible de distinguer un leader en panne d'un leader lent pendant les périodes asynchrones, le Goutte peut amener les nœuds de validation à examiner tous les leaders sans Consensus actif.
Dans Bullshark, le délai est utilisé pour la construction du DAG, afin de s'assurer qu'un leader honnête ajoutera des points d'ancrage pendant la synchronisation.
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.
11 J'aime
Récompense
11
6
Reposter
Partager
Commentaire
0/400
GateUser-c799715c
· Il y a 6h
Les performances se sont bien améliorées~
Voir l'originalRépondre0
AllInAlice
· Il y a 9h
C'est un dur, réduction de latence de 40%
Voir l'originalRépondre0
0xSherlock
· Il y a 9h
latence cette vague peut être traitée c'est un peu élégant
Voir l'originalRépondre0
BrokenYield
· Il y a 9h
meh, un autre "optimisation" qui créera probablement plus de risques systémiques qu'elle n'en résout... le smart money se couvre déjà contre cela
Optimisation du cadre Shoal pour le consensus DAG, réduction importante de la latence de Bullshark sur Aptos.
Optimisation du consensus DAG : comment le cadre Shoal réduit 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 éliminant pour la première fois le besoin de délais dans les protocoles asynchrones déterministes. Dans l'ensemble, le cadre Shoal a amélioré la latence de Bullshark de 40 % en cas de fonctionnement sans faute et de 80 % en cas de défaillance.
Shoal est un cadre qui renforce le protocole de consensus basé sur Narwhal ( grâce à une pipeline et à la réputation des leaders, comme DAG-Rider, Tusk, Bullshark ). La pipeline réduit la latence de tri de 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é au nœud de validation le plus rapide. De plus, la réputation des leaders permet à Shoal d'utiliser la construction de DAG asynchrone pour éliminer les délais dans tous les scénarios. Cela permet à Shoal d'offrir une réactivité universelle, incluant la réactivité optimiste généralement requise.
La technologie de Shoal est relativement simple, impliquant plusieurs instances du protocole sous-jacent exécutées en séquence. Lors de l'instanciation de Bullshark, nous obtenons un groupe de "requins" participant à une course de relais.
Motif
Dans la quête d'une haute performance des réseaux blockchain, l'accent a toujours été mis sur la réduction de la complexité de 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'atteignait que 3500 TPS, bien en dessous de l'objectif de 100k+ TPS.
Récemment, la percée provient de la reconnaissance que la propagation des données est le principal goulot d'étranglement basé sur un protocole de leader, et peut bénéficier de la parallélisation. Le système Narwhal dissocie 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 petit nombre 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 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, permettant une réduction de latence de 33% pour Hotstuff. Cependant, les protocoles de consensus basés sur un leader ne peuvent manifestement pas exploiter pleinement le 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 du DAG Narwhal, un protocole de consensus sans frais de communication. Malheureusement, par rapport à Jolteon, la structure DAG qui prend en charge un haut débit pour Bullshark entraîne un coût de latence de 50 %.
Cet article présente comment Shoal a considérablement réduit 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'asynchronisme du réseau, différents validateurs peuvent observer différentes vues locales du DAG à tout moment.
Une caractéristique clé du DAG est la non-ambiguïté : si deux nœuds de validation ont le même sommet v dans la vue locale du DAG, alors ils ont la même histoire causale de v.
Ordre total
Il est possible d'atteindre un consensus sur un 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 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, il y a un leader prédéterminé, dont le sommet est appelé point d'ancrage.
Points d'ancrage de tri : les validateurs décident de manière indépendante mais déterministe quels points d'ancrage trier et lesquels sauter.
Tri de l'historique causal : les validateurs traitent un par un la liste des points d'ancrage ordonnés, en triant tous les sommets désordonnés précédents dans l'historique causal de chaque point d'ancrage.
La clé pour garantir la sécurité est de s'assurer que, dans l'étape (2), toutes les listes de points d'ancrage ordonnés créées par des nœuds de validation honnêtes partagent le même préfixe. Dans Shoal, nous faisons les observations suivantes sur tous ces protocoles :
Tous les validateurs s'accordent sur le premier point d'ancrage ordonné.
Bullshark latence
Le latence de Bullshark dépend du nombre de tours entre les ancrages ordonnés dans le DAG. Bien que la version synchronisée de Bullshark soit plus pratique que la version asynchrone, elle est loin d'être optimale.
Question 1 : latence moyenne des blocs. Dans Bullshark, chaque tour pair a un point d'ancrage, et le sommet de chaque tour impair est interprété comme un vote. Dans les cas courants, il faut deux tours de DAG pour trier les points d'ancrage, cependant, les sommets dans l'historique causale des points d'ancrage nécessitent plus de tours pour que les points d'ancrage soient triés. En général, 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 de la situation de défaillance. Si le leader d'un tour ne parvient pas à diffuser assez rapidement le point d'ancrage, il est impossible de trier le point d'ancrage (, il est donc ignoré ). Tous les sommets non triés des tours précédents doivent attendre que le prochain point d'ancrage soit trié. Cela peut considérablement Goutte la performance du réseau de réplication géographique, en particulier parce que Bullshark utilise un délai d'attente pour le leader.
Cadre Shoal
Shoal a amélioré Bullshark( ou tout autre protocole BFT basé sur Narwhal) grâce à une chaîne de montage, permettant à chaque tour d'avoir un point d'ancrage 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, rendant le choix favorable aux leaders rapides.
Défi
Dans le contexte du protocole DAG, les pipelines 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 pour modifier la logique centrale de Bullshark semblent être essentiellement impossibles.
La réputation des leaders est introduite dans DiemBFT et officialisée dans Carousel, en fonction de la performance passée des validateurs pour sélectionner dynamiquement les leaders futurs, l'idée des ancres dans (Bullshark. Bien que le désaccord sur l'identité des leaders ne compromette pas la sécurité de ces protocoles, cela pourrait entraîner un classement complètement différent dans Bullshark, ce qui soulève le cœur du problème : choisir dynamiquement et de manière déterministe les ancres de rotation est nécessaire pour résoudre le Consensus, et les validateurs doivent parvenir à un accord sur l'historique ordonné pour sélectionner les futures ancres.
En tant que preuve de la difficulté des problèmes, nous avons noté que l'implémentation de Bullshark, y compris celle actuellement en production, ne prend pas en charge ces caractéristiques.
Protocole
Malgré les défis mentionnés ci-dessus, 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 centrale 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 un traitement en pipeline, rendant ) le premier point d'ancrage ordonné comme point de commutation des instances, ainsi que ( l'historique causal des points d'ancrage utilisé pour calculer la réputation des leaders.
![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(
Pipeline
V qui associe les tours aux leaders. Shoal exécute les instances Bullshark les unes après les autres, de sorte que pour chaque instance, l'ancre est préalablement déterminée par le mappage F. Chaque instance ordonne une ancre, déclenchant le passage à l'instance suivante.
Au départ, Shoal a lancé la première instance de Bullshark lors du premier tour du DAG et a fonctionné jusqu'à ce que le premier point d'ancrage ordonné soit déterminé, comme 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 trier un ancêtre à chaque tour. Le premier ancêtre est trié par la première instance. Ensuite, Shoal commence une nouvelle instance au début du second tour, qui a elle-même un ancêtre, cet ancêtre étant trié par cette instance, puis une autre nouvelle instance trie l'ancêtre au troisième tour, après quoi le processus se poursuit.
![Analyse 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 technique de pipeline est inefficace, car une nouvelle instance ne peut pas être lancée avant que le point d'ancrage de l'instance précédente soit trié. Shoal s'assure qu'il est peu probable que le leader correspondant soit choisi pour traiter les points d'ancrage manquants à l'avenir, en attribuant des scores à chaque nœud de validation en fonction de l'historique d'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 obtiendront des scores élevés, sinon, les nœuds de validation se verront attribuer de faibles scores, car ils peuvent être en panne, lents ou malveillants.
Son concept est de recalculer de manière déterministe la correspondance prédéfinie F du tour au leader à chaque mise à jour de score, en faveur des leaders ayant des scores plus élevés. Pour que les validateurs parviennent à un consensus sur la nouvelle correspondance, ils doivent s'accorder 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 atteint un consensus sur le premier point d'ancrage ordonné.
En fait, la seule différence est qu'après le classement des points d'ancrage lors du tour r, le validateur n'a qu'à calculer un nouveau mappage F' à partir du tour r+1 en se basant sur l'historique causal des points d'ancrage ordonnés au tour r. Ensuite, les nœuds de validation commencent à utiliser la fonction de sélection de points d'ancrage 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 Bullshark sur Aptos ?])https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.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'observabilité.
Les délais excessifs augmentent également significativement la latence, car il est très important de les configurer correctement et qu'ils nécessitent souvent des ajustements dynamiques, car cela dépend fortement de l'environnement ) réseau (. Avant de passer au prochain leader, le protocole impose une pénalité de latence 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 temps de délai est trop court, le protocole peut passer de bons leaders. Par exemple, nous avons observé que, en cas de forte charge, les leaders dans Jolteon/Hotstuff étaient submergés et que le délai avait expiré avant qu'ils ne puissent faire avancer les choses.
Malheureusement, les protocoles basés sur les leaders ) tels que Hotstuff et Jolteon ( nécessitent essentiellement un Goutte pour garantir que le protocole progresse chaque fois qu'un leader échoue. Sans Goutte, même un leader en panne pourrait arrêter le protocole indéfiniment. Étant donné qu'il est impossible de distinguer un leader en panne d'un leader lent pendant les périodes asynchrones, le Goutte peut amener les nœuds de validation à examiner tous les leaders sans Consensus actif.
Dans Bullshark, le délai est utilisé pour la construction du DAG, afin de s'assurer qu'un leader honnête ajoutera des points d'ancrage pendant la synchronisation.