Starknet est à nouveau en panne : la couche d'exécution et la couche de preuve se disputent, une activité de 18 minutes a été annulée

Ethereum L2 réseau Starknet a connu une panne majeure ce lundi. Selon le rapport d’analyse post-incident publié le 11 janvier, cet incident est dû à une incohérence d’état entre la couche d’exécution (blockifier) et la couche de preuve. Dans certains scénarios combinant appels inter-fonctions et rollback, la couche d’exécution a incorrectement enregistré un état qui aurait dû être annulé, entraînant une erreur dans l’exécution des transactions. Bien que ces transactions n’aient pas obtenu la confirmation finale sur L1, l’événement a déclenché une réorganisation de blocs, et environ 18 minutes d’activité on-chain ont été rollbackés. Il est également important de noter que c’est la deuxième interruption majeure de Starknet depuis 2025.

Détails techniques : désynchronisation entre la couche d’exécution et la couche de preuve

Cause fondamentale de l’incident

La cause technique de cette panne est relativement complexe. L’architecture de Starknet implique deux couches clés : la couche d’exécution, responsable du traitement des transactions, et la couche de preuve, chargée de générer des preuves à connaissance zéro et de les soumettre à la blockchain Ethereum. Lors de cet incident, lorsqu’un certain scénario d’appels de fonctions et de rollback s’est produit, la couche d’exécution (blockifier) a incorrectement enregistré un état qui aurait dû être annulé, créant un conflit d’état entre les deux couches.

La bonne nouvelle est que la couche de preuve a correctement détecté cette erreur, rejetant la transaction problématique et ne la soumettant pas au registre. Ce mécanisme d’auto-correction a empêché que cet état erroné ne soit pérennisé sur Ethereum.

Pourquoi une réorganisation était nécessaire

En raison de cette incohérence entre la couche d’exécution et la couche de preuve, le réseau a été contraint de procéder à une réorganisation de blocs pour restaurer un état cohérent. La réorganisation a entraîné le rollback d’environ 18 minutes d’activité réseau, obligeant les utilisateurs à resoumettre leurs transactions. Si l’impact est moindre pour des transactions non sensibles au temps, cela peut causer des pertes concrètes pour les traders fréquents ou pour des opérations nécessitant une exécution rapide (par exemple, des liquidations urgentes).

Comparaison historique : des incidents de plus en plus fréquents

Bien que cette fois le rollback ait été plus court (18 minutes contre 1 heure), la fréquence commence à devenir préoccupante. Entre septembre et janvier, Starknet a connu deux interruptions majeures en moins de six mois, avec des causes différentes, ce qui indique des risques potentiels à différents niveaux du système.

Réponse et engagement de l’équipe

Actions immédiates

L’équipe Starknet, en publiant le rapport d’analyse, a également fait plusieurs engagements :

• Renforcer les processus de tests, notamment pour les scénarios limites et complexes
• Améliorer la sécurité des audits de code pour éviter de telles incohérences
• Selon les informations, Starknet prévoit de lancer la version v0.14.1, incluant une mise à jour des fonctions de hachage et des optimisations pour des blocs plus rapides

Ces mesures montrent une volonté d’améliorer la stabilité du système, mais leur efficacité à prévenir de futures pannes reste à confirmer dans le temps.

Impact sur l’écosystème

Sur le plan utilisateur

L’impact réel de cet incident est relativement limité :

• La durée de rollback courte (18 minutes), avec peu de transactions affectées
• Aucune perte de fonds, car aucune transaction n’a obtenu la confirmation finale sur L1
• Les utilisateurs doivent simplement resoumettre leurs transactions, sans risque de perte d’actifs

Sur le plan de l’écosystème

Cependant, à une échelle plus large, la fréquence accrue de ces incidents pose un défi pour le développement de Starknet :

• Diminution de la confiance des utilisateurs dans la stabilité du réseau
• Potentiel frein à l’adoption de nouvelles applications DeFi
• Un désavantage dans la compétition avec d’autres L2 comme Arbitrum ou Optimism

Il est aussi à noter que Starknet continue d’étendre ses cas d’usage, notamment via des collaborations comme avec Noon pour lancer un Vault Bitcoin, ou avec AlchemyPay. La capacité de ces initiatives à compenser l’impact négatif de ces problèmes de stabilité reste à observer.

Conclusion

Cet incident sur Starknet illustre les défis techniques rencontrés par les réseaux L2 dans des scénarios complexes. Plutôt qu’un problème de sécurité grave, il s’agit d’un défaut dans la gestion des conditions limites. La capacité de la couche de preuve à s’auto-corriger a permis d’éviter des pertes financières, mais la fréquence des interruptions ne doit pas être négligée.

L’essentiel est de voir si les mesures d’amélioration de Starknet seront réellement efficaces. Renforcer les tests et audits est nécessaire, mais la véritable question est de savoir si ces problèmes seront résolus de façon durable dans les futures versions. Pour les acteurs de l’écosystème, il est crucial de continuer à suivre l’évolution de la stabilité de Starknet tout en lui faisant confiance.