Los desarrolladores de Ethereum han pausado la activación de la actualización Glamsterdam en la testnet Hoodi debido a preocupaciones sobre el comportamiento de los contratos inteligentes ya desplegados bajo las nuevas reglas de precios de gas de la actualización. La decisión se tomó en la All Core Devs Execution call #248, según anunció la Ethereum Foundation en su anuncio del 22 de octubre.

Puntos clave de la decisión:

• El costo de estado de un nuevo slot de almacenamiento sube de 20,000 a 97,920 de gas.
• También se eliminó el aumento planeado del límite de gas de Hoodi a 200M.
• No se ha fijado una fecha de activación de Glamsterdam en la mainnet.
• La revisión Last Call de la EIP-8037 termina el 1 de noviembre.

El último paso de testnet antes de la mainnet queda en pausa

Glamsterdam estaba previsto activarse en Hoodi el 26 de octubre a las 17:42:48 UTC. El aplazamiento elimina tanto la activación de la capa de ejecución Amsterdam como la de la capa de consenso Gloas —las dos mitades de la actualización—, junto con el cronograma que habría elevado el límite de gas de Hoodi a 200 millones al mismo tiempo. Esto cambia la configuración futura de la testnet sin revertir su historial, y no se ha fijado una fecha de reemplazo.

Durante Fusaka, la actualización anterior, Hoodi fue la tercera y última testnet en hacer el fork antes de la mainnet, y la Foundation dijo que la mainnet seguiría al menos 30 días después, según The Block. En ese despliegue, el fork final en testnet fue el último punto de control público antes de la mainnet. Glamsterdam ya superó un ensayo de 200 millones de gas en Sepolia, donde la corrección fue una actualización de Prysm a los valores por defecto de los validadores —un problema de configuración del cliente—. Esta vez la pregunta es cómo se comportan los contratos que ya están desplegados. La Foundation no ha fijado una fecha de mainnet para Glamsterdam y afirma que los usuarios de la mainnet y los holders de ETH no necesitan hacer nada.

Un aumento del precio de almacenamiento que reduce el gas de ejecución en algunas escrituras

La EIP-8037 existe para frenar el crecimiento del estado de Ethereum, los datos que cada nodo debe almacenar. Sus autores calculan que ese estado rondaba los 390 GiB en enero de 2026. Estiman que, con los precios actuales, un límite de gas de 200 millones podría llevarlo más allá de los 650 GiB —el nivel en el que los nodos empiezan a ralentizarse— en menos de un año. Su respuesta es cobrar 1,530 de gas por byte de nuevo estado, elevando el costo de estado de un nuevo slot de almacenamiento de 20,000 a 97,920 de gas, y el de una nueva cuenta de 25,000 a 183,600.

Para que sigan siendo posibles los despliegues de contratos grandes, la propuesta divide el gas en dos pools. El gas de ejecución cubre la computación, y el gas de estado cubre el nuevo almacenamiento. Cualquier gas que una transacción aporte por encima de 16,777,216 va a un depósito separado de gas de estado, del cual los cargos de estado se toman primero. Ese depósito se transfiere íntegro a cada sub-llamada, y los contratos no pueden verlo a través de la lectura estándar de gasleft().

Gas de ejecución requerido para una escritura en frío a un nuevo slot de almacenamiento, según ChainSecurity, usando cifras de la EIP-8037 y la EIP-8038:

• Hoy: 22,100
• Glamsterdam, el depósito paga el cargo de estado de 97,920: 12,100
• Glamsterdam, depósito vacío: 110,020

En otras palabras, la misma escritura en frío puede costar aproximadamente nueve veces más gas de ejecución con el depósito vacío que cuando el depósito cubre el cargo de estado.

