Glamsterdam se cae del calendario de octubre de Hoodi mientras Ethereum revisa los riesgos en los contratos

Se ha cancelado la prueba Hoodi del 26 de octubre, incluido su límite de gas planificado de 200 millones. Los desarrolladores están examinando una propuesta de reajuste de precios frente a contratos que ya están en la mainnet.

Ethereum ha cancelado una prueba que debía ejecutarse el próximo lunes. El aviso de la Fundación Ethereum del 22 de octubre indica que Glamsterdam no se activará en Hoodi a las 17:42:48 UTC del 26 de octubre, y no se ha fijado una nueva época. El aumento del límite de gas a 200 millones que lo acompañaba también se ha retirado del calendario de la testnet. Esto es un aplazamiento de una configuración futura, no una reversión de bloques ya registrados por Hoodi.

Los desarrolladores tomaron la decisión de investigar cómo interactúa la EIP-8037, un cambio en el precio de crear nuevo estado en Ethereum, con los contratos en la mainnet. La Fundación no ha dicho que la actualización haya roto la mainnet. Tampoco ha fijado una fecha para una bifurcación en producción. El riesgo operativo inmediato está en Hoodi: los clientes o configuraciones personalizadas que aún conserven la antigua hora de activación podrían discrepar con el calendario revisado. La cuestión más profunda es cómo cambiar el costo del trabajo dentro de una transacción sin alterar las aplicaciones que incorporaron los antiguos números en el código.

La bifurcación de Hoodi del 26 de octubre está fuera del calendario

El anuncio de Hoodi del 16 de octubre especificaba la época 132.352 y el slot 4.235.264. Emparejaba los cambios de Amsterdam en la capa de ejecución con los cambios de Gloas en la capa de consenso y un límite de gas de 200 millones. El nuevo aviso reemplaza esas instrucciones en su totalidad. Los operadores deben leer las notas de la versión más recientes para ambos tipos de cliente; una versión anterior descrita como compatible con Glamsterdam aún podría contener la activación de Hoodi ahora cancelada.

Eso es más que una nota a pie de página de programación. Un validador necesita seguir las mismas reglas de red que sus pares. Si parte de su software espera nuevas reglas de ejecución o deberes de consenso en la época antigua mientras la red no lo hace, puede perder la capacidad de seguir la cadena canónica. La infraestructura de constructores y validadores puede tener su propia configuración. Por lo tanto, la Fundación indica a los operadores que verifiquen las versiones revisadas de los clientes y eliminen configuraciones personalizadas obsoletas antes del 26 de octubre, en lugar de asumir que no hacer nada es seguro porque se retrasó una bifurcación.

Sepolia activó Glamsterdam el 6 de octubre y probó un límite de gas de 200 millones, como registró la cobertura de esa activación. La activación exitosa de una testnet es útil pero no concluyente para otra. El ensayo restante de Hoodi se ha pospuesto precisamente porque la investigación de los contratos necesita tiempo. No hay una marca de tiempo de reemplazo publicada para extrapolar a una fecha de mainnet.

Glamsterdam se activó en Sepolia el 6 de octubre, donde los desarrolladores probaron un límite de gas de 200 millones. La prueba exitosa no resuelve cómo afectará la EIP-8037 a los contratos que ya se ejecutan en la mainnet. El ensayo de Hoodi está pospuesto mientras los desarrolladores investigan esas interacciones, y no se ha anunciado una fecha de reemplazo.

La secuencia ha cambiado más de una vez este año. La información de septiembre sobre el plan de Sepolia describió problemas en la devnet y un problema de implementación de EIP-8037 antes de que procediera la prueba pública. Esos problemas anteriores no son prueba de la misma causa que la investigación de contratos del 22 de octubre. Muestran por qué las fechas han sido condicionales a medida que los equipos de clientes pasan de las pruebas privadas a las redes públicas. Preocupaciones separadas sobre el comportamiento de los builders en las testnets conciernen a otra parte de Glamsterdam y no deben confundirse con la repreciación. El último aviso da una razón específica para la pausa de Hoodi: una investigación adicional de la interacción de EIP-8037 con los contratos de la mainnet.

Por qué crear estado cuesta más en la propuesta

