La red de pruebas Hoodi de Ethereum no activará Glamsterdam el 26 de octubre, como estaba previsto. El Protocol Cluster de la Fundación Ethereum anunció el 22 de octubre de 2026 un aplazamiento sin fecha alternativa. Los operadores de Hoodi deben comprobar que su software y sus configuraciones personalizadas ya no incluyan los parámetros de aquella activación. El aviso no exige ninguna actuación a los usuarios de la red principal de Ethereum ni a quienes poseen ETH.
El comunicado de la Fundación sobre el aplazamiento en Hoodi deja sin efecto la activación fijada para el 26 de octubre a las 17:42:48 UTC, en la época 132.352, y sustituye tanto el calendario como las instrucciones del anuncio anterior. Para los operadores, la diferencia es importante: no basta con haber preparado una versión del software o una configuración para aquella fecha y dar por hecho que sigue siendo adecuada tras el aplazamiento.
Qué se retira del calendario de Hoodi
La decisión afecta a tres elementos programados para la misma época: Amsterdam, en la capa de ejecución; Gloas, en la capa de consenso; y el cambio que habría elevado el límite de gas de Hoodi a 200 millones. El comunicado no proporciona otra época ni otra hora de activación. Por tanto, el 26 de octubre tampoco queda como una fecha provisional a la que recurrir: se ha eliminado de la configuración actualizada.
La Fundación distingue expresamente entre retirar esos parámetros y revertir el historial de la cadena. Los desarrolladores están deshaciendo la configuración de una actualización futura, no anulando transacciones ya registradas en la red de pruebas. Presentar la decisión simplemente como una «reversión» podría inducir a pensar que Glamsterdam ya se había activado y que después se deshicieron sus efectos, algo que el aviso no describe.
También hay que separar el límite de gas previsto de la capacidad efectivamente disponible. El anuncio establece que el aumento a 200 millones no se producirá conforme al calendario anterior. No informa de una mejora de rendimiento ya lograda, no indica cuál es el límite actual de Hoodi y tampoco ofrece un nuevo calendario de capacidad. Los equipos de aplicaciones no pueden tomar esa cifra cancelada como prueba de los recursos con los que contarán para sus pruebas.
Una investigación de compatibilidad todavía abierta
Según la Fundación, los desarrolladores principales acordaron en la reunión ACDE #248 dedicar más tiempo a investigar las interacciones entre EIP-8037 y los contratos inteligentes de la red principal. Una propuesta de mejora de Ethereum, o EIP, es una especificación de un cambio propuesto. El comunicado identifica la propuesta que se está examinando, pero no explica qué comportamiento concreto de los contratos motiva la investigación, no nombra aplicaciones afectadas ni publica una reproducción técnica del problema.
Ese límite de la información disponible es esencial para interpretar la noticia. La fuente permite hablar de una investigación de compatibilidad aún sin resolver como motivo del aplazamiento. No acredita que se haya explotado una vulnerabilidad, que se hayan perdido fondos ni que la red principal de Ethereum haya sufrido un incidente. La referencia a contratos de la red principal señala qué se investiga; el calendario operativo que cambia es el de Hoodi.
En términos prácticos, la decisión cambia una activación programada en la red de pruebas por más tiempo de investigación. Retirar la fecha evita que los equipos sigan tratando la configuración anterior como el calendario acordado mientras continúa ese trabajo. Sin embargo, la Fundación no cuantifica cuánto tiempo adicional hará falta. No hay base en el anuncio para estimar una nueva fecha de lanzamiento ni para calcular la duración final del retraso.
Los operadores deben revisar todos los componentes
La tarea inmediata para los operadores de nodos de Hoodi es comprobar que los clientes de ejecución y de consenso estén configurados de forma coherente con el aplazamiento. La Fundación indica que el software o los ajustes de red personalizados que todavía programen Glamsterdam para la fecha anterior deben actualizarse antes del 26 de octubre. Que se haya modificado el calendario en un comunicado no demuestra, por sí solo, que una máquina concreta haya recibido los cambios correspondientes.
Las instrucciones revisadas para los clientes advierten expresamente que las tablas de versiones del anuncio anterior no prueban que esas versiones incorporen el aplazamiento. Los operadores deben consultar notas de versión que confirmen de manera explícita la eliminación de la activación del 26 de octubre. Lo relevante es el comportamiento documentado de cada versión, no que en algún momento figurara en un anuncio sobre la actualización.
Quienes operan validadores tienen más componentes que revisar. El aviso señala que deben actualizarse tanto el nodo beacon de la capa de consenso como el cliente del validador, y aborda por separado la infraestructura de construcción de bloques. Los operadores que recurran a servicios externos de construcción de bloques deben seguir las instrucciones de su proveedor de herramientas. La Fundación añadirá orientación sobre las herramientas de constructores de bloques y validadores a medida que se confirme, sin presentar todas esas dependencias como asuntos ya resueltos.
De ahí se desprende que actualizar un solo componente no basta para acreditar que toda la instalación refleje el aplazamiento. Una actualización del cliente de ejecución no permite saber si el software de consenso, el cliente del validador o los parámetros personalizados siguen haciendo referencia a la activación anterior. Se trata de revisar dependencias; no de afirmar que algún operador concreto haya configurado mal su nodo o que la red ya haya sufrido un fallo.
Las pruebas de aplicaciones pierden una fecha, no su historial
Los desarrolladores de aplicaciones también deben distinguir entre las pruebas del comportamiento actual de Hoodi y las que dependen de Glamsterdam. La Fundación pide expresamente que no se planifiquen pruebas en Hoodi contando con una activación el 26 de octubre. Por ello, el trabajo que presuponga la nueva actualización o el aumento del límite de gas carece ahora de una fecha de activación confirmada. Esto no significa que se haya revertido el historial existente de la red de pruebas.
Para un equipo que mantiene un plan de pruebas, la distinción útil es la que separa una suposición de una condición de red verificada. Una fecha copiada del anuncio sustituido ya no basta para concluir que las pruebas dependientes de Glamsterdam podrán ejecutarse según lo previsto. El nuevo comunicado no ofrece otra fecha que pueda incorporarse a ese plan ni informa de que la investigación de compatibilidad haya concluido.
La cobertura anterior de BTC-Pulse sobre la fecha tentativa de Glamsterdam en Sepolia aporta contexto histórico a esta diferencia. Aquel artículo describía un objetivo condicionado a la estabilidad de una red de desarrollo y mencionaba un problema anterior relacionado con EIP-8037. No demuestra que Sepolia se activara posteriormente. Tampoco el nuevo aviso de la Fundación establece que aquel problema y la investigación actual sean el mismo.
Existe otra comparación, más acotada, en la cobertura histórica del debate sobre EOF durante la preparación de Fusaka, que recogió inquietudes por cambios en la semántica de ejecución y en las herramientas. Eran argumentos sobre una propuesta distinta, no pruebas que expliquen EIP-8037. Sirven para ilustrar por qué los cambios del protocolo que afectan a los contratos pueden requerir un examen de compatibilidad, pero no demuestran que la investigación actual vaya a encontrar los mismos problemas.
Retirar una activación del calendario tampoco equivale a rediseñar el alcance de una actualización. Las discusiones anteriores sobre una posible división de Pectra trataban de una propuesta para repartir el trabajo en fases. El aviso de Hoodi, en cambio, elimina parámetros de activación programados. No anuncia que Glamsterdam se haya dividido, no identifica funciones descartadas ni especifica un nuevo conjunto de cambios.
Qué falta por conocer
La Fundación limita expresamente el anuncio a Hoodi y aclara que no fija una fecha de activación de Glamsterdam en la red principal. Ni un objetivo anterior de la hoja de ruta ni el aplazamiento de una red de pruebas permiten establecer una fecha confirmada para mainnet. Esta actualización tampoco pide a los titulares de ETH que migren activos, autoricen transacciones o cambien algo en sus billeteras.
La próxima referencia para el calendario será un anuncio separado que establezca una época o una hora de activación para Hoodi, acompañado de instrucciones para los clientes que coincidan con ella. La publicación de los resultados de la investigación de EIP-8037 respondería a otra pregunta: qué encontraron los desarrolladores y si fue necesario introducir cambios. Son dos asuntos pendientes distintos; conocer uno no sustituye la información que falta sobre el otro.
Hasta que aparezcan esos documentos, los operadores pueden verificar que sus sistemas hayan eliminado los parámetros de la antigua activación. Los equipos de aplicaciones, por su parte, no disponen de otra fecha confirmada con la que sustituir el 26 de octubre en las pruebas que dependan de Glamsterdam.
