Qué cambia en Glamsterdam y por qué preocupa a los contratos
El foco está en dos propuestas técnicas incluidas en el diseño de Glamsterdam: EIP-8037 y EIP-8038. La primera modifica el coste de crear nuevo estado en la red, como cuentas, espacios de almacenamiento o código de contratos. La segunda revisa cuánto gas consumen determinadas operaciones de lectura y escritura sobre ese estado. El gas es la unidad que mide el trabajo computacional de cada operación.
El objetivo es que el coste refleje mejor los recursos que Ethereum necesita para procesar y almacenar información y permitir que la red escale sin exigir tanto hardware a los nodos. Como referencia, EIP-8037 elevaría el coste base de crear un contrato de 32.000 a 183.600 unidades de gas, sin contar el almacenamiento del código ni su ejecución. Son unidades de gas, no euros. Quien quiera entender cómo se coordinan estos cambios puede consultar nuestra guía sobre las bifurcaciones de Ethereum.
El problema está en cómo puede afectar al código que ya funciona con las reglas actuales. Algunos contratos inteligentes reservan una cantidad fija de gas para llamar a otros contratos, utilizan el gas restante para decidir qué hacer o dependen de cuánto gas queda después de una operación fallida. Si el nuevo sistema cambia ese cálculo, una llamada que antes podía completarse podría quedarse sin gas. En determinados diseños, el contrato que recibe el fallo podría incluso registrar la operación como fallida y cerrar la posibilidad de repetirla.
Esto no significa que todos los contratos de Ethereum vayan a dejar de funcionar. En su análisis publicado el 24 de agosto, la Fundación Ethereum señaló que la gran mayoría de los contratos analizados no presentaba cambios relevantes y que los casos potencialmente problemáticos eran una parte pequeña. También indicó que muchos fallos detectados podían resolverse aumentando el límite de gas utilizado.
La diferencia importante es entre una operación que necesita más gas y otra que seguiría fallando incluso con un margen superior. La situación es más delicada cuando el contrato no puede actualizarse directamente: algunos protocolos son inmutables, mientras que otros cuentan con mecanismos de actualización o pueden modificar la infraestructura que prepara las transacciones.
Dos borradores plantean caminos distintos para conservar la compatibilidad
El 8 de noviembre se abrieron dos propuestas en el repositorio de Ethereum Improvement Proposals. La primera, EIP-8488, presentada por Leo Glisic, plantea crear una segunda versión de los códigos de operación afectados por el cambio de gas. Con ese diseño, los contratos ya desplegados conservarían el esquema de costes antiguo, mientras que los contratos nuevos tendrían que utilizar las nuevas instrucciones compatibles con EIP-8037 y EIP-8038.
La segunda, EIP-8487, presentada por Giulio Rebuffo, propone mantener dos contadores de gas durante una misma transacción. Uno aplicaría las reglas anteriores para controlar la ejecución que ve el contrato; el otro calcularía el coste económico con las nuevas reglas. La intención es que el comportamiento de los contratos antiguos no cambie de forma inesperada, aunque la facturación refleje el nuevo modelo de recursos.
Las dos alternativas persiguen un objetivo parecido, pero no son equivalentes. EIP-8488 separa las instrucciones que utilizan los contratos antiguos y los nuevos. EIP-8487 separa la contabilidad de la ejecución y la del cobro. Además, el propio borrador de Rebuffo reconoce que todavía no se ha implementado en un cliente de ejecución ni se han realizado pruebas de consenso. Ambas siguen siendo propuestas preliminares: no están aprobadas ni tienen una fecha de activación. La Fundación Ethereum ha confirmado que trabaja en prototipos de posibles revisiones, pero no ha anunciado que vaya a adoptar ninguna de estas dos propuestas.
Qué significa la cifra de 200.000 y cuándo se decidirá
El desarrollador seudónimo banteg advirtió el 7 de noviembre de que el listado de contratos afectados en la herramienta de análisis repricing-impact rondaba los 200.000 y que, a su juicio, su metodología podía estar dejando casos fuera. Es una advertencia relevante de un participante del ecosistema, pero no debe interpretarse como una confirmación de que 200.000 contratos vayan a romperse.
El dashboard reproduce transacciones históricas, no una predicción, y las clasifica en varios grupos: operaciones que no cambian, otras que siguen funcionando con diferencias, casos que se corrigen aumentando el límite de gas y transacciones potencialmente rotas, que siguen fallando incluso al probar con un límite de hasta diez veces el original. Aparecer en el análisis no equivale automáticamente a que un contrato vaya a dejar de funcionar o a que los fondos depositados en él estén en riesgo.
La Fundación comunicó el 9 de noviembre que había recibido cuatro informes con ejemplos de contratos desplegados que podrían romperse y que estaba revisándolos con los equipos afectados. El aplazamiento de Hoodi ya se había anunciado el 22 de octubre, cuando se retiró la activación prevista para el día 26. Glamsterdam ya se había activado en Sepolia el 6 de octubre, pero la Fundación reiteró el 6 de noviembre que los desarrolladores no volverían a programar la prueba de Hoodi hasta resolver las dudas sobre la interacción de EIP-8037 y EIP-8038 con contratos de la red principal. Hoodi no tiene nueva fecha y tampoco se ha fijado una fecha para activar Glamsterdam en la red principal de Ethereum.
Qué deben vigilar ahora los usuarios de Ethereum
El calendario de revisión sí tiene próximos hitos: la Fundación prevé publicar los informes de ChainSecurity y Dedaub el 13 de noviembre, presentar sus conclusiones y responder preguntas el día 16, y debatir los siguientes pasos en la reunión de desarrolladores del 19 de noviembre. La propia Fundación aclara que no hay una decisión anticipada sobre el resultado.
Para quien utiliza Ethereum, el mensaje práctico es que el problema se está tratando antes de que las nuevas reglas lleguen a la red principal. No hay una alerta general sobre el saldo de ETH en una cartera convencional ni una razón para que todos los usuarios muevan sus fondos.
Sí conviene distinguir entre la seguridad de la red y la compatibilidad de cada contrato: si utilizas una wallet inteligente, un puente o una aplicación DeFi, el riesgo dependerá de su código y de si sus responsables pueden actualizarlo o migrarlo. Nuestra guía de seguridad en criptomonedas explica otros riesgos que conviene valorar al utilizar wallets y aplicaciones descentralizadas.
La clave no es quedarse con una cifra aislada, sino comprobar qué contratos fallarían realmente, cuáles pueden adaptarse y si la solución elegida mantiene el objetivo de escalabilidad. Hasta que terminen las auditorías y los desarrolladores decidan qué hacer con las especificaciones, Glamsterdam sigue siendo una actualización en pruebas, no un cambio activo en la red principal.