El gas también puede fluir de vuelta durante la ejecución. Limpiar un slot creado antes en la misma transacción rellena de inmediato hasta 97,920 de gas, y una sub-llamada que revierte puede devolver los cargos de estado que pagó. El saldo de gas visible de un contrato puede, por lo tanto, aumentar a mitad de la ejecución. La propia EIP advierte que los contratos que miden el trabajo como la diferencia entre dos lecturas de gas pueden obtener un resultado negativo, y que los contratos ya desplegados con ese diseño no pueden corregirse.

Cómo podría usar un atacante las nuevas reglas

La firma de seguridad ChainSecurity detalló el riesgo en un análisis del 13 de octubre. Los contratos suelen capturar una llamada fallida y registrar el resultado, lo que permite que un atacante malicioso aporte deliberadamente demasiado poco gas para que una operación válida falle mientras el contrato aún tiene gas suficiente para guardar ese fallo. Esta técnica se conoce como insufficient gas griefing, y puede bloquear permanentemente un reintento o eliminar el reclamo de un usuario.

Para los contratos que dependen de que el propio manejador de fallos se quede sin gas:

• Paso 1: El atacante envía una llamada con demasiado poco gas.
• Paso 2: La operación objetivo se queda sin gas.
• Hoy: El manejador también se queda sin gas, todo revierte y el usuario puede reintentar.
• Glamsterdam: El depósito o el gas rellenado permite que el manejador termine y guarde el fallo de forma permanente.

Los contratos que verifican el gas restante tras una llamada fallida pueden serañados cuando los rellenos de gas o un intermediario que revierte empujan el saldo por encima de su umbral. Los presupuestos fijos de gas también pueden quedarse cortos, porque la EIP-8038 eleva el costo de tocar el estado existente: el primer cambio en un slot cálido existente sube de 2,900 a 10,100 de gas.

No todas las defensas se rompen. ChainSecurity señala que una verificación realizada antes de la llamada sigue garantizando la entrega del gas solicitado, siempre que el presupuesto cubra cada ruta de ejecución bajo los nuevos precios sin contar con el depósito. Recomienda no depender en absoluto de las verificaciones de gas posteriores a la llamada. El aviso de la Foundation menciona solo la EIP-8037 y no cita el trabajo de la firma, que también cubre la EIP-8038.

Qué deben hacer los operadores y desarrolladores

Los operadores de Hoodi deben actualizar sus clientes de ejecución y consenso antes del 26 de octubre, usando versiones cuyas notas confirmen explícitamente que la activación anterior fue eliminada. Las tablas de versiones del anuncio original no cuentan como confirmación. Al 23 de octubre, la Foundation había listado versiones actualizadas para dos clientes, y dijo que se añadirían otras a medida que se confirmen.

Los validadores deben actualizar tanto el nodo beacon como el cliente validador, y quienes operen infraestructura externa de construcción de bloques deben seguir las instrucciones de su proveedor. Los equipos de aplicaciones deben dejar de planificar pruebas en Hoodi en torno a la fecha original.

Para los desarrolladores de contratos, la lista de verificación de ChainSecurity empieza con cada llamada que permite que la ejecución continúe tras un fallo. Incluye rastrear la ruta completa, incluidos los proxies; identificar los slots que se crean y se limpian en la misma transacción, y los intermediarios que revierten; revisar de nuevo los presupuestos fijos; y forzar que las sub-llamadas fallen y comparar el resultado bajo ambos conjuntos de reglas. Cuando sea posible, una llamada fallida debería revertir toda la operación. Los wallets y el software de nodos también deben actualizar su estimación de gas para el modelo de dos pools, según la EIP.

Las próximas decisiones corresponden a los desarrolladores core. La revisión Last Call de la EIP-8037 —la ventana final de revisión antes de que una propuesta se finalice en el proceso de Ethereum— cierra el 1 de noviembre, la investigación podría llevar a cambios en la especificación, y una nueva fecha para Hoodi se fijará en una llamada futura.

Este artículo se proporciona únicamente con fines informativos y no constituye asesoramiento financiero ni de inversión. Los calendarios de actualización de Ethereum y sus especificaciones técnicas pueden cambiar durante las pruebas.

Fuente: Coindoo