Les validateurs Ethereum invités à désactiver Prysm en raison d’un risque lié à des états obsolètes

Les opérateurs de validateurs Ethereum utilisant le client de consensus Prysm ont reçu une alerte urgente le 4 décembre. L’équipe Prysm a confirmé que certains nœuds généraient d’anciens états afin de traiter des attestations obsolètes, ce qui peut entraîner un comportement de validation incorrect si rien n’est fait. Pour éviter cela, Prysm a demandé à tous les opérateurs de désactiver immédiatement une fonction précise en ajoutant un simple paramètre à leur beacon node. La correction ne nécessite pas de mise à jour complète du client et n’affecte pas les clients validateurs.

L’équipe a demandé aux opérateurs d’ajouter la ligne suivante :
–disable-last-epoch-targets
Ce paramètre fonctionne avec Prysm v7.0.0, ce qui signifie que la plupart des nœuds peuvent appliquer la correction en quelques minutes. L’avertissement a déclenché des réactions rapides au sein de la communauté des validateurs, compte tenu de l’empreinte importante de Prysm dans la couche de consensus d’Ethereum.

La part de marché de Prysm en fait un événement à l’échelle du réseau

Les données de MigaLabs montrent que Prysm détient près de 20 % de la part de marché des clients de consensus d’Ethereum, ce qui en fait le deuxième client derrière Lighthouse. Cette ampleur a transformé un bug côté client en un sujet d’inquiétude pour l’ensemble de la chaîne. Lorsqu’un client de cette taille traite des états obsolètes, les répercussions ne touchent pas seulement un validateur. Elles peuvent provoquer :

• des attestations manquées
• des signaux erronés dans le choix du fork
• un risque accru de pénalités ou de slashing dans certains cas extrêmes

À ce stade, aucun signe ne montre un arrêt de la chaîne en direct ni un échec de finalité liés à ce problème. L’enjeu est avant tout préventif, non réactif. Prysm est intervenu avant que la situation ne s’aggrave. En d’autres termes, il s’agissait d’un exercice préventif, pas d’un nettoyage post-incident.

Ce qui s’est passé exactement à l’intérieur de Prysm

Selon l’équipe Prysm, les nœuds concernés produisaient des états anciens inutiles en tentant de traiter des attestations obsolètes provenant d’époques antérieures. Ce comportement augmente la charge sur le processeur et la mémoire, et peut fausser le suivi de la progression de la chaîne sous contrainte. Ce type de problème n’est pas nouveau dans l’historique d’Ethereum. Des dysfonctionnements similaires de gestion d’état sont déjà apparus lors de :

• l’incident de finalité de mai 2023
• anciens bugs de corruption d’index de base de données
• hausses de mémoire constatées chez plusieurs clients par le passé

La différence clé cette fois-ci est la rapidité. Prysm a détecté le problème tôt, publié une solution de contournement en une étape, et évité de forcer des milliers de validateurs à effectuer en urgence une mise à jour complète.

Ce que les validateurs doivent faire maintenant

Si vous utilisez Prysm, la liste de tâches est courte et urgente :

• ajouter le paramètre –disable-last-epoch-targets
• redémarrer le beacon node
• vérifier les journaux pour confirmer le flux normal des attestations
• surveiller l’usage de la mémoire et du processeur après le redémarrage

Aucun changement de clé de validateur n’est requis. Aucune resynchronisation n’est nécessaire. Aucun retrait n’est nécessaire. Pour l’ensemble du réseau Ethereum, cet épisode rappelle une réalité bien connue : la diversité des clients reste essentielle. Lorsqu’un client approche 20 % du réseau, même un bug maîtrisable devient un événement notable. Mais cet incident illustre aussi la maturité opérationnelle d’Ethereum. Le problème a été identifié, communiqué et atténué en quelques heures seulement. C’est ainsi qu’une couche de règlement de plus de 400 milliards de dollars reste résiliente. Pour l’heure, la chaîne demeure stable. La seule urgence réelle est que les opérateurs Prysm agissent rapidement et activent le mécanisme de sécurité.