Una transacción puede ejecutar cálculos y puede dejar datos que la red debe retener y a los que debe acceder más tarde. Crear una nueva cuenta, abrir una nueva ranura de almacenamiento o desplegar bytecode de contrato se suma a ese estado persistente. EIP-8037 propone cobrar más por esas operaciones y medir la parte de creación de estado por separado. El objetivo es acercar el precio a la carga de mayor duración sobre los nodos, especialmente si se permite que los bloques lleven más trabajo.

La tabla ilustrativa de la propuesta sitúa el componente de creación de estado de una nueva cuenta en 183.600 gas, frente a los 25.000 actuales; una nueva ranura de almacenamiento en 97.920, frente a 20.000; y un despliegue de 24 kilobytes en 37.784.880, frente a 4.947.200. La tabla no es una predicción universal de la comisión en ETH que pagará un usuario. Aísla un componente bajo una constante propuesta, con otros cargos de ejecución por encima, y el coste final en moneda depende del precio del gas en ese momento. El tamaño del cambio explica por qué los contratos con límites ajustados merecen un examen más detenido.

Una propuesta de acceso al estado relacionada, EIP-8038, reprecia algunas lecturas y escrituras. La guía de impacto para desarrolladores de la Fundación dice que estos costes de gas se ajustaron sustancialmente por última vez en la bifurcación Berlín en 2021, mientras que el estado ha crecido. La repreciación planificada se diseñó junto con el trabajo para aumentar el rendimiento; hacer bloques más grandes sin tener en cuenta las costosas operaciones de estado podría dificultar la validación para los operadores de nodos. La pausa, por lo tanto, afecta tanto a la compatibilidad de las aplicaciones como al plan de escalado, aunque su desencadenante anunciado es la interacción de EIP-8037.

Una llamada externa muestra por qué esto puede ser difícil de detectar de antemano. Un llamador puede pasar deliberadamente solo el gas suficiente para que un receptor realice una acción limitada, asumiendo que cualquier trabajo adicional fallará de forma segura. Si una cuenta o un acceso al almacenamiento reprecia ahora consume esa asignación, el receptor puede fallar durante un pago rutinario, aunque el usuario haya suministrado gas de sobra a la transacción externa. Cambiar la estimación de la billetera no reescribe la asignación interna. Los desarrolladores deben inspeccionar la ruta del código y el manejo de fallos a su alrededor, porque algunas aplicaciones consideran que una llamada externa fallida es razón para revertir, mientras que otras continúan y registran un resultado diferente.

Los patrones transfer y send de Solidity históricamente reenvían un estipendio de 2.300 gas. Muchos equipos ya han dejado de depender de ese estipendio, pero los contratos desplegados pueden seguir en uso durante años. La Fundación identifica los estipendios fijos como una categoría de riesgo; no dice que toda llamada que los use vaya a fallar. Un receptor que realiza poco trabajo puede mantenerse dentro de la asignación, mientras que un contrato que toca estado recién reprecia puede superarla. Probar las contrapartes reales importa más que tratar la mera presencia de un nombre de función como prueba de rotura.

Una segunda clase de problema reside en la automatización. Las billeteras, los relayers y los custodios pueden almacenar límites de gas predeterminados para tareas habituales. Una operación que se ejecutó con éxito durante años podría empezar a quedarse sin gas aunque el contrato de la aplicación en sí sea sólido. Aumentar una estimación en el frontend puede corregir esa ruta, pero un agente programado o un cliente que use una billetera más antigua podría seguir enviando el límite anterior. Por lo tanto, los desarrolladores tienen que identificar no solo el código afectado, sino también los servicios que construyen transacciones para él.

¿Qué contratos pueden tener problemas?

La Fundación reprodujo transacciones históricas de la red principal bajo el calendario propuesto. La mayoría no tuvo ningún problema significativo. De los casos señalados, muchos se completaron después de que se elevara su límite de gas; un grupo más pequeño podría fallar incluso con sustancialmente más gas. Un estipendio fijo, una cantidad de gas codificada de forma rígida enviada a otro contrato, o una rama basada en el resultado de gasleft() pueden cambiar la ruta que toma una transacción. La advertencia anterior sobre contratos describía esas categorías antes de que Hoodi adquiriera su fecha de octubre. El aplazamiento actual hace urgentes los casos sin respuesta, pero no demuestra que todos los contratos de Ethereum sean vulnerables.

