Les opérateurs de validation 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 conduire à 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 spécifique en ajoutant un seul indicateur à leur nœud de balise. Le correctif ne nécessite pas de mise à niveau complète du client et n’affecte pas les clients du validateur.
L’équipe a demandé aux opérateurs d’ajouter cette ligne : Cet indicateur fonctionne avec Prysm v7.0.0, ce qui signifie que la plupart des nœuds peuvent appliquer le correctif en quelques minutes. L’avertissement a déclenché des réactions rapides au sein de la communauté des validateurs. Cela donne à Prysm une grande empreinte au sein de la couche de consensus d’Ethereum.
La part de marché de Prysm en fait un événement au niveau du réseau
Les données de MigaLabs montrent que Prysm contrôle près de 20 % de la part de marché des clients consensuels d’Ethereum. Cela en fait le deuxième client après Lighthouse. C’est cette ampleur qui a transformé un bug côté client en un problème à l’échelle de la chaîne. Lorsqu’un client avec ce type de poids traite des données d’état obsolètes. Cela n’affecte pas qu’un seul validateur. Cela peut se répercuter sur :
- Attestations manquées
- Signaux de choix de fourche incorrects
- Risque accru de pénalités ou de réductions dans les cas extrêmes
Jusqu’à présent, il n’y a aucune preuve d’un arrêt de la chaîne ou d’un échec final lié à ce problème. Cependant, la préoccupation porte uniquement sur la prévention des risques et non sur le contrôle des dommages. Prysm a agi avant que la situation ne dégénère. En d’autres termes, il s’agissait d’un exercice d’incendie préventif et non d’un nettoyage post-incident.
Qu’est-ce qui n’a pas fonctionné exactement à l’intérieur de Prysm
Selon l’équipe Prysm, les nœuds concernés produisaient d’anciens états inutiles tout en essayant de traiter des attestations obsolètes d’époques antérieures. Ce comportement augmente la pression sur le processeur et la mémoire et peut fausser la façon dont un nœud suit la progression de la chaîne sous contrainte. Ce type de comportement n’est pas nouveau dans l’histoire d’Ethereum. Des problèmes similaires de gestion de l’état sont apparus lors de :
- L’incident final de mai 2023
- Bogues antérieurs de corruption d’index de base de données
- Problèmes de pic de mémoire passés sur plusieurs clients
La principale différence cette fois-ci est la vitesse. Prysm a détecté le problème très tôt et a publié une solution de contournement en une étape. Nous avons également évité de forcer des milliers de validateurs à se lancer dans un cycle de mise à niveau complet et précipité.
Ce que les validateurs devraient faire dès maintenant
Si vous utilisez Prysm, la liste de contrôle est courte et urgente :
- Ajouter le drapeau
- Redémarrez le nœud de balise
- Vérifier les journaux pour le flux d’attestation normal
- Surveiller la mémoire et le processeur après le redémarrage
Aucune modification de la clé du validateur n’est requise. Aucune resynchronisation n’est requise et aucune sortie n’est requise. Pour Ethereum dans son ensemble, cet épisode renforce une vérité familière : la diversité des clients compte toujours. Lorsqu’un client détient près de 20 % du réseau, même un bug gérable devient un événement majeur. Néanmoins, cet incident montre également la maturité opérationnelle d’Ethereum. Le problème a été identifié, divulgué et atténué en quelques heures, et non en quelques jours. C’est ainsi qu’une couche de règlement active de plus de 400 milliards de dollars reste résiliente. Actuellement, la chaîne reste stable. La seule véritable date limite est que les opérateurs de Prysm agissent rapidement et actionnent l’interrupteur de sécurité.
