DAG rencontre BFT — La prochaine génération de consensus BFT

19 min readJul 4, 2022

Avant de rentrer dans cet article je ne saurai vous conseiller de comprendre ce qu’est un DAG.

Cet article explique en termes simples un développement récent dans la théorie et la pratique du consensus byzantin de tolérance aux pannes (BFT) basé sur des graphes orientés acycliques (basés sur DAG), publié dans trois prestigieuses conférences évaluées par des pairs, et en cours d’intégration dans plusieurs projets Blockchain, par exemple : Aptos, Celo, MystenLabs et Sommelier.

DAG-Rider: All You Need Is DAG (PODC 2021). [I. Keidar, E. Kokoris-Kogias, O. Naor, A. Spiegelman]
Narwhal&Tusk (eurosys 2022 Best paper award) [G. Danezis, E. Kokoris-Kogias, A. Sonnino, A. Spiegelman]
Bullshark (À paraître au CCS 2022) [A. Spiegelman, N. Giridharan, A. Sonnino, E. Kokoris-Kogias]

TL;DR: Le découplage entre la diffusion des données et l’ordre des métadonnées est le mécanisme clé pour permettre des systèmes de consensus évolutifs et à haut débit. De plus, l’utilisation d’une implémentation efficace d’un DAG pour extraire la couche de communication réseau de la logique de consensus (zéro frais de communication) permet des implémentations simples et efficaces (par exemple, une amélioration du débit plus de 90 fois supérieure à celle de Hotstuff).

Consensus basé sur le DAG

Dans le contexte de la Blockchain, le consensus BFT est un problème dans lequel n validateurs, dont f pourraient être byzantin, tentent de s’entendre sur une séquence de transactions infiniment croissante. L’idée du consensus BFT basé sur DAG (par exemple, HashGraph et Aleph) est de séparer la couche de communication réseau de la logique de consensus. Chaque message contient un ensemble de transactions et un ensemble de références aux messages précédents. Ensemble, tous les messages forment un DAG qui ne cesse de croître — un message constitue le sommet et ses références sont des arêtes.

La logique de consensus n’ajoute aucune surcharge de communication. Autrement dit, chaque validateur regarde indépendamment sa vue locale du DAG et ordonne totalement (entièrement) tous les sommets sans envoyer un seul message supplémentaire. Cela se fait en interprétant la structure du DAG comme un protocole de consensus, c’est-à-dire qu’un sommet peut être une proposition et une arête peut être un vote.

Il est important de noter qu’en raison de la nature asynchrone du réseau, différents validateurs peuvent voir des DAG légèrement différents à tout moment. Un défi clé est donc de savoir comment garantir que tous les validateurs sont d’accord sur le même ordre total.

DAG basé sur des périodes

Dans un DAG à base de périodes (introduit pour la première fois dans Aleph), chaque sommet est associé à un numéro de période. Chaque validateur diffuse un message par période et chaque message fait référence à au moins n−f messages. Autrement dit, pour avancer vers la période r, un validateur doit d’abord obtenir n−f messages (de différents validateurs) dans la période r−1. Vous trouverez ci-dessous une illustration de ce à quoi pourrait ressembler la vue locale d’un validateur d’un DAG basé sur des périodes :

Non Equivoque

Aleph et DAG-Rider utilisent une diffusion fiable pour diffuser les sommets, ce qui garantit que tous les validateurs honnêtes finissent par livrer les mêmes sommets et que tous les sommets des validateurs honnêtes sont finalement livrés. Donc :

Pour tout validateur v et période r, si deux validateurs ont un sommet de v dans la période r sur leurs vues locales, alors les deux validateurs ont exactement le même sommet (mêmes transactions et références).
Par conséquent, récursivement, l’histoire causale du sommet dans les deux vues locales est exactement la même.

