El desarrollador de la Ethereum Foundation Marius van der Wijden dijo en una actualización del 6 de noviembre que los desarrolladores principales no harán fork del testnet Hoodi hasta que se resuelvan los problemas identificados por la firma de seguridad ChainSecurity. Hoodi es la red de pruebas pública donde Ethereum ensaya los cambios de protocolo antes de que lleguen a la mainnet. Pidió a los desarrolladores de contratos y auditores que revisen sus proyectos frente a ocho invariantes de gas que la próxima actualización Glamsterdam rompe. El gas es la unidad en la que Ethereum pone precio a cada operación que realiza una transacción, por lo que cuando esos precios cambian, el código escrito bajo los números antiguos puede comportarse de forma distinta aunque el código en sí no se haya modificado.

Una invariante, en este contexto, es una regla que el código trata como siempre verdadera — por ejemplo, "un presupuesto de gas fijo es suficiente para esta llamada" o "una delegación minada ha surtido efecto". El repositorio de invariantes de la Foundation enumera ocho supuestos que cambian bajo Glamsterdam y dice que la mayoría de los hallazgos hasta ahora involucran dos de ellos.

Dos propuestas reconfiguran los costos de gas

Dos propuestas impulsan el cambio. EIP-8037 eleva el precio de crear nuevo estado — cuentas nuevas, slots de almacenamiento y código desplegado — y lo mide por separado de la ejecución ordinaria. EIP-8038 eleva el precio de leer y actualizar el estado ya existente. Según la especificación contra la que el repositorio hace pruebas, escribir en un slot de almacenamiento nuevo sube de 22,100 gas a 110,020, actualizar un slot existente caliente de 2,900 a 10,100, y desplegar código de 200 gas por byte a 1,530. Esas cifras cambian si la especificación lo hace.

La pausa en las pruebas de Glamsterdam siguió a la revisión del 13 de octubre de ChainSecurity, como se informó anteriormente. El repositorio amplía esos hallazgos con el propio escaneo de la Foundation de contratos verificados en Sourcify, un registro público de código fuente de contratos, y con casos fuera de la cadena, como software que lee recibos de transacciones.

Una transacción minada ya no prueba que una delegación surtió efecto

EIP-7702 permite que una cuenta ordinaria de Ethereum ejecute código de contrato inteligente firmando una autorización que apunta a un contrato delegado. El mecanismo se activó con la actualización Pectra de 2025 y sustenta las funciones de cuentas inteligentes que las wallets han estado lanzando desde entonces. La autorización está pensada para usarse una sola vez. Antes de Glamsterdam, su costo completo se cobraba por adelantado, por lo que una transacción que no podía pagarlo era inválida y nunca llegaba a un bloque. Si una transacción era minada, la delegación había surtido efecto.

La entrada INV-8 del repositorio explica lo que cambia EIP-8037. Parte del costo ahora depende del estado de la cuenta y se cobra solo mientras se procesa la autorización. Delegar desde una cuenta vacía cuesta 235,606 gas, frente a 25,000 antes. Una transacción presupuestada con la cifra anterior puede ser aceptada, quedarse sin gas al aplicar la autorización e incluirse en un bloque con estado de fallo. La delegación se revierte, y también el incremento del nonce de la cuenta, el contador que marca una autorización como usada. Sin embargo, la autorización firmada ahora es pública y sigue siendo válida.

Por sí solo, eso deja una wallet sin configurar en lugar de comprometida. El peligro surge cuando el contrato delegado permite que cualquiera llame a su función de setup. Un atacante puede entonces reenviar la autorización expuesta en su propia transacción, llamar primero a setup y nombrarse propietario de la cuenta. Hacer front-running de autorizaciones en el mempool público ya era posible. El punto del repositorio es que una transacción fallida ahora publica por sí misma una autorización válida, por lo que enrutarla de forma privada no ofrece protección. El patrón está documentado con código de ejemplo, y no se nombra ninguna wallet afectada.

El cambio práctico recae en wallets, relayers e indexadores. El repositorio aconseja verificar el código y el nonce de la cuenta después de una transacción de delegación en lugar de confiar en el recibo. Cualquier autorización fallida debe tratarse como expuesta y cancelarse, ya sea avanzando el nonce de la cuenta o delegando de nuevo hacia un contrato seguro. Se ha sugerido un cambio de especificación que cobraría el costo del peor caso por adelantado, pero no se ha adoptado, y se pide a los desarrolladores que construyan como si el comportamiento actual se mantuviera.

Los presupuestos de gas a menudo están fuera del contrato

La entrada más amplia, INV-4, cubre cualquier cantidad de gas fijada antes del fork. Ahora puede ser demasiado pequeña dondequiera que esté escrita: código de contrato, un valor de configuración, un mensaje firmado o software fuera de la cadena. Este último grupo incluye relayers — servicios que envían transacciones en nombre de los usuarios — así como keepers y sistemas de retiro de exchanges.

Los destinatarios por primera vez son el detonante más común. Enviar un token a una dirección con saldo cero crea un nuevo slot de saldo, y enviar ETH a una dirección vacía crea una cuenta nueva, ambos casos que EIP-8037 pone mucho más caros. Según el repositorio, una transferencia que hoy cabe en 65,000 gas puede necesitar más de 150,000.

Dónde vive el número fijo determina qué tan grave es el déficit. En software fuera de la cadena, la transacción completa revierte y puede reenviarse con más gas. En un contrato, su configuración o un mensaje firmado, solo falla la llamada interna. Si el contrato externo captura ese fallo, el resultado suele ser definitivo: un mensaje guardado como fallido, un callback omitido o recompensas registradas incorrectamente. Algunos de estos números no pueden editarse en absoluto, incluidas las transacciones multisig firmadas antes del fork, las meta-transacciones firmadas y los mensajes cross-chain ya en vuelo.

