Les validateurs Ethereum invités à désactiver Prysm en raison d’un risque lié à un état obsolète

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 pour traiter des attestations obsolètes, ce qui peut entraîner un comportement de validation incorrect si cela n’est pas corrigé. Pour éviter cela, Prysm a demandé à tous les opérateurs de désactiver immédiatement une fonction spécifique en ajoutant un seul indicateur à leur nœud beacon. Cette correction ne nécessite pas de mise à niveau complète du client et n’affecte pas les clients validateurs.

L’équipe a demandé aux opérateurs d’ajouter cette ligne : –disable-last-epoch-targets. Cet indicateur 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 dans toute la communauté des validateurs. Cela s’explique par l’empreinte importante de Prysm dans la couche de consensus d’Ethereum.

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

Les données de MigaLabs montrent que Prysm détient près de 20 % de part de marché des clients de consensus sur Ethereum, ce qui en fait le deuxième plus grand client après Lighthouse. Cette ampleur a transformé un bug côté client en une inquiétude à l’échelle de la chaîne. Lorsqu’un client de ce poids traite des données d’état obsolètes, ce n’est pas qu’un seul validateur qui est affecté. Cela peut avoir des répercussions telles que :

• Attestations manquées
• Signaux de choix de fork incorrects
• Risque accru de pénalités ou de slashing dans certains cas limites

Jusqu’à présent, il n’y a aucune preuve d’un arrêt de la chaîne ou d’une perte de finalité liée à ce problème. Cependant, la préoccupation est strictement préventive, et non une gestion de crise. Prysm a agi avant que la situation ne s’aggrave. En d’autres termes, il s’agissait d’un exercice d’incendie préventif, et non d’un nettoyage après incident.

Ce qui a exactement mal tourné dans Prysm

Selon l’équipe Prysm, les nœuds affectés produisaient des états anciens inutiles en tentant de traiter des attestations obsolètes provenant d’époques antérieures. Ce comportement augmente la charge CPU et mémoire et peut fausser la manière dont un nœud suit la progression de la chaîne sous stress. Ce type de comportement n’est pas nouveau dans l’histoire d’Ethereum. Des problèmes similaires de gestion d’état sont apparus lors de :

• L’incident de finalité de mai 2023
• D’anciens bugs de corruption d’index de base de données
• Des pics de mémoire passés chez plusieurs clients

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

Ce que les validateurs doivent faire immédiatement

Si vous utilisez Prysm, la liste est courte et urgente :

• Ajoutez l’indicateur –disable-last-epoch-targets
• Redémarrez le nœud beacon
• Vérifiez les logs pour s’assurer du bon déroulement des attestations
• Surveillez la mémoire et le CPU après le redémarrage

Aucun changement de clé de validateur n’est requis. Aucun resynchronisation ou sortie n’est nécessaire. Pour Ethereum dans son ensemble, cet épisode rappelle une vérité familière : la diversité des clients importe toujours. Lorsqu’un client détient près de 20 % du réseau, même un bug maîtrisé devient un événement d’envergure. Cependant, cet incident montre également la maturité opérationnelle d’Ethereum. Le problème a été identifié, divulgué et atténué en quelques heures, non en quelques jours. C’est ainsi qu’une couche de règlement en direct de plus de 400 milliards de dollars reste résiliente. Actuellement, la chaîne demeure stable. La seule véritable urgence est que les opérateurs Prysm agissent rapidement et activent le mécanisme de sécurité.