La propriété de non-équivoque élimine la capacité des validateurs byzantins à mentir, ce qui simplifie considérablement la logique du consensus. Comme nous l’expliquons plus bas, Narwhal et Bullshark fournissent une mise en œuvre efficace de celui-ci.

Débit de vitesse du réseau et qualité de la chaîne

Une fois qu’un sommet v est validé via le protocole de consensus, toute l’histoire causale de v (tous les sommets pour lesquels il existe un chemin de v à eux) peut être immédiatement ordonnée. Cela permet :

Une utilisation parfaite de la communication réseau :
Les messages ne sont jamais gaspillés (en opposition, par exemple, à un vote sur une proposition qui n’est jamais validée dans un protocole monolithique).
Le débit de consensus total est la vitesse du réseau même si la latence de consensus est élevée.
Une qualité de la chaîne. Puisque chaque période dans l’histoire causale de v contient au moins n-f sommets, au moins la moitié (>f) des sommets ordonnés dans chaque période ont été diffusés par des parties honnêtes.

Comparaison des protocoles

DAGRider, Tusk , et Bullshark sont tous des protocoles de consensus sans frais généraux de communication pour ordonner les sommets du DAG. Autrement dit, étant donné une vue locale d’un DAG basé sur des périodes comme décrit ci-dessus, ces protocoles ordonnent totalement les sommets simplement en interprétant localement la structure du DAG (sans envoyer de messages supplémentaires).

Le tableau ci-dessous résume les principales différences. La latence est mesurée par le nombre de périodes DAG requis entre deux validations. Tous les protocoles garantissent une réactivité même contre le pire adversaire en asynchrone. En raison de la limite inférieure FLP, le caractère aléatoire est nécessaire pour résoudre le consensus asynchrone, d’où la latence mesurée. L’équité signifie que même les validateurs lents sont en mesure de contribuer à la séquence des sommets validés (ordre total).

Dans cet article, nous nous concentrons sur Bullshark, qui est clairement le meilleur.

Garbage collection

Au fur et à mesure que le DAG grandit indéfiniment, il est nécessaire de collecter les sommets des anciennes périodes. Comme expliqué plus en détail ci-dessous, Bullshark fournit le garbage collector dans toutes les conditions avec équité pendant les périodes synchrones. C’est le mieux que nous puissions espérer, car, comme nous l’expliquerons plus bas, il est impossible de fournir à la fois le garbage collector et l’équité pendant les périodes asynchrones.

Narwhal : Scalabilité et percée en matière de débit

La principale conclusion du document de Narwhal&Tusk est que dans les systèmes de consensus évolutifs et à haut débit, la diffusion des données doit être fiable et découplée du mécanisme de commande.

Le système Narwhal met en œuvre une construction DAG hautement évolutive et efficace qui, avec Tusk/Bullshark, séquence plus de 100 000 transactions par seconde (tps) dans un environnement géo-répliqué tout en maintenant la latence en dessous de 3s. À titre de comparaison, Hotstuff séquence moins de 2k tps dans le même environnement.

De plus, comme la diffusion des données est complètement symétrique entre les validateurs, le système est résistant aux pannes (un point faible dans de nombreux systèmes précédents) -le nombre de tps n’est affecté que parce que les validateurs défectueux ne diffusent pas les données.

Chaque validateur se compose d’un certain nombre de travailleurs et d’un master. Les travailleurs se transmettent en permanence des lots de données et transmettent les résumés des lots à leurs masters. Les masters forment une DAG de base périodique sur les métadonnées (les sommets contiennent des résumés). Il est important de noter que les données sont diffusées par les travailleurs à la vitesse du réseau en ce qui concerne la construction du DAG de métadonnées par les masters. Pour former le DAG, les validateurs utilisent le broadcast protocol suivant qui satisfait les propriétés de diffusion fiables avec un nombre linéaire de messages sur le chemin critique.

À chaque période (voir la figure 2 dans Narwhal&Tusk pour l’illustration) :

