Cadre Shoal : comment Goutte la latence de Bullshark sur Aptos ?
Aperçu
Aptos labs a résolu deux problèmes ouverts importants dans le BFT DAG, réduisant considérablement la latence et éliminant pour la première fois le besoin de délais dans les protocoles 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 panne.
Shoal est un cadre qui améliore tout protocole de consensus basé sur Narwhal (, tel que DAG-Rider, Tusk, Bullshark ), grâce à des pipelines et à la réputation des leaders. Le pipeline réduit la latence de tri DAG en introduisant un point d'ancrage à chaque tour, et la 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 de DAG asynchrone pour éliminer les délais dans tous les scénarios. Cela permet à Shoal d'offrir des propriétés de réponse universelle, incluant la réponse optimiste généralement requise.
Cette technologie est très simple, impliquant l'exécution séquentielle de plusieurs instances du protocole sous-jacent. Ainsi, lorsque nous l'instancions avec Bullshark, nous obtenons un groupe de "requins" participant à une course de relais.
Motivation
Dans la quête de 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 mis en œuvre 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 découle de la prise de conscience que la propagation des données est le principal goulet d'étranglement basé sur le protocole des leaders, et qu'elle 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 commande qu'une petite quantité de métadonnées. Le document sur Narwhal rapporte un débit de 160 000 TPS.
Précédemment, nous avons présenté Quorum Store, qui sépare la diffusion des données et le 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 tirer pleinement parti du potentiel de débit de Narwhal. Bien que la diffusion des données et le consensus soient séparés, avec l'augmentation du débit, le leader de Hotstuff/Jolteon reste limité.
Ainsi, il a été décidé de déployer Bullshark, un protocole de consensus sans coût de communication, sur le Narwhal DAG. Malheureusement, par rapport à Jolteon, la structure DAG qui prend en charge un haut débit pour Bullshark entraîne un coût de Goutte de 50 %.
Cet article présente comment Shoal réduit considérablement la latence de Bullshark.
Contexte DAG-BFT
Dans le DAG Narwhal, chaque sommet est associé au numéro de ronde. Pour entrer dans la ronde r, un validateur doit d'abord obtenir n-f sommets appartenant à la ronde r-1. Chaque validateur peut diffuser un sommet par ronde, et chaque sommet doit référencer au moins n-f sommets de la ronde précédente. En raison de l'asynchrone du réseau, différents validateurs peuvent observer à tout moment des vues locales différentes 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.
Ordre total
Il est possible d'atteindre un consensus sur l'ordre total de tous les sommets dans le DAG sans frais de communication supplémentaires. Pour cela, les validateurs dans DAG-Rider, Tusk et Bullshark interprètent la structure du DAG comme un protocole de consensus, où les sommets représentent des propositions et les arêtes représentent des votes.
Bien que la logique d'intersection des groupes 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 ( comme dans Bullshark, il y a un leader préalablement déterminé tous les deux tours ), 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 commander et lesquels sauter.
Historique causal 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 non ordonnés précédents dans son historique causal selon des 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 d'ancrage ordonnée, de sorte que toutes les listes partagent le même préfixe. Dans Shoal, les observations suivantes peuvent être faites sur tous les protocoles mentionnés 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 la plus pratique de Bullshark ait une latence meilleure que la version asynchrone, elle est loin d'être optimale.
Problème 1 : latence moyenne des blocs. Dans Bullshark, chaque ronde paire a un point d'ancrage, et les sommets de chaque ronde impaire sont interprétés comme des votes. Dans des cas courants, il faut deux rondes de DAG pour commander 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 des 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 de cycle n'arrive pas à diffuser suffisamment rapidement les points d'ancrage, il est impossible de trier les points d'ancrage (, et donc ils sont sautés ). Tous les sommets non triés des cycles précédents doivent attendre que le prochain point d'ancrage soit trié. Cela réduit considérablement les performances du réseau de réplication géographique, surtout parce que Bullshark utilise un délai d'attente pour le leader.
Cadre Shoal
Shoal a résolu ces deux problèmes de latence, en améliorant Bullshark( ou tout autre protocole BFT basé sur Narwhal) grâce à un 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 sans frais dans le DAG, ce qui favorise le choix des 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 chaînes de production précédentes 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, en sélectionnant dynamiquement les futurs leaders en fonction des performances passées des validateurs, idée des ancres dans Bullshark. Bien qu'il existe des divergences sur l'identité des leaders, cela ne compromet pas la sécurité de ces protocoles, mais cela pourrait conduire à un ordre complètement différent dans Bullshark, ce qui soulève le problème central, à 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 choisir les futures ancres.
En tant qu'évidence de la difficulté des problèmes, 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 derrière la simplicité.
Dans Shoal, nous nous appuyons sur la capacité d'exécuter des calculs locaux sur le DAG et avons mis en œuvre la capacité de sauvegarder et de réinterpréter les informations des tours précédents. Grâce à l'accord de tous les validateurs sur la première ancre ordonnée comme insight clé, Shoal combine en séquence plusieurs instances de Bullshark pour les traiter en pipeline, rendant ( le premier ancrage ordonné le point de basculement des instances, ainsi que ) l'historique causal des ancrages utilisé pour calculer la réputation des leaders.
Chaîne de montage
V qui mappe 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 la correspondance F. Chaque instance commande une ancre, ce qui déclenche le passage à l'instance suivante.
Au départ, Shoal a lancé le premier instance de Bullshark lors du premier tour de DAG et l'a exécuté 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 commander un ancre à chaque tour. Les points d'ancrage de la première ronde sont triés par le premier exemple. Ensuite, Shoal commence un nouvel exemple lors de la deuxième ronde, qui a lui-même un point d'ancrage, cette ancre étant triée par cet exemple, puis un autre nouvel exemple commande un point d'ancrage lors de la troisième ronde, puis le processus continue.
Réputation des leaders
Lorsqu'on saute des points d'ancrage pendant le tri de Bullshark, la latence augmente. Dans ce cas, la technologie des pipelines est impuissante, car il est impossible de lancer une nouvelle instance avant que le point d'ancrage de l'instance précédente ne soit commandé. Shoal garantit qu'il est peu probable que les leaders correspondants soient choisis à l'avenir pour traiter les points d'ancrage manquants, 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 des scores faibles, car ils peuvent être en panne, lents ou malveillants.
Son principe est de recalculer de manière déterministe le mappage prédéfini F de chaque tour au leader à chaque mise à jour du score, en faveur du leader ayant le score le plus élevé. Pour que les validateurs parviennent à un consensus sur le nouveau mappage, ils doivent parvenir à un consensus sur le score, afin d'atteindre un consensus sur l'historique utilisé pour dériver les scores.
Dans Shoal, la pipeline et la réputation des leaders peuvent se combiner naturellement, car elles utilisent toutes deux la même technologie de base, à savoir la réinterprétation du DAG après avoir atteint un consensus sur le premier point d'ancrage ordonné.
En fait, la seule différence est qu'après le tri des points d'ancrage lors du tour r, le validateur n'a besoin de calculer une nouvelle carte F' qu'à partir du tour r+1, en se basant sur l'historique causal des points d'ancrage ordonnés du 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.
Il n'y a plus de dépassement de délai
Le temps d'attente joue un rôle crucial dans toutes les implémentations BFT déterministes basées sur des leaders. Cependant, la complexité qu'ils introduisent augmente le nombre d'états internes à gérer et à surveiller, ce qui complique le processus de débogage et nécessite davantage de techniques d'observation.
Le dépassement de délai augmentera également significativement la latence, car il est très important de les configurer correctement et nécessite souvent des ajustements dynamiques, car cela dépend fortement de l'environnement ( réseau ). Avant de passer au prochain leader, le protocole paie la pénalité de latence complète 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 sauter de bons leaders. Par exemple, nous avons observé qu'en cas de forte charge, les leaders dans Jolteon/Hotstuff sont accablés et que le délai a expiré avant qu'ils ne puissent faire progresser les choses.
Malheureusement, les protocoles basés sur le leader ( comme Hotstuff et Jolteon) nécessitent essentiellement une Goutte pour garantir que le protocole progresse chaque fois qu'un leader échoue. Sans Goutte, même un leader en panne peut arrêter le protocole indéfiniment. En raison de l'incapacité à distinguer pendant la latence, il est impossible de savoir s'il y a un problème.
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.
23 J'aime
Récompense
23
6
Partager
Commentaire
0/400
VirtualRichDream
· 07-25 11:15
latence降这么多 aptos要To the moon了
Voir l'originalRépondre0
CoffeeNFTs
· 07-22 19:02
Cette goutte de latence est un peu agréable.
Voir l'originalRépondre0
RugDocDetective
· 07-22 19:01
Trop bien ! J'ai attendu si longtemps, la solution Aptos est enfin sortie.
Voir l'originalRépondre0
RuntimeError
· 07-22 19:00
Est-ce que cette nouvelle fonctionnalité d'aptos fonctionne vraiment ?
Voir l'originalRépondre0
UnluckyValidator
· 07-22 18:58
La période de haute latence est enfin terminée, cela a été pénible pendant plus de six mois.
Le cadre Shoal réduit considérablement la latence de Bullshark off-chain sur Aptos, améliorant de 40 à 80 %.
Cadre Shoal : comment Goutte la latence de Bullshark sur Aptos ?
Aperçu
Aptos labs a résolu deux problèmes ouverts importants dans le BFT DAG, réduisant considérablement la latence et éliminant pour la première fois le besoin de délais dans les protocoles 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 panne.
Shoal est un cadre qui améliore tout protocole de consensus basé sur Narwhal (, tel que DAG-Rider, Tusk, Bullshark ), grâce à des pipelines et à la réputation des leaders. Le pipeline réduit la latence de tri DAG en introduisant un point d'ancrage à chaque tour, et la 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 de DAG asynchrone pour éliminer les délais dans tous les scénarios. Cela permet à Shoal d'offrir des propriétés de réponse universelle, incluant la réponse optimiste généralement requise.
Cette technologie est très simple, impliquant l'exécution séquentielle de plusieurs instances du protocole sous-jacent. Ainsi, lorsque nous l'instancions avec Bullshark, nous obtenons un groupe de "requins" participant à une course de relais.
Motivation
Dans la quête de 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 mis en œuvre 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 découle de la prise de conscience que la propagation des données est le principal goulet d'étranglement basé sur le protocole des leaders, et qu'elle 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 commande qu'une petite quantité de métadonnées. Le document sur Narwhal rapporte un débit de 160 000 TPS.
Précédemment, nous avons présenté Quorum Store, qui sépare la diffusion des données et le 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 tirer pleinement parti du potentiel de débit de Narwhal. Bien que la diffusion des données et le consensus soient séparés, avec l'augmentation du débit, le leader de Hotstuff/Jolteon reste limité.
Ainsi, il a été décidé de déployer Bullshark, un protocole de consensus sans coût de communication, sur le Narwhal DAG. Malheureusement, par rapport à Jolteon, la structure DAG qui prend en charge un haut débit pour Bullshark entraîne un coût de Goutte de 50 %.
Cet article présente comment Shoal réduit considérablement la latence de Bullshark.
Contexte DAG-BFT
Dans le DAG Narwhal, chaque sommet est associé au numéro de ronde. Pour entrer dans la ronde r, un validateur doit d'abord obtenir n-f sommets appartenant à la ronde r-1. Chaque validateur peut diffuser un sommet par ronde, et chaque sommet doit référencer au moins n-f sommets de la ronde précédente. En raison de l'asynchrone du réseau, différents validateurs peuvent observer à tout moment des vues locales différentes 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.
Ordre total
Il est possible d'atteindre un consensus sur l'ordre total de tous les sommets dans le DAG sans frais de communication supplémentaires. Pour cela, les validateurs dans DAG-Rider, Tusk et Bullshark interprètent la structure du DAG comme un protocole de consensus, où les sommets représentent des propositions et les arêtes représentent des votes.
Bien que la logique d'intersection des groupes 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 ( comme dans Bullshark, il y a un leader préalablement déterminé tous les deux tours ), 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 commander et lesquels sauter.
Historique causal 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 non ordonnés précédents dans son historique causal selon des 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 d'ancrage ordonnée, de sorte que toutes les listes partagent le même préfixe. Dans Shoal, les observations suivantes peuvent être faites sur tous les protocoles mentionnés 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 la plus pratique de Bullshark ait une latence meilleure que la version asynchrone, elle est loin d'être optimale.
Problème 1 : latence moyenne des blocs. Dans Bullshark, chaque ronde paire a un point d'ancrage, et les sommets de chaque ronde impaire sont interprétés comme des votes. Dans des cas courants, il faut deux rondes de DAG pour commander 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 des 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 de cycle n'arrive pas à diffuser suffisamment rapidement les points d'ancrage, il est impossible de trier les points d'ancrage (, et donc ils sont sautés ). Tous les sommets non triés des cycles précédents doivent attendre que le prochain point d'ancrage soit trié. Cela réduit considérablement les performances du réseau de réplication géographique, surtout parce que Bullshark utilise un délai d'attente pour le leader.
Cadre Shoal
Shoal a résolu ces deux problèmes de latence, en améliorant Bullshark( ou tout autre protocole BFT basé sur Narwhal) grâce à un 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 sans frais dans le DAG, ce qui favorise le choix des 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 chaînes de production précédentes 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, en sélectionnant dynamiquement les futurs leaders en fonction des performances passées des validateurs, idée des ancres dans Bullshark. Bien qu'il existe des divergences sur l'identité des leaders, cela ne compromet pas la sécurité de ces protocoles, mais cela pourrait conduire à un ordre complètement différent dans Bullshark, ce qui soulève le problème central, à 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 choisir les futures ancres.
En tant qu'évidence de la difficulté des problèmes, 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 derrière la simplicité.
Dans Shoal, nous nous appuyons sur la capacité d'exécuter des calculs locaux sur le DAG et avons mis en œuvre la capacité de sauvegarder et de réinterpréter les informations des tours précédents. Grâce à l'accord de tous les validateurs sur la première ancre ordonnée comme insight clé, Shoal combine en séquence plusieurs instances de Bullshark pour les traiter en pipeline, rendant ( le premier ancrage ordonné le point de basculement des instances, ainsi que ) l'historique causal des ancrages utilisé pour calculer la réputation des leaders.
Chaîne de montage
V qui mappe 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 la correspondance F. Chaque instance commande une ancre, ce qui déclenche le passage à l'instance suivante.
Au départ, Shoal a lancé le premier instance de Bullshark lors du premier tour de DAG et l'a exécuté 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 commander un ancre à chaque tour. Les points d'ancrage de la première ronde sont triés par le premier exemple. Ensuite, Shoal commence un nouvel exemple lors de la deuxième ronde, qui a lui-même un point d'ancrage, cette ancre étant triée par cet exemple, puis un autre nouvel exemple commande un point d'ancrage lors de la troisième ronde, puis le processus continue.
Réputation des leaders
Lorsqu'on saute des points d'ancrage pendant le tri de Bullshark, la latence augmente. Dans ce cas, la technologie des pipelines est impuissante, car il est impossible de lancer une nouvelle instance avant que le point d'ancrage de l'instance précédente ne soit commandé. Shoal garantit qu'il est peu probable que les leaders correspondants soient choisis à l'avenir pour traiter les points d'ancrage manquants, 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 des scores faibles, car ils peuvent être en panne, lents ou malveillants.
Son principe est de recalculer de manière déterministe le mappage prédéfini F de chaque tour au leader à chaque mise à jour du score, en faveur du leader ayant le score le plus élevé. Pour que les validateurs parviennent à un consensus sur le nouveau mappage, ils doivent parvenir à un consensus sur le score, afin d'atteindre un consensus sur l'historique utilisé pour dériver les scores.
Dans Shoal, la pipeline et la réputation des leaders peuvent se combiner naturellement, car elles utilisent toutes deux la même technologie de base, à savoir la réinterprétation du DAG après avoir atteint un consensus sur le premier point d'ancrage ordonné.
En fait, la seule différence est qu'après le tri des points d'ancrage lors du tour r, le validateur n'a besoin de calculer une nouvelle carte F' qu'à partir du tour r+1, en se basant sur l'historique causal des points d'ancrage ordonnés du 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.
Il n'y a plus de dépassement de délai
Le temps d'attente joue un rôle crucial dans toutes les implémentations BFT déterministes basées sur des leaders. Cependant, la complexité qu'ils introduisent augmente le nombre d'états internes à gérer et à surveiller, ce qui complique le processus de débogage et nécessite davantage de techniques d'observation.
Le dépassement de délai augmentera également significativement la latence, car il est très important de les configurer correctement et nécessite souvent des ajustements dynamiques, car cela dépend fortement de l'environnement ( réseau ). Avant de passer au prochain leader, le protocole paie la pénalité de latence complète 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 sauter de bons leaders. Par exemple, nous avons observé qu'en cas de forte charge, les leaders dans Jolteon/Hotstuff sont accablés et que le délai a expiré avant qu'ils ne puissent faire progresser les choses.
Malheureusement, les protocoles basés sur le leader ( comme Hotstuff et Jolteon) nécessitent essentiellement une Goutte pour garantir que le protocole progresse chaque fois qu'un leader échoue. Sans Goutte, même un leader en panne peut arrêter le protocole indéfiniment. En raison de l'incapacité à distinguer pendant la latence, il est impossible de savoir s'il y a un problème.