MultiversX lance Supernova sur testnet avant le mainnet
La mise à niveau découple le consensus de l'exécution et revendique une finalité en shard de 100 à 250 ms pour les applications DeFi sensibles à la latence.
MultiversX a déployé sa mise à jour "Supernova" sur testnet, redéfinissant la production de blocs afin que les validateurs puissent s'accorder sur les blocs avant l'exécution des transactions. L'équipe vise des blocs d'environ 600 millisecondes et une finalité intra-shard de 100 à 250 millisecondes, avec une activation sur le mainnet prévue pour le 10 septembre 2026.
Supernova arrive sur Testnet avec un passage au Mainnet prévu le 10 septembre.
Supernova est maintenant en ligne sur le testnet de MultiversX, avec la même architecture également en cours d'exécution sur devnet, alors que le réseau se dirige vers un pipeline d'exécution asynchrone explicitement conçu pour maintenir le consensus même lorsque l'exécution des transactions est encore en retard.
Le calendrier annoncé est serré et spécifique. Supernova produit des blocs d'environ 600 millisecondes sur le testnet et le devnet en direct depuis le 20 août, et le réseau travaille vers une date d'activation du mainnet prévue pour le 10 septembre 2026.
La mise à niveau est présentée comme une réponse à un plafond de scalabilité familier pour les chaînes haute performance : lorsque l'exécution des transactions se trouve sur le chemin critique du consensus, le calcul le plus lent devient la voiture de tête du système.
Le pari de MultiversX est que le prochain changement radical en latence proviendra du changement de l'ordre des opérations, et non seulement de l'optimisation de la propagation et de la finalité.
Consensus et exécution découplés : Les objectifs de latence et le nouveau problème de validité.
Le changement fondamental de Supernova est mécanique : il "découple le consensus de l'exécution afin que le réseau puisse s'accorder sur les blocs avant de traiter leurs transactions", déplaçant l'exécution hors du chemin critique du consensus et dans une étape asynchrone qui se déroule après que les validateurs ont déjà voté.
Avant la mise à niveau, le flux était séquentiel. Un proposeur sélectionnait des transactions, les exécutait localement et proposait un bloc avec les transitions d'état résultantes, puis les validateurs réexécutaient ces transactions avant de voter.
Sous Supernova, "Le proposeur sélectionne des transactions et propose le bloc sans les exécuter d'abord," et "Les validateurs vérifient que la proposition respecte les règles du protocole et peuvent voter immédiatement, tandis que l'exécution continue de manière asynchrone en arrière-plan."
Cette réorganisation est ce qui rend les objectifs de latence plausibles en théorie. La sortie d'exécution est "normalement référencée et notariée dans l'en-tête du bloc suivant," ce qui signifie que l'exécution suit le consensus d'environ un bloc, ou environ 600 millisecondes.
En pratique, l'architecture vise une cadence en pipeline où le consensus peut continuer à produire des blocs d'environ 600 ms même si l'exécution est un bloc en retard, plutôt que de forcer chaque validateur à terminer le même calcul avant que le bloc suivant puisse être finalisé.
Pour les développeurs, l'affirmation principale est que "la finalité intra-shard arrive dès que la preuve est disponible, généralement dans le même tour autour de 100 à 250 millisecondes," associée à "des conditions d'exécution plus prévisibles."
Les cas d'utilisation cibles sont ceux qui se dégradent rapidement lorsque la latence devient visible pour l'utilisateur, y compris les primitives DeFi à haute fréquence et les carnets de commandes on-chain.
Le problème est la question de validité que l'exécution asynchrone introduit. Si le réseau vote sur un bloc avant l'exécution, une transaction qui semblait valide au moment de la proposition peut devenir invalide au moment où l'exécution l'atteint, car les nonces et les soldes des comptes peuvent avoir été consommés par d'autres activités en attente.
État de Mempool Virtuel, EIE et Contre-pression : Comment Supernova Essaie de Garder les Blocs Sûrs et les Nœuds Synchronisés
La première ligne de défense de Supernova se situe au niveau du proposeur, via un "état de mempool virtuel" qui regarde au-delà de l'état exécuté le plus récent et suit les nonces en attente, la consommation de solde attendue et les transactions déjà proposées mais pas encore exécutées ou finalisées par consensus.
L'objectif est de donner aux proposeurs une vue prospective de l'activité des comptes afin qu'ils puissent éviter d'inclure des transactions susceptibles d'échouer une fois que l'exécution les rattrape.
La conception ajoute également deux régulateurs explicites destinés à empêcher la longue traîne de matériel du réseau de prendre du retard.
L'Estimation de l'Inclusion des Résultats d'Exécution (EIE) limite le nombre de résultats d'exécution pouvant être référencés dans un bloc en fonction de ce que "les nœuds à spécifications minimales peuvent traiter en toute sécurité", et la contre-pression automatique réduit la capacité des blocs si l'exécution prend trop de retard, donnant au système le temps de rattraper.
Ces mécanismes sont également là où se situe aujourd'hui l'incertitude pertinente pour le marché. Le document décrit le pipeline et ses sauvegardes, mais il ne fournit pas de références indépendantes, de chiffres de débit ou de données de tests de résistance qui montreraient si des blocs d'environ 600 ms persistent sous des mélanges de transactions plus lourds et plus complexes.
Il ne précise pas non plus, au-delà de l'état de mempool virtuel et des régulateurs, comment les échecs d'exécution post-consensus et les transactions invalides sont traités opérationnellement dans des cas limites.
Les prochaines étapes concrètes sont procédurales plutôt que narratives : confirmation ou révision de la date d'activation du mainnet prévue pour le 10 septembre 2026, production soutenue de blocs d'environ 600 ms sur testnet/devnet à mesure que la charge et la complexité des transactions augmentent, et toutes les métriques divulguées montrant à quelle fréquence les limites de l'EIE ou les réductions de contre-pression se déclenchent sous stress.
Mon avis : C'est un pari UX/Constructeur—Mais les traders devraient considérer les chiffres comme provisoires jusqu'au mainnet
La partie que la plupart des gens vont mal interpréter est la revendication de latence comme une garantie de performance achevée.
Ce qui est réellement livré est un changement architectural qui retire l'exécution du chemin critique du consensus, et c'est un véritable choix de conception avec un précédent clair à travers les chaînes à haute performance : vous obtenez une cadence de blocs plus prévisible à mesure que la complexité des transactions augmente, mais vous héritez d'une nouvelle classe de problèmes de validité et de retard qui ne se manifestent que sous une charge désordonnée et antagoniste.
Le seuil qui compte est de savoir si le testnet/devnet peut maintenir des blocs d'environ 600 ms pendant que les régulateurs restent principalement en arrière-plan, car si l'EIE et la contre-pression s'engagent constamment, le pipeline est toujours "rapide" sur le papier mais contraint en pratique.
Cela devient pertinent pour le marché lorsque la date du mainnet est confirmée et que le réseau peut démontrer un comportement à faible latence soutenu sans que le retard d'exécution routinier ne devienne le limiteur dominant.
