Cadre Shoal : une solution innovante pour améliorer les performances de la blockchain Aptos
Aptos Labs a récemment proposé le cadre Shoal, visant à résoudre deux problèmes clés dans le consensus DAG BFT, réduisant considérablement la latence et éliminant pour la première fois la dépendance aux délais dans les protocoles asynchrones déterministes. Dans l'ensemble, Shoal augmente la latence de Bullshark de 40 % en l'absence de défaillance et de 80 % en cas de défaillance.
Shoal améliore le protocole de consensus basé sur Narwhal ( grâce à un mécanisme de pipeline et de réputation des leaders, tel que DAG-Rider, Tusk, Bullshark, etc. La technologie de pipeline réduit la latence de tri DAG en introduisant un point d'ancrage à chaque tour, tandis que le mécanisme de réputation des leaders améliore encore la latence en s'assurant que le point d'ancrage est associé aux nœuds de validation les plus rapides. De plus, la réputation des leaders permet à Shoal d'exploiter la construction asynchrone du DAG pour éliminer les délais dans tous les scénarios, réalisant ainsi une réactivité universelle.
L'idée fondamentale de Shoal est d'exécuter plusieurs instances du protocole sous-jacent dans l'ordre. Prenons l'exemple de Bullshark, on peut l'imaginer comme un groupe de "requins" en train de courir une course de relais.
![Explication détaillée du cadre Shoal : comment réduire la latence de Bullshark sur Aptos ?])https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp(
Motivation
Le réseau Blockchain a toujours cherché à obtenir de meilleures performances, se concentrant initialement sur la réduction de la complexité de communication. Cependant, cette approche n'a pas entraîné d'amélioration significative du débit. Par exemple, le Hotstuff implémenté dans les premières versions de Diem n'atteignait que 3500 TPS, bien en dessous de l'objectif de plus de 100 000 TPS.
Les récentes avancées proviennent 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 classe qu'un petit nombre de métadonnées, atteignant un débit de 160 000 TPS.
Aptos a précédemment présenté Quorum Store, qui est l'implémentation de Narwhal, séparant la diffusion des données du consensus et utilisé pour étendre le protocole de consensus actuel Jolteon. Jolteon combine le chemin rapide linéaire de Tendermint et le changement de vue de style PBFT, réduisant le retard 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.
Ainsi, Aptos a décidé de déployer Bullshark, un protocole de consensus sans coût de communication, sur le DAG Narwhal. Cependant, la structure DAG à haut débit prise en charge par Bullshark entraîne un coût de latence de 50 %. L'objectif du cadre Shoal est de réduire considérablement la latence de Bullshark.
![Explication détaillée du cadre Shoal : Comment réduire le délai de Bullshark sur Aptos ?])https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp(
Contexte DAG-BFT
Chaque sommet dans le DAG Narwhal est associé à un tour. Pour entrer au tour r, il est nécessaire d'obtenir n-f sommets du 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'asynchrone du réseau, différents validateurs peuvent observer différentes vues locales du DAG.
Une caractéristique clé du DAG est l'absence d'ambiguïté : si deux nœuds de validation ont le même sommet v dans leur vue locale du DAG, alors ils possèdent exactement la même histoire causale de v.
![Explication détaillée du cadre Shoal : comment réduire la latence de Bullshark sur Aptos ?])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
Tri 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. Des protocoles tels que 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 spécifique soit différente, tous les protocoles de consensus basés sur Narwhal ont la structure suivante :
Point d'ancrage prévu : tous les quelques cycles, un leader prédéterminé est désigné, et son 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 trier ou sauter.
Histoire causale triée : les validateurs traitent un par un la liste des points d'ancrage ordonnée, en triant les sommets non triés précédemment dans l'histoire causale de chaque point d'ancrage.
La clé pour satisfaire la sécurité est de s'assurer que toutes les listes d'ancrage ordonnées créées par les nœuds de validation honnêtes partagent le même préfixe. Shoal fait une observation importante sur tous ces protocoles : tous les validateurs s'accordent sur le premier ancrage ordonné.
Problèmes de délai de Bullshark
Le délai de Bullshark dépend du nombre de tours entre les points d'ancrage ordonnés dans le DAG. Bien que certaines versions synchronisées aient un délai inférieur à celui des versions asynchrones, elles restent néanmoins loin d'être optimales.
Il existe principalement deux problèmes :
Délai moyen de bloc : Dans des cas courants, les sommets impairs nécessitent trois tours pour être triés, tandis que les sommets pairs non ancrés nécessitent quatre tours.
Délai de situation de défaillance : Si un leader d'une ronde ne parvient pas à diffuser à temps le point d'ancrage, ce point d'ancrage sera sauté, et tous les sommets non triés des rondes précédentes devront attendre le tri du prochain point d'ancrage. Cela réduit considérablement les performances des réseaux géographiquement distribués, surtout parce que Bullshark utilise un délai d'attente pour le leader.
![Explication détaillée du cadre Shoal : Comment réduire le délai de Bullshark sur Aptos ?])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
Cadre Shoal
Shoal améliore Bullshark) ou tout protocole BFT basé sur Narwhal( grâce à des pipelines, permettant d'avoir un point d'ancrage à chaque tour, réduisant le délai de tous les sommets non ancrés à trois tours. Shoal introduit également un mécanisme de réputation de leader sans coût dans le DAG, favorisant le choix de leaders rapides.
) défi
Il est considéré comme difficile d'implémenter le pipeline et la réputation du leader dans le protocole DAG :
Il semble que tenter de modifier la logique de base de Bullshark ne soit pas viable.
La réputation des leaders peut entraîner des classements différents, et les validateurs doivent parvenir à un consensus sur l'historique ordonné pour sélectionner les futurs points d'ancrage.
En tant que preuve de la difficulté des problèmes, les implémentations de Bullshark dans l'environnement de production actuelle ne prennent pas en charge ces fonctionnalités.
protocole
La solution de Shoal est relativement simple. Elle utilise la capacité d'exécuter des calculs locaux sur un DAG pour réaliser la sauvegarde et la réinterprétation des informations des premiers tours. Basé sur l'idée que tous les validateurs s'accordent sur le premier point d'ancrage ordonné, Shoal combine de manière séquentielle plusieurs instances de Bullshark pour un traitement en pipeline, permettant ainsi :
Le premier point d'ancrage ordonné est le point de changement de l'instance.
L'histoire causale des points d'ancrage est utilisée pour calculer la réputation des leaders.
chaîne de montage
V qui mappe les tours aux leaders. Shoal exécute les instances de Bullshark dans l'ordre, chaque instance classant un point d'ancrage et déclenchant la transition vers l'instance suivante.
Shoal a lancé la première instance de Bullshark à partir du premier tour de DAG, jusqu'à ce que le premier point d'ancrage ordonné ### soit déterminé, supposons au tour r (. Tous les validateurs ont accepté ce point d'ancrage, permettant ainsi de convenir de manière déterministe de la réinterprétation du DAG à partir du tour r+1. Shoal lance une nouvelle instance de Bullshark au tour r+1.
Idéalement, cela permet à Shoal de trier un point d'ancrage par round. Le premier point d'ancrage est trié par la première instance, puis une nouvelle instance commence à trier le point d'ancrage de ce round au début du deuxième round, et ainsi de suite.
![Explication détaillée du cadre Shoal : comment réduire la latence de Bullshark sur Aptos ?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
) Réputation des leaders
Lorsque le Bullshark saute un point d'ancrage, le délai augmente. La technologie de pipeline est inefficace dans ce cas, car il faut attendre que l'instance précédente trie le point d'ancrage avant de pouvoir démarrer une nouvelle instance. Shoal attribue un score à chaque nœud de validation grâce à un mécanisme de réputation, en fonction de son historique d'activité récent. Les validateurs réactifs obtiennent un score élevé, sinon un score bas.
L'idée est de recalculer de manière déterministe la correspondance F entre les tours et les leaders à chaque mise à jour de score, en faveur des leaders à score élevé. Pour que les validateurs parviennent à un consensus sur la nouvelle correspondance, ils doivent parvenir à un consensus sur les scores, puis sur l'historique utilisé pour dériver les scores.
Dans Shoal, la réputation des pipelines et des leaders peut se combiner naturellement, car elle est basée sur la réinterprétation du DAG après avoir atteint un consensus au premier point d'ancrage ordonné. La seule différence est qu'après le point d'ancrage de la rème ronde, les validateurs calculent la nouvelle mappage F' à partir de la r+1ème ronde en fonction de l'historique causal de ce point d'ancrage. Ensuite, à partir de la r+1ème ronde, une nouvelle instance de Bullshark est exécutée en utilisant le F' mis à jour.
![Explication détaillée du cadre Shoal : comment réduire le délai de Bullshark sur Aptos ?]###https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
) Éliminer le dépassement de temps
Le dépassement de temps est crucial dans toutes les implémentations BFT déterministes basées sur un leader. Cependant, cela augmente la complexité, nécessitant une gestion et une observation internes plus importantes, rendant le débogage plus difficile.
Le dépassement de temps augmentera également de manière significative le délai, car une configuration correcte est importante et nécessite souvent des ajustements dynamiques. Avant de passer au prochain leader, le protocole doit payer la pénalité de délai de dépassement complète pour le leader défaillant. Par conséquent, les paramètres de dépassement ne doivent pas être trop conservateurs, mais s'ils sont trop courts, ils pourraient passer à côté de bons leaders.
Malheureusement, les protocoles basés sur le leader ### comme Hotstuff et Jolteon( nécessitent essentiellement des délais pour garantir des progrès en cas de défaillance du leader. Sans délai, même un leader en panne pourrait arrêter le protocole indéfiniment. Étant donné qu'il est impossible de distinguer les défaillances des leaders lents pendant les périodes asynchrones, les délais peuvent amener les nœuds de validation à remplacer tous les leaders sans activité de consensus.
Dans Bullshark, le temps d'attente est utilisé pour la construction du DAG, afin de s'assurer que les leaders honnêtes ajoutent des points d'ancrage au DAG suffisamment rapidement pour le tri pendant la synchronisation.
Nous avons observé que la construction du DAG fournit une "horloge" pour estimer la vitesse du réseau. Tant que n-f validateurs honnêtes continuent à ajouter des sommets au DAG, les tours avanceront. Bien que Bullshark ne puisse peut-être pas trier à la vitesse du réseau, le DAG continue de croître à la vitesse du réseau. Finalement, lorsque un leader sans faute diffuse suffisamment rapidement le point d'ancrage, l'ensemble de l'histoire causale du point d'ancrage sera trié.
Dans l'évaluation, nous avons comparé Bullshark avec et sans dépassement de temps :
Leader rapide : les deux méthodes ont le même délai, car les points d'ancrage sont triés et ne utilisent pas de délai d'attente.
Leaders erronés : pas de délai Bullshark sans délai, car les nœuds de validation sautent immédiatement leur point d'ancrage.
Leaders lents : avec Bullshark sans délai, les performances sont meilleures, car les validateurs attendront le point d'ancrage, tandis qu'avec un délai, ils pourraient sauter le point d'ancrage.
Dans Shoal, éviter les délais est étroitement lié à la réputation des leaders. Attendre de manière répétée des leaders lents augmente la latence, tandis que le mécanisme de réputation exclut les validateurs lents d'être choisis comme leaders. De cette manière, le système peut fonctionner à la vitesse du réseau dans tous les scénarios réels.
Il est important de noter que le résultat d'impossibilité de FLP indique qu'il n'existe aucun protocole de consensus déterministe capable d'éviter complètement les délais. Shoal ne peut pas contourner ce résultat, car il existe théoriquement un calendrier d'événements adverses qui peut empêcher tous les points d'ancrage d'être triés. En revanche, après un nombre configurable de sauts de points d'ancrage, Shoal reviendra à un délai. Cependant, dans la pratique, cette situation est extrêmement improbable.
) Réactivité générale
Le papier Hotstuff popularise le concept de réponse optimiste, ce qui signifie intuitivement que le protocole peut fonctionner à la vitesse du réseau dans de bonnes conditions, y compris un leader rapide et un réseau synchronisé ###.
Shoal offre une meilleure caractéristique, appelée la réactivité universelle. Plus précisément, par rapport à Hotstuff, même si le leader échoue dans un nombre configurable de tours consécutifs ou si le réseau subit des périodes asynchrones, Shoal continuera à fonctionner à la vitesse du réseau.
La réactivité universelle offre une garantie de progrès strictement meilleure pendant les périodes asynchrones et en cas de défaillance du leader. Pendant la synchronisation avec un leader lent, ces caractéristiques ne peuvent pas être comparées directement, car elles dépendent de la vitesse du leader. Cependant, compte tenu du mécanisme de réputation du leader, les leaders lents dans Shoal devraient être rares.
Cadre Shoal : Amélioration de 40 % de la latence de la chaîne Aptos et élimination de la dépendance au délai.
Cadre Shoal : une solution innovante pour améliorer les performances de la blockchain Aptos
Aptos Labs a récemment proposé le cadre Shoal, visant à résoudre deux problèmes clés dans le consensus DAG BFT, réduisant considérablement la latence et éliminant pour la première fois la dépendance aux délais dans les protocoles asynchrones déterministes. Dans l'ensemble, Shoal augmente la latence de Bullshark de 40 % en l'absence de défaillance et de 80 % en cas de défaillance.
Shoal améliore le protocole de consensus basé sur Narwhal ( grâce à un mécanisme de pipeline et de réputation des leaders, tel que DAG-Rider, Tusk, Bullshark, etc. La technologie de pipeline réduit la latence de tri DAG en introduisant un point d'ancrage à chaque tour, tandis que le mécanisme de réputation des leaders améliore encore la latence en s'assurant que le point d'ancrage est associé aux nœuds de validation les plus rapides. De plus, la réputation des leaders permet à Shoal d'exploiter la construction asynchrone du DAG pour éliminer les délais dans tous les scénarios, réalisant ainsi une réactivité universelle.
L'idée fondamentale de Shoal est d'exécuter plusieurs instances du protocole sous-jacent dans l'ordre. Prenons l'exemple de Bullshark, on peut l'imaginer comme un groupe de "requins" en train de courir une course de relais.
![Explication détaillée du cadre Shoal : comment réduire la latence de Bullshark sur Aptos ?])https://img-cdn.gateio.im/webp-social/moments-8d6acd885bad7b8f911bdce15a7c884f.webp(
Motivation
Le réseau Blockchain a toujours cherché à obtenir de meilleures performances, se concentrant initialement sur la réduction de la complexité de communication. Cependant, cette approche n'a pas entraîné d'amélioration significative du débit. Par exemple, le Hotstuff implémenté dans les premières versions de Diem n'atteignait que 3500 TPS, bien en dessous de l'objectif de plus de 100 000 TPS.
Les récentes avancées proviennent 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 classe qu'un petit nombre de métadonnées, atteignant un débit de 160 000 TPS.
Aptos a précédemment présenté Quorum Store, qui est l'implémentation de Narwhal, séparant la diffusion des données du consensus et utilisé pour étendre le protocole de consensus actuel Jolteon. Jolteon combine le chemin rapide linéaire de Tendermint et le changement de vue de style PBFT, réduisant le retard 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.
Ainsi, Aptos a décidé de déployer Bullshark, un protocole de consensus sans coût de communication, sur le DAG Narwhal. Cependant, la structure DAG à haut débit prise en charge par Bullshark entraîne un coût de latence de 50 %. L'objectif du cadre Shoal est de réduire considérablement la latence de Bullshark.
![Explication détaillée du cadre Shoal : Comment réduire le délai de Bullshark sur Aptos ?])https://img-cdn.gateio.im/webp-social/moments-f6b6281c928e3fa7a2412a480c9c1806.webp(
Contexte DAG-BFT
Chaque sommet dans le DAG Narwhal est associé à un tour. Pour entrer au tour r, il est nécessaire d'obtenir n-f sommets du 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'asynchrone du réseau, différents validateurs peuvent observer différentes vues locales du DAG.
Une caractéristique clé du DAG est l'absence d'ambiguïté : si deux nœuds de validation ont le même sommet v dans leur vue locale du DAG, alors ils possèdent exactement la même histoire causale de v.
![Explication détaillée du cadre Shoal : comment réduire la latence de Bullshark sur Aptos ?])https://img-cdn.gateio.im/webp-social/moments-b7ed8888da112bae8d34c0fdb338b138.webp(
Tri 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. Des protocoles tels que 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 spécifique soit différente, tous les protocoles de consensus basés sur Narwhal ont la structure suivante :
Point d'ancrage prévu : tous les quelques cycles, un leader prédéterminé est désigné, et son 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 trier ou sauter.
Histoire causale triée : les validateurs traitent un par un la liste des points d'ancrage ordonnée, en triant les sommets non triés précédemment dans l'histoire causale de chaque point d'ancrage.
La clé pour satisfaire la sécurité est de s'assurer que toutes les listes d'ancrage ordonnées créées par les nœuds de validation honnêtes partagent le même préfixe. Shoal fait une observation importante sur tous ces protocoles : tous les validateurs s'accordent sur le premier ancrage ordonné.
Problèmes de délai de Bullshark
Le délai de Bullshark dépend du nombre de tours entre les points d'ancrage ordonnés dans le DAG. Bien que certaines versions synchronisées aient un délai inférieur à celui des versions asynchrones, elles restent néanmoins loin d'être optimales.
Il existe principalement deux problèmes :
Délai moyen de bloc : Dans des cas courants, les sommets impairs nécessitent trois tours pour être triés, tandis que les sommets pairs non ancrés nécessitent quatre tours.
Délai de situation de défaillance : Si un leader d'une ronde ne parvient pas à diffuser à temps le point d'ancrage, ce point d'ancrage sera sauté, et tous les sommets non triés des rondes précédentes devront attendre le tri du prochain point d'ancrage. Cela réduit considérablement les performances des réseaux géographiquement distribués, surtout parce que Bullshark utilise un délai d'attente pour le leader.
![Explication détaillée du cadre Shoal : Comment réduire le délai de Bullshark sur Aptos ?])https://img-cdn.gateio.im/webp-social/moments-46d37add0d9e81b2f295edf8eddd907f.webp(
Cadre Shoal
Shoal améliore Bullshark) ou tout protocole BFT basé sur Narwhal( grâce à des pipelines, permettant d'avoir un point d'ancrage à chaque tour, réduisant le délai de tous les sommets non ancrés à trois tours. Shoal introduit également un mécanisme de réputation de leader sans coût dans le DAG, favorisant le choix de leaders rapides.
) défi
Il est considéré comme difficile d'implémenter le pipeline et la réputation du leader dans le protocole DAG :
Il semble que tenter de modifier la logique de base de Bullshark ne soit pas viable.
La réputation des leaders peut entraîner des classements différents, et les validateurs doivent parvenir à un consensus sur l'historique ordonné pour sélectionner les futurs points d'ancrage.
En tant que preuve de la difficulté des problèmes, les implémentations de Bullshark dans l'environnement de production actuelle ne prennent pas en charge ces fonctionnalités.
protocole
La solution de Shoal est relativement simple. Elle utilise la capacité d'exécuter des calculs locaux sur un DAG pour réaliser la sauvegarde et la réinterprétation des informations des premiers tours. Basé sur l'idée que tous les validateurs s'accordent sur le premier point d'ancrage ordonné, Shoal combine de manière séquentielle plusieurs instances de Bullshark pour un traitement en pipeline, permettant ainsi :
chaîne de montage
V qui mappe les tours aux leaders. Shoal exécute les instances de Bullshark dans l'ordre, chaque instance classant un point d'ancrage et déclenchant la transition vers l'instance suivante.
Shoal a lancé la première instance de Bullshark à partir du premier tour de DAG, jusqu'à ce que le premier point d'ancrage ordonné ### soit déterminé, supposons au tour r (. Tous les validateurs ont accepté ce point d'ancrage, permettant ainsi de convenir de manière déterministe de la réinterprétation du DAG à partir du tour r+1. Shoal lance une nouvelle instance de Bullshark au tour r+1.
Idéalement, cela permet à Shoal de trier un point d'ancrage par round. Le premier point d'ancrage est trié par la première instance, puis une nouvelle instance commence à trier le point d'ancrage de ce round au début du deuxième round, et ainsi de suite.
![Explication détaillée du cadre Shoal : comment réduire la latence de Bullshark sur Aptos ?])https://img-cdn.gateio.im/webp-social/moments-0b0928cb6240e994c1514c75e080a4b2.webp(
) Réputation des leaders
Lorsque le Bullshark saute un point d'ancrage, le délai augmente. La technologie de pipeline est inefficace dans ce cas, car il faut attendre que l'instance précédente trie le point d'ancrage avant de pouvoir démarrer une nouvelle instance. Shoal attribue un score à chaque nœud de validation grâce à un mécanisme de réputation, en fonction de son historique d'activité récent. Les validateurs réactifs obtiennent un score élevé, sinon un score bas.
L'idée est de recalculer de manière déterministe la correspondance F entre les tours et les leaders à chaque mise à jour de score, en faveur des leaders à score élevé. Pour que les validateurs parviennent à un consensus sur la nouvelle correspondance, ils doivent parvenir à un consensus sur les scores, puis sur l'historique utilisé pour dériver les scores.
Dans Shoal, la réputation des pipelines et des leaders peut se combiner naturellement, car elle est basée sur la réinterprétation du DAG après avoir atteint un consensus au premier point d'ancrage ordonné. La seule différence est qu'après le point d'ancrage de la rème ronde, les validateurs calculent la nouvelle mappage F' à partir de la r+1ème ronde en fonction de l'historique causal de ce point d'ancrage. Ensuite, à partir de la r+1ème ronde, une nouvelle instance de Bullshark est exécutée en utilisant le F' mis à jour.
![Explication détaillée du cadre Shoal : comment réduire le délai de Bullshark sur Aptos ?]###https://img-cdn.gateio.im/webp-social/moments-859e732e16c3eee0e2c93422474debc2.webp(
) Éliminer le dépassement de temps
Le dépassement de temps est crucial dans toutes les implémentations BFT déterministes basées sur un leader. Cependant, cela augmente la complexité, nécessitant une gestion et une observation internes plus importantes, rendant le débogage plus difficile.
Le dépassement de temps augmentera également de manière significative le délai, car une configuration correcte est importante et nécessite souvent des ajustements dynamiques. Avant de passer au prochain leader, le protocole doit payer la pénalité de délai de dépassement complète pour le leader défaillant. Par conséquent, les paramètres de dépassement ne doivent pas être trop conservateurs, mais s'ils sont trop courts, ils pourraient passer à côté de bons leaders.
Malheureusement, les protocoles basés sur le leader ### comme Hotstuff et Jolteon( nécessitent essentiellement des délais pour garantir des progrès en cas de défaillance du leader. Sans délai, même un leader en panne pourrait arrêter le protocole indéfiniment. Étant donné qu'il est impossible de distinguer les défaillances des leaders lents pendant les périodes asynchrones, les délais peuvent amener les nœuds de validation à remplacer tous les leaders sans activité de consensus.
Dans Bullshark, le temps d'attente est utilisé pour la construction du DAG, afin de s'assurer que les leaders honnêtes ajoutent des points d'ancrage au DAG suffisamment rapidement pour le tri pendant la synchronisation.
Nous avons observé que la construction du DAG fournit une "horloge" pour estimer la vitesse du réseau. Tant que n-f validateurs honnêtes continuent à ajouter des sommets au DAG, les tours avanceront. Bien que Bullshark ne puisse peut-être pas trier à la vitesse du réseau, le DAG continue de croître à la vitesse du réseau. Finalement, lorsque un leader sans faute diffuse suffisamment rapidement le point d'ancrage, l'ensemble de l'histoire causale du point d'ancrage sera trié.
Dans l'évaluation, nous avons comparé Bullshark avec et sans dépassement de temps :
Leader rapide : les deux méthodes ont le même délai, car les points d'ancrage sont triés et ne utilisent pas de délai d'attente.
Leaders erronés : pas de délai Bullshark sans délai, car les nœuds de validation sautent immédiatement leur point d'ancrage.
Leaders lents : avec Bullshark sans délai, les performances sont meilleures, car les validateurs attendront le point d'ancrage, tandis qu'avec un délai, ils pourraient sauter le point d'ancrage.
Dans Shoal, éviter les délais est étroitement lié à la réputation des leaders. Attendre de manière répétée des leaders lents augmente la latence, tandis que le mécanisme de réputation exclut les validateurs lents d'être choisis comme leaders. De cette manière, le système peut fonctionner à la vitesse du réseau dans tous les scénarios réels.
Il est important de noter que le résultat d'impossibilité de FLP indique qu'il n'existe aucun protocole de consensus déterministe capable d'éviter complètement les délais. Shoal ne peut pas contourner ce résultat, car il existe théoriquement un calendrier d'événements adverses qui peut empêcher tous les points d'ancrage d'être triés. En revanche, après un nombre configurable de sauts de points d'ancrage, Shoal reviendra à un délai. Cependant, dans la pratique, cette situation est extrêmement improbable.
) Réactivité générale
Le papier Hotstuff popularise le concept de réponse optimiste, ce qui signifie intuitivement que le protocole peut fonctionner à la vitesse du réseau dans de bonnes conditions, y compris un leader rapide et un réseau synchronisé ###.
Shoal offre une meilleure caractéristique, appelée la réactivité universelle. Plus précisément, par rapport à Hotstuff, même si le leader échoue dans un nombre configurable de tours consécutifs ou si le réseau subit des périodes asynchrones, Shoal continuera à fonctionner à la vitesse du réseau.
La réactivité universelle offre une garantie de progrès strictement meilleure pendant les périodes asynchrones et en cas de défaillance du leader. Pendant la synchronisation avec un leader lent, ces caractéristiques ne peuvent pas être comparées directement, car elles dépendent de la vitesse du leader. Cependant, compte tenu du mécanisme de réputation du leader, les leaders lents dans Shoal devraient être rares.
![Explication détaillée du cadre Shoal : comment réduire