Détails de l'incident de Starknet : une erreur d'exécution à l'origine d'une brève panne du réseau principal
- Un bug d’état du blockifier a causé une incompatibilité avec la couche de preuve, entraînant une interruption et un rollback de l’activité récente de Starknet.
- Les systèmes de sécurité ont arrêté l’exécution défectueuse avant la finalité sur Ethereum, bien que les utilisateurs aient encore rencontré des temps d’arrêt et des revers de transaction.
- Environ 18 minutes d’activité réseau ont été annulés, obligeant les utilisateurs à resoumettre leurs transactions après la reprise du service.
- Starknet prévoit un renforcement des tests et une détection plus rapide alors que les systèmes de couche-2 complexes continuent de faire face à des risques de fiabilité.
Starknet a publié un rapport d’analyse post-mortem expliquant la cause d’une brève panne du mainnet lundi. L’incident a conduit à une courte interruption du réseau et à un rollback des blocs récents.
Cependant, cela n’a pas affecté le règlement final sur Ethereum. Selon l’équipe, les systèmes de sécurité intégrés ont fonctionné comme prévu, même si les utilisateurs ont subi des temps d’arrêt et des revers de transactions.
La panne de Starknet attribuée à un bug de gestion d’état du blockifier
Comme indiqué dans le rapport, la panne provenait d’une incompatibilité dans l’état du réseau entre la couche d’exécution de Starknet, appelée le blockifier, et sa couche de preuve. Le blockifier est responsable de l’exécution des transactions. Pendant ce temps, la couche de preuve vérifie que ces exécutions sont correctes avant qu’elles ne soient finalisées sur Ethereum.
Un bug logiciel dans le blockifier a provoqué un résultat de transaction incorrect dans un ensemble de conditions très spécifiques. Celles-ci comprenaient des appels inter-fonctions, des changements d’état, des revers de transaction, et une logique qui intercepte ces revers.
Dans ce cas extrême, le blockifier a accidentellement conservé un changement d’état qui aurait dû être abandonné après qu’une fonction ait été revertée. En conséquence, le résultat de la transaction différait de ce que la couche de preuve attendait.
En raison de cette incohérence, l’exécution défectueuse n’a jamais atteint la finalité sur Ethereum. Au lieu de cela, le réseau s’est arrêté et a effectué un rollback de l’activité récente pour restaurer un état cohérent. L’équipe de Starknet a indiqué que ce comportement reflète un principe de conception central axé sur la correction même lorsque le logiciel d’exécution se comporte de manière inattendue.
Une réorganisation de blocs a suivi l’incident, effaçant environ 18 minutes d’activité réseau. Pendant cette période, les transactions confirmées ont été annulées et ont dû être resoummises une fois le réseau revenu à la normale. Starknet a indiqué que la pleine fonctionnalité a depuis été restaurée.
Pannes répétées mettent en lumière la complexité des réseaux de couche-2
En 2025, les utilisateurs de Starknet ont connu une panne plus perturbatrice que celle de lundi. En septembre, une mise à niveau majeure du protocole appelée Grinta a déclenché un bug de séquenceur qui a arrêté le réseau pendant plus de cinq heures.
Source de l’image : Starknet
Pendant cette période, les transactions ne pouvaient pas être traitées, obligeant les utilisateurs à attendre ou à resoumettre leur activité. Deux réorganisations de chaîne ont été nécessaires pour restaurer le fonctionnement normal, et environ une heure d’activité réseau a été rollbackée.
Les utilisateurs affectés par cet événement ont également dû resoumettre leurs transactions, créant des frictions pour les participants actifs du marché. Ces incidents soulignent les défis persistants auxquels sont confrontés les réseaux de couche-2 avancés.
Starknet fonctionne sur plusieurs systèmes étroitement liés, comprenant des moteurs d’exécution, des couches de preuve à connaissance zéro, des séquenceurs, et le règlement sur Ethereum. Chaque couche améliore la sécurité ou la scalabilité, mais augmente aussi la complexité.
À mesure que davantage de couches interagissent, de rares bugs logiciels peuvent apparaître de manière inattendue, même lorsque les mécanismes de sécurité fondamentaux restent intacts.
L’incident Starknet met en évidence le coût pour l’utilisateur des rollback de couche-2
La dernière panne illustre comment de petites erreurs d’exécution peuvent encore provoquer des disruptions visibles, même lorsque les systèmes de sécurité fonctionnent correctement. La couche de preuve de Starknet a servi de garde-fou, détectant l’incohérence avant le règlement final. Cependant, cette protection ne supprime pas le coût pour l’utilisateur en termes de temps d’arrêt et de réorganisations.
De petites erreurs d’exécution peuvent toujours causer des disruptions notables du réseau, même lorsque les systèmes de sécurité intégrés fonctionnent comme prévu. Dans le cas de Starknet, la couche de preuve a détecté la transaction défectueuse avant qu’elle n’atteigne le règlement final sur Ethereum, évitant ainsi des dommages durables au réseau.
Même avec la protection des fonds des utilisateurs, les temps d’arrêt et les réorganisations de chaîne ont encore perturbé l’activité normale. Les traders et applications dépendant d’une exécution rapide et prévisible des transactions ont été les plus affectés, car les blocs revertés ont forcé les utilisateurs à resoumettre leurs transactions et à gérer des retards inattendus.
Starknet renforce ses tests autour du système de blockifier et de preuve
Des revues d’ingénierie continues sont en cours chez Starknet suite à la récente perturbation du mainnet, avec un accent particulier sur la réduction du risque d’incidents similaires. De nouvelles suites de tests fuzz sont introduites pour comparer directement les résultats d’exécution du blockifier avec le système de preuve.
Un audit interne de la logique de revert du blockifier est également en cours pour identifier d’autres scénarios pouvant conduire à une gestion incorrecte de l’état. De plus, l’équipe prévoit de réduire le délai entre l’exécution des transactions et l’exécution compatible avec le preuveur.
Une comparaison plus rapide permettrait de détecter plus tôt les incompatibilités, limitant ainsi la quantité d’activité réseau devant être rollbackée.
Starknet a présenté l’incident comme une preuve que son modèle de sécurité fonctionne comme conçu, car l’exécution défectueuse n’a jamais atteint la finalité sur Ethereum. En même temps, l’équipe a reconnu que l’amélioration de la stabilité reste une priorité à mesure que la technologie de couche-2 continue de mûrir.