À la réception d’un tel message, un validateur répond avec une signature si :
Ses travailleurs ont conservé les données correspondant aux résumés dans le sommet (pour la disponibilité des données).
Il n’a jamais répondu à ce validateur dans ce cycle auparavant (pour non-équivoque).
L’expéditeur forme un certificat de quorum à partir des n-f signatures et le renvoie aux validateurs dans le cadre de son sommet pour cette période.
Un validateur passe à la période suivant une fois qu’il reçoit n-f sommets avec des certificats valides.

L’objectif des certificats de quorum est triple :

Non équivoque : puisque les validateurs signent au plus un sommet par validateur et par période, l’intersection du quorum garantit la non-équivoque sur le DAG. C’est-à-dire que les validateurs byzantins ne peuvent pas obtenir de certificats de quorum sur deux sommets différents sur la même période.
Disponibilité des données : étant donné que les validateurs ne signent que s’ils stockent localement les données correspondant aux résumés dans le sommet, lorsqu’un certificat de quorum est formé, il est garanti que les données seront disponibles pour que tout validateur puisse les récupérer ultérieurement.
Disponibilité de l’historique : puisque les blocs certifiés contiennent les certificats des blocs de la période précédente, un certificat d’un bloc garantit la disponibilité de l’ensemble de l’historique causal du bloc. Un nouveau validateur peut se joindre en apprenant les certificats de la période précédente. Cela simplifie le « garbage collection » .

La séparation entre la diffusion des données et l’ordre des métadonnées garantit un débit de vitesse réseau indépendamment de la vitesse de construction du DAG ou de la latence du consensus utilisé pour la commande. Les données sont diffusées à la vitesse du réseau par les travailleurs, et le DAG contient des résumés qui se réfèrent à toutes les données diffusées. Une fois qu’un sommet dans le DAG est validé, tout l’historique causal du sommet (qui contient la plupart des données diffusées) est ordonné.

Le protocole Bullshark

L’article de Bullshark présente deux versions du protocole. Le premier est un protocole asynchrone avec un chemin rapide à 2 périodes pendant la synchronisation, et le second est un protocole partiellement synchrone à 2 périodes. Cet article de blog décrit la seconde version, c’est-à-dire partiellement synchrone.

Par rapport aux protocoles de consensus BFT partiellement synchrones précédents (par exemple, PBFT, SBFT, Tendermint/Hotstuff), Bullshark a (sans doute) la mise en œuvre la plus simple (200 lignes de code au-dessus du système Narwhal).

Quand il s’agit de la simplicité des protocoles de consensus, le diable est toujours dans les détails, en particulier les mécanismes de changement de vue et de synchronisation de vue. Certains protocoles de consensus prétendument simples (par exemple, Hotstuff et Raft), présentent un chemin préférentiel et masquent les détails de la synchronisation. En fait, le protocole Hotstuff a été adopté pour le projet Diem en raison de sa simplicité présumée, mais l’équipe d’ingénierie a rapidement découvert que la boîte noire Pacemaker (qui était magiquement supposée synchroniser les vues sur le papier), était assez complexe, difficile à implémenter dans une base de code de production et constitue un goulot d’étranglement sérieux en cas de pannes.

Bullshark n’a besoin ni d’un changement de vue ni d’un mécanisme de synchronisation de vue !

Étant donné que le DAG encode des informations complètes, il n’est pas nécessaire de « s’entendre » sur le fait de sauter et d’écarter les leaders lents / défectueux via des plaintes de délai d’attente. Au lieu de cela, comme expliqué brièvement, une fois qu’un validateur valide un sommet (leader) vv ancré sur le DAG, il parcourt l’historique causal de v v et ordonne les enregistrements qu’il a précédemment ignorées mais qui auraient pu être validés par d’autres validateurs. En ce qui concerne la synchronisation, la mode de communication globale de la construction du DAG à base périodique s’en occupe.

