Los desarrolladores principales de Ethereum han puesto en pausa la actualización Glamsterdam para la testnet Hoodi, deteniendo la transición de la red hasta que se resuelvan las preocupaciones de seguridad vinculadas a ocho invariantes de contratos inteligentes. La Fundación Ethereum reveló la decisión en una entrada de blog publicada el 6 de noviembre.

LATEST: ⚡ Ethereum developers say they are delaying the Glamsterdam hard fork process and won't fork the Hoodi testnet until gas-repricing issues flagged by ChainSecurity are resolved. pic.twitter.com/7HDv6dZDrc

— CoinMarketCap (@CoinMarketCap) November 6, 2026

Un invariante es una condición que un contrato inteligente espera que se mantenga siempre. El gas es la unidad que Ethereum utiliza para medir el trabajo computacional, y muchos proyectos ya desplegados asumen que ciertas operaciones costarán una cantidad fija de este. Dos propuestas programadas para incluirse en Glamsterdam cambian la forma en que se cobra el gas, y esos cambios podrían invalidar dichas suposiciones en los contratos existentes. Por eso la revalorización se trata como un asunto de seguridad y no como un simple ajuste de tarifas: las cantidades involucradas pueden determinar si ciertas rutas de código se ejecutan o no.

Lo que encontró ChainSecurity

Las preocupaciones provienen de un informe del 13 de octubre del auditor de contratos inteligentes ChainSecurity, que examinó cómo Glamsterdam podría afectar a los contratos que siguen ejecutándose después de que falla una llamada externa. El informe cubre EIP-8037, que cambia el costo de crear nuevo estado en la blockchain, y EIP-8038, que ajusta los cargos por acceder al estado existente. Ambos alteran la contabilidad de gas de ciertas operaciones.

Bajo las reglas actuales, algunos contratos dependen de que una operación fallida deje muy poco gas para que se ejecuten los pasos siguientes. Bajo las nuevas reglas, ciertas operaciones podrían completarse incluso cuando los desarrolladores esperaban que toda la transacción se revirtiera. Eso podría debilitar las salvaguardas integradas en esos contratos.

ChainSecurity dio un ejemplo. Un contrato marca una operación como fallida después de que una llamada externa se queda sin gas. Con las nuevas reglas, el gas que antes estaba fuera de alcance podría volver a estar disponible, y el contrato podría registrar una falla permanente.

La Fundación Ethereum ha publicado un repositorio de GitHub que documenta los ocho invariantes afectados. Incluye explicaciones, ejemplos y pasos concretos que los desarrolladores pueden usar para verificar su propio código frente a las nuevas reglas de gas. Los presupuestos de gas fijos y las reservas de gas son los problemas más comunes encontrados hasta ahora, lo que significa que un cambio a nivel de protocolo puede revelar suposiciones latentes en el código desplegado sin ninguna modificación en los propios contratos.

Otros riesgos involucran contratos que asumen que el uso de gas solo se mueve en una dirección, que las asignaciones de gas fijas seguirán siendo suficientes, o que una llamada revertida no puede devolver el gas ya gastado en crear estado.

El hard fork de Hoodi en pausa

La activación de Hoodi estaba programada inicialmente para el 26 de octubre a las 17:42:48 UTC. Hoodi es la testnet pública principal de Ethereum, donde los cambios de protocolo planificados suelen ensayarse antes del despliegue en la mainnet. El aplazamiento eliminó del calendario las activaciones Amsterdam de la capa de ejecución y Gloas de la capa de consenso, junto con un aumento planificado del límite de gas de la testnet a 200 millones. No se ha anunciado una fecha de reemplazo, y la Fundación dijo que el hard fork de Hoodi no procederá hasta que se resuelvan los problemas. Dado que la activación en la mainnet normalmente sigue a los ensayos en testnets públicas, el camino de Glamsterdam hacia la mainnet también queda sin un calendario fijo.

Los desarrolladores ahora evalúan si los contratos afectados pueden actualizarse por sí mismos o si las especificaciones de la actualización deben cambiar. El desarrollador de la Fundación Ethereum Marius van der Wijden dijo que el grupo está trabajando con ChainSecurity y Dedaub, y que está realizando auditorías internas para evaluar los efectos en las aplicaciones existentes.

La Fundación dijo que sus revisiones no pueden cubrir todos los proyectos, especialmente donde los contratos interactúan con sistemas fuera de la cadena. Ha pedido a los desarrolladores y auditores independientes que revisen tanto los contratos en cadena como las herramientas fuera de la cadena, incluidas billeteras, relayers y otra infraestructura que pueda usar límites de gas codificados de forma fija.

Los hallazgos deben enviarse antes de las próximas discusiones de All Core Developers, el foro permanente donde los equipos de clientes de Ethereum y los investigadores coordinan los cambios de protocolo. Los informes deben indicar el contrato afectado, el invariante involucrado, posibles correcciones y pruebas cuando estén disponibles. Pueden enviarse de forma privada a glamsterdam@ethereum.org. Según los comentarios recibidos, los desarrolladores pueden ajustar EIP-8037 y EIP-8038, lo que convierte esas discusiones en el punto de control a observar para cambios de especificación que determinarían cuándo se puede reprogramar el hard fork de Hoodi.

Antecedentes de Glamsterdam

Glamsterdam se activó en la testnet Sepolia el 6 de octubre, donde los desarrolladores comenzaron a probar sus cambios de escalabilidad bajo un límite de gas de 200 millones. La actualización también agrega la separación de proponente-constructores incorporada al protocolo mediante EIP-7732 y listas de acceso a nivel de bloque mediante EIP-7928. Las activaciones en testnets como esta permiten a los desarrolladores observar el comportamiento de la actualización en un entorno real antes del despliegue en la mainnet.

En una evaluación de agosto, la Fundación dijo que las repeticiones de transacciones pasadas mostraron que la mayoría de los contratos inteligentes no fueron afectados por los cambios de precios. Un grupo más pequeño necesitaba límites de gas más altos o cambios mayores para evitar fallas inesperadas.

El 26 de octubre, los desarrolladores también fusionaron una corrección de depósitos de validadores. Abordaba una falla que podría haber acreditado depósitos de staking a constructores de bloques que compartieran la misma clave pública. Se agregaron pruebas de regresión a las especificaciones.

La Fundación dijo que el trabajo en la próxima actualización, Hegota, continúa en paralelo y no se ve afectado por el retraso de Glamsterdam.