Los desarrolladores de Ethereum pospusieron el hard fork de Glamsterdam —una actualización de protocolo para toda la red que requiere que cada operador de nodo actualice su software cliente— en el testnet Hoodi después de que expertos en seguridad identificaran posibles ajustes en la contabilidad de gas que podrían afectar el funcionamiento de los contratos inteligentes actualmente desplegados durante transacciones fallidas.

La última actualización retrasa indefinidamente la activación del próximo hard fork en la mainnet de Ethereum y pone en duda la ventana tentativa de lanzamiento de diciembre de la red.

El cronograma de Glamsterdam en duda

En una entrada de blog publicada el jueves, la Ethereum Foundation indicó que la activación fue retrasada debido a preocupaciones de seguridad. Según la Foundation, los desarrolladores tomaron la decisión conjunta de posponer la actualización durante la llamada ACDE #248 —la reunión quincenal All Core Developers Execution— para evaluar la interacción entre la propuesta EIP-8037 y los contratos inteligentes actualmente desplegados en la mainnet de Ethereum.

Inicialmente, el hard fork de Hoodi estaba programado para activarse el 26 de octubre a las 17:42:48 UTC en la época 132,352, una unidad de tiempo de longitud fija en la capa de consenso de Ethereum. Esa época ahora fue eliminada de la configuración de despliegue, sin que se haya programado ninguna nueva en su lugar. No se anunció una fecha de activación de reemplazo.

El retraso también afecta el despliegue de la activación de Gloas en la capa de consenso y un aumento planificado del límite de gas actual de Hoodi a 200 millones —el techo de cuánta computación puede llevar cada bloque—, ambos parte del paquete de actualización del hard fork de Glamsterdam. Sin embargo, la Foundation enfatizó que el cambio de cronograma no afectará el historial de cadena existente de Hoodi.

Cómo los cambios de gas podrían salir caros

El problema se remonta al 13 de octubre, cuando la empresa de auditoría de blockchain ChainSecurity marcó dos propuestas de mejora de Ethereum de la actualización Glamsterdam —EIP-8037 y EIP-8038— como una amenaza a las medidas actuales diseñadas para prevenir lo que denomina "insufficient gas griefing". Según este ataque, quien llama envía deliberadamente gas insuficiente para que una función legítima de un contrato falle.

El gas es la unidad con la que Ethereum mide la computación, y los contratos se escriben bajo el supuesto de que el gas asignado a una operación se gasta en lugar de devolverse. Con la introducción de estas medidas, sería posible devolver gas a un contrato una vez que una operación falle, permitiendo así una operación adicional que de otro modo se habría detenido. Muchos contratos utilizan la cantidad de gas restante a mitad de la transacción como una de sus medidas de seguridad. Alterar ese supuesto haría posible que el contrato finalice la operación fallida, impidiendo que un usuario reclame algo o realice otra operación.

El alcance de la actualización va más allá de la contabilidad de gas. En una publicación del 26 de septiembre en X, el cofundador de Ethereum, Vitalik Buterin, destacó las mejoras de sincronización que se espera que traiga la actualización:

Recordatorio: ahora puedes sincronizar un nodo de ethereum en medio día y con ajustes agresivos el espacio que ocupa en disco puede ser inferior a medio terabyte. EIP-4444 y el arduo trabajo de los equipos de clientes optimizando snap sync han mejorado las cosas mucho. Glamsterdam mejorará aún más la situación de la sincronización (por ejemplo, el nuevo protocolo de sincronización de Nimbus lo usa) — vitalik.eth (@VitalikButerin), 26 de septiembre de 2026, en X

Algunas verificaciones de gas resistirán los cambios de todos modos, pero será necesario auditarlas frente al nuevo sistema de contabilidad de Glamsterdam.

13 contratos reales señalados

ChainSecurity declaró el viernes que había descubierto 13 casos de contratos reales potencialmente expuestos y que estaba llevando a cabo una divulgación responsable con los proyectos concernidos. Aunque la empresa no reveló los proyectos afectados ni los detalles de los casos descubiertos, recomendó a los desarrolladores evaluar sus contratos con urgencia. A diferencia del software tradicional, los contratos de Ethereum desplegados no pueden simplemente parchearse, razón por la cual la carga de la revisión recae en cada proyecto antes de cualquier nueva fecha de activación.

La noticia tuvo un fuerte impacto entre los miembros de la comunidad. El desarrollador pseudónimo pcaversaccio comentó en GitHub el 21 de octubre que la situación era "grave" y que el fork debía reevaluarse.

El anuncio llega además tras una advertencia previa de la Ethereum Foundation de que el nuevo mecanismo de precios de gas de Glamsterdam podría afectar a wallets, indexadores y estimadores de gas que operan bajo supuestos fijos.

Glamsterdam se lanzó en el testnet Sepolia el 6 de octubre, y Hoodi era el siguiente punto de control esperado antes del lanzamiento a la mainnet —bajo el proceso de despliegue de Ethereum, las ejecuciones en testnet actúan como puertas que una actualización debe superar antes de llegar a la mainnet. Inicialmente, el equipo planificó un despliegue en la mainnet en diciembre, condicionado a pruebas exitosas del testnet Hoodi. Sin embargo, con la activación en Hoodi ya no siendo posible, el lanzamiento propuesto para diciembre no debe considerarse una fecha límite. Los indicadores a observar de aquí en adelante son si se añade una época de reemplazo a la configuración de despliegue, qué arroja la evaluación de interacción de la EIP-8037 y qué surge de los intercambios de divulgación responsable de ChainSecurity con los 13 proyectos señalados.