Considere una aplicación que envía fondos a otro contrato mientras proporciona una asignación de gas fija. El contrato receptor podría necesitar más gas bajo el nuevo calendario para acceder al almacenamiento. Si la asignación del llamador está incrustada en el código desplegado, simplemente elevar el límite de la transacción de nivel superior podría no dar más margen a la llamada receptora. Entonces, un fallo podría requerir una corrección a nivel de contrato o una ruta diferente para los usuarios. Por el contrario, si el único problema es que una billetera estimó una transacción usando precios antiguos, una estimación actualizada y un límite suministrado más alto podrían ser suficientes. Los dos casos son operativamente distintos.

Un problema particularmente inusual de EIP-8037 involucra código que mide el trabajo restando dos lecturas del gas restante. La propuesta explica que el depósito de gas de estado puede hacer que gasleft() aumente bajo algunas circunstancias. Un cálculo que espera una disminución no negativa podría comportarse de manera diferente, y los contratos desplegados inmutables no pueden parchearse en su lugar. El impacto preciso depende del código y de la ruta de la transacción, por lo que una reproducción de transacciones históricas reales importa más que una advertencia genérica sobre tarifas más altas.

La herramienta de búsqueda de la Fundación permite a los desarrolladores examinar las direcciones de contratos afectadas y la razón de una divergencia señalada. Recomienda probar en una devnet usando el nuevo calendario e inspeccionar el código que asume límites fijos incluso cuando un contrato no aparece en la lista. Una reproducción histórica es un filtro, no un inventario completo del comportamiento futuro: una ruta que ningún usuario llamó durante la muestra podría aún contener una suposición vulnerable. Los equipos necesitan sus propias pruebas para las ramas que operan.

El resultado de una reproducción también depende de la muestra de transacciones. Un contrato puede contener una asignación de gas fija en una función que rara vez se ha llamado; si esa ruta está ausente del historial reproducido, la herramienta no puede demostrar su fallo. La Fundación aconseja a los mantenedores que revisen el código incluso cuando su dirección no aparece en la lista de afectados. Una aplicación grande puede tener varios contratos, frontends actualizables y agentes automatizados, cada uno suministrando un límite de gas diferente. El equipo necesita probar la operación tal como sus usuarios realmente la invocan, incluyendo una billetera o bot que podría estar manteniendo una estimación antigua en una caché.

Para un contrato cuyo comportamiento cambia, corregir la interfaz que envía transacciones no siempre es suficiente. Si la asignación de gas de una llamada interna se compiló en código inmutable, su propietario podría necesitar una migración a un nuevo contrato. Dicha migración puede implicar mover saldos, aprobaciones o permisos de usuario, y comunicar la nueva dirección. La dificultad depende del diseño del producto; no hay evidencia de que todos los contratos señalados requieran ese trabajo. Esto es precisamente por lo que la distinción entre un fallo solucionable mediante límites y un contrato potencialmente roto importa tanto para el equipo como para sus clientes.

La guía de pruebas es especialmente relevante para aplicaciones que usan abstracción de cuentas o múltiples llamadas a contratos para completar una acción del usuario. Un proceso de pago puede aprobar un activo, encaminar un intercambio y liquidar a un comerciante en una sola secuencia. Si un paso interno usa una asignación codificada de forma rígida, el cliente puede ver un pago fallido sin saber qué contrato alcanzó el límite. Reproducir toda la secuencia bajo las reglas propuestas es más informativo que verificar el método público de cada contrato de forma aislada. Los mantenedores deberían registrar el primer paso fallido y si un límite de gas externo mayor realmente cambia el resultado.

Los contratos también pueden comportarse de manera diferente tras una llamada fallida en lugar de simplemente detenerse. Un fallback que registra un evento, acredita un saldo interno o intenta una segunda ruta puede continuar bajo condiciones que sus autores originales nunca esperaron. Esa divergencia es la razón por la que un resultado de prueba descrito solo como "transacción exitosa" puede ser inadecuado. El estado de salida y los eventos deben compararse con la ejecución anterior. La categoría de la Fundación de ejecución exitosa con cambios captura esta posibilidad sin declararla automáticamente dañina.