INV-7 aplica el mismo problema al gas mantenido en reserva. Las funciones transfer y send de Solidity pasan un gas fijo de 2,300, pero un contrato receptor que escribe un nuevo slot de almacenamiento ahora necesita más de 110,000. Las wallets inteligentes, los divisores de pagos y las bóvedas con lógica en sus funciones receive son los candidatos obvios.

Rutas de fallo que antes revertían ahora pueden completarse

El análisis del 13 de octubre de ChainSecurity explica por qué algunas protecciones que pasaron auditorías anteriores pueden dejar de cumplir su función. Los contratos suelen capturar una llamada externa fallida para registrar el fallo, omitir un elemento o probar un fallback. Eso se vuelve peligroso cuando alguien suministra deliberadamente muy poco gas — un ataque llamado insufficient gas griefing — porque una operación que debería ser reintentable queda marcada como fallida permanentemente.

Los contratos suelen defenderse de esto de dos maneras. Algunos verifican cuánto gas queda después de la llamada. Otros confían en que el manejador de fallos sea demasiado caro para completarse. Glamsterdam debilita ambos. EIP-8037 otorga a las transacciones con un límite de gas superior a 16,777,216 un depósito separado para costos de almacenamiento que la verificación habitual de gasleft() no ve. Revertir una llamada o limpiar un slot recién escrito también puede devolver el gas gastado. En palabras de ChainSecurity, "Incluso con código de contrato sin cambios, una ruta de fallo que antes revertía ahora puede completarse".

La firma ahora desaconseja inferir por qué falló una llamada a partir del gas restante después. Su enfoque preferido es dejar que toda la operación revierta cuando sea posible, o mantener una ruta de recuperación en lugar de tomar una decisión irreversible basada en el gas restante.

Una auditoría anterior no puede cerrar esa brecha por sí sola, porque juzgó el código según las reglas de gas vigentes en ese momento. La Foundation ha contratado a ChainSecurity y Dedaub junto con sus auditorías internas, pero su publicación del 6 de noviembre reconoce que no puede revisar todos los proyectos, especialmente el código fuera de la cadena. Las decisiones de diseño también moldean la solución: un límite de gas almacenado como configuración ajustable simplemente puede subirse, mientras que uno escrito como constante fija puede dejar el redespliegue y la migración como la única vía.

Por qué Ethereum sigue adelante con el reprecio

El argumento de la Foundation para el cambio se basa en la precisión de los precios. Su guía de agosto para desarrolladores de contratos decía que los precios de gas para operaciones de estado se ajustaron por última vez en el fork Berlin de 2021, el fork que estableció el precio actual de lectura de estado frío frente a caliente. El estado de Ethereum — el registro continuo de cuentas, saldos y almacenamiento de contratos que los nodos rastrean — ha crecido significativamente desde entonces, y los recientes aumentos del límite de gas han acelerado ese crecimiento. La publicación calificó el reprecio como un prerrequisito para subir más el límite de gas y dijo que el nuevo esquema se deriva de un objetivo de rendimiento que respalda un aumento de aproximadamente tres veces en el throughput base.

La misma publicación reportó que reproducir transacciones históricas de la mainnet bajo los nuevos precios dejó sin cambios a la gran mayoría, y que la mayoría de los problemas señalados podrían corregirse subiendo un límite de gas. Dijo a los usuarios regulares que no se requería ninguna acción, porque las wallets e infraestructura actualizadas manejarían el cambio. Los hallazgos de noviembre dan más peso a esa última cláusula. Manejar el cambio ahora incluye verificar el estado de la cuenta después de una delegación fallida y dimensionar los presupuestos de los relayers para destinatarios por primera vez — trabajo que las reglas de gas antiguas nunca exigían.

Qué decidirán las próximas llamadas de desarrolladores principales

Según el repositorio, la Foundation está recopilando comentarios antes de la próxima llamada All Core Developers, el foro permanente donde se acuerdan los cambios de protocolo de Ethereum. Dependiendo de la respuesta, podría cambiar ligeramente EIP-8037 y EIP-8038 o dejarlos como están. Hoodi sigue sin fork hasta que se resuelvan los problemas, y la publicación del 6 de noviembre no da una nueva fecha. Según la misma publicación, el trabajo en Hegota, la actualización planeada después de Glamsterdam, continúa en paralelo.

Antes de que Hoodi haga fork: quién revisa qué

• Equipos de contratos: peguen las direcciones en el buscador de contratos afectados de la Foundation, y luego revisen cualquier código que fije valores de gas o se ramifique según el gas restante, esté listado o no.
• Wallets y proveedores de RPC: actualicen la estimación de gas para el nuevo esquema. La Foundation advierte que las constantes de gas en caché subestimarán los costos y causarán transacciones fallidas.
• Relayers, keepers y bundlers: hagan los límites ajustables y re-estimen bajo las nuevas reglas con un margen, probando transacciones a ambos lados del umbral del depósito.
• Auditores: el repositorio incluye instrucciones para ejecutar sus verificaciones con un agente de código con IA, manteniendo el código y los resultados en local.

Las señales que vale la pena seguir son una fecha de fork de Hoodi en el blog de la Foundation, cualquier revisión a la especificación de cualquiera de los EIP y proyectos afectados confirmando correcciones. La Foundation ha pedido a los equipos que reporten problemas de forma privada a glamsterdam@ethereum.org en lugar de en issues públicos, para que los problemas puedan corregirse antes de que los detalles se difundan.

Este artículo apareció originalmente en Coindoo.