Cadre Shoal : Goutte une nouvelle solution pour la latence de Bullshark sur Aptos
Aptos Labs a récemment résolu deux problèmes ouverts importants dans le DAG BFT, ce qui a considérablement Goutte la latence, et a éliminé pour la première fois le besoin de délais dans un protocole pratique déterministe. Dans l'ensemble, la latence de Bullshark a été améliorée de 40% en cas de fonctionnement sans défaut et de 80% en cas de défaillance.
Shoal est un cadre qui renforce 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 des points d'ancrage à chaque tour, tandis que le mécanisme de réputation des leaders améliore encore le problème de latence en veillant à ce que les points d'ancrage soient associés aux nœuds de validation les plus rapides. De plus, la réputation des leaders permet à Shoal d'exploiter la construction de DAG asynchrone pour éliminer les délais dans tous les scénarios. Cela permet à Shoal d'offrir une propriété appelée "réponse universelle", qui contient généralement la réponse optimiste requise.
La technologie de Shoal est assez simple, impliquant l'exécution séquentielle d'instances multiples du protocole sous-jacent. Ainsi, lorsque nous instancions Bullshark, nous obtenons un groupe de "requins" qui participent à une course de relais.
Contexte
Dans la recherche de hautes performances pour les réseaux blockchain, les gens se sont toujours concentrés sur la Goutte de la complexité de communication. Cependant, cette approche n'a pas conduit à une augmentation significative du débit. Par exemple, le Hotstuff implémenté dans les premières versions de Diem n'a atteint que 3500 TPS, bien en dessous de notre objectif de 100k+ TPS.
Les récentes percées proviennent de la prise de conscience que la propagation des données est le principal goulet d'étranglement basé sur l'accord 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'une quantité réduite de métadonnées. Le document Narwhal rapporte un débit de 160 000 TPS.
Notre implémentation Narwhal du Quorum Store sépare la diffusion des données et le consensus, afin d'étendre le protocole de consensus actuel Jolteon. Jolteon est un protocole basé sur un leader, combinant le chemin rapide linéaire de Tendermint et les changements de vue de style PBFT, capable 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 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 DAG Narwhal. 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 peut réduire 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'asynchronicité du réseau, différents validateurs peuvent observer différentes vues locales du DAG à tout moment.
Une caractéristique clé du DAG 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 ce faire, les validateurs de DAG-Rider, Tusk et Bullshark interprètent la structure du DAG comme un protocole de consensus, où les sommets représentent des propositions et les arêtes représentent des votes.
Bien que la logique d'intersection des groupes dans la structure DAG soit différente, tous les protocoles de consensus basés sur Narwhal existants ont la structure suivante :
Point d'ancrage prévu : tous les quelques tours, 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 de causalité ordonné : les validateurs traitent un par un la liste des points d'ancrage ordonnés, pour chaque point d'ancrage, ils trient tous les sommets précédemment désordonnés dans son historique de causalité selon des règles déterministes.
La clé de la satisfaction de la sécurité est de s'assurer qu'à l'étape (2), tous les nœuds de validation honnêtes créent une liste d'ancrage ordonnée, afin que toutes les listes partagent le même préfixe. Dans Shoal, nous faisons les observations suivantes sur tous les protocoles ci-dessus:
Tous les validateurs s'accordent sur le premier point d'ancrage ordonné.
Bullshark latence
La latence de Bullshark dépend du nombre de tours entre les points d'ancrage ordonnés dans le DAG. Bien que la version synchronisée de Bullshark soit plus pratique et ait une meilleure latence que la version asynchrone, elle est loin d'être optimale.
Question 1 : latence moyenne des blocs. Dans Bullshark, chaque ronde paire a un point d'ancrage, et chaque sommet de ronde impaire est interprété comme un vote. Dans les cas courants, il faut deux rondes de DAG pour trier les points d'ancrage, cependant, les sommets de l'histoire causale du point d'ancrage nécessitent plus de rondes pour attendre le tri des points d'ancrage. Dans les cas courants, les sommets de la ronde impaire nécessitent trois rondes, tandis que les sommets non ancrés de la ronde paire 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 le leader d'un tour ne parvient pas à diffuser suffisamment rapidement le point d'ancrage, il ne sera pas possible de trier le point d'ancrage ( et donc sera sauté ), par conséquent, tous les sommets non triés des premiers tours 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 des délais d'attente pour attendre le leader.
Cadre Shoal
Shoal a amélioré le Bullshark( ou tout autre protocole BFT basé sur Narwhal) via un traitement en pipeline, permettant d'avoir un point d'ancrage à chaque tour et de réduire 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 traitements de pipeline précédents ont tenté de modifier la logique centrale de Bullshark, mais cela semble fondamentalement impossible.
La réputation des leaders est introduite dans DiemBFT et formalisée dans Carousel, selon l'idée de sélectionner dynamiquement les futurs leaders basés sur les performances passées des validateurs dans (Bullshark, en tant qu'ancre dans ). Bien qu'il puisse y avoir des divergences quant à l'identité des leaders, cela ne compromet pas la sécurité de ces protocoles, mais dans Bullshark, cela peut entraîner un ordre complètement différent, soulevant le cœur du problème, à savoir que le choix dynamique et déterministe des ancres de rotation est nécessaire pour résoudre le consensus, et que les validateurs doivent parvenir à un consensus sur l'historique ordonné pour sélectionner les futures ancres.
En tant qu'évidence de la difficulté du problème, nous avons noté que l'implémentation de Bullshark, y compris celle actuellement en environnement de production, ne prend pas en charge ces caractéristiques.
Accord
Bien qu'il existe des défis mentionnés ci-dessus, il s'avère que la solution est cachée 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 à l'aperçu fondamental selon lequel tous les validateurs s'accordent sur le premier point d'ancrage ordonné, Shoal combine séquentiellement plusieurs instances de Bullshark pour les traiter en pipeline, ce qui fait que ( le premier point d'ancrage ordonné est le point de basculement des instances, et ) l'historique causal des points d'ancrage est utilisé pour calculer la réputation des leaders.
Traitement en flux
V qui fait correspondre 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 trie une ancre, ce qui déclenche le passage à l'instance suivante.
Au départ, Shoal a lancé la première 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 s'accordent sur 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. 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, 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 technologie de traitement en pipeline est impuissante, car une nouvelle instance ne peut pas être lancée avant que le point d'ancrage de l'instance précédente ne soit trié. Shoal garantit qu'il est peu probable que le leader correspondant soit choisi 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 à l'aide d'un mécanisme de réputation. 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 de la ronde au leader à chaque mise à jour du score, en faveur des leaders ayant des scores plus élevés. Pour que les validateurs parviennent à un consensus sur la nouvelle cartographie, ils doivent parvenir à un consensus sur le score, afin d'atteindre un accord sur l'historique utilisé pour dériver le score.
Dans Shoal, le traitement en pipeline et la réputation du leader peuvent se combiner naturellement, car ils utilisent tous deux la même technologie de base, à savoir la réinterprétation du DAG après avoir atteint un consensus sur le premier point d'ancrage ordonné.
En fait, la seule différence est qu'après avoir trié les points d'ancrage lors du tour r, le validateur n'a qu'à calculer un nouveau mappage F' à partir du tour r+1 en se basant sur l'historique causale des points d'ancrage ordonnés lors du tour r. Ensuite, les nœuds de validation exécutent une nouvelle instance de Bullshark à partir du tour r+1 en utilisant la fonction de sélection de points d'ancrage mise à jour F'.
Pas de délai supplémentaire
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 accroît la complexité du processus de débogage et nécessite davantage de techniques d'observation.
Le dépassement de délai peut également augmenter significativement 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 impose une pénalité de délai complet en cas de 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 sauter de bons leaders. Par exemple, nous avons observé que, dans des conditions de forte charge, les leaders dans Jolteon/Hotstuff sont submergés et le délai d'expiration est atteint avant qu'ils ne puissent faire avancer les choses.
Malheureusement, les protocoles de leader ( comme Hotstuff et Jolteon) nécessitent essentiellement une latence, pour s'assurer qu'à chaque fois qu'un leader échoue, cela garantit.
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.
14 J'aime
Récompense
14
9
Partager
Commentaire
0/400
ChainComedian
· Il y a 13h
latence baisse autant, on dirait qu'on peut faire un gros coup.
Voir l'originalRépondre0
YouMustMakeBigMoneyEvery
· 07-19 04:14
au-delà so l
Voir l'originalRépondre0
YouMustMakeBigMoneyEvery
· 07-19 04:14
ferme HODL💎
Voir l'originalRépondre0
VirtualRichDream
· 07-19 03:33
latence Goutte tellement aptos s'est mis en marche
Voir l'originalRépondre0
FOMOSapien
· 07-19 03:33
Réduire la latence, c'est même pas aussi bien que de directement A le président.
Voir l'originalRépondre0
BearEatsAll
· 07-19 03:30
aptos peut-il être encore plus rapide ? bull
Voir l'originalRépondre0
PaperHandsCriminal
· 07-19 03:26
Dieu sait à quoi sert cette latence Goutte, cela n'a pas empêché que je sois pris pour un idiot.
Voir l'originalRépondre0
ApeShotFirst
· 07-19 03:23
Encore hausse, sinon latence et ce sera delisting.
Voir l'originalRépondre0
BlockchainFries
· 07-19 03:15
Regardant la latence diminuer autant, achetons d'abord une petite Position.
Le cadre Shoal réduit considérablement la latence de consensus Bullshark sur Aptos.
Cadre Shoal : Goutte une nouvelle solution pour la latence de Bullshark sur Aptos
Aptos Labs a récemment résolu deux problèmes ouverts importants dans le DAG BFT, ce qui a considérablement Goutte la latence, et a éliminé pour la première fois le besoin de délais dans un protocole pratique déterministe. Dans l'ensemble, la latence de Bullshark a été améliorée de 40% en cas de fonctionnement sans défaut et de 80% en cas de défaillance.
Shoal est un cadre qui renforce 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 des points d'ancrage à chaque tour, tandis que le mécanisme de réputation des leaders améliore encore le problème de latence en veillant à ce que les points d'ancrage soient associés aux nœuds de validation les plus rapides. De plus, la réputation des leaders permet à Shoal d'exploiter la construction de DAG asynchrone pour éliminer les délais dans tous les scénarios. Cela permet à Shoal d'offrir une propriété appelée "réponse universelle", qui contient généralement la réponse optimiste requise.
La technologie de Shoal est assez simple, impliquant l'exécution séquentielle d'instances multiples du protocole sous-jacent. Ainsi, lorsque nous instancions Bullshark, nous obtenons un groupe de "requins" qui participent à une course de relais.
Contexte
Dans la recherche de hautes performances pour les réseaux blockchain, les gens se sont toujours concentrés sur la Goutte de la complexité de communication. Cependant, cette approche n'a pas conduit à une augmentation significative du débit. Par exemple, le Hotstuff implémenté dans les premières versions de Diem n'a atteint que 3500 TPS, bien en dessous de notre objectif de 100k+ TPS.
Les récentes percées proviennent de la prise de conscience que la propagation des données est le principal goulet d'étranglement basé sur l'accord 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'une quantité réduite de métadonnées. Le document Narwhal rapporte un débit de 160 000 TPS.
Notre implémentation Narwhal du Quorum Store sépare la diffusion des données et le consensus, afin d'étendre le protocole de consensus actuel Jolteon. Jolteon est un protocole basé sur un leader, combinant le chemin rapide linéaire de Tendermint et les changements de vue de style PBFT, capable 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 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 DAG Narwhal. 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 peut réduire 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'asynchronicité du réseau, différents validateurs peuvent observer différentes vues locales du DAG à tout moment.
Une caractéristique clé du DAG 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 ce faire, les validateurs de DAG-Rider, Tusk et Bullshark interprètent la structure du DAG comme un protocole de consensus, où les sommets représentent des propositions et les arêtes représentent des votes.
Bien que la logique d'intersection des groupes dans la structure DAG soit différente, tous les protocoles de consensus basés sur Narwhal existants ont la structure suivante :
Point d'ancrage prévu : tous les quelques tours, 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 de causalité ordonné : les validateurs traitent un par un la liste des points d'ancrage ordonnés, pour chaque point d'ancrage, ils trient tous les sommets précédemment désordonnés dans son historique de causalité selon des règles déterministes.
La clé de la satisfaction de la sécurité est de s'assurer qu'à l'étape (2), tous les nœuds de validation honnêtes créent une liste d'ancrage ordonnée, afin que toutes les listes partagent le même préfixe. Dans Shoal, nous faisons les observations suivantes sur tous les protocoles ci-dessus:
Tous les validateurs s'accordent sur le premier point d'ancrage ordonné.
Bullshark latence
La latence de Bullshark dépend du nombre de tours entre les points d'ancrage ordonnés dans le DAG. Bien que la version synchronisée de Bullshark soit plus pratique et ait une meilleure latence que la version asynchrone, elle est loin d'être optimale.
Question 1 : latence moyenne des blocs. Dans Bullshark, chaque ronde paire a un point d'ancrage, et chaque sommet de ronde impaire est interprété comme un vote. Dans les cas courants, il faut deux rondes de DAG pour trier les points d'ancrage, cependant, les sommets de l'histoire causale du point d'ancrage nécessitent plus de rondes pour attendre le tri des points d'ancrage. Dans les cas courants, les sommets de la ronde impaire nécessitent trois rondes, tandis que les sommets non ancrés de la ronde paire 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 le leader d'un tour ne parvient pas à diffuser suffisamment rapidement le point d'ancrage, il ne sera pas possible de trier le point d'ancrage ( et donc sera sauté ), par conséquent, tous les sommets non triés des premiers tours 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 des délais d'attente pour attendre le leader.
Cadre Shoal
Shoal a amélioré le Bullshark( ou tout autre protocole BFT basé sur Narwhal) via un traitement en pipeline, permettant d'avoir un point d'ancrage à chaque tour et de réduire 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 traitements de pipeline précédents ont tenté de modifier la logique centrale de Bullshark, mais cela semble fondamentalement impossible.
La réputation des leaders est introduite dans DiemBFT et formalisée dans Carousel, selon l'idée de sélectionner dynamiquement les futurs leaders basés sur les performances passées des validateurs dans (Bullshark, en tant qu'ancre dans ). Bien qu'il puisse y avoir des divergences quant à l'identité des leaders, cela ne compromet pas la sécurité de ces protocoles, mais dans Bullshark, cela peut entraîner un ordre complètement différent, soulevant le cœur du problème, à savoir que le choix dynamique et déterministe des ancres de rotation est nécessaire pour résoudre le consensus, et que les validateurs doivent parvenir à un consensus sur l'historique ordonné pour sélectionner les futures ancres.
En tant qu'évidence de la difficulté du problème, nous avons noté que l'implémentation de Bullshark, y compris celle actuellement en environnement de production, ne prend pas en charge ces caractéristiques.
Accord
Bien qu'il existe des défis mentionnés ci-dessus, il s'avère que la solution est cachée 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 à l'aperçu fondamental selon lequel tous les validateurs s'accordent sur le premier point d'ancrage ordonné, Shoal combine séquentiellement plusieurs instances de Bullshark pour les traiter en pipeline, ce qui fait que ( le premier point d'ancrage ordonné est le point de basculement des instances, et ) l'historique causal des points d'ancrage est utilisé pour calculer la réputation des leaders.
Traitement en flux
V qui fait correspondre 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 trie une ancre, ce qui déclenche le passage à l'instance suivante.
Au départ, Shoal a lancé la première 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 s'accordent sur 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. 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, 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 technologie de traitement en pipeline est impuissante, car une nouvelle instance ne peut pas être lancée avant que le point d'ancrage de l'instance précédente ne soit trié. Shoal garantit qu'il est peu probable que le leader correspondant soit choisi 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 à l'aide d'un mécanisme de réputation. 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 de la ronde au leader à chaque mise à jour du score, en faveur des leaders ayant des scores plus élevés. Pour que les validateurs parviennent à un consensus sur la nouvelle cartographie, ils doivent parvenir à un consensus sur le score, afin d'atteindre un accord sur l'historique utilisé pour dériver le score.
Dans Shoal, le traitement en pipeline et la réputation du leader peuvent se combiner naturellement, car ils utilisent tous deux la même technologie de base, à savoir la réinterprétation du DAG après avoir atteint un consensus sur le premier point d'ancrage ordonné.
En fait, la seule différence est qu'après avoir trié les points d'ancrage lors du tour r, le validateur n'a qu'à calculer un nouveau mappage F' à partir du tour r+1 en se basant sur l'historique causale des points d'ancrage ordonnés lors du tour r. Ensuite, les nœuds de validation exécutent une nouvelle instance de Bullshark à partir du tour r+1 en utilisant la fonction de sélection de points d'ancrage mise à jour F'.
Pas de délai supplémentaire
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 accroît la complexité du processus de débogage et nécessite davantage de techniques d'observation.
Le dépassement de délai peut également augmenter significativement 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 impose une pénalité de délai complet en cas de 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 sauter de bons leaders. Par exemple, nous avons observé que, dans des conditions de forte charge, les leaders dans Jolteon/Hotstuff sont submergés et le délai d'expiration est atteint avant qu'ils ne puissent faire avancer les choses.
Malheureusement, les protocoles de leader ( comme Hotstuff et Jolteon) nécessitent essentiellement une latence, pour s'assurer qu'à chaque fois qu'un leader échoue, cela garantit.