Analyse de l'événement de mise à niveau Fusaka d'Ethereum : le rapport post-mortem de Prysm révèle la cause de l'échec

L’équipe de développement Prysm a récemment publié un rapport d’analyse post-événement détaillant l’incident sur le réseau principal survenu après la mise à niveau Fusaka le 4 décembre 2025. Ce problème a brièvement menacé la stabilité du réseau Ethereum, mais a finalement été résolu grâce à la mécanisme de diversité des clients.

Le rapport indique que le problème s’est produit au 411 392e epoch après l’activation de la mise à niveau Fusaka (21h49 UTC le 4 décembre). Le client de consensus Prysm, lors du traitement de certaines données de preuve, a déclenché une recalcul répétée d’un grand nombre d’états historiques, entraînant une consommation rapide des ressources CPU et mémoire, ce qui a provoqué une dégradation des performances de type déni de service (DoS). Il ne s’agit pas d’un défaut de conception du protocole, mais d’un problème d’implémentation du client dans des conditions limites spécifiques.

Les nœuds de validation Prysm affectés représentent environ 15% à 22,71% de l’ensemble du réseau. Pendant l’incident, le taux de participation global des validateurs est passé d’un plus de 95% à environ 75%, le réseau ayant manqué 41 epochs consécutifs, entraînant une perte d’environ 382 ETH en récompenses de preuve, et s’étant approché de la perte de finalité. Terence Tsao, développeur principal de Prysm, a souligné que le volume de calcul pour la lecture des états historiques est très élevé, et que le déclenchement en parallèle multithread ralentit considérablement la performance du nœud.

Il est important de noter que la mise à niveau Fusaka elle-même a réussi. Cette mise à niveau a introduit la technologie PeerDAS (échantillonnage de disponibilité des données entre pairs), visant à augmenter la capacité des blobs Layer 2 à huit fois leur taille d’origine, sans interruption ni bifurcation du consensus lors du processus de mise à niveau.

La raison pour laquelle le réseau Ethereum a évité des conséquences plus graves réside dans la diversité des clients. Outre Prysm, dix autres clients de consensus tels que Lighthouse, Teku, Nimbus, etc., ont maintenu un fonctionnement normal tout au long de l’incident, permettant à environ 75% à 85% des validateurs de rester en ligne, assurant ainsi que la finalité du réseau n’a pas été compromise. Si un problème similaire s’était produit sur des clients représentant une part plus importante, les conséquences auraient pu être plus graves, notamment une suspension du résumé Layer 2 et des obstacles au retrait des validateurs.

Après l’incident, la Fondation Ethereum a rapidement publié des directives d’urgence, l’équipe Prysm a déployé une correction temporaire en runtime, et des solutions permanentes ont été introduites dans les versions v7.0.1 et v7.1.0. Au 5 décembre, le taux de participation du réseau est revenu à près de 99%, et le réseau principal Ethereum a retrouvé un fonctionnement normal en 24 heures.