Ethereum retrasa Glamsterdam tras corregir un fallo crítico en el staking
Ethereum aplazó la activación de Glamsterdam en la testnet Hoodi, según un anuncio publicado por la Ethereum Foundation en su blog oficial. La decisión deja en pausa el despliegue previsto en esa red de pruebas, mientras los equipos de cliente publican nuevas versiones y se corrige un error relacionado con la ruta de depósitos de staking.
El anuncio indica que el retraso afecta al calendario de Hoodi y que los operadores deben revisar las notas de versión de sus clientes antes de seguir con el proceso. La Foundation no presentó en ese comunicado una nueva fecha de activación, por lo que Glamsterdam sigue en fase de prueba y sin cronograma actualizado para Hoodi.
Las versiones de cliente acompañan el cambio de calendario
Junto con el aplazamiento, el ecosistema de Ethereum distribuyó actualizaciones de clientes para alinearse con el nuevo estado de la red de pruebas. La comunicación oficial señala versiones concretas para los distintos clientes, con el objetivo de que nodos y validadores no den por válida la activación originalmente prevista.
Ese matiz importa porque las versiones preparadas para la fecha anterior no deben asumirse automáticamente como compatibles con el cambio. En la práctica, los operadores necesitan seguir las notas de sus respectivos equipos de cliente para saber qué compilaciones usar mientras se reprograma Hoodi.
Un parche para el flujo de depósitos de staking
Además del retraso, el desarrollo también incorpora una corrección de un fallo en la ruta de depósitos de staking. El ajuste busca evitar que los depósitos se dirijan por un camino incorrecto, un problema que afectaba al comportamiento esperado del sistema durante la actualización.
La información disponible no detalla el alcance operativo del error más allá de esa corrección, pero sí deja claro que el parche forma parte del paquete técnico que acompaña a Glamsterdam en esta fase. Por ahora, el cambio relevante para usuarios y operadores no es una nueva función activada en mainnet, sino la reprogramación del testnet y la revisión de las versiones de cliente necesarias para seguir el proceso.
Hoodi permanece así como el punto de referencia inmediato para la siguiente etapa de pruebas, mientras Ethereum ajusta el despliegue y corrige los componentes que debían llegar con la actualización.
