Ethereum apunta al 6 de octubre para Glamsterdam en Sepolia

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 calendario de Sepolia.

El plan de pruebas ha avanzado desde entonces una iteración más. Kim dijo el 11 de septiembre que la atención se había centrado en Glamsterdam-Devnet-11, cuyo lanzamiento está previsto para el lunes 14 de septiembre. Los planes anteriores habían identificado Devnet-10 como la siguiente prueba importante.

No se han confirmado fechas de activación para la red de pruebas Hoodi ni para la red principal de Ethereum. Los desarrolladores han discutido un posible lanzamiento en la red principal en diciembre, pero los resultados de las pruebas determinarán si ese calendario sigue siendo práctico.

Durante la reunión de desarrolladores principales de consenso del 3 de septiembre, los participantes acordaron la época 351232 de Sepolia para la activación propuesta. Kim informó que el tiempo 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 ofrece 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 la bifurcación si la siguiente fase de pruebas descubre un fallo importante o si los equipos de clientes no pueden preparar versiones 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, lo que la convertía en la mayor devnet de Glamsterdam por número de validadores en esa etapa.

La finalidad requiere que suficientes validadores estén de acuerdo sobre el estado de la cadena. Cuando una red de pruebas no logra finalizar, los desarrolladores deben determinar si la causa involucra el software del cliente, la participación de los validadores, la configuración de la red o una interacción entre cambios de protocolo separados.

Devnet-11 probará las correcciones antes de Sepolia

El plan original contemplaba Devnet-10 después de que aparecieran fallos durante las pruebas anteriores. La última actualización de Kim identifica ahora Devnet-11 como la siguiente prueba que los desarrolladores están observando, lo que indica que la secuencia de pruebas privadas avanzó más allá del plan anterior.

Un Devnet-11 estable darí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 funcionales antes de poder probar de forma segura sus sistemas contra la bifurcación propuesta.

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 limitado a una implementación puede interrumpir una red de pruebas cuando los validadores afectados tienen suficiente peso.

La agenda de ACDC #186 registra solicitudes de Lido y Optimism de al menos un día estable antes de una bifurcación. La agenda enumeraba las correcciones de clientes y la interoperabilidad exitosa como asuntos que requerían confirmación antes de Sepolia.

Un Devnet-11 fallido 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 desarrolladores principales.

Los errores de consenso y EIP-8037 ampliaron las pruebas

Las pruebas anteriores de Glamsterdam expusieron fallos en ambos lados de la arquitectura de Ethereum. El ingeniero de operaciones de desarrollo de la Fundación Ethereum, Stefan Starflinger, informó que Devnet-8 reveló un problema en la capa de consenso que involucraba 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 falta de finalidad, lo que llevó a los ingenieros a investigar más casos límite en un conjunto de validadores más grande.

En 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 nuevo estado, incluidas nuevas cuentas, contratos y entradas de almacenamiento.

EIP-8037 separa los costes de creación de estado de los costes de ejecución normales mediante un modelo de gas multidimensional. Su especificación publicada dice 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 bajo revisión por pares.

El problema descubierto requirió que los clientes de ejecución revisaran sus implementaciones y dio lugar a trabajo de especificación. EIP-8037 se ha probado junto con los demás 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 funcionan juntos en múltiples clientes, configuraciones de validadores y patrones de transacciones.

Las fechas de Hoodi y la red principal dependen de los resultados de las pruebas

Los desarrolladores se han negado a programar Glamsterdam en Hoodi mientras Sepolia siga siendo condicional. Se espera que Hoodi sirva como segunda etapa de red de pruebas pública, dando a los operadores de staking y a los equipos de protocolo otro entorno que represente más fielmente las condiciones de la red principal.

El desarrollador de Teku Enrico del Fante apoyó esperar antes de fijar la fecha de Hoodi. Durante ACDC #186, citó los recientes problemas de Devnet-9 y se mostró partidario de dar más tiempo de pruebas después de la decisión de Sepolia.

Una activación de la red principal en diciembre sigue siendo un objetivo posible, no una ventana de lanzamiento confirmada. Programar Sepolia para principios de octubre preserva suficiente tiempo de calendario para otra fase de red de pruebas pública y la preparación de versiones de clientes, siempre que las pruebas avancen sin retrasos prolongados.

Los desarrolladores no han publicado una época de red principal, una marca de tiempo de activación ni un calendario final de versiones de clientes. No se ha anunciado ningún plazo 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 tras las pruebas anteriores antes de decidir si Sepolia puede proceder según el calendario actual.