Cadre Shoal : une solution innovante pour Goutte la latence de Bullshark sur Aptos
Aptos Labs a récemment résolu deux problèmes d'ouverture importants dans le DAG BFT, réduisant considérablement la latence et éliminant pour la première fois le besoin de délais dans le protocole de consensus déterministe. Dans l'ensemble, dans des conditions sans faute, la latence de Bullshark a été améliorée de 40 %, et en cas de faute, elle a été améliorée de 80 %.
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 dans DAG-Rider, Tusk, Bullshark ). Le traitement en 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 encore le problème de latence en s'assurant que le point d'ancrage est associé au nœud de validation le plus rapide. De plus, la réputation des leaders permet à Shoal de tirer parti de la construction asynchrone du DAG pour éliminer les mécanismes de délai dans tous les scénarios. Cela permet à Shoal d'offrir ce que nous appelons une "réponse universelle", qui inclut les propriétés de réponse optimiste généralement requises.
La technologie de Shoal est très simple, impliquant l'exécution séquentielle de plusieurs instances du protocole sous-jacent. Ainsi, lorsque nous instancions Bullshark, l'effet que nous obtenons ressemble à un groupe de "requins" participant à une course de relais.
Contexte et motivation
Dans la quête d'une haute performance des réseaux blockchain, les gens se sont toujours concentrés sur la Goutte de la complexité de communication. Cependant, cette méthode n'a pas conduit à une amélioration significative du débit. Par exemple, le Hotstuff mis en œuvre dans les premières versions de Diem n'a réalisé que 3500 TPS, bien en dessous de notre objectif de 100 000+ TPS.
Les récentes avancées proviennent de la prise de conscience que la propagation des données est le principal goulot 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 de base, proposant une architecture où tous les validateurs propagent les données simultanément, tandis que le composant de consensus ne classe qu'un petit nombre de métadonnées. Le document Narwhal rapporte un débit de 160 000 TPS.
Dans un article précédent, nous avons présenté Quorum Store - notre implémentation de Narwhal, qui sépare la propagation des données du consensus, ainsi que la manière dont nous l'utilisons pour étendre le protocole de consensus actuel Jolteon. Jolteon est un protocole basé sur un leader, qui combine le chemin rapide linéaire de Tendermint et le changement de vue de style PBFT, capable de réduire la latence de Hotstuff de 33 %. Cependant, il est clair qu'un protocole de consensus basé sur un leader ne peut pas pleinement exploiter le potentiel de débit de Narwhal. Bien que la propagation des données soit séparée du consensus, à 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 coût de communication sur le Narwhal DAG. Malheureusement, par rapport à Jolteon, la structure DAG qui prend en charge le haut débit de Bullshark entraîne un coût de latence de 50 %.
Cet article présentera comment Shoal peut réduire considérablement la latence de Bullshark.
Contexte DAG-BFT
Chaque sommet dans le Narwhal DAG est associé à un tour. Pour entrer dans le tour r, le validateur doit d'abord obtenir n-f sommets appartenant au tour r-1. Chaque validateur peut diffuser un sommet par tour, chaque sommet référant 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 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.
Tri séquentiel
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 réservé : toutes les quelques rondes (, comme dans Bullshark, deux rondes ) auront 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.
Ordre de l'historique causale : les validateurs traitent un par un la liste des ancrages ordonnés, pour chaque ancrage, ils ordonnent tous les sommets précédemment désordonnés dans son historique causale selon certaines règles de déterminisme.
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, afin que toutes les listes partagent le même préfixe. Dans Shoal, nous faisons les observations suivantes 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 synchrone de Bullshark soit plus pratique et ait une meilleure latence que la version asynchrone, elle est loin d'être optimale.
Problème 1 : latence moyenne des blocs. Dans Bullshark, chaque round pair a un point d'ancrage, et chaque sommet du round impair est interprété comme un vote. Dans des cas courants, deux tours de DAG sont nécessaires pour trier les points d'ancrage, cependant, les sommets dans l'historique causal des points d'ancrage nécessitent plus de tours pour attendre que les points d'ancrage soient triés. Dans des cas courants, les sommets dans le round impair nécessitent trois tours, tandis que les sommets non ancrés dans le round pair nécessitent quatre tours.
Problème 2 : latence des pannes. L'analyse de latence ci-dessus s'applique aux situations sans pannes. D'autre part, si le leader d'un tour ne parvient pas à diffuser suffisamment rapidement les points d'ancrage, il ne sera pas possible de les trier (, ce qui entraîne leur saut ), obligeant tous les sommets non triés des premiers tours à 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, en améliorant Bullshark( ou tout autre protocole BFT basé sur Narwhal) grâce à un traitement en pipeline, permettant un point d'ancrage à chaque ronde et réduisant la latence de tous les sommets non ancrés dans le DAG à trois rondes. Shoal a également introduit un mécanisme de réputation de leader sans coût dans le DAG, ce qui favorise le choix de dirigeants 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 de la chaîne précédente ont essayé de modifier la logique centrale de Bullshark, mais cela semble en essence impossible.
La réputation des leaders est introduite dans DiemBFT et officialisée dans Carousel, basée sur le choix dynamique des futurs leaders selon la performance passée des validateurs, l'idée des points d'ancrage dans Bullshark. Bien que des divergences sur l'identité des leaders ne violent pas la sécurité de ces protocoles, dans Bullshark, cela peut entraîner un classement complètement différent, ce qui soulève le cœur du problème, à savoir que le choix dynamique et déterministe des points d'ancrage est nécessaire pour résoudre le consensus, et les validateurs doivent s'accorder sur l'historique ordonné pour choisir les futurs points d'ancrage.
En tant que preuve de la difficulté des problèmes, nous remarquons que l'implémentation de Bullshark, y compris celle actuellement en production, ne prend pas en charge ces caractéristiques.
Accord
Malgré les défis mentionnés ci-dessus, il s'avère que 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 sauvegarder et de réinterpréter les informations des tours précédents. Grâce à la compréhension fondamentale 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 du leader.
( traitement en chaîne
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, le point d'ancrage est déterminé à l'avance par le mappage F. Chaque instance trie un point d'ancrage, ce qui déclenche le passage à l'instance suivante.
Au début, Shoal a lancé le premier exemple de Bullshark lors du premier tour de DAG et l'a fait fonctionner jusqu'à ce qu'il détermine le premier point d'ancrage ordonné, comme lors du tour r. Tous les validateurs ont convenu de ce point d'ancrage. Par conséquent, tous les validateurs peuvent de manière déterministe convenir de réinterpréter le DAG à partir du tour r+1. Shoal a simplement lancé un nouvel exemple de Bullshark lors du tour r+1.
Dans le meilleur des cas, cela permet à Shoal de trier un point d'ancrage à chaque tour. Le point d'ancrage du premier tour est trié par la première instance. Ensuite, Shoal commence une nouvelle instance au deuxième tour, qui a elle-même un point d'ancrage, ce point d'ancrage étant trié par cette instance, puis une autre nouvelle instance trie un point d'ancrage au troisième tour, ce processus continue.
![Explication détaillée du cadre Shoal : comment réduire la latence de Bullshark sur Aptos ?])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
) réputation des leaders
Lorsqu'un point d'ancrage est sauté pendant le tri de 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 le tri du point d'ancrage de l'instance précédente. Shoal garantit qu'il est peu probable que le leader correspondant soit choisi à l'avenir pour traiter les points d'ancrage manquants en attribuant un score à chaque nœud de validation en fonction de l'historique des activités récentes de chaque nœud de validation grâce à 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 faible score, 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 lors de chaque mise à jour des scores, en faveur des leaders ayant des scores plus élevés. Pour que les validateurs parviennent à un consensus sur le nouveau mappage, ils devraient s'accorder sur les scores, afin d'atteindre un consensus sur l'historique utilisé pour dériver les scores.
Dans Shoal, le traitement en pipeline et la réputation des leaders peuvent naturellement se combiner, 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 ancrages au cours de la rème ronde, le validateur n'a qu'à calculer un nouveau mappage F' à partir de la r+1ème ronde en se basant sur l'historique causal des ancrages ordonnés de la rème ronde. Ensuite, les nœuds de validation commencent à utiliser la fonction de sélection d'ancrage mise à jour F' pour exécuter une nouvelle instance de Bullshark à partir de la r+1ème ronde.
![Explication détaillée du cadre Shoal : comment réduire la latence de Bullshark sur Aptos ?]###https://img-cdn.gateio.im/webp-social/moments-1baf540693f376d93cb18ef3193593cc.webp(
) Éliminer le dépassement 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'observation.
Le dépassement de délai augmentera également significativement la latence.
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.
10 J'aime
Récompense
10
4
Partager
Commentaire
0/400
ZKProofEnthusiast
· 07-21 04:12
Hmm, tous ceux qui ont des soal sont assez en hausse.
Voir l'originalRépondre0
SchrodingerWallet
· 07-21 04:10
Cette vague de 3 va-t-elle décoller ?
Voir l'originalRépondre0
SmartContractPlumber
· 07-21 04:10
L'amélioration de la couche de consensus est la plus susceptible de provoquer des risques en chaîne. Parlez-moi des nouvelles vulnérabilités plus tard.
Voir l'originalRépondre0
DecentralizedElder
· 07-21 04:05
Trop fort ! Cette latence peut-elle vraiment atteindre 10 % ?
Shoal : Le nouveau cadre Aptos réduit considérablement la latence de Bullshark et élimine les besoins de dépassement de délai.
Cadre Shoal : une solution innovante pour Goutte la latence de Bullshark sur Aptos
Aptos Labs a récemment résolu deux problèmes d'ouverture importants dans le DAG BFT, réduisant considérablement la latence et éliminant pour la première fois le besoin de délais dans le protocole de consensus déterministe. Dans l'ensemble, dans des conditions sans faute, la latence de Bullshark a été améliorée de 40 %, et en cas de faute, elle a été améliorée de 80 %.
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 dans DAG-Rider, Tusk, Bullshark ). Le traitement en 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 encore le problème de latence en s'assurant que le point d'ancrage est associé au nœud de validation le plus rapide. De plus, la réputation des leaders permet à Shoal de tirer parti de la construction asynchrone du DAG pour éliminer les mécanismes de délai dans tous les scénarios. Cela permet à Shoal d'offrir ce que nous appelons une "réponse universelle", qui inclut les propriétés de réponse optimiste généralement requises.
La technologie de Shoal est très simple, impliquant l'exécution séquentielle de plusieurs instances du protocole sous-jacent. Ainsi, lorsque nous instancions Bullshark, l'effet que nous obtenons ressemble à un groupe de "requins" participant à une course de relais.
Contexte et motivation
Dans la quête d'une haute performance des réseaux blockchain, les gens se sont toujours concentrés sur la Goutte de la complexité de communication. Cependant, cette méthode n'a pas conduit à une amélioration significative du débit. Par exemple, le Hotstuff mis en œuvre dans les premières versions de Diem n'a réalisé que 3500 TPS, bien en dessous de notre objectif de 100 000+ TPS.
Les récentes avancées proviennent de la prise de conscience que la propagation des données est le principal goulot 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 de base, proposant une architecture où tous les validateurs propagent les données simultanément, tandis que le composant de consensus ne classe qu'un petit nombre de métadonnées. Le document Narwhal rapporte un débit de 160 000 TPS.
Dans un article précédent, nous avons présenté Quorum Store - notre implémentation de Narwhal, qui sépare la propagation des données du consensus, ainsi que la manière dont nous l'utilisons pour étendre le protocole de consensus actuel Jolteon. Jolteon est un protocole basé sur un leader, qui combine le chemin rapide linéaire de Tendermint et le changement de vue de style PBFT, capable de réduire la latence de Hotstuff de 33 %. Cependant, il est clair qu'un protocole de consensus basé sur un leader ne peut pas pleinement exploiter le potentiel de débit de Narwhal. Bien que la propagation des données soit séparée du consensus, à 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 coût de communication sur le Narwhal DAG. Malheureusement, par rapport à Jolteon, la structure DAG qui prend en charge le haut débit de Bullshark entraîne un coût de latence de 50 %.
Cet article présentera comment Shoal peut réduire considérablement la latence de Bullshark.
Contexte DAG-BFT
Chaque sommet dans le Narwhal DAG est associé à un tour. Pour entrer dans le tour r, le validateur doit d'abord obtenir n-f sommets appartenant au tour r-1. Chaque validateur peut diffuser un sommet par tour, chaque sommet référant 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 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.
Tri séquentiel
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 réservé : toutes les quelques rondes (, comme dans Bullshark, deux rondes ) auront 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.
Ordre de l'historique causale : les validateurs traitent un par un la liste des ancrages ordonnés, pour chaque ancrage, ils ordonnent tous les sommets précédemment désordonnés dans son historique causale selon certaines règles de déterminisme.
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, afin que toutes les listes partagent le même préfixe. Dans Shoal, nous faisons les observations suivantes 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 synchrone de Bullshark soit plus pratique et ait une meilleure latence que la version asynchrone, elle est loin d'être optimale.
Problème 1 : latence moyenne des blocs. Dans Bullshark, chaque round pair a un point d'ancrage, et chaque sommet du round impair est interprété comme un vote. Dans des cas courants, deux tours de DAG sont nécessaires pour trier les points d'ancrage, cependant, les sommets dans l'historique causal des points d'ancrage nécessitent plus de tours pour attendre que les points d'ancrage soient triés. Dans des cas courants, les sommets dans le round impair nécessitent trois tours, tandis que les sommets non ancrés dans le round pair nécessitent quatre tours.
Problème 2 : latence des pannes. L'analyse de latence ci-dessus s'applique aux situations sans pannes. D'autre part, si le leader d'un tour ne parvient pas à diffuser suffisamment rapidement les points d'ancrage, il ne sera pas possible de les trier (, ce qui entraîne leur saut ), obligeant tous les sommets non triés des premiers tours à 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, en améliorant Bullshark( ou tout autre protocole BFT basé sur Narwhal) grâce à un traitement en pipeline, permettant un point d'ancrage à chaque ronde et réduisant la latence de tous les sommets non ancrés dans le DAG à trois rondes. Shoal a également introduit un mécanisme de réputation de leader sans coût dans le DAG, ce qui favorise le choix de dirigeants 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 de la chaîne précédente ont essayé de modifier la logique centrale de Bullshark, mais cela semble en essence impossible.
La réputation des leaders est introduite dans DiemBFT et officialisée dans Carousel, basée sur le choix dynamique des futurs leaders selon la performance passée des validateurs, l'idée des points d'ancrage dans Bullshark. Bien que des divergences sur l'identité des leaders ne violent pas la sécurité de ces protocoles, dans Bullshark, cela peut entraîner un classement complètement différent, ce qui soulève le cœur du problème, à savoir que le choix dynamique et déterministe des points d'ancrage est nécessaire pour résoudre le consensus, et les validateurs doivent s'accorder sur l'historique ordonné pour choisir les futurs points d'ancrage.
En tant que preuve de la difficulté des problèmes, nous remarquons que l'implémentation de Bullshark, y compris celle actuellement en production, ne prend pas en charge ces caractéristiques.
Accord
Malgré les défis mentionnés ci-dessus, il s'avère que 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 sauvegarder et de réinterpréter les informations des tours précédents. Grâce à la compréhension fondamentale 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 du leader.
( traitement en chaîne
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, le point d'ancrage est déterminé à l'avance par le mappage F. Chaque instance trie un point d'ancrage, ce qui déclenche le passage à l'instance suivante.
Au début, Shoal a lancé le premier exemple de Bullshark lors du premier tour de DAG et l'a fait fonctionner jusqu'à ce qu'il détermine le premier point d'ancrage ordonné, comme lors du tour r. Tous les validateurs ont convenu de ce point d'ancrage. Par conséquent, tous les validateurs peuvent de manière déterministe convenir de réinterpréter le DAG à partir du tour r+1. Shoal a simplement lancé un nouvel exemple de Bullshark lors du tour r+1.
Dans le meilleur des cas, cela permet à Shoal de trier un point d'ancrage à chaque tour. Le point d'ancrage du premier tour est trié par la première instance. Ensuite, Shoal commence une nouvelle instance au deuxième tour, qui a elle-même un point d'ancrage, ce point d'ancrage étant trié par cette instance, puis une autre nouvelle instance trie un point d'ancrage au troisième tour, ce processus continue.
![Explication détaillée du cadre Shoal : comment réduire la latence de Bullshark sur Aptos ?])https://img-cdn.gateio.im/webp-social/moments-9f789cb669f6fcc244ea7ff7648e48b4.webp(
) réputation des leaders
Lorsqu'un point d'ancrage est sauté pendant le tri de 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 le tri du point d'ancrage de l'instance précédente. Shoal garantit qu'il est peu probable que le leader correspondant soit choisi à l'avenir pour traiter les points d'ancrage manquants en attribuant un score à chaque nœud de validation en fonction de l'historique des activités récentes de chaque nœud de validation grâce à 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 faible score, 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 lors de chaque mise à jour des scores, en faveur des leaders ayant des scores plus élevés. Pour que les validateurs parviennent à un consensus sur le nouveau mappage, ils devraient s'accorder sur les scores, afin d'atteindre un consensus sur l'historique utilisé pour dériver les scores.
Dans Shoal, le traitement en pipeline et la réputation des leaders peuvent naturellement se combiner, 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 ancrages au cours de la rème ronde, le validateur n'a qu'à calculer un nouveau mappage F' à partir de la r+1ème ronde en se basant sur l'historique causal des ancrages ordonnés de la rème ronde. Ensuite, les nœuds de validation commencent à utiliser la fonction de sélection d'ancrage mise à jour F' pour exécuter une nouvelle instance de Bullshark à partir de la r+1ème ronde.
![Explication détaillée du cadre Shoal : comment réduire la latence de Bullshark sur Aptos ?]###https://img-cdn.gateio.im/webp-social/moments-1baf540693f376d93cb18ef3193593cc.webp(
) Éliminer le dépassement 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'observation.
Le dépassement de délai augmentera également significativement la latence.