De plus, la construction du DAG est sans leader et bénéficie d’une symétrie et d’un équilibrage de charge parfaits entre les validateurs. Les sommets DAG sont totalement ordonnés sans aucune communication supplémentaire entre les validateurs. Au lieu de cela, chaque validateur interprète localement la structure de sa vue du DAG. Voici une illustration du protocole Bullshark avec n=4 et f=1 :

Chaque période impair dans le DAG a un sommet d’enregistrement prédéfini (remplissage vert) et l’objectif est de décider d’abord quels enregistrements valider. Ensuite, pour ordonner totalement tous les sommets du DAG, un validateur passe un par un sur tous les enregistrements engagés et ordonne leurs histoires causales via une règle déterministe. L’histoire causale de l’enregistrement 2 est marquée en sommets verts dans la figure ci-dessus.

Chaque sommet d’une période paire peut contribuer à une voix pour l’enregistrement de la période précédente. En particulier, un sommet de la période r vote pour l’enregistrement de la période r−1 s’il y a une arête entre eux. La règle de validation est simple : un enregistrement est validé s’il a au moins f+1 votes. Dans la figure ci-dessus, A2 est engagé avec 3 voix, alors que A1 n’a que 1 voix et n’est donc pas engagé.

Rappelons qu’en raison de la nature asynchrone du réseau, les vues locales du DAG peuvent différer selon les validateurs. Autrement dit, certains sommets peuvent être livrés et ajoutés à la vue locale du DAG de certains des validateurs, mais pas encore livrés par les autres. Par conséquent, même si certains validateurs n’ont pas validé A1, d’autres pourraient l’avoir fait.

Dans l’exemple ci-dessus, le validateur 2 voit deux votes (f+1) pour l’enregistrement A1 et l’engage donc même si le validateur 1 ne l’a pas fait. Par conséquent, pour garantir l’ordre total (sécurité), le validateur 1 doit ordonner l’enregistrement 1 avant l’enregistrement 2. Pour ce faire, Bullshark s’appuie sur l’intersection du quorum :

Étant donné que la règle de validation nécessite f+1 votes et que chaque sommet du DAG a au moins n-f arêtes aux sommets de la période précédent, il est garanti que si un validateur valide un enregistrement A, tous les enregistrements futurs auront un chemin vers au moins un sommet qui a voté pour A, et auront donc un chemin vers A.

Par conséquent, nous obtenons le corollaire suivant :

« Safe to skip » : s’il n’y a pas de chemin vers un enregistrement A à partir d’un enregistrement futur, il est garanti qu’aucun validateur n’a validé A et il est sûr de sauter « skipper » A.

Le mécanisme d’ordre des enregistrements est le suivant : lorsqu’un enregistrement i est validé, le validateur vérifie s’il existe un chemin entre l’enregistrement i et i−1. Si tel est le cas, l’enregistrement i−1 est ordonné avant i et le mécanisme est redémarré récursivement à partir de i−1. Sinon, l’enregistrement i−1 est ignorée et le validateur vérifie s’il existe un chemin entre i et i−2. S’il y a un chemin, i−2 est ordonné avant i et le mécanisme est redémarré récursivement à partir de i−2. Sinon, l’enregistrement i−2est ignorée et le processus se poursuit de la même manière. Le processus s’arrête lorsqu’il atteint un enregistrement qui a été précédemment validé (car tous les enregistrements avant lui sont déjà traités).

Dans la figure ci-dessus, les enregistrements A1 et A2 n’ont pas assez de votes pour être engagées et une fois que le validateur a validé A3, il doit décider de les traiter ou non. Comme il n’y a pas de chemin de A3 à A2, par corollaire « safe-to-skip » A2 peut être sauté. Cependant, comme il existe un chemin entre A3 et A1, A1 est ordonné avant A3 (il est possible qu’un validateur ait validé A1). Ensuite, le validateur doit vérifier s’il existe un chemin entre A1 et A0 (pas dans la figure) pour décider s’il faut traiter A0 avant A1

