L'évolution du consensus de Sui : de Tusk à Mysticeti

Sui a remplacé son cœur de consensus deux fois. Le réseau n'a jamais eu besoin d'un hard fork.

Cet article fait partie d'une série sur Sui :

• Découvrir Sui : une Blockchain aux multiples innovations
• Sous le capot de Sui : validateurs, consensus et Staking
• Sui : le modèle objet, ou repenser les Blockchains à travers les données
• La gouvernance de Sui : mettre à niveau sans tout casser
• Le consensus de Sui expliqué : comment Narwhal et Mysticeti finalisent en 0,5 seconde

La raison tient à un choix architectural. Narwhal, la couche responsable de la dissémination des transactions entre les validateurs et de leur organisation en DAG, est restée stable à travers les trois protocoles. Au-dessus, le mécanisme chargé d'ordonner les transactions pouvait être remplacé. Tusk, puis Bullshark, puis Mysticeti se sont chacun connectés à la même fondation. Là où d'autres Blockchains auraient dû tout reconstruire de zéro, Sui n'a remplacé qu'une seule couche.

Un point terminologique mérite d'être clarifié d'emblée. Sui traite deux types de transactions différemment, et cette distinction n'a rien à voir avec le protocole de consensus en cours d'exécution. Les objets appartenant à une seule partie — un simple transfert, par exemple — contournent entièrement le consensus via le Byzantine Consistent Broadcast, qui est plus rapide. Seuls les objets partagés nécessitent un consensus pour l'ordonnancement. Ce mécanisme est en place depuis le lancement de Sui et fonctionne indépendamment du protocole de consensus actif. Il ne doit pas être confondu avec l'évolution du protocole de consensus lui-même, qui est le sujet de cet article.

Tusk : le point de départ asynchrone

Tusk a été conçu pour un réseau où rien ne peut être supposé concernant les délais de livraison des messages. Aucune contrainte de temps, aucune hypothèse de synchronie. C'est le scénario le plus hostile — et aussi le plus réaliste pour un réseau mondial où les conditions varient considérablement d'un validateur à l'autre.

Son idée centrale : une fois le DAG de Narwhal construit, le consensus est atteint sans aucune communication supplémentaire. Chaque validateur applique le même algorithme déterministe à sa vue locale du DAG et arrive au même ordonnancement que tous les autres validateurs. Aucun tour de vote, aucune coordination explicite. L'ordre est lu depuis la structure de référence elle-même, en identifiant des points d'ancrage qui servent de marqueurs de validation.

Les benchmarks du papier original, mesurés sur 20 validateurs, indiquent un débit d'environ 160 000 transactions par seconde avec une Latence d'environ 3 secondes. À l'époque, c'était en avance sur ce que les systèmes classiques pouvaient atteindre.

Deux problèmes subsistaient. Premièrement, la Latence : 3 secondes est acceptable pour de nombreux cas d'usage, mais rédhibitoire pour le trading ou les jeux en temps réel. Deuxièmement, l'équité. Dans un environnement purement asynchrone, les validateurs mieux connectés voyaient leurs transactions incluses plus souvent que les autres — un déséquilibre structurel qui favorisait les nœuds les plus rapides.

Tusk a surtout vécu dans la recherche et sur le réseau de test. Au moment du lancement du mainnet de Sui en 2023, Bullshark était déjà aux commandes.

Bullshark : synchronie partielle

Le bond conceptuel de Bullshark repose sur une seule hypothèse : la plupart du temps, le réseau se comporte normalement. Plutôt que de toujours se préparer au pire, le protocole exploite les périodes où les messages arrivent dans des délais raisonnables. C'est le modèle partiellement synchrone : des contraintes de temps sont supposées dans des conditions normales ; la robustesse asynchrone s'active lorsque le réseau se dégrade.

De cette hypothèse découle le véritable chemin rapide de Bullshark — à ne pas confondre avec la distinction objets possédés/partagés mentionnée plus haut. Durant les périodes synchrones, le protocole peut valider plus rapidement, sans attendre autant de tours qu'en mode dégradé. C'est un raccourci de Latence conditionné à la santé du réseau.

Bullshark a également résolu le problème d'équité que Tusk avait laissé sans réponse, grâce aux liens faibles. Ces liens permettent à un validateur temporairement lent d'être inclus dans le consensus final, même si les validateurs plus rapides ne l'ont pas encore référencé. Aucun validateur honnête n'est exclu en raison d'une mauvaise connexion. Le protocole a également affiné la sélection des points d'ancrage et le nettoyage de la mémoire, ce qui lui a permis de maintenir la charge sur des périodes prolongées.

Le coût : une complexité accrue. Les liens faibles et l'adaptation au réseau introduisent des cas limites et une surcharge de calcul. Le papier rapporte 125 000 TPS à 2 secondes de Latence sur 50 parties — inférieur à Tusk sur le papier, mais la comparaison est trompeuse : Tusk a été mesuré sur 20 validateurs, et le débit chute mécaniquement à mesure que le réseau grandit. Les deux chiffres ne sont pas directement comparables. La Latence, quant à elle, est restée dans la plage d'une seconde — encore trop lente pour les applications les plus exigeantes.

Pour Sui, la transition avait une valeur principale : prouver que le réseau pouvait changer son consensus sans perturbation. Un signal de confiance significatif pour les développeurs qui construisent dessus.

Mysticeti : l'abandon de la certification explicite

