¿Se ha cancelado la actualización Glamsterdam de Ethereum? No. Los desarrolladores de Ethereum pospusieron su activación prevista en la red de prueba Hoodi el 26 de octubre de 2026 para investigar cómo los cambios propuestos en la contabilidad de gas podrían afectar a los contratos inteligentes existentes. No se ha fijado una nueva fecha para Hoodi, y Glamsterdam no tenía ninguna fecha confirmada de activación en mainnet que pudiera cancelarse.
Esa distinción es fundamental para la hoja de ruta de Ethereum en 2026. Glamsterdam ya se activó en la red de prueba Sepolia el 6 de octubre. El paso pausado es una prueba adicional en una red pública, no una reversión del mainnet de Ethereum ni el abandono de los objetivos de escalabilidad de la actualización. La Ethereum Foundation indica que la pausa concierne a las interacciones entre EIP-8037 y los contratos desplegados; la agenda de desarrolladores principales del 22 de octubre también analiza preocupaciones de seguridad relacionadas con EIP-8038.
¿Qué cambió el 22 de octubre?
El anuncio anterior de la Ethereum Foundation había programado la activación de Hoodi para el 26 de octubre a las 17:42:48 UTC. El 22 de octubre, esa programación fue sustituida: la activación de la capa de ejecución Amsterdam, la activación de la capa de consenso Gloas y un aumento previsto del límite de gas de Hoodi a 200 millones fueron retirados de la configuración programada. No se anunció ningún nuevo epoch ni marca de tiempo.
Esto es un cambio de programación, no una reversión del historial de cadena de Hoodi. También genera una tarea operativa: los operadores de nodos (qué son los nodos blockchain) y validadores de Hoodi deben seguir las instrucciones revisadas de sus equipos de clientes. El software que aún contiene la antigua configuración de activación del 26 de octubre necesita una actualización adecuada para que los operadores no sigan programaciones contradictorias. La Foundation afirma que los usuarios de mainnet y los holders de ETH no necesitan tomar ninguna medida debido a este anuncio sobre Hoodi.
| Red | Estado a 23 de octubre de 2026 | Qué significa ese estado |
|---|---|---|
| Sepolia | Glamsterdam activado el 6 de octubre | Se ha producido una activación en una red de prueba pública |
| Hoodi | Activación del 26 de octubre aplazada; nueva fecha sin definir | Se requieren pruebas adicionales y versiones revisadas de los clientes |
| Mainnet de Ethereum | Fecha de activación no definida | No se ha cancelado ninguna bifurcación programada en mainnet |
Las fechas y estados anteriores provienen de los anuncios de redes de prueba de la Ethereum Foundation y del aviso de aplazamiento del 22 de octubre.
¿Por qué un cambio de gas puede convertirse en una preocupación de seguridad?
La "readecuación del gas" suena como un cambio en los costes de transacción. Sin embargo, para algunos contratos, el gas también forma parte del comportamiento del programa. Un contrato puede llamar a otro contrato, observar si esa llamada tuvo éxito y decidir si reintentar, revertir o registrar de forma permanente un fallo. Esa decisión puede depender de suposiciones sobre cuánta gas consume la llamada y cuánto queda después.
EIP-8037 propone una contabilidad separada para algunos costes de creación de estado; EIP-8038 cambia el coste de acceso al estado. El análisis de ChainSecurity explica la preocupación de compatibilidad: bajo las reglas propuestas, una subllamada fallida podría dejar —o restaurar— suficiente gas utilizable para que el manejador de fallos de un contrato externo finalice cuando ese mismo camino habría revertido previamente. Un contrato cuya seguridad depende del comportamiento antiguo podría entonces registrar un resultado no pretendido por sus desarrolladores.
Esto no significa que todos los contratos inteligentes de Ethereum tengan una vulnerabilidad, que ETH haya sido comprometido o que se haya producido una explotación en mainnet. Las propuestas están siendo revisadas antes de que Glamsterdam se active en mainnet. La guía anterior para desarrolladores de la Ethereum Foundation indicaba que la gran mayoría de los contratos no se veían afectados por los casos de readecuación identificados, al tiempo que instaba a los equipos afectados a probar sus suposiciones y actualizar donde fuera necesario. La revisión de seguridad posterior es precisamente la razón por la que esas suposiciones merecen un examen más detenido.
Rutas de riesgo descritas públicamente
Los siguientes son patrones de riesgo descritos en el análisis de ChainSecurity, no una lista fabricada de 13 hallazgos distintos:
- Un presupuesto de gas antiguo puede resultar insuficiente. Un contrato puede reenviar correctamente la cantidad de gas solicitada por su desarrollador, pero la operación llamada podría requerir más gas bajo las reglas de precios propuestas. Una comprobación que parecía segura puede conducir así a un fallo inesperado de out-of-gas.
- Una lectura baja de gas restante puede no contar toda la historia. El reservorio de gas de estado propuesto por EIP-8037 cambia qué puede pagarse después de una llamada. El código que interpreta
gasleft()como prueba de que un manejador de fallos no puede completarse puede llegar a una conclusión errónea. - Limpiar estado recién creado puede reponer gas durante una ruta de fallo. En las circunstancias descritas por ChainSecurity, esa reposición puede permitir que el código finalice tras una llamada fallida en lugar de revertir. Si afecta a una aplicación concreta depende de su ruta de llamadas y de sus suposiciones contables.
- Un intermediario que revierte puede devolver más gas del esperado. Con múltiples contratos en una cadena de llamadas, la reversión de un contrato intermedio puede alterar el gas disponible para el llamador original. Un umbral post-llamada que parecía detectar un fallo de out-of-gas puede dejar de ser fiable.
- El manejo de fallos puede convertirse en un problema a nivel de aplicación. La consecuencia no es simplemente una estimación de comisión diferente. En un diseño susceptible, tratar un intento infradotado como un fallo permanente de la aplicación podría eliminar un reintento o registrar un resultado incorrecto. Este es el resultado que los desarrolladores deben probar, en lugar de asumir que cada valor de gas modificado es en sí mismo una explotación.
¿Qué cuenta realmente el número "13" reportado?
Algunas coberturas describen 13 grandes proyectos DeFi con contratos potencialmente afectados. Eso es materialmente distinto a afirmar que los investigadores han revelado 13 vulnerabilidades de seguridad independientes. El artículo técnico público de ChainSecurity explica varios mecanismos, pero no publica 13 hallazgos individualmente nombrados ni una lista verificada de 13 proyectos afectados. La divulgación y la investigación siguen formando parte de la historia.
Para un artículo publicable sobre riesgos de seguridad de ETH, la formulación más segura es: "Los informes indican que los investigadores identificaron proyectos potencialmente afectados; la documentación técnica disponible describe patrones de riesgo relacionados con la contabilidad de gas y el manejo de fallos, no un registro completo de 13 vulnerabilidades." No debe invitarse a los lectores a inferir que 13 protocolos activos de Ethereum hayan sido explotados.
¿Qué mejoras de Glamsterdam siguen previstas?
La pausa no borra los beneficios previstos de la actualización. Las dos características principales de Glamsterdam son la separación entre proponente y constructor integrada en el protocolo (enshrined PBS) y las listas de acceso a nivel de bloque. La primera incorpora aspectos de cómo los proponentes y constructores de bloques coordinan dentro del protocolo de consenso de Ethereum. La segunda registra las cuentas y ubicaciones de almacenamiento que accede un bloque, creando oportunidades para que los clientes procesen partes del trabajo de validación de forma más eficiente. Estas son capacidades propuestas, no una promesa de una reducción particular de comisiones o de una cifra específica de transacciones por segundo para los usuarios.
Los cambios en los precios del gas forman otra parte del paquete. Su objetivo es que los cargos reflejen mejor los recursos que Ethereum utiliza a medida que escala. La pausa de Hoodi ilustra el intercambio: mejorar cómo la red contabiliza los costes de recursos debe reconciliarse con el comportamiento de los contratos ya desplegados bajo suposiciones anteriores. La pregunta para los desarrolladores no es solo "¿Pueden los clientes ejecutar las nuevas reglas?" sino también "¿Qué harán las aplicaciones existentes bajo esas reglas?"
¿Qué deben observar a continuación los desarrolladores y los holders de ETH?
Los desarrolladores de aplicaciones deben revisar las llamadas que capturan fallos y continúan la ejecución, especialmente donde el código usa presupuestos fijos de gas, umbrales de gas restante o suposiciones de que un manejador de fallos agotará su propio gas. ChainSecurity recomienda probar el resultado de esas rutas tanto bajo las programaciones de gas anteriores como propuestas, no simplemente aumentar un límite numérico y asumir que la aplicación es segura.
Los operadores de Hoodi deben buscar versiones de clientes cuyas notas retiren explícitamente la activación del 26 de octubre previamente programada. La Ethereum Foundation advierte contra asumir que una versión listada en un anuncio anterior ya incluye el aplazamiento.
Los holders de ETH no necesitan convertir sus ETH, instalar software ni tomar ninguna acción en mainnet en respuesta a este retraso en la red de prueba. Para quienes sigan las implicaciones de inversión, los hitos relevantes son una decisión publicada de mitigación o especificación, una nueva programación de Hoodi, pruebas exitosas y, solo entonces, una fecha confirmada de mainnet. El retraso por sí solo no establece un efecto medible sobre el precio futuro de ETH.
Preguntas frecuentes
¿Se ha cancelado la actualización Glamsterdam de Ethereum?
No. La Ethereum Foundation aplazó la activación del 26 de octubre en la red de prueba Hoodi y no ha fijado una fecha alternativa. No anunció la cancelación de Glamsterdam en su conjunto.
¿Se ha retrasado Glamsterdam en el mainnet de Ethereum?
No había ninguna fecha confirmada de activación en mainnet en la programación de la Foundation. Perder la fecha de prueba planificada en Hoodi puede afectar la ruta hacia mainnet, pero sería inexacto afirmar que se perdió una fecha específica de mainnet oficialmente programada.
¿Encontraron los investigadores 13 vulnerabilidades separadas de Glamsterdam?
El análisis técnico público no enumera 13 vulnerabilidades separadas. El "13" en algunos reportes se refiere a proyectos con contratos potencialmente afectados. La preocupación técnica verificada se centra en cómo los cambios propuestos en el gas podrían alterar el comportamiento de manejo de fallos de los contratos existentes.
¿Están en riesgo los fondos de los usuarios de Ethereum porque Hoodi fue aplazada?
El aviso de aplazamiento no reporta una compromisión de mainnet e indica que los usuarios de mainnet y los holders de ETH no necesitan tomar ninguna medida. Los desarrolladores están investigando las implicaciones de compatibilidad y seguridad antes de programar la actualización en mainnet; eso no es una garantía de que todas las aplicaciones hayan sido ya evaluadas.
Conclusión: El ensayo de Glamsterdam en Hoodi se detuvo por una razón específica: los desarrolladores necesitan entender cómo interactúan las nuevas reglas de gas con la lógica existente de los contratos inteligentes. La próxima actualización más útil no será una fecha de lanzamiento especulativa, sino evidencia de que las rutas de fallo identificadas han sido evaluadas y de que una programación de pruebas revisada está lista.
