El calendario de Ethereum se movió cuatro días antes de la cita. La Fundación Ethereum fijó el 16 de octubre la activación de Glamsterdam en Hoodi para el 26 de octubre de 2026 a las 17:42:48 UTC, en la época 132.352 y el slot 4.235.264, con una subida del límite de gas a 200 millones en esa misma época. Este jueves 22 de octubre, la fundación publicó una nota que deshace el plan: la activación queda aplazada y no hay fecha nueva en el anuncio del aplazamiento.
El motivo no es un cliente que no arranca. Los desarrolladores centrales decidieron en la llamada ACDE #248, celebrada hoy a las 14:00 UTC, retrasar el despliegue para investigar cómo interactúa el nuevo cálculo del gas de creación de estado (EIP-8037) con contratos ya desplegados en la red principal, después de que ChainSecurity avisara de que varias comprobaciones de gas dejan de proteger lo que protegían.
Quien opera un nodo en Hoodi ya no puede fiarse de la tabla de versiones del 16 de octubre. Quien sigue el roadmap ve dónde está la fricción real de Glamsterdam, que no es el consenso ni el tamaño de bloque, sino el precio del estado. La red principal sigue sin fecha.
La fecha que había en el calendario
El anuncio del 16 de octubre era inusualmente preciso para una red de pruebas. Fijaba la época 132.352, el slot 4.235.264 y la hora exacta con marca de tiempo UNIX, y añadía que Hoodi subiría el límite de gas a 200 millones mediante el calendario de EIP-8261, igual que Sepolia. La tabla cerraba con la red principal en tres celdas vacías. El aplazamiento retira la activación de Amsterdam en ejecución, la de Gloas en consenso y ese calendario de gas.
| Red |
Época |
Slot |
Hora UTC |
| Sepolia |
353.024 |
11.296.768 |
6 de octubre de 2026, 13:53:36 |
| Hoodi (anulado) |
132.352 |
4.235.264 |
26 de octubre de 2026, 17:42:48 |
| Mainnet |
sin decidir |
sin decidir |
sin decidir |
Sepolia ya pasó por ese trámite el 6 de octubre y desde entonces opera con 200 millones de gas por bloque, cerca del triple del presupuesto anterior. En la crónica de aquel ensayo, los bloques revisados se movieron entre 52 y 92 millones de gas, del 26% al 46% de la capacidad.
Hoodi iba a repetir la jugada cuatro días después de hoy. El aplazamiento deja esa segunda opinión en el aire, con los clientes ya publicados y las configuraciones de red apuntando a una época que ya no existe.
¿Qué encontró ChainSecurity en el nuevo cálculo del gas?
El análisis de la auditora, hecho sobre las especificaciones del 13 de octubre, se centra en dos propuestas del mismo paquete. EIP-8037 sube y separa el coste de crear estado, mientras EIP-8038 actualiza el coste de acceder al informe técnico. La conclusión es que el gas deja de ser un número que solo baja.
El mecanismo nuevo es un depósito de gas de estado. Todo lo que una transacción pone por encima de 16.777.216 de gas entra ahí, y la creación de estado tira primero de ese depósito antes de tocar el gas de ejecución. Crear una casilla desde cero cuesta 97.920 de gas de estado, 64 bytes por 1.530 de gas, y el cargo de ejecución baja a 10.100 en caliente y 12.100 en frío frente a los 20.000 y 22.100 de Osaka.
La consecuencia práctica es la que encendió las alarmas. Si el depósito paga la parte cara, a un contrato le puede quedar gas de ejecución suficiente para terminar una ruta de error que antes se quedaba sin gas y revertía. Los contratos que deducen de `gasleft()` si una llamada falló por falta de gas dejan de poder deducirlo, y una operación que debía poder reintentarse se registra como fallo definitivo.
Riesgos serios
ChainSecurity lo resume así: el gas que le queda a un contrato puede subir. Lo hace al limpiar una casilla creada en la misma transacción, porque el reembolso llega como recarga inmediata de hasta 97.920 unidades. El comentario firmado por pcaversaccio en el hilo de la llamada habla de riesgos serios con impacto en la capa de aplicación y avisa de que la divulgación a los protocolos afectados sigue en curso.
Ese es el punto que explica la decisión. Glamsterdam no se cae por un cliente que no arranca, se aplaza por contratos que ya están en producción y que todavía no han podido revisarse con la etiqueta de afectados.
El paquete no se reduce al gas. Glamsterdam mete en el consenso la separación entre quien propone el bloque y quien lo construye (EIP-7732), y añade listas de acceso por bloque que permiten leer el estado en paralelo antes de validar (EIP-7928).
¿Qué tiene que hacer quien opera un nodo en Hoodi?
El primer reflejo, actualizar a la versión de la tabla del 16 de octubre, ya no vale. La nota del aplazamiento lo dice sin rodeos: esas versiones no confirman que el cambio de calendario esté dentro, y las configuraciones que sigan programando Glamsterdam a la hora antigua tienen que corregirse. De momento, la lista revisada solo incluía dos versiones, Lodestar v1.50.1 en consenso y Besu 26.10.1 en ejecución.
Para un operador, el orden de comprobaciones es corto y no admite dejarlo para el lunes, porque una configuración que siga apuntando a la época anulada puede arrancar con reglas que nadie más aplica:
- Actualiza cliente de ejecución y cliente de consenso, y si validas, también el cliente validador, porque los tres tienen que hablar el mismo idioma.
- Lee las notas de tu equipo en vez de la tabla del anuncio anterior, y espera una versión que diga que la activación del 26 de octubre queda fuera.
- Revisa la configuración de red de Hoodi si la mantienes a mano, porque la época 132.352 ya no es la buena.
El resto de la lista del 16 de octubre sigue sirviendo para saber quién trabaja en el fork, con seis implementaciones de consenso y seis de ejecución, y con Grandine todavía en release candidate. Pero ninguna de esas filas promete el calendario nuevo, y la propia fundación avisa de que la tabla se irá actualizando.
Queda un detalle de validadores que ya mordió en Sepolia. Prysm 7.2.0 y Teku 26.9.1 arrancaban allí con 60 millones de gas por defecto tras el fork, y quien quisiera proponer con 200 millones tenía que configurarlo a mano. Ese ajuste vuelve a la lista de deberes de Hoodi.
Mainnet sigue sin fecha y el gas marca el camino
La red principal sigue sin día. La nota del aplazamiento lo repite dos veces: el anuncio de Hoodi no fija fecha de mainnet, y la actualización no cambia nada para usuarios ni tenedores de ether. La agenda de la llamada de hoy incluía un aviso con tres candidatos, el 1, el 8 y el 9 de diciembre, y la intención de fijar fecha en el ACDC de la semana que viene si Hoodi salía bien. Era un aviso, no una decisión, y el retraso de la segunda testnet lo deja en el aire.
Hay una razón para que el retraso pese más en mainnet que en Hoodi. Los contratos que preocupan a ChainSecurity son los que ya corren en producción, y una red de pruebas solo reproduce una parte de esa maraña. Cuanto más tarde el fork, más tiempo hay para localizar los protocolos afectados y avisarles, que es justo lo que la divulgación en curso está haciendo.
Para las capas 2 el aplazamiento no mueve la aguja principal. El 4 de octubre el precio de los blobs subió alrededor de un 400%, y ese coste depende del espacio de datos, no del gas de ejecución. En la lista de 18 EIPs de Glamsterdam no hay ninguna propuesta que amplíe el cupo de blobs por bloque, así que el cuello de botella de datos de las capas 2 sigue donde estaba. Aztec, que cierra el 24 de octubre la votación de su salto a v6, ya ha metido constantes de gas de Glamsterdam en la próxima versión.
Lo que compra el aplazamiento y lo que deja abierto
Cuatro días antes de la cita, una red de pruebas es el sitio barato para descubrir que un cambio de precios rompe contratos. El repricing es lo más difícil de ensayar, porque depende de combinaciones de llamadas que nadie escribe en una prueba unitaria.
La próxima señal está en el calendario de las llamadas y en las notas de los clientes, no en una fecha que hoy no existe. Hasta que Hoodi tenga época, los operadores conviven con configuraciones a medio actualizar y los equipos de mainnet, con un fork sin día. El 26 de octubre a las 17:42:48 UTC ya no es una cita de Ethereum.