Veuillez consulter ci-dessous les détails sur la construction spécifique du DAG et vous référer au document Bullshark pour un pseudocode formel et des preuves rigoureuses de sécurité et de réactivité.

Équité et garbage collector

Une propriété d’équité souhaitée dans un système Blockchain est qu’aucun validateur ne soit ignoré et que même les validateurs lents puissent contribuer aux transactions à l’ordre total. Dans le contexte du BFT basé sur le DAG, chaque validateur doit pouvoir ajouter des sommets au DAG.

Rappelons que les validateurs peuvent être byzantins et donc ne jamais diffuser leurs sommets. Comme il est impossible de faire la distinction entre ces validateurs et les validateurs lents pendant les périodes asynchrones, les validateurs honnêtes ne doivent pas attendre plus de n−f sommets pour passer à la période suivante. Par conséquent, un validateur lent peut toujours être en retard et ne jamais ajouter de sommet au DAG (c’est-à-dire que d’autres validateurs avancent à la période i avant de recevoir son sommet à la période i−1).

Pour résoudre ce problème, DAG-Rider a introduit des arêtes faibles qui pointent vers des sommets d’anciennes période. Ces bords sont ignorés par le mécanisme de consensus (c’est-à-dire qu’ils ne comptent pas comme des votes). Leur seul but est d’aider tous les sommets de tous les validateurs honnêtes à être éventuellement ajoutés au DAG (et à devenir totalement ordonnés dans le cadre de l’histoire causale d’un futur enregistrement. Voir une illustration ci-dessous :

L’inconvénient de cette approche est le « garbage collection ». En asynchrone, la livraison d’un sommet peut prendre un temps illimité, et il n’est donc jamais sûr de collecter une période pour laquelle tous les sommets ne se trouvent pas dans le DAG. C’est inacceptable d’un point de vue pratique.

Bullshark, d’autre part, établit un juste milieu entre garbage collector et l’équité. Le DAG est constamment collecté et l’équité est garantie pendant les périodes synchrones.

Pour se faire, les validateurs attachent leur heure locale à chaque sommet qu’ils diffusent. Une fois qu’un enregistrement est validé et prêt à être ordonné, l’horodatage de l’enregistrement est calculé comme une médiane de temps sur les sommets de ses parents. Ensuite, tout en parcourant l’historique causal de l’enregistrement (pour l’ordonner de manière déterministe), un horodatage de chaque période est calculé comme la médiane des temps des sommets verticaux. Lorsque l’horodatage d’une période r est inférieur de plus d’un temps Δ prédéfini à l’horodatage de l’enregistrement atteint, alors r et toutes les périodes inférieures à r sont envoyées au garbage collector. Les sommets qui ont été ajoutés au DAG dans ces périodes devront être rediffusés dans les périodes futures. Cependant, il est garanti que si un validateur lent est capable de diffuser son sommet sur un temps Δ, le sommet sera ajouté au DAG et totalement ordonné.

Une fois que l’enregistrement dans la figure ci-dessus est ordonnée, son horodatage est calculé à 5 en fonction de l’heure de ses parents. Les horodatages des périodes i, i+1, i+2, et i+3, sont calculées en fonction des temps des sommets de ces périodes dans l’historique causal de l’enregistrement. Dans cet exemple, Δ=2 et donc la période i et toutes les périodes précédentes sont des « garbage collection ». Le Validateur 4 est lent, mais comme il a pu diffuser son sommet à temps, le sommet est ordonné grâce aux maillons faibles « weak link ».

DAG logique vs physique

DAGRider et Tusk sont des protocoles asynchrones aléatoires qui construisent le DAG à la vitesse du réseau : une fois que les n−f sommets sur la période r sont livrés, les validateurs diffusent leurs sommets sur la période r+1. Aucune information du niveau de consensus n’est requise pour construire le DAG car le caractère aléatoire de chaque période est produit via des signatures de seuil — chaque sommet inclut une signature partagée sur le numéro de la période du sommet, qui peut être facilement précalculé.

Bullshark exploite les périodes synchrones pour réduire la latence de validation. Idéalement, pour simplifier la mise en œuvre, il serait bon de garder la séparation nette entre la mise en réseau (abstraction DAG) et la logique de consensus local pour ordonner le DAG.

Cependant, il y a rarement de la magie dans le monde et nous savons qu’en raison de FLP, un protocole de consensus déterministe ne peut pas garantir la réactivité en synchronisation partielle sans délais d’attente.

Par conséquent, tout protocole partiellement synchrone basé sur DAG devra intégrer des délais d’expiration et rompre la séparation entre l’abstraction réseau DAG et la couche de consensus d’une manière ou d’une autre.

Pour Bullshark, nous avons comparé deux alternatives :

DAG physique : utilisez des délais d’expiration consensuels pour créer le DAG.
DAG logique : ajoutez un DAG logique au-dessus du DAG physique pour intégrer les délais d’expiration.

DAG physique

Le problème dans l’avancement des périodes chaque fois que n−f sommets sont livrés vient du fait que les validateurs peuvent ne pas voter pour l’enregistrement même si le validateur qui l’a diffusé est juste légèrement plus lent que les autres.

Pour y faire face, Bullshark intègre des délais d’attente dans la construction du DAG. En plus d’attendre n−f sommets à chaque période, les validateurs attendent soit l’enregistrement, soit un délai d’expiration lors d’une période impaire. De même, lors d’une période paire, les validateurs attendent soit des sommets f+1 qui votent pour l’enregistrement, soit des sommets 2f+1 qui ne le font pas, soit un délai d’expiration.

Notez que les données sont toujours diffusées à la vitesse du réseau, car cela est fait par les travailleurs (en dehors de la construction du DAG) par le système Narwhal sous-jacent.

DAG logique

En bref, l’idée de séparer le DAG en couches physiques et logiques est que le DAG physique continue d’avancer à la vitesse du réseau, c’est-à-dire que les validateurs avancent les périodes physiques immédiatement après la livraison des sommets n−f. Le DAG logique est associé au-dessus du DAG physique — chaque sommet a un bit supplémentaire qui indique si le sommet appartient au DAG logique. Une arête logique entre deux sommets logiques existe s’il existe un chemin physique entre eux. Les délais d’expiration sont intégrés dans le DAG logique de la même manière qu’ils sont intégrés dans le DAG physique dans la description ci-dessus. La logique de consensus s’exécute au-dessus du DAG logique et une fois qu’un enregistrement est validé, toute son histoire causale sur le DAG physique est ordonnée.

Dans l’exemple ci-dessus, la figure de droite est le DAG logique qui est greffé sur le DAG physique dans la figure de gauche. Le validateur 1 obtient les sommets 1,2 et 3 dans le DAG physique avant d’obtenir le sommet A1. Par conséquent, il passe à la période numéro deux dans le DAG physique sans marquer son sommet comme logique. Cependant, son sommet dans la période 3, est marqué comme logique même s’il n’a pas de chemin d’accès à A1 car son délai d’expiration local a expiré.

Comparaison dans la pratique

On peut s’attendre à ce que l’approche DAG logique augmente le débit du système, car les validateurs n’attendent jamais un délai d’expiration pour diffuser des sommets sur le DAG physique. Cependant, étant donné que Narwhal sépare la diffusion des données des métadonnées, cela ne fait aucune différence dans la pratique. Les travailleurs de Narwhal continuent de diffuser des lots de transactions à la vitesse du réseau et le DAG ne contient que des informations de métadonnées telles que des résumés de lots. Par conséquent, si la construction du DAG est ralentie en raison d’un délai d’attente, le bloc suivant inclura simplement plus de résumés. De plus, la latence dans l’approche logique peut en fait augmenter — en effet, si un sommet logique n’est pas prêt à être greffé lorsque le sommet physique est diffusé, il devra attendre la prochaine période.

Nous avons évalué et comparé les deux approches et le DAG physique a surpassé le DAG logique. Le débit avec le DAG logique était plus faible, peut-être parce que l’approche du DAG logique consomme plus de mémoire et de bande passante, et la latence était plus élevée pour la raison mentionnée ci-dessus.

En général, d’après notre expérience, une légère pression sur la construction du DAG conduit à des performances maximales puisque les sommets contiennent plus de digests. En outre, l’approche logique du DAG nécessitera probablement une mise en œuvre plus complexe.

Évaluation bullshark

Nous avons implémenté Bullshark à Rust dans moins de 200 LOC au-dessus du système Narwhal DAG. Notre implémentation utilise tokio pour la mise en réseau asynchrone, ed25519-dalek pour les signatures basées sur des courbes elliptiques et Rocksdb pour le stockage persistant des données. BullShark ne nécessite pas de messages de protocole supplémentaires ou d’outils cryptographiques par rapport à Narwhal. Le code, ainsi que les scripts d’orchestration des services Web Amazon et les données de mesure nécessaires pour reproduire les résultats, sont open source.

Nous avons évalué Bullshark par rapport à Tusket Hotstuff dans un environnement géo-répliqué. Étant donné que le protocole Vanilla Hotstuff produit de très mauvaises performances dans notre environnement (ne dépasse jamais 1 800 tps, voir la figure 6 dans Narwhal), nous avons également mis en œuvre une version améliorée de Hotstuff en appliquant les informations de Narwhal, c’est-à-dire que nous avons séparé la diffusion des données et utilisé HotStuff pour ordonner uniquement des métadonnées.

La figure ci-dessous illustre la latence et le débit de Bullshark, Tusk et une version améliorée de HotStuff pour un nombre variable de validateurs sans défaillance :

Comme le montre la figure, Bullshark trouve un équilibre entre le débit élevé de Tusk et la faible latence de HotStuff. Son débit est 2 fois supérieur à celui de HotStuff, atteignant 110 000 tx/s (pour un groupe de 10 nœuds) et 130 000 tx/s (pour un groupe de 50 noeuds), tandis que sa latence est inférieure de 33% à celle de Tusk. C’est parce que Bullshark valide en deux périodes sur le DAG alors que Tusk en a besoin de 3. Bullshark et Tusk s’adaptent mieux que HotStuff lorsqu’ils augmentent le nombre de nœuds en raison du système de narval sous-jacent.

La figure ci-dessous illustre les performances de Bullshark, Tusk et une version améliorée de HotStuff lorsqu’un groupe de 10 validateurs subit 1 à 3 crashs :

HotStuff subit une dégradation massive du débit ainsi qu’une augmentation spectaculaire de la latence. Pour 3 crashs, le débit de HotStuff diminue de plus de 10x et sa latence augmente de 15x par rapport à une période sans défaut. En revanche, Bullshark et Tusk maintiennent tous deux un bon niveau de débit : le DAG Narwhal sous-jacent continue de collecter et de diffuser les transactions malgré les crash, et n’est pas trop affecté par les validateurs défectueux. La réduction du débit est en grande partie due à la perte de la capacité des validateurs défectueux à diffuser les transactions. Lorsqu’ils fonctionnent avec 3 crashs, Bullshark et Tusk offrent une augmentation de débit de 10 fois supérieure et une réduction de latence d’environ 7 fois par rapport à HotStuff.

Un grand merci à Rati Gelashvili, Eleftherios Kokoris-Kogias et Alberto Sonnino pour avoir contribué à façonner cet article.

Traduction communautaire par Aptos France

Rejoignez nous sur le Telegram Aptos France !