Piden a validadores de Ethereum desactivar Prysm por riesgo de estado desactualizado

Los operadores de validadores de Ethereum que usan 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, algo que puede provocar comportamientos de validación incorrectos si no se corrige. Para evitarlo, Prysm indicó a todos los operadores que deshabilitaran de inmediato una función concreta añadiendo una única bandera a su beacon node. La solución no requiere una actualización completa del cliente ni afecta a los clientes de validación.

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 corrección en cuestión de minutos. La advertencia generó reacciones rápidas en toda la comunidad de validadores debido al peso significativo que tiene Prysm dentro de la capa de consenso de Ethereum.

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

Datos de MigaLabs muestran que Prysm controla cerca del 20% de la cuota de mercado de clientes de consenso de Ethereum, situándose como el segundo cliente más utilizado después de Lighthouse. Esa escala es lo que convirtió un fallo del lado del cliente en una preocupación para toda la red. Cuando un cliente con este peso procesa estados desactualizados, el impacto no recae solo en un validador; se puede traducir en:

• Atestaciones perdidas
• Señales de fork choice incorrectas
• Mayor riesgo de penalizaciones o slashing en escenarios límite

Hasta ahora no hay señales de detención de la cadena ni de fallos de finalidad vinculados a este problema. Sin embargo, la preocupación es puramente preventiva, no reactiva. Prysm actuó antes de que la situación escalara. En otras palabras, se trató de un simulacro preventivo, no de una limpieza posterior a un incidente.

Qué ocurrió exactamente dentro de Prysm

Según el equipo de Prysm, los nodos afectados estaban generando estados antiguos de forma innecesaria al intentar procesar atestaciones atrasadas de epochs anteriores. Ese comportamiento aumenta la carga de CPU y memoria y puede distorsionar el seguimiento del progreso de la cadena bajo estrés. Este tipo de problemas no es nuevo en la historia de Ethereum. Incidencias similares en la gestión de estados han aparecido durante:

• El incidente de finalidad de mayo de 2023
• Anteriores fallos por corrupción de índices en bases de datos
• Picos de memoria registrados en múltiples 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 completa apresurada.

Qué deben hacer ahora los validadores

Si usas Prysm, la lista es breve y urgente:

• Añadir la bandera –disable-last-epoch-targets
• Reiniciar el beacon node
• Verificar en los registros que el flujo de atestaciones sea normal
• Monitorizar memoria y CPU tras el reinicio

No se requieren cambios en las claves del validador. No es necesario resincronizar ni salir del validador. Para Ethereum en su conjunto, este episodio refuerza una realidad conocida: la diversidad de clientes sigue siendo importante. Cuando un cliente acumula cerca del 20% de la red, incluso un fallo manejable se convierte en un evento relevante. Aun así, el incidente demuestra la madurez operativa de Ethereum: el problema se identificó, se divulgó y se mitigó en cuestión de horas, no días. Así es como una capa de liquidación en vivo de más de 400.000 millones de dólares mantiene su resiliencia.