Cadre Shoal : Comment réduire la latence de Bullshark sur Aptos ?
Aperçu
Aptos labs a résolu deux problèmes ouverts importants dans le DAG BFT, réduisant considérablement la latence et éliminant pour la première fois le besoin de pauses dans les protocoles pratiques 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 défaillance.
Shoal est un cadre qui renforce le protocole de consensus basé sur Narwhal grâce à des pipelines et à la réputation des leaders. Les pipelines réduisent la latence de tri des DAG en introduisant des points d'ancrage à chaque tour, tandis que la réputation des leaders améliore davantage la latence en garantissant 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 des constructions de DAG asynchrones pour éliminer les dépassements de temps dans tous les scénarios. Cela permet à Shoal d'offrir des propriétés de réponse universelle, y compris les réponses optimistes généralement requises.
Cette technologie est très simple, impliquant l'exécution séquentielle de plusieurs instances du protocole sous-jacent. Lorsqu'elle est instanciée par Bullshark, c'est comme un groupe de "requins" participant à une course de relais.
Motivation
Dans la quête d'une 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 amélioration significative du débit. Par exemple, Hotstuff, mis en œuvre dans les premières versions de Diem, n'a atteint que 3500 TPS, bien en dessous de l'objectif de 100k+ TPS.
Récemment, la percée provient de la reconnaissance que la propagation des données est le principal goulot d'étranglement basé sur le protocole 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, et le composant de consensus ne commande qu'une petite quantité de métadonnées. Le document Narwhal rapporte un débit de 160 000 TPS.
Le Quorum Store introduit précédemment sépare la propagation des données du 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 le changement de vue de style PBFT, permettant de réduire la latence de Hotstuff de 33 %. Cependant, les protocoles de consensus basés sur un leader ne peuvent pas exploiter pleinement le potentiel de débit de Narwhal.
Ainsi, il a été décidé de déployer Bullshark sur le DAG Narwhal, un protocole de consensus sans frais de communication. Cependant, la structure DAG de Bullshark entraîne un coût de latence 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é à un tour. Pour entrer dans le tour r, un validateur doit 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'asynchronicité du réseau, différents validateurs peuvent observer différentes vues locales du DAG à tout moment.
Une propriété clé du DAG est qu'elle n'est pas ambiguë : si deux nœuds de validation ont le même sommet v dans leur vue locale du DAG, alors ils ont exactement la même histoire causale de v.
Ordre 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. 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.
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 a 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 commander et quels points d'ancrage sauter.
Historique de causalité ordonné : les validateurs traitent un par un la liste des points d'ancrage ordonnés, en triant tous les sommets désordonnés précédents dans l'historique de causalité de chaque point d'ancrage.
La clé pour garantir 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, où toutes les listes partagent le même préfixe. Dans Shoal, nous avons observé que tous les validateurs acceptent 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 certaines versions synchrones aient une meilleure latence que les versions asynchrones, elles sont loin d'être optimales.
Il y a principalement deux problèmes:
Latence moyenne des blocs : Dans des conditions courantes, les sommets impairs nécessitent trois tours, tandis que les sommets pairs non ancrés nécessitent quatre tours pour être triés.
Situation de latence des pannes : Si un leader de tour échoue à diffuser à temps le point d'ancrage, alors les sommets non triés des tours précédents doivent attendre le tri du prochain point d'ancrage, ce qui réduit considérablement la performance du réseau de réplication géographique.
Cadre Shoal
Shoal améliore Bullshark par le biais de pipelines, permettant à chaque tour d'avoir un point d'ancrage, réduisant la latence de tous les sommets non ancrés à trois tours. Shoal introduit également un mécanisme de réputation de leader à coût nul, favorisant le choix de leaders rapides.
Défi
Dans le protocole DAG, le pipeline et la réputation des leaders sont considérés comme des problèmes difficiles :
Les tentatives précédentes de modifier la logique de base de Bullshark dans la chaîne de production semblent en réalité impossibles.
La réputation des leaders peut conduire à un classement complètement différent, et les validateurs doivent parvenir à un consensus sur l'historique ordonné pour choisir les ancres futures.
En tant que preuve de la difficulté des problèmes, les implémentations Bullshark en environnement de production ne prennent actuellement pas en charge ces fonctionnalités.
Protocole
Shoal s'appuie sur l'exécution de calculs locaux sur le DAG, réalisant la capacité de sauvegarder et de réinterpréter les informations des tours précédents. En utilisant la compréhension selon laquelle 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 que :
Le premier point d'ancrage ordonné est le point de basculement de l'instance.
L'historique causal des points d'ancrage est utilisé pour calculer la réputation des leaders
chaîne de montage
Shoal exécute des instances Bullshark les unes après les autres, chaque instance commandant une ancre, déclenchant le passage à l'instance suivante.
Au départ, Shoal a lancé la première instance de Bullshark lors du premier tour de DAG, fonctionnant jusqu'à ce que le premier point d'ancrage ordonné ( soit déterminé, par exemple lors du tour r ). Tous les validateurs ont accepté ce point d'ancrage, permettant ainsi de convenir de manière certaine de la réinterprétation de DAG à partir du tour r+1. Shoal a lancé une nouvelle instance de Bullshark lors du tour r+1.
Idéalement, cela permet à Shoal de commander un point d'ancrage par tour.
réputation des leaders
Lorsque Bullshark saute au-dessus du point d'ancrage, la latence augmente. Shoal attribue des scores à chaque nœud de validation grâce à un mécanisme de réputation, garantissant qu'il est moins probable de choisir des leaders lents à l'avenir.
À chaque mise à jour des scores, recalculer de manière déterministe le mapping F des tours aux leaders, en favorisant les leaders à score élevé. Pour que les validateurs parviennent à un consensus sur le nouveau mapping, ils doivent parvenir à un consensus sur les scores.
Les chaînes de production 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é.
pas de latence
Le dépassement de délai joue un rôle clé dans l'implémentation BFT déterministe basée sur un leader, mais il introduit de la complexité et augmente significativement la latence.
Shoal a observé que la construction de DAG fournit une "horloge" pour estimer la vitesse du réseau. Tant que n-f validateurs honnêtes continuent d'ajouter des sommets au DAG, les tours continueront d'avancer. Finalement, lorsque le leader sans faute diffuse suffisamment rapidement le point d'ancrage, toute l'histoire causale du point d'ancrage sera triée.
Éviter les dépassements de temps est étroitement lié à la réputation des dirigeants. Attendre de manière répétée des dirigeants lents augmentera la latence, tandis que le mécanisme de réputation exclut les validateurs lents d'être choisis comme dirigeants.
réponse universelle
Shoal fournit des attributs de réponse universelle, fonctionnant à la vitesse du réseau même en cas d'échec du leader ou de réseau asynchrone. Cela est supérieur au concept de réponse optimiste de Hotstuff.
Évaluation
Réalisé Bullshark et Shoal, et comparé avec Jolteon. Principales conclusions :
Le Baseline Bullshark sans délai fonctionne le mieux en cas de défaillance.
Le pipeline de Shoal et le mécanisme de réputation des leaders ont considérablement amélioré la latence de Bullshark.
Sur 50 échecs, 16 échecs ont montré que la latence de Shoal était inférieure de 65 % à celle de Baseline Bullshark.
Jolteon ne peut pas être étendu à plus de 20 nœuds de validation, avec un débit d'environ la moitié de Bullshark/Shoal.
Dans l'ensemble, Shoal a considérablement amélioré la latence de Bullshark, et devrait pouvoir rivaliser avec la latence de bout en bout de Jolteon sous forte charge.
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.
12 J'aime
Récompense
12
5
Reposter
Partager
Commentaire
0/400
governance_ghost
· 08-10 03:14
80% de latence réduite, tss tss cette fois-ci, nous, les joueurs d'apttas, avons gagné à fond !
Voir l'originalRépondre0
ForkItAll
· 08-10 03:09
aptos a bien fait, tps a augmenté autant.
Voir l'originalRépondre0
DaisyUnicorn
· 08-10 03:08
Le petit requin nage enfin sans difficulté ~ La mise à niveau technique s'est transformée en un étang d'eau printanière.
Le cadre Shoal améliore considérablement les performances de la blockchain Aptos, réduisant la latence de 40 % à 80 %.
Cadre Shoal : Comment réduire la latence de Bullshark sur Aptos ?
Aperçu
Aptos labs a résolu deux problèmes ouverts importants dans le DAG BFT, réduisant considérablement la latence et éliminant pour la première fois le besoin de pauses dans les protocoles pratiques 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 défaillance.
Shoal est un cadre qui renforce le protocole de consensus basé sur Narwhal grâce à des pipelines et à la réputation des leaders. Les pipelines réduisent la latence de tri des DAG en introduisant des points d'ancrage à chaque tour, tandis que la réputation des leaders améliore davantage la latence en garantissant 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 des constructions de DAG asynchrones pour éliminer les dépassements de temps dans tous les scénarios. Cela permet à Shoal d'offrir des propriétés de réponse universelle, y compris les réponses optimistes généralement requises.
Cette technologie est très simple, impliquant l'exécution séquentielle de plusieurs instances du protocole sous-jacent. Lorsqu'elle est instanciée par Bullshark, c'est comme un groupe de "requins" participant à une course de relais.
Motivation
Dans la quête d'une 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 amélioration significative du débit. Par exemple, Hotstuff, mis en œuvre dans les premières versions de Diem, n'a atteint que 3500 TPS, bien en dessous de l'objectif de 100k+ TPS.
Récemment, la percée provient de la reconnaissance que la propagation des données est le principal goulot d'étranglement basé sur le protocole 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, et le composant de consensus ne commande qu'une petite quantité de métadonnées. Le document Narwhal rapporte un débit de 160 000 TPS.
Le Quorum Store introduit précédemment sépare la propagation des données du 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 le changement de vue de style PBFT, permettant de réduire la latence de Hotstuff de 33 %. Cependant, les protocoles de consensus basés sur un leader ne peuvent pas exploiter pleinement le potentiel de débit de Narwhal.
Ainsi, il a été décidé de déployer Bullshark sur le DAG Narwhal, un protocole de consensus sans frais de communication. Cependant, la structure DAG de Bullshark entraîne un coût de latence 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é à un tour. Pour entrer dans le tour r, un validateur doit 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'asynchronicité du réseau, différents validateurs peuvent observer différentes vues locales du DAG à tout moment.
Une propriété clé du DAG est qu'elle n'est pas ambiguë : si deux nœuds de validation ont le même sommet v dans leur vue locale du DAG, alors ils ont exactement la même histoire causale de v.
Ordre 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. 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.
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 a 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 commander et quels points d'ancrage sauter.
Historique de causalité ordonné : les validateurs traitent un par un la liste des points d'ancrage ordonnés, en triant tous les sommets désordonnés précédents dans l'historique de causalité de chaque point d'ancrage.
La clé pour garantir 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, où toutes les listes partagent le même préfixe. Dans Shoal, nous avons observé que tous les validateurs acceptent 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 certaines versions synchrones aient une meilleure latence que les versions asynchrones, elles sont loin d'être optimales.
Il y a principalement deux problèmes:
Latence moyenne des blocs : Dans des conditions courantes, les sommets impairs nécessitent trois tours, tandis que les sommets pairs non ancrés nécessitent quatre tours pour être triés.
Situation de latence des pannes : Si un leader de tour échoue à diffuser à temps le point d'ancrage, alors les sommets non triés des tours précédents doivent attendre le tri du prochain point d'ancrage, ce qui réduit considérablement la performance du réseau de réplication géographique.
Cadre Shoal
Shoal améliore Bullshark par le biais de pipelines, permettant à chaque tour d'avoir un point d'ancrage, réduisant la latence de tous les sommets non ancrés à trois tours. Shoal introduit également un mécanisme de réputation de leader à coût nul, favorisant le choix de leaders rapides.
Défi
Dans le protocole DAG, le pipeline et la réputation des leaders sont considérés comme des problèmes difficiles :
Les tentatives précédentes de modifier la logique de base de Bullshark dans la chaîne de production semblent en réalité impossibles.
La réputation des leaders peut conduire à un classement complètement différent, et les validateurs doivent parvenir à un consensus sur l'historique ordonné pour choisir les ancres futures.
En tant que preuve de la difficulté des problèmes, les implémentations Bullshark en environnement de production ne prennent actuellement pas en charge ces fonctionnalités.
Protocole
Shoal s'appuie sur l'exécution de calculs locaux sur le DAG, réalisant la capacité de sauvegarder et de réinterpréter les informations des tours précédents. En utilisant la compréhension selon laquelle 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 que :
chaîne de montage
Shoal exécute des instances Bullshark les unes après les autres, chaque instance commandant une ancre, déclenchant le passage à l'instance suivante.
Au départ, Shoal a lancé la première instance de Bullshark lors du premier tour de DAG, fonctionnant jusqu'à ce que le premier point d'ancrage ordonné ( soit déterminé, par exemple lors du tour r ). Tous les validateurs ont accepté ce point d'ancrage, permettant ainsi de convenir de manière certaine de la réinterprétation de DAG à partir du tour r+1. Shoal a lancé une nouvelle instance de Bullshark lors du tour r+1.
Idéalement, cela permet à Shoal de commander un point d'ancrage par tour.
réputation des leaders
Lorsque Bullshark saute au-dessus du point d'ancrage, la latence augmente. Shoal attribue des scores à chaque nœud de validation grâce à un mécanisme de réputation, garantissant qu'il est moins probable de choisir des leaders lents à l'avenir.
À chaque mise à jour des scores, recalculer de manière déterministe le mapping F des tours aux leaders, en favorisant les leaders à score élevé. Pour que les validateurs parviennent à un consensus sur le nouveau mapping, ils doivent parvenir à un consensus sur les scores.
Les chaînes de production 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é.
pas de latence
Le dépassement de délai joue un rôle clé dans l'implémentation BFT déterministe basée sur un leader, mais il introduit de la complexité et augmente significativement la latence.
Shoal a observé que la construction de DAG fournit une "horloge" pour estimer la vitesse du réseau. Tant que n-f validateurs honnêtes continuent d'ajouter des sommets au DAG, les tours continueront d'avancer. Finalement, lorsque le leader sans faute diffuse suffisamment rapidement le point d'ancrage, toute l'histoire causale du point d'ancrage sera triée.
Éviter les dépassements de temps est étroitement lié à la réputation des dirigeants. Attendre de manière répétée des dirigeants lents augmentera la latence, tandis que le mécanisme de réputation exclut les validateurs lents d'être choisis comme dirigeants.
réponse universelle
Shoal fournit des attributs de réponse universelle, fonctionnant à la vitesse du réseau même en cas d'échec du leader ou de réseau asynchrone. Cela est supérieur au concept de réponse optimiste de Hotstuff.
Évaluation
Réalisé Bullshark et Shoal, et comparé avec Jolteon. Principales conclusions :
Le Baseline Bullshark sans délai fonctionne le mieux en cas de défaillance.
Le pipeline de Shoal et le mécanisme de réputation des leaders ont considérablement amélioré la latence de Bullshark.
Sur 50 échecs, 16 échecs ont montré que la latence de Shoal était inférieure de 65 % à celle de Baseline Bullshark.
Jolteon ne peut pas être étendu à plus de 20 nœuds de validation, avec un débit d'environ la moitié de Bullshark/Shoal.
Dans l'ensemble, Shoal a considérablement amélioré la latence de Bullshark, et devrait pouvoir rivaliser avec la latence de bout en bout de Jolteon sous forte charge.