Cadre Shoal : Amélioration de la latence du consensus Bullshark sur Aptos
Aptos Labs a récemment résolu deux problèmes ouverts importants dans le DAG BFT, réduisant ainsi considérablement la latence, et a éliminé pour la première fois le besoin de délais dans un protocole asynchrone déterministe. Dans l'ensemble, la latence de Bullshark a été améliorée de 40 % en cas de fonctionnement sans erreur 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 en pipeline et à un mécanisme de réputation des leaders, comme DAG-Rider, Tusk, Bullshark ). Le traitement en pipeline réduit la latence de tri DAG en introduisant un point d'ancrage à chaque tour, et le mécanisme de réputation des leaders améliore encore 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 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 généralement la réponse optimiste requise.
La technologie de Shoal est relativement simple, impliquant plusieurs instances du protocole sous-jacent fonctionnant dans l'ordre. Lors de l'instanciation de Bullshark, nous obtenons un groupe de "sharks" participant à une course de relais.
Contexte et motivation
Dans la quête de 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, le Hotstuff mis en œuvre dans les premières versions de Diem n'atteignait que 3500 TPS, bien en dessous de l'objectif de 100k+ TPS.
La récente percée provient de la réalisation que la propagation des données est le principal goulot d'étranglement basé sur le Consensus 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 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 papier Narwhal rapporte un débit de 160 000 TPS.
Dans un article précédent, nous avons présenté Quorum Store. Narwhal met en œuvre la séparation de la propagation des données et de la Consensus, ainsi que la manière de 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 de réduire la latence de Hotstuff de 33 %. Cependant, les protocoles de Consensus basés sur un leader ne peuvent pas exploiter pleinement le potentiel de débit de Narwhal. Bien que la séparation de la propagation des données et de la Consensus soit effective, à mesure que le débit augmente, 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 soutenant Bullshark à haut débit entraîne un coût de latence de 50 %.
Cet article présentera comment Shoal réduit considérablement la latence de Bullshark.
Contexte DAG-BFT
Chaque sommet dans le DAG 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 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.
Ordre de tri
Il est possible d'atteindre un consensus sur l'ordre total de tous les sommets dans le DAG sans frais de communication supplémentaires. Pour ce faire, les validateurs dans DAG-Rider, Tusk et Bullshark interprètent la structure du DAG comme un protocole de Consensus, où les sommets représentent des propositions et les arêtes représentent des votes.
Bien que la logique d'intersection des groupes sur 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 aura un leader prédéterminé, le sommet du leader est appelé point d'ancrage.
Tri des points d'ancrage : les validateurs décident de manière indépendante mais déterministe quels points d'ancrage trier et quels points d'ancrage sauter.
Ordre historique causale : les validateurs traitent un par un la liste des points d'ancrage ordonnés et trient tous les sommets précédemment désordonnés dans l'historique causale de chaque point d'ancrage.
La clé pour satisfaire aux exigences de 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 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 synchronisée la plus pratique de Bullshark ait une meilleure latence 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 chaque sommet du 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 davantage de tours pour attendre que les points d'ancrage soient triés. Dans les cas courants, les sommets dans le tour impair nécessitent trois tours, tandis que les sommets non ancrés dans le tour pair 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 un leader de tour n'est pas assez rapide pour diffuser les points d'ancrage, il ne peut pas trier les points d'ancrage (, qui sont donc ignorés ). Par conséquent, tous les sommets non triés des tours précédentes 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, surtout parce que Bullshark utilise un délai 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) grâce à un traitement en pipeline, permettant ainsi 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 à 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 précédentes de traitement en pipeline pour modifier la logique centrale de Bullshark semblaient fondamentalement impossibles.
La réputation des leaders est introduite dans DiemBFT et formalisée dans Carousel, et elle consiste à sélectionner dynamiquement les futurs leaders en fonction des performances passées des validateurs dans (Bullshark. Bien que le désaccord sur l'identité des leaders ne viole pas la sécurité de ces protocoles, dans Bullshark, cela peut conduire à 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 les validateurs doivent parvenir à un accord sur l'historique ordonné pour choisir les futures ancres.
En tant que preuve de la difficulté des problèmes, nous avons remarqué que l'implémentation de Bullshark, y compris celle actuellement en production, ne prend pas en charge ces fonctionnalités.
) protocole
Malgré les défis mentionnés ci-dessus, la solution se cache dans la simplicité. Dans Shoal, nous comptons 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 précédents tours. Grâce à la vision centrale 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, ce qui fait que ### le premier point d'ancrage ordonné est le point de commutation des instances, ainsi que ( l'historique causal du point d'ancrage utilisé pour calculer la réputation des leaders.
) traitement en pipeline
V qui mappe les tours aux leaders. Shoal exécute un exemple de Bullshark un à un, de sorte que pour chaque exemple, l'ancre est préalablement déterminée par le mapping F. Chaque exemple trie une ancre, ce qui déclenche le passage au prochain exemple.
Au début, Shoal a lancé le premier instance de Bullshark lors du premier tour du DAG et l'a fait fonctionner jusqu'à ce que le premier point d'ancrage ordonné soit déterminé, par exemple au 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 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é par le premier exemple. Ensuite, Shoal commence un nouvel exemple au début du deuxième tour, qui a lui-même un point d'ancrage, cet ancre étant trié par cet exemple, puis un autre nouvel exemple trie le point d'ancrage au troisième tour, et le processus se poursuit.
réputation des leaders
Lors de la suppression des points d'ancrage pendant le tri Bullshark, la latence augmente. Dans ce cas, la technique de traitement en 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 garantit 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 de l'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 un score élevé, sinon, les nœuds de validation se verront attribuer un score faible, 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 de chaque 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 avoir trié les points d'ancrage lors de la r-ème ronde, les validateurs n'ont qu'à calculer un nouveau mappage F' à partir de la r+1-ème ronde en se basant sur l'historique causal des points d'ancrage ordonnés de la r-ème ronde. Ensuite, les nœuds de validation exécutent une nouvelle instance de Bullshark à partir de la r+1-ème ronde en utilisant la fonction de sélection de points d'ancrage mise à jour F'.
n'a plus de délai
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 cela nécessite souvent des ajustements dynamiques, car cela dépend fortement de l'environnement ( réseau ). Avant de passer au prochain leader, le protocole paiera la pénalité complète du délai d'attente pour le leader défaillant. Par conséquent, les paramètres de dépassement de délai ne doivent pas être trop conservateurs, mais si le temps de dépassement est trop court, le protocole peut ignorer de bons leaders. Par exemple, nous avons observé que, en cas de forte charge, les leaders dans Jolteon/Hotstuff sont submergés et que le délai a expiré avant qu'ils ne puissent faire avancer les choses.
Malheureusement, le protocole basé sur le leader ### comme Hotstuff
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
6
Reposter
Partager
Commentaire
0/400
SchrodingerProfit
· 08-11 12:19
Cette fois, Aptos va To the moon.
Voir l'originalRépondre0
CodeAuditQueen
· 08-11 05:48
L'optimisation des algorithmes complexes présente également des risques de réentrance de la puissance de calcul. J'espère qu'il n'y aura pas de retournement dans les caniveaux.
Voir l'originalRépondre0
metaverse_hermit
· 08-11 05:48
aptos est toujours en vie tql
Voir l'originalRépondre0
ReverseTradingGuru
· 08-11 05:47
Encore encore encore mis à jour ah bull bière
Voir l'originalRépondre0
DeadTrades_Walking
· 08-11 05:31
L'amélioration de l'efficacité est correcte, n'oubliez pas d'envoyer les scores.
Le cadre Shoal améliore l'efficacité du consensus Aptos : Bullshark réduit la latence de 40 à 80 %.
Cadre Shoal : Amélioration de la latence du consensus Bullshark sur Aptos
Aptos Labs a récemment résolu deux problèmes ouverts importants dans le DAG BFT, réduisant ainsi considérablement la latence, et a éliminé pour la première fois le besoin de délais dans un protocole asynchrone déterministe. Dans l'ensemble, la latence de Bullshark a été améliorée de 40 % en cas de fonctionnement sans erreur 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 en pipeline et à un mécanisme de réputation des leaders, comme DAG-Rider, Tusk, Bullshark ). Le traitement en pipeline réduit la latence de tri DAG en introduisant un point d'ancrage à chaque tour, et le mécanisme de réputation des leaders améliore encore 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 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 généralement la réponse optimiste requise.
La technologie de Shoal est relativement simple, impliquant plusieurs instances du protocole sous-jacent fonctionnant dans l'ordre. Lors de l'instanciation de Bullshark, nous obtenons un groupe de "sharks" participant à une course de relais.
Contexte et motivation
Dans la quête de 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, le Hotstuff mis en œuvre dans les premières versions de Diem n'atteignait que 3500 TPS, bien en dessous de l'objectif de 100k+ TPS.
La récente percée provient de la réalisation que la propagation des données est le principal goulot d'étranglement basé sur le Consensus 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 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 papier Narwhal rapporte un débit de 160 000 TPS.
Dans un article précédent, nous avons présenté Quorum Store. Narwhal met en œuvre la séparation de la propagation des données et de la Consensus, ainsi que la manière de 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 de réduire la latence de Hotstuff de 33 %. Cependant, les protocoles de Consensus basés sur un leader ne peuvent pas exploiter pleinement le potentiel de débit de Narwhal. Bien que la séparation de la propagation des données et de la Consensus soit effective, à mesure que le débit augmente, 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 soutenant Bullshark à haut débit entraîne un coût de latence de 50 %.
Cet article présentera comment Shoal réduit considérablement la latence de Bullshark.
Contexte DAG-BFT
Chaque sommet dans le DAG 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 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.
Ordre de tri
Il est possible d'atteindre un consensus sur l'ordre total de tous les sommets dans le DAG sans frais de communication supplémentaires. Pour ce faire, les validateurs dans DAG-Rider, Tusk et Bullshark interprètent la structure du DAG comme un protocole de Consensus, où les sommets représentent des propositions et les arêtes représentent des votes.
Bien que la logique d'intersection des groupes sur 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 aura un leader prédéterminé, le sommet du leader est appelé point d'ancrage.
Tri des points d'ancrage : les validateurs décident de manière indépendante mais déterministe quels points d'ancrage trier et quels points d'ancrage sauter.
Ordre historique causale : les validateurs traitent un par un la liste des points d'ancrage ordonnés et trient tous les sommets précédemment désordonnés dans l'historique causale de chaque point d'ancrage.
La clé pour satisfaire aux exigences de 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 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 synchronisée la plus pratique de Bullshark ait une meilleure latence 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 chaque sommet du 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 davantage de tours pour attendre que les points d'ancrage soient triés. Dans les cas courants, les sommets dans le tour impair nécessitent trois tours, tandis que les sommets non ancrés dans le tour pair 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 un leader de tour n'est pas assez rapide pour diffuser les points d'ancrage, il ne peut pas trier les points d'ancrage (, qui sont donc ignorés ). Par conséquent, tous les sommets non triés des tours précédentes 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, surtout parce que Bullshark utilise un délai 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) grâce à un traitement en pipeline, permettant ainsi 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 à 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 précédentes de traitement en pipeline pour modifier la logique centrale de Bullshark semblaient fondamentalement impossibles.
La réputation des leaders est introduite dans DiemBFT et formalisée dans Carousel, et elle consiste à sélectionner dynamiquement les futurs leaders en fonction des performances passées des validateurs dans (Bullshark. Bien que le désaccord sur l'identité des leaders ne viole pas la sécurité de ces protocoles, dans Bullshark, cela peut conduire à 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 les validateurs doivent parvenir à un accord sur l'historique ordonné pour choisir les futures ancres.
En tant que preuve de la difficulté des problèmes, nous avons remarqué que l'implémentation de Bullshark, y compris celle actuellement en production, ne prend pas en charge ces fonctionnalités.
) protocole
Malgré les défis mentionnés ci-dessus, la solution se cache dans la simplicité. Dans Shoal, nous comptons 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 précédents tours. Grâce à la vision centrale 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, ce qui fait que ### le premier point d'ancrage ordonné est le point de commutation des instances, ainsi que ( l'historique causal du point d'ancrage utilisé pour calculer la réputation des leaders.
) traitement en pipeline
V qui mappe les tours aux leaders. Shoal exécute un exemple de Bullshark un à un, de sorte que pour chaque exemple, l'ancre est préalablement déterminée par le mapping F. Chaque exemple trie une ancre, ce qui déclenche le passage au prochain exemple.
Au début, Shoal a lancé le premier instance de Bullshark lors du premier tour du DAG et l'a fait fonctionner jusqu'à ce que le premier point d'ancrage ordonné soit déterminé, par exemple au 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 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é par le premier exemple. Ensuite, Shoal commence un nouvel exemple au début du deuxième tour, qui a lui-même un point d'ancrage, cet ancre étant trié par cet exemple, puis un autre nouvel exemple trie le point d'ancrage au troisième tour, et le processus se poursuit.
réputation des leaders
Lors de la suppression des points d'ancrage pendant le tri Bullshark, la latence augmente. Dans ce cas, la technique de traitement en 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 garantit 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 de l'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 un score élevé, sinon, les nœuds de validation se verront attribuer un score faible, 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 de chaque 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 avoir trié les points d'ancrage lors de la r-ème ronde, les validateurs n'ont qu'à calculer un nouveau mappage F' à partir de la r+1-ème ronde en se basant sur l'historique causal des points d'ancrage ordonnés de la r-ème ronde. Ensuite, les nœuds de validation exécutent une nouvelle instance de Bullshark à partir de la r+1-ème ronde en utilisant la fonction de sélection de points d'ancrage mise à jour F'.
n'a plus de délai
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 cela nécessite souvent des ajustements dynamiques, car cela dépend fortement de l'environnement ( réseau ). Avant de passer au prochain leader, le protocole paiera la pénalité complète du délai d'attente pour le leader défaillant. Par conséquent, les paramètres de dépassement de délai ne doivent pas être trop conservateurs, mais si le temps de dépassement est trop court, le protocole peut ignorer de bons leaders. Par exemple, nous avons observé que, en cas de forte charge, les leaders dans Jolteon/Hotstuff sont submergés et que le délai a expiré avant qu'ils ne puissent faire avancer les choses.
Malheureusement, le protocole basé sur le leader ### comme Hotstuff