Billeteras, RPC y fábricas enfrentan trabajos diferentes

Las billeteras y los proveedores de llamadas a procedimiento remoto estiman el gas que necesita una transacción antes de que un usuario firme. EIP-8037 dice que eth_estimateGas y el software de nodo deben tener en cuenta tanto el gas de ejecución como la nueva dimensión de gas de estado. Una constante antigua en caché puede subestimar una transacción con mucho estado. Los usuarios pueden entonces ver transacciones fallidas, incluso si el contrato funcionaría con un límite estimado adecuadamente. Las actualizaciones de infraestructura son, por lo tanto, parte de la compatibilidad, no meramente una conveniencia superpuesta al protocolo.

Las fábricas de despliegue determinista presentan otro caso limitado. EIP-8037 analiza fábricas colocadas originalmente en direcciones estándar usando transacciones prefirmadas con límites de gas codificados. En una red nueva que adopta el nuevo esquema antes de que exista la fábrica, el antiguo despliegue prefirmado podría quedarse sin gas. La propuesta dice explícitamente que las instancias ya desplegadas en la mainnet existente y en las redes de capa 2 no se ven afectadas por ese escenario de génesis particular. Informar la advertencia importa: sería engañoso sugerir que toda fábrica ya usada en Ethereum está a punto de desaparecer.

Los constructores también necesitan distinguir un contrato sin cambios de costos sin cambios. Una transacción puede tener éxito pero consumir una cantidad diferente de gas. Un negocio que agrupa despliegues o crea muchas ranuras de almacenamiento podría enfrentar una estructura de costos materialmente diferente incluso cuando ninguna función falla. Su producto podría necesitar cotizaciones de tarifas diferentes, una política de subsidios revisada o un cambio en cómo almacena la información. Las categorías de repetición de la Fundación separan la ejecución idéntica, la ejecución cambiada pero exitosa, las fallas solucionables con límites y los contratos potencialmente rotos precisamente por esa razón.

Las cifras en EIP-8037 merecen otra matización. Su ejemplo convierte el gas propuesto a ETH usando una tarifa base asumida de 0,08 gwei. Si la tarifa base cambia, el ETH pagado por el mismo gas también cambia. Un desarrollador que compare la tabla con una factura existente debe sumar los cargos de ejecución y las condiciones reales de la transacción, en lugar de presentar un cambio de costo de estado de siete veces como un aumento de siete veces en el pago completo de un usuario. El propósito de la propuesta es asignar costos a los recursos; la tarifa final de una persona depende de la mezcla de esos recursos en la transacción.

La escala del recálculo de precios propuesto debe leerse junto con el objetivo de capacidad. Más espacio para transacciones en un bloque puede hacer que la red sea costosa de validar si esas transacciones crean desproporcionadamente estado persistente. EIP-8037 asigna un medidor separado a ese crecimiento para que el costo no desaparezca dentro de un límite de gas titular más grande. EIP-8038 aborda los accesos al estado existente. Resuelven partes diferentes de la cuestión de los recursos, y un constructor de bloques que funcione por sí solo no puede establecer que las aplicaciones manejen correctamente el recálculo de precios.

Las listas de acceso de bloques de Ethereum tienen una tarea separada. Le dicen a los clientes qué cuentas y ubicaciones de almacenamiento toca un bloque, ayudando a organizar parte del trabajo de validación en paralelo. Eso puede permitir un mayor rendimiento bajo condiciones favorables, pero no borra el almacenamiento persistente añadido por nuevas cuentas y ranuras. Una testnet necesita ejecutar la actualización combinada bajo actividad realista porque una mejora en una dimensión puede exponer una restricción en otra. El aplazamiento deja ese ejercicio combinado de Hoodi sin hacer por ahora.

Muchos usuarios encontrarán estos cambios primero indirectamente, a través del límite de gas cotizado por su billetera o la estimación de tarifas de una aplicación. Una transacción que no crea nuevo estado puede tener un efecto diferente al de una que despliega un contrato considerable. Una interfaz de trading que promete un costo de transacción fijo necesitaría verificar si su promesa todavía cubre las operaciones que realiza. Las generalizaciones sobre que todas las tarifas de Ethereum se mueven en una sola dirección serían prematuras sin un calendario final de mainnet, demanda observada y los parámetros finales.

La cifra de 200 millones era una configuración de testnet

Glamsterdam combina más que el recálculo de precios. La separación proposer-builder consagrada cambia la entrega de la carga útil de un bloque, mientras que las listas de acceso a nivel de bloque ayudan a los clientes a identificar las cuentas y el almacenamiento que tocará un bloque. Los desarrolladores planeaban probar esos cambios con un límite de gas de Hoodi de 200 millones, igualando Sepolia. La cifra era un parámetro de testnet. Nunca fue una promesa de que la mainnet de Ethereum adoptaría inmediatamente el mismo límite o de que las tarifas de los usuarios caerían en un porcentaje determinado.

Eliminar el calendario de límite de gas de Hoodi mantiene unidos los componentes del fork pospuesto. Los operadores no estarán probando la capacidad superior prevista bajo Glamsterdam en esa red el próximo lunes. Los desarrolladores aún pueden usar Sepolia y redes de desarrollo creadas específicamente para investigar los efectos de la repreciación. El ensayo faltante en Hoodi afecta la secuencia en la que los equipos de clientes pueden ganar confianza antes de elegir una fecha para la mainnet, pero la Fundación no ha publicado un calendario de producción revisado.

La economía es menos sencilla que un eslogan sobre gas más barato. Cobrar más por crear estado duradero puede hacer que una transacción concreta sea más costosa al mismo precio de gas. Una mayor capacidad segura, si se adopta y utiliza más adelante, podría aliviar la congestión en otras condiciones. La demanda determina cuánto espacio de bloque pujan los usuarios, y la configuración final del protocolo determina qué operaciones se vuelven más o menos costosas. Ni la pausa ni una prueba exitosa resolverían por sí solas esas variables de mercado.

La coordinación pública tiene costos, pero proceder con una incertidumbre conocida puede tenerlos mayores. Los operadores prepararon software para la época anterior y ahora deben eliminar ese calendario; los desarrolladores de aplicaciones tienen que seguir probando contra una propuesta cuya forma final puede cambiar. El costo de ese reinicio es visible. Una regla de mainnet que hiciera fallar un contrato ampliamente utilizado sería más difícil de revertir, y las consecuencias podrían involucrar fondos o aplicaciones dependientes. El aviso del 22 de octubre no cuantifica tal riesgo, pero deja claro que los desarrolladores consideraron la interacción lo suficientemente importante como para detener el ensayo en Hoodi.

Una propuesta revisada podría preservar el objetivo de cobrar por el estado mientras cambia la forma en que funciona el reservorio de gas o las reglas de transición para los contratos existentes. Podría, en cambio, mantener la especificación y exigir correcciones específicas en las aplicaciones. Ninguna decisión pública entre esas rutas aparece en el aviso de aplazamiento. Los lectores deben resistirse a tratar una investigación como una elección de diseño final. Las enmiendas precisas, si las hay, importarán más que cuántos días espere Hoodi.

Por qué los desarrolladores eligieron esperar

El proceso de Ethereum permite a los equipos de clientes ajustar un plan antes de la activación en una testnet pública. La decisión del 22 de octubre en la llamada 248 de All Core Devs Execution sigue a advertencias previas y al contacto con los constructores afectados. El aviso público identifica el área bajo investigación pero no publica un recuento final de contratos en riesgo, una nueva versión de EIP-8037 ni una fecha en la que terminará la investigación. Llamar al retraso un defecto confirmado en todos los contratos desplegados iría más allá del comunicado; llamarlo un reajuste rutinario del calendario pasaría por alto su causa declarada.

La configuración anterior tiene que retirarse en ambas capas. Los clientes de ejecución procesan transacciones y estado, mientras que los clientes de consenso coordinan validadores y el calendario del fork. Una red solo puede probar la actualización si esos clientes coinciden en las reglas y los tiempos. Los operadores de Hoodi que instalaron versiones específicamente para el 26 de octubre deben buscar las notas de la versión revisadas. La Fundación dice que añadirá enlaces a las nuevas versiones de clientes a medida que se confirmen, en lugar de tratar su tabla de compatibilidad original como vigente.

También hay una lección en el orden de la evidencia. Reproducir el historial reveló un pequeño grupo afectado; las testnets públicas revelan el comportamiento de clientes y aplicaciones en un entorno real; la mainnet expone las reglas finales al uso económico a escala. Cada etapa responde algo que la anterior no puede. Un breve retraso en Hoodi puede ganar tiempo para el trabajo en los contratos, pero no prueba por sí mismo que las reglas eventuales sean seguras. La decisión de proceder debería seguir a los resultados de las pruebas y a instrucciones claras para los operadores.

Vale la pena detallar el alcance del aviso a los operadores. Un titular ordinario de mainnet no necesita cambiar una billetera porque se haya retirado el calendario de Hoodi. Un operador de nodo de Hoodi que se preparó para el fork sí necesita revisar las notas de la versión. Un ingeniero de protocolo que investiga la EIP necesita determinar si el comportamiento del contrato encontrado en las reproducciones es aceptable, corregible mediante herramientas o un motivo para alterar la propuesta. Un equipo de aplicaciones necesita probar sus propias rutas de ejecución. Son audiencias diferentes con plazos diferentes, y una sola alerta de "actualización retrasada" no da a cada una de ellas la instrucción correcta.

La próxima publicación de la Fundación también puede resolver cómo se comunicarán los desarrolladores con los equipos afectados. Su guía de agosto decía que había comenzado el contacto directo, pero un recuento de contactos por sí solo no establecería que un contrato fue reparado. La evidencia comprobable es un contrato actualizado, una configuración de gas revisada o un respaldo documentado para un producto concreto. Algunos contratos inmutables pueden requerir una migración de usuarios, lo que plantea una preocupación separada de comunicación y seguridad: los clientes deben saber dónde reside un reemplazo legítimo y evitar direcciones fraudulentas. No se ha anunciado ninguna migración masiva, así que esto sigue siendo una contingencia para equipos cuyo código no puede modificarse en el lugar.

Qué viene antes de otra fecha

Un calendario revisado debería indicar qué reglas de EIP-8037 se probarán, qué cambió si la propuesta se modifica, y qué versiones de cliente coinciden en la nueva época de Hoodi. Los mantenedores de aplicaciones necesitan tiempo para ejecutar búsquedas de contratos afectados, actualizar estimadores, elevar límites donde eso sea suficiente y examinar las asignaciones internas de llamadas codificadas de forma rígida donde no lo sea. Si un contrato desplegado potencialmente roto no tiene una ruta de actualización directa, su equipo podría necesitar explicar cómo los usuarios llegarán a un reemplazo antes de cualquier bifurcación de la red principal.

La evidencia pública incluiría la metodología de repetición y los hallazgos actualizados de contratos afectados, resultados de redes de desarrollo con el calendario final de gas, una activación de Hoodi con diversos clientes en acuerdo, y un anuncio separado de la red principal. Incluso una activación limpia de Hoodi sería un ensayo, no una garantía de un precio específico de ETH o de una tarifa final de transacción. La historia práctica para los usuarios es que no se ha anunciado ninguna acción en la red principal para el 26 de octubre. La acción inmediata corresponde a los operadores de Hoodi y a los equipos cuyas aplicaciones hacen suposiciones sobre el gas.

Qué observar

• Lanzamientos de clientes: Actualizaciones de ejecución y consenso que eliminen explícitamente la antigua activación de Hoodi del 26 de octubre.
• Hallazgos de EIP-8037: Nuevos resultados de repetición, cambios en las reglas de gas propuestas y el tratamiento de contratos con límites codificados o lógica de gasleft().
• Una época de reemplazo: Un plan de Hoodi con fecha que restaure una configuración testeable tras la investigación.
• Correcciones de aplicaciones: Informes de los constructores afectados que expliquen si los límites más altos son suficientes o si el código desplegado necesita otra ruta.
• Aviso de mainnet: Un calendario de producción distinto por parte de la Fundación después de la secuencia de testnet y la coordinación de clientes.

Preguntas frecuentes