Se ha instado a los validadores de Ethereum a desactivar Prysm debido al riesgo de estado desactualizado

Los operadores de validadores de Ethereum que utilizan el cliente de consenso Prysm recibieron una alerta urgente el 4 de diciembre. El equipo de Prysm confirmó que algunos nodos estaban generando estados antiguos para procesar atestaciones desactualizadas, lo que puede provocar un comportamiento de validación incorrecto si no se corrige. Para evitarlo, Prysm indicó a todos los operadores que desactivaran una función específica de inmediato añadiendo una sola bandera a su nodo beacon. La solución no requiere una actualización completa del cliente y no afecta a los clientes de validadores.

El equipo instruyó a los operadores a añadir esta línea: –disable-last-epoch-targets. Esta bandera funciona con Prysm v7.0.0, lo que significa que la mayoría de los nodos pueden aplicar la solución en cuestión de minutos. La advertencia desencadenó reacciones rápidas en toda la comunidad de validadores, dada la gran presencia de Prysm en la capa de consenso de Ethereum.

La cuota de mercado de Prysm convierte esto en un evento a nivel de red

Los datos de MigaLabs muestran que Prysm controla cerca del 20% de la cuota de mercado de clientes de consenso de Ethereum, lo que lo convierte en el segundo cliente más grande después de Lighthouse. Esa escala es lo que convirtió un error del lado del cliente en una preocupación para toda la red. Cuando un cliente con este peso procesa datos de estado desactualizados, no afecta solo a un validador. Puede provocar:

• Atestaciones perdidas
• Señales incorrectas de elección de bifurcación (fork choice)
• Mayor riesgo de penalizaciones o slashing en casos límite

Hasta ahora, no hay evidencia de una parada de la cadena en vivo o un fallo de finalidad relacionado con este problema. Sin embargo, la preocupación es estrictamente preventiva, no de control de daños. Prysm actuó antes de que la situación se agravara. En otras palabras, fue un simulacro preventivo, no una limpieza post-incidente.

Qué falló exactamente dentro de Prysm

Según el equipo de Prysm, los nodos afectados estaban produciendo estados antiguos innecesarios al intentar procesar atestaciones desactualizadas de épocas anteriores. Ese comportamiento aumenta la carga de CPU y memoria, y puede distorsionar cómo un nodo sigue el progreso de la cadena bajo presión. Este tipo de comportamiento no es nuevo en la historia de Ethereum. Problemas similares en el manejo de estados han aparecido durante:

• El incidente de finalidad de mayo de 2023
• Errores previos de corrupción del índice de la base de datos
• Problemas pasados de picos de memoria en varios clientes

La diferencia clave esta vez es la rapidez. Prysm detectó el problema pronto, publicó una solución temporal de un solo paso y evitó forzar a miles de validadores a una actualización apresurada del cliente.

Qué deben hacer los validadores ahora mismo

Si ejecutas Prysm, la lista de tareas es corta y urgente:

• Añade la bandera –disable-last-epoch-targets
• Reinicia el nodo beacon
• Verifica los registros para comprobar el flujo normal de atestaciones
• Monitoriza la memoria y la CPU tras el reinicio

No se requieren cambios en las claves del validador, ni resincronización ni salida. Para Ethereum en su conjunto, este episodio refuerza una verdad ya conocida: la diversidad de clientes sigue siendo importante. Cuando un cliente posee cerca del 20% de la red, incluso un error manejable se convierte en un evento destacado. Aun así, este incidente también demuestra la madurez operativa de Ethereum: el problema fue identificado, comunicado y mitigado en cuestión de horas, no días. Así es como una capa de asentamiento en vivo de más de $400.000 millones se mantiene resiliente. Actualmente, la cadena permanece estable. La única fecha límite real es que los operadores de Prysm actúen rápido y activen el interruptor de seguridad.