Cadre Shoal : Comment réduire 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 la nécessité de temporisation dans les protocoles réels 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 améliore le protocole de consensus basé sur Narwhal ( grâce à un traitement par pipeline et un mécanisme de réputation des leaders, tel que DAG-Rider, Tusk, Bullshark ). Le traitement par pipeline réduit la latence de tri du DAG en introduisant un point d'ancrage à chaque tour, tandis que le mécanisme de réputation des leaders améliore davantage le problème de latence en garantissant que le point d'ancrage est associé aux nœuds de validation les plus rapides. De plus, la réputation des leaders permet à Shoal de tirer parti de la construction asynchrone de DAG pour éliminer les délais dans tous les scénarios. Cela permet à Shoal d'offrir des caractéristiques de réponse universelle, incluant généralement une réponse optimiste.
Cette technologie est très simple, impliquant l'exécution séquentielle de plusieurs instances de protocole sous-jacent. Ainsi, lorsque nous instancions Bullshark, nous obtenons un groupe de "requins" participant à une course de relais.
Contexte
Dans la quête 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 approche n'a pas apporté d'amélioration significative du débit. Par exemple, Hotstuff, implémenté dans les premières versions de Diem, n'atteignait que 3500 TPS, bien en dessous de l'objectif de 100 000+ TPS.
Les récentes percées proviennent de la prise de conscience que la propagation des données est le principal goulot d'étranglement basé sur les protocoles 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, 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 sur Narwhal rapporte un taux de 160 000 TPS.
Aptos a précédemment introduit Quorum Store, c'est-à-dire l'implémentation de Narwhal, qui sépare la propagation 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 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 soit séparée du consensus, avec l'augmentation du débit, le leader de Hotstuff/Jolteon reste limité.
Ainsi, Aptos a décidé de déployer Bullshark sur le DAG Narwhal, qui est un protocole de consensus sans coût de communication. Malheureusement, par rapport à Jolteon, la structure de DAG qui prend en charge le haut débit de Bullshark entraîne un coût de latence de 50 %.
Cet article présente comment Shoal réduit 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'asynchronisme du réseau, différents validateurs peuvent observer à tout moment différentes vues locales du DAG.
Une caractéristique clé du DAG est l'absence d'ambiguïté : 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 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 sur la structure DAG soit différente, tous les protocoles de consensus basés sur Narwhal existants possèdent la structure suivante :
Point d'ancrage réservé : tous les quelques tours ( par exemple, dans Bullshark, 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 causale ordonnée : les validateurs traitent un par un leur liste d'ancrages ordonnés, et pour chaque ancrage, ils ordonnent tous les sommets précédemment désordonnés dans leur historique causal en utilisant 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 de points d'ancrage ordonnée, afin que toutes les listes partagent le même préfixe. Dans Shoal, les observations suivantes peuvent être faites concernant tous les protocoles mentionnés 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 synchrone de Bullshark soit plus pratique et ait une meilleure latence que la version asynchrone, elle est loin d'être optimale.
Question 1 : latence moyenne des blocs. Dans Bullshark, chaque ronde paire a un point d'ancrage, et le sommet de chaque ronde impaire est interprété comme un vote. Dans les cas courants, deux rondes de DAG sont nécessaires pour trier les points d'ancrage, cependant, les sommets dans l'historique causale des points d'ancrage nécessitent plus de rondes pour attendre que les points d'ancrage soient triés. Dans les cas courants, les sommets dans les rondes impaires nécessitent trois rondes, tandis que les sommets non ancrés dans les rondes paires nécessitent quatre rondes.
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 un leader d'un tour ne parvient pas à diffuser suffisamment rapidement le point d'ancrage, il est impossible de trier le point d'ancrage (, ce qui entraîne qu'il est sauté ). Par conséquent, tous les sommets non triés des tours précédents doivent attendre que le prochain point d'ancrage soit trié. Cela réduira considérablement les performances du réseau de réplication géographique, en particulier parce que Bullshark utilise un délai pour attendre le leader.
Cadre Shoal
Shoal a résolu ces deux problèmes de latence, il a amélioré Bullshark( ou tout autre protocole BFT basé sur Narwhal) grâce à un traitement en pipeline, permettant la présence d'un point d'ancrage à chaque tour et réduisant la latence de tous les sommets non ancrés dans le DAG à trois tours. Shoal a également introduit un mécanisme de réputation de leader à coût nul dans le DAG, ce qui favorise le choix des leaders rapides.
Défi
Dans le contexte du protocole DAG, le traitement en pipeline et la réputation des leaders sont considérés comme des problèmes difficiles pour les raisons suivantes :
Les tentatives de traitement en ligne de production précédentes ont essayé de modifier la logique fondamentale de Bullshark, mais cela semble fondamentalement impossible.
La réputation des leaders est introduite dans DiemBFT et formalisée dans Carousel, et elle est basée sur la performance passée des validateurs pour sélectionner dynamiquement les futurs leaders dans l'idée de l'ancre dans Bullshark. Bien qu'il n'y ait pas de violation de la sécurité de ces protocoles en raison des divergences dans l'identité des leaders, dans Bullshark, cela peut entraîner un ordre complètement différent, ce qui soulève le cœur du problème, à savoir que le choix dynamique et déterministe des ancres de cycle est nécessaire pour résoudre le consensus, et que 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, l'implémentation de Bullshark, y compris celle actuellement en environnement de production, ne prend pas en charge ces caractéristiques.
Accord
Malgré les défis mentionnés ci-dessus, 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 sauvegarder et de réinterpréter les informations des tours précédents. Grâce à la perspective 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, de sorte que ( le premier point d'ancrage ordonné soit le point de basculement des instances, et que ) l'historique causale du point d'ancrage soit utilisé pour calculer la réputation du leader.
Traitement en pipeline
Tout comme Bullshark, les validateurs parviennent a priori à un consensus sur les points d'ancrage potentiels, c'est-à-dire qu'il existe un mappage connu F : R -\u003e V qui associe les tours aux leaders. Shoal exécute un à un les instances de Bullshark, de sorte que pour chaque instance, l'ancre est préalablement déterminée par le mappage F. Chaque instance classe une ancre, ce qui déclenche le passage à l'instance suivante.
Au départ, Shoal a lancé le premier exemple de Bullshark lors du premier tour du DAG et l'a fait fonctionner jusqu'à ce que le premier point d'ancrage ordonné soit établi, par exemple au tour r. Tous les validateurs ont accepté 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é un nouvel exemple de Bullshark au tour r+1.
Dans le meilleur des cas, cela permet à Shoal de trier un ancre à chaque tour. Le premier point d'ancrage est trié selon la première instance. Ensuite, Shoal commence une nouvelle instance au début du deuxième tour, qui a elle-même un point d'ancrage, cet ancre étant trié par cette instance, puis une autre nouvelle instance trie le point d'ancrage au troisième tour, puis le processus continue.
Réputation des leaders
Lorsqu'on saute des points d'ancrage pendant le tri Bullshark, la latence augmente. Dans ce cas, la technique de traitement par pipeline est impuissante, car il n'est pas possible de démarrer une nouvelle instance avant le point d'ancrage de tri de l'instance précédente. Shoal s'assure qu'il est peu probable que les leaders correspondants soient choisis pour traiter les points d'ancrage manquants à l'avenir, en attribuant un score à chaque nœud de validation basé sur l'historique de l'activité récente de chaque nœud. 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 être en panne, 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 du score, en faveur des leaders ayant un score plus élevé. Pour que les validateurs parviennent à un consensus sur la nouvelle cartographie, ils devraient parvenir à un consensus sur le score, afin d'atteindre un consensus sur l'historique utilisé pour dériver le score.
Dans Shoal, le traitement en pipeline 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 le tri des ancres à la ronde r, le validateur n'a qu'à calculer un nouveau mappage F' à partir de la ronde r+1 en se basant sur l'historique causal des ancres ordonnées de la ronde r. Ensuite, le nœud de validation utilise la fonction de sélection d'ancres mise à jour F' pour exécuter une nouvelle instance de Bullshark à partir de la ronde r+1.
Pas plus de délais
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 complique le processus de débogage et nécessite davantage de techniques d'observabilité.
Le dépassement de délai augmentera également considérablement la latence, car il est très important de les configurer correctement et qu'elles nécessitent souvent des ajustements dynamiques, car elles dépendent fortement de l'environnement ( réseau ). Avant de passer au prochain leader, le protocole impose une pénalité de délai complète pour le leader en panne. Par conséquent, les réglages de délai ne doivent pas être trop conservateurs, mais si le temps de dépassement 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 sont submergés et que le délai est écoulé avant qu'ils ne fassent avancer les choses.
Malheureusement, basé sur le protocole de leader ( comme
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.
9 J'aime
Récompense
9
5
Partager
Commentaire
0/400
ChainSpy
· Il y a 7h
Feu vert, APT doit aller au ciel
Voir l'originalRépondre0
AirdropHunter007
· Il y a 18h
latence réduite de 40 % ? To the moon !
Voir l'originalRépondre0
BTCBeliefStation
· Il y a 18h
incroyable cette optimisation m'a laissé sans voix
Voir l'originalRépondre0
CounterIndicator
· Il y a 18h
bull ah latence a été réduite de plus de la moitié
Voir l'originalRépondre0
MoonRocketTeam
· Il y a 18h
Aïe, latence directe, effondrement de 50. Cette fenêtre de lancement doit aller vers la lune.
Optimisation du cadre Shoal pour le protocole de consensus Aptos, la latence de Bullshark a été fortement Goutte.
Cadre Shoal : Comment réduire 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 la nécessité de temporisation dans les protocoles réels 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 améliore le protocole de consensus basé sur Narwhal ( grâce à un traitement par pipeline et un mécanisme de réputation des leaders, tel que DAG-Rider, Tusk, Bullshark ). Le traitement par pipeline réduit la latence de tri du DAG en introduisant un point d'ancrage à chaque tour, tandis que le mécanisme de réputation des leaders améliore davantage le problème de latence en garantissant que le point d'ancrage est associé aux nœuds de validation les plus rapides. De plus, la réputation des leaders permet à Shoal de tirer parti de la construction asynchrone de DAG pour éliminer les délais dans tous les scénarios. Cela permet à Shoal d'offrir des caractéristiques de réponse universelle, incluant généralement une réponse optimiste.
Cette technologie est très simple, impliquant l'exécution séquentielle de plusieurs instances de protocole sous-jacent. Ainsi, lorsque nous instancions Bullshark, nous obtenons un groupe de "requins" participant à une course de relais.
Contexte
Dans la quête 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 approche n'a pas apporté d'amélioration significative du débit. Par exemple, Hotstuff, implémenté dans les premières versions de Diem, n'atteignait que 3500 TPS, bien en dessous de l'objectif de 100 000+ TPS.
Les récentes percées proviennent de la prise de conscience que la propagation des données est le principal goulot d'étranglement basé sur les protocoles 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, 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 sur Narwhal rapporte un taux de 160 000 TPS.
Aptos a précédemment introduit Quorum Store, c'est-à-dire l'implémentation de Narwhal, qui sépare la propagation 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 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 soit séparée du consensus, avec l'augmentation du débit, le leader de Hotstuff/Jolteon reste limité.
Ainsi, Aptos a décidé de déployer Bullshark sur le DAG Narwhal, qui est un protocole de consensus sans coût de communication. Malheureusement, par rapport à Jolteon, la structure de DAG qui prend en charge le haut débit de Bullshark entraîne un coût de latence de 50 %.
Cet article présente comment Shoal réduit 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'asynchronisme du réseau, différents validateurs peuvent observer à tout moment différentes vues locales du DAG.
Une caractéristique clé du DAG est l'absence d'ambiguïté : 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 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 sur la structure DAG soit différente, tous les protocoles de consensus basés sur Narwhal existants possèdent la structure suivante :
Point d'ancrage réservé : tous les quelques tours ( par exemple, dans Bullshark, 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 causale ordonnée : les validateurs traitent un par un leur liste d'ancrages ordonnés, et pour chaque ancrage, ils ordonnent tous les sommets précédemment désordonnés dans leur historique causal en utilisant 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 de points d'ancrage ordonnée, afin que toutes les listes partagent le même préfixe. Dans Shoal, les observations suivantes peuvent être faites concernant tous les protocoles mentionnés 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 synchrone de Bullshark soit plus pratique et ait une meilleure latence que la version asynchrone, elle est loin d'être optimale.
Question 1 : latence moyenne des blocs. Dans Bullshark, chaque ronde paire a un point d'ancrage, et le sommet de chaque ronde impaire est interprété comme un vote. Dans les cas courants, deux rondes de DAG sont nécessaires pour trier les points d'ancrage, cependant, les sommets dans l'historique causale des points d'ancrage nécessitent plus de rondes pour attendre que les points d'ancrage soient triés. Dans les cas courants, les sommets dans les rondes impaires nécessitent trois rondes, tandis que les sommets non ancrés dans les rondes paires nécessitent quatre rondes.
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 un leader d'un tour ne parvient pas à diffuser suffisamment rapidement le point d'ancrage, il est impossible de trier le point d'ancrage (, ce qui entraîne qu'il est sauté ). Par conséquent, tous les sommets non triés des tours précédents doivent attendre que le prochain point d'ancrage soit trié. Cela réduira considérablement les performances du réseau de réplication géographique, en particulier parce que Bullshark utilise un délai pour attendre le leader.
Cadre Shoal
Shoal a résolu ces deux problèmes de latence, il a amélioré Bullshark( ou tout autre protocole BFT basé sur Narwhal) grâce à un traitement en pipeline, permettant la présence d'un point d'ancrage à chaque tour et réduisant la latence de tous les sommets non ancrés dans le DAG à trois tours. Shoal a également introduit un mécanisme de réputation de leader à coût nul dans le DAG, ce qui favorise le choix des leaders rapides.
Défi
Dans le contexte du protocole DAG, le traitement en pipeline et la réputation des leaders sont considérés comme des problèmes difficiles pour les raisons suivantes :
Les tentatives de traitement en ligne de production précédentes ont essayé de modifier la logique fondamentale de Bullshark, mais cela semble fondamentalement impossible.
La réputation des leaders est introduite dans DiemBFT et formalisée dans Carousel, et elle est basée sur la performance passée des validateurs pour sélectionner dynamiquement les futurs leaders dans l'idée de l'ancre dans Bullshark. Bien qu'il n'y ait pas de violation de la sécurité de ces protocoles en raison des divergences dans l'identité des leaders, dans Bullshark, cela peut entraîner un ordre complètement différent, ce qui soulève le cœur du problème, à savoir que le choix dynamique et déterministe des ancres de cycle est nécessaire pour résoudre le consensus, et que 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, l'implémentation de Bullshark, y compris celle actuellement en environnement de production, ne prend pas en charge ces caractéristiques.
Accord
Malgré les défis mentionnés ci-dessus, 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 sauvegarder et de réinterpréter les informations des tours précédents. Grâce à la perspective 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, de sorte que ( le premier point d'ancrage ordonné soit le point de basculement des instances, et que ) l'historique causale du point d'ancrage soit utilisé pour calculer la réputation du leader.
Traitement en pipeline
Tout comme Bullshark, les validateurs parviennent a priori à un consensus sur les points d'ancrage potentiels, c'est-à-dire qu'il existe un mappage connu F : R -\u003e V qui associe les tours aux leaders. Shoal exécute un à un les instances de Bullshark, de sorte que pour chaque instance, l'ancre est préalablement déterminée par le mappage F. Chaque instance classe une ancre, ce qui déclenche le passage à l'instance suivante.
Au départ, Shoal a lancé le premier exemple de Bullshark lors du premier tour du DAG et l'a fait fonctionner jusqu'à ce que le premier point d'ancrage ordonné soit établi, par exemple au tour r. Tous les validateurs ont accepté 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é un nouvel exemple de Bullshark au tour r+1.
Dans le meilleur des cas, cela permet à Shoal de trier un ancre à chaque tour. Le premier point d'ancrage est trié selon la première instance. Ensuite, Shoal commence une nouvelle instance au début du deuxième tour, qui a elle-même un point d'ancrage, cet ancre étant trié par cette instance, puis une autre nouvelle instance trie le point d'ancrage au troisième tour, puis le processus continue.
Réputation des leaders
Lorsqu'on saute des points d'ancrage pendant le tri Bullshark, la latence augmente. Dans ce cas, la technique de traitement par pipeline est impuissante, car il n'est pas possible de démarrer une nouvelle instance avant le point d'ancrage de tri de l'instance précédente. Shoal s'assure qu'il est peu probable que les leaders correspondants soient choisis pour traiter les points d'ancrage manquants à l'avenir, en attribuant un score à chaque nœud de validation basé sur l'historique de l'activité récente de chaque nœud. 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 être en panne, 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 du score, en faveur des leaders ayant un score plus élevé. Pour que les validateurs parviennent à un consensus sur la nouvelle cartographie, ils devraient parvenir à un consensus sur le score, afin d'atteindre un consensus sur l'historique utilisé pour dériver le score.
Dans Shoal, le traitement en pipeline 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 le tri des ancres à la ronde r, le validateur n'a qu'à calculer un nouveau mappage F' à partir de la ronde r+1 en se basant sur l'historique causal des ancres ordonnées de la ronde r. Ensuite, le nœud de validation utilise la fonction de sélection d'ancres mise à jour F' pour exécuter une nouvelle instance de Bullshark à partir de la ronde r+1.
Pas plus de délais
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 complique le processus de débogage et nécessite davantage de techniques d'observabilité.
Le dépassement de délai augmentera également considérablement la latence, car il est très important de les configurer correctement et qu'elles nécessitent souvent des ajustements dynamiques, car elles dépendent fortement de l'environnement ( réseau ). Avant de passer au prochain leader, le protocole impose une pénalité de délai complète pour le leader en panne. Par conséquent, les réglages de délai ne doivent pas être trop conservateurs, mais si le temps de dépassement 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 sont submergés et que le délai est écoulé avant qu'ils ne fassent avancer les choses.
Malheureusement, basé sur le protocole de leader ( comme