Mysticeti n'étend pas Bullshark — il change la logique sous-jacente. Tusk et Bullshark reposent tous deux sur un DAG certifié : chaque bloc doit être signé par un quorum de validateurs avant d'être considéré comme disponible. Cette certification est coûteuse — en signatures à produire et à vérifier, et en allers-retours réseau. C'était le goulot d'étranglement partagé par les deux générations précédentes.

Mysticeti supprime entièrement cette étape. Il fonctionne sur un DAG non certifié : les validateurs signent et diffusent leurs blocs, et c'est tout. L'accord n'est plus soumis au vote ; il est inféré. Lorsqu'un validateur référence le bloc d'un autre dans sa propre sortie, cet acte de référencement constitue une approbation implicite. Le consensus est dérivé du comportement de référencement, sans aucun message de vote dédié.

Les résultats se manifestent sur deux dimensions. Sur la Latence, Mysticeti valide en trois tours de messages — le minimum théorique, comparable au BFT pratique. Sur les ressources, l'élimination de milliers de signatures par tour réduit considérablement la charge CPU : environ 40 % de moins en production (de ~48 % à ~29 % sur les validateurs déployés). Le protocole fait également tourner plusieurs leaders en parallèle à chaque tour, ce qui réduit les latences médianes et de queue, et il absorbe l'indisponibilité d'un leader sans bloquer.

Une variante, Mysticeti-FPC, ajoute un chemin de validation rapide pour les transferts d'actifs. Sa caractéristique distinctive est d'intégrer ces transactions directement dans le DAG plutôt que de les traiter séparément, ce qui économise des signatures et des messages. C'est là que réside le véritable chemin de validation rapide intégré dans la structure — pas dans Bullshark.

Les chiffres, mesurés en environnement contrôlé : 300 000 TPS avec 10 nœuds et 400 000 TPS avec 50 nœuds avant que la Latence ne dépasse une seconde. Sous charge soutenue, les validations s'effectuent autour de 0,5 seconde à 200 000 TPS. Dans les mêmes tests, les autres protocoles leaders plafonnent en dessous de 150 000 TPS avec des latences commençant autour de 2 secondes.

Il y a aussi la réduction de Latence de 80 % par rapport à Bullshark largement citée (de ~1,9 s à ~400 ms). Le chiffre est exact, mais c'est une comparaison dans le meilleur des cas : elle oppose Bullshark dans des conditions dégradées à Mysticeti dans des conditions optimales. Sous une charge typique d'objets partagés, le gain est plus modeste, bien qu'aucune mesure publique ne fixe un chiffre exact. Il convient également de garder à l'esprit que les chiffres de 200 000 à 400 000 TPS proviennent de benchmarks contrôlés. Sur le mainnet, dans des conditions réelles, le débit observé est bien plus faible.

Ce que la trajectoire montre

En alignant les trois générations, la progression est claire — à condition de lire les chiffres dans leur contexte.

Le débit passe de ~160 000 TPS (Tusk, 20 validateurs) à 125 000 TPS (Bullshark, 50 parties) puis à 300 000–400 000 TPS selon la configuration (Mysticeti). Les nombres de nœuds diffèrent, donc ces valeurs ne se comparent pas point par point : elles donnent un ordre de grandeur, pas un classement strict. La Latence, en revanche, diminue sans ambiguïté : de 3 secondes à environ 0,5 seconde, en passant par ~2 secondes pour Bullshark. Du côté des communications, la progression passe de zéro surcharge une fois le DAG construit (mais avec une certification coûteuse en amont) à une certification implicite qui élimine la majeure partie du trafic de vote.

Le véritable point d'inflexion n'est pas entre Tusk et Bullshark — tous deux appartiennent à la même famille : DAG certifié, certification explicite, optimisations incrémentales. La rupture se situe entre Bullshark et Mysticeti, avec l'abandon de la certification. Tusk et Bullshark ont optimisé une étape ; Mysticeti l'a éliminée.

Une chose mérite d'être soulignée : à travers les trois protocoles, Narwhal a à peine changé. Toute l'innovation s'est concentrée sur la couche d'ordonnancement, sans déstabiliser la dissémination des données. C'est cette séparation des responsabilités qui a rendu ces remplacements possibles sans interruption de service — le genre de choix architectural qui ne porte pas ses fruits immédiatement, mais finit par tout changer.

Mysticeti n'est probablement pas le dernier mot. L'approche de Sui est précisément de remplacer un composant lorsqu'un meilleur émerge, sans toucher au reste. Si une quatrième génération arrive, elle se connectera très probablement au même Narwhal.

Sources

• Tusk — Danezis, Kokoris-Kogias, Sonnino, Spiegelman. Narwhal and Tusk: A DAG-based Mempool and Efficient BFT Consensus (2021). arXiv · PDF
• Bullshark — Spiegelman, Giridharan, Sonnino, Kokoris-Kogias. Bullshark: DAG BFT Protocols Made Practical (2022). arXiv · PDF
• Mysticeti — Babel, Chursin, Danezis, Kichidis, Kokoris-Kogias, Koshy, Sonnino, Tian. Mysticeti: Reaching the Limits of Latency with Uncertified DAGs (2023, NDSS 2025). arXiv · PDF

L'évolution du consensus de Sui : de Tusk à Mysticeti a été initialement publié dans Coinmonks sur Medium, où les gens poursuivent la conversation en mettant en avant et en répondant à cette histoire.