Los desarrolladores de Ethereum han programado tentativamente la actualización Glamsterdam para su activación en Sepolia a las 13:53 UTC del 6 de octubre de 2026, mientras que aún es necesaria otra prueba en la red de desarrollo privada (devnet privada) antes de que se lleve a cabo el fork de la red de prueba pública (testnet pública).
Las notas de la reunión ACDC #186 y los informes posteriores de la investigadora de protocolo de Ethereum Christine D. Kim muestran que la fecha sigue siendo condicional. Los desarrolladores no habían completado una activación estable de Glamsterdam en una red de desarrollo privada cuando seleccionaron el cronograma de Sepolia.
Desde entonces, el plan de pruebas ha avanzado una iteración más. Kim dijo el 11 de septiembre que la atención se había centrado en Glamsterdam-Devnet-11, que se espera que se lance el lunes 14 de septiembre. Los planes anteriores habían identificado a Devnet-10 como la próxima prueba importante.
No se han confirmado fechas de activación para la testnet de Hoodi o la mainnet de Ethereum. Los desarrolladores han discutido un posible lanzamiento de la mainnet en diciembre, pero los resultados de las pruebas determinarán si ese cronograma sigue siendo práctico.
Durante la reunión del Consenso de Desarrolladores Principales (All Core Developers Consensus) del 3 de septiembre, los participantes acordaron la época 351232 de Sepolia para la activación propuesta. Kim informó que la hora correspondiente sería el 6 de octubre a las 13:53 UTC. La reunión se celebró antes de que los desarrolladores hubieran demostrado un rendimiento estable en las redes de prueba privadas utilizadas para Glamsterdam.
La selección de la época proporciona a los equipos de clientes, operadores de infraestructura y desarrolladores de aplicaciones un objetivo de planificación común. No hace que la activación sea definitiva. Los desarrolladores pueden posponer el fork si la siguiente fase de pruebas descubre un fallo importante o si los equipos de clientes no pueden preparar lanzamientos fiables.
La advertencia sigue siendo relevante después de que Devnet-9 experimentara problemas de finalidad. Según el material de la reunión, la red incluía aproximadamente 1.000 nodos validadores, convirtiéndola en la devnet de Glamsterdam más grande por número de validadores en esa etapa.
La finalidad requiere que suficientes validadores se pongan de acuerdo sobre el estado de la cadena. Cuando una red de prueba no logra finalizar, los desarrolladores deben determinar si la causa implica el software del cliente, la participación del validador, la configuración de la red o una interacción entre cambios de protocolo separados.
El plan original preveía Devnet-10 después de que aparecieran fallos durante las pruebas anteriores. La última actualización de Kim ahora identifica a Devnet-11 como la próxima prueba que los desarrolladores están observando, indicando que la secuencia de pruebas privadas avanzó más allá del plan anterior.
Una Devnet-11 estable proporcionaría a los equipos de clientes de Ethereum otro entorno para probar las especificaciones combinadas de Glamsterdam. Los equipos de Capa 2, los proveedores de staking y otros operadores de infraestructura necesitan implementaciones de cliente que funcionen antes de poder probar con seguridad sus sistemas contra el fork propuesto.
La diversidad de clientes hace que el proceso sea más complejo. Ethereum opera a través de varios clientes de ejecución y consenso desarrollados de forma independiente, y la actualización debe funcionar en diferentes combinaciones de clientes. Un fallo confinado a una implementación aún puede interrumpir una red de prueba cuando los validadores afectados tienen suficiente peso.
La agenda ACDC #186 registra solicitudes de Lido y Optimism para al menos un día estable antes de un fork. La agenda enumeró las correcciones de clientes y la interoperabilidad exitosa como asuntos que requieren confirmación antes de Sepolia.
Una Devnet-11 fallida o inestable no cancelaría automáticamente la activación del 6 de octubre. Los desarrolladores tendrían que evaluar la causa y el tiempo necesario para las reparaciones. Un problema grave podría llevarlos a reconsiderar la fecha durante una reunión de todos los desarrolladores principales.
Las pruebas anteriores de Glamsterdam expusieron fallos en ambos lados de la arquitectura de Ethereum. El ingeniero de operaciones para desarrolladores de la Fundación Ethereum, Stefan Starflinger, informó que Devnet-8 reveló un problema en la capa de consenso que implicaba bloques que repetían un hash padre.
“Se podría detener toda la red”, dijo Starflinger al describir el escenario de prueba.
El problema afectó al sistema responsable del acuerdo de bloques. Devnet-9 sufrió entonces una falta de finalidad, lo que llevó a los ingenieros a investigar más casos límite en un conjunto de validadores más grande.
Por el lado de la ejecución, la investigadora de la Fundación Ethereum, Maria Silva, informó de un problema de implementación relacionado con EIP-8037. La propuesta cambia la forma en que Ethereum cobra el gas por crear un nuevo estado, incluidas nuevas cuentas, contratos y entradas de almacenamiento.
EIP-8037 separa los costos de creación de estado de los costos normales de ejecución a través de un modelo de gas multidimensional. Su especificación publicada indica que el diseño busca controlar el crecimiento del estado a medida que Ethereum aumenta su límite de gas por bloque. La propuesta sigue en revisión por pares.
El problema descubierto requirió que los clientes de ejecución revisaran sus implementaciones y llevó a un trabajo de especificación. Como informó crypto.news en su cobertura del progreso anterior de Glamsterdam en la devnet, EIP-8037 ha sido probado junto con otros cambios de protocolo de la actualización.
Las pruebas tienen un propósito diferente al de aprobar cada propuesta individualmente. Los desarrolladores deben confirmar que todos los cambios seleccionados operan juntos en múltiples clientes, configuraciones de validadores y patrones de transacciones.
Los desarrolladores se han negado a programar Glamsterdam en Hoodi mientras Sepolia siga siendo condicional. Se espera que Hoodi sirva como la segunda etapa de la red de prueba pública, proporcionando a los operadores de staking y a los equipos de protocolo otro entorno que representa más fielmente las condiciones de la mainnet.
Enrico del Fante, desarrollador de Teku, apoyó la espera antes de fijar la fecha de Hoodi. Durante la ACDC #186, citó los recientes problemas de Devnet-9 y se mostró a favor de conceder más tiempo de prueba después de la decisión de Sepolia.
Una activación de la mainnet en diciembre sigue siendo un objetivo posible, no una ventana de lanzamiento confirmada. Programar Sepolia para principios de octubre conserva suficiente tiempo en el calendario para otra fase de la red de prueba pública y la preparación del lanzamiento del cliente, siempre que las pruebas avancen sin demoras prolongadas.
Los desarrolladores no han publicado una época de la mainnet, una marca de tiempo de activación o un cronograma final de lanzamiento del cliente. No se ha anunciado una fecha límite formal para decidir si el 6 de octubre sigue siendo adecuado para Sepolia.
El evento procesal inmediato es el lanzamiento previsto de Devnet-11 el 14 de septiembre. Los equipos de clientes examinarán la finalidad, el comportamiento entre clientes y las correcciones introducidas después de pruebas anteriores antes de decidir si Sepolia puede proceder según el cronograma actual.
ETH