Los desarrolladores de Ethereum han confirmado una activación de Glamsterdam el 6 de octubre en Sepolia, al tiempo que advirtieron que el ether de prueba barato podría permitir a constructores maliciosos ganar repetidamente subastas de bloques y retener sus cargas útiles de transacciones durante la fase de prueba pública.
Resumen
- Los desarrolladores de Ethereum confirmaron que Glamsterdam se activará en Sepolia el 6 de octubre antes de una prueba posterior en Hoodi.
- Los desarrolladores advirtieron que el ether de prueba gratuito podría permitir a constructores desechables ganar pujas y retener las cargas útiles de ejecución.
- Se instó a los equipos de clientes a lanzar software listo para Sepolia antes del 29 de septiembre, dejando siete días de revisión.
- Devnet-11 completó su transición a Gloas y elevó los límites de gas de 60 millones a 200 millones.
- Ethereum no ha programado la activación de Glamsterdam en la red principal, con su hoja de ruta aún apuntando al cuarto trimestre de 2026.
La transcripción de la llamada de consenso de todos los desarrolladores principales de Ethereum del 17 de septiembre muestra que los participantes aceptaron la fecha del 6 de octubre después de revisar los resultados recientes de la devnet de Glamsterdam, aunque los desarrolladores simultáneamente plantearon preocupaciones sobre cómo la Separación Consagrada entre Proponente y Constructor podría comportarse en una red pública donde el ETH de prueba no tiene un costo económico significativo.
La prueba de Glamsterdam en Ethereum podría enfrentar ataques de constructores baratos
En el centro de la advertencia está la EIP-7732, el diseño de Separación Consagrada entre Proponente y Constructor de Glamsterdam. Ethereum.org describe ePBS como un cambio de protocolo que separa la tarea de ensamblar cargas útiles de transacciones de las obligaciones de consenso del validador, trasladando una relación que actualmente depende en gran medida de infraestructura externa a las reglas de consenso de Ethereum.
Según el diseño, los constructores pueden enviar pujas por el derecho a suministrar una carga útil de ejecución. Una vez que un proponente se compromete con la puja ganadora, se espera que el constructor libere las transacciones detrás de ella. La especificación de consenso de Ethereum define a los constructores como actores apostadores separados que envían pujas firmadas de carga útil de ejecución antes de transmitir el sobre de carga útil correspondiente.
Durante la llamada de desarrolladores del jueves, el desarrollador de consenso Potuz advirtió que la economía cambia en una testnet porque los atacantes pueden obtener ETH de prueba sin pagar su valor de mercado en la red principal. Un operador malicioso podría crear muchas identidades de constructor, enviar pujas muy por encima de los competidores legítimos y luego negarse a proporcionar la carga útil prometida después de ganar.
"Puedo simplemente crear mil constructores", dijo Potuz, explicando que el atacante podría rotarlos, pujar agresivamente y retener las cargas útiles. Más tarde añadió: "Cualquier adolescente puede hacer esto".
El desarrollador enmarcó la preocupación como un problema de disponibilidad de la testnet pública, no como una nueva ruta para robar ETH de la red principal. En la red principal, un participante ya puede pagar para producir un bloque vacío, pero el costo económico de obtener espacio de bloque limita el comportamiento. El ETH de prueba hace que la interrupción persistente sea mucho más barata.
Los clientes podrían necesitar interruptores automáticos a nivel de constructor
Las salvaguardas existentes podrían no ser suficientes para el entorno de Sepolia. Potuz dijo a los desarrolladores que algunos interruptores automáticos de clientes recurren a bloques construidos localmente solo después de que se pierden varias cargas útiles, mientras que no tenía conocimiento de protecciones universales que pudieran rechazar constructores abusivos individuales.
Su preocupación se centró en atacantes que regresan bajo identidades nuevas. Incluso si un cliente reacciona a cargas útiles faltantes, los constructores desechables podrían continuar pujando a menos que la lógica defensiva identifique y restrinja el comportamiento lo suficientemente rápido.
Los desarrolladores no presentaron el ataque de constructores como un exploit confirmado contra Sepolia. La discusión se centró en un escenario que esperan que las pruebas públicas puedan exponer una vez que los externos puedan participar bajo las condiciones de ePBS. Potuz argumentó que las testnets de Ethereum necesitan salvaguardas más fuertes porque los equipos de aplicaciones e infraestructura dependen de ellas para probar software contra bloques funcionales.
Ethereum.org señala que Sepolia utiliza un conjunto de validadores con permisos controlado por equipos de clientes y pruebas, mientras que Hoodi tiene un conjunto de validadores abierto destinado a pruebas de staking y protocolo. La estructura de Sepolia otorga a los desarrolladores de Ethereum más control operativo si la primera implementación pública de Glamsterdam de larga duración encuentra problemas.
Como informó previamente crypto.news, los desarrolladores habían seleccionado tentativamente el 6 de octubre antes de la última llamada, con la fecha aún dependiente de otra transición estable a una devnet privada. La llamada de consenso del 17 de septiembre adelantó ese calendario después de que Devnet-11 completara su ensayo de bifurcación programado.
Devnet-11 probó 200 millones de gas antes de Sepolia
Glamsterdam Devnet-11 se creó como un ensayo controlado de "camino feliz" en lugar de una red de ataque adversarial. Su especificación oficial programó el génesis para el 14 de septiembre, la transición de Gloas para el 16 de septiembre y un aumento del límite de gas por bloque de 60 millones a 200 millones poco después.
La red de prueba utilizó 84.000 validadores en una configuración multicliente y llevó el mismo conjunto de EIP centrales planeado para las pruebas de Glamsterdam. Sus organizadores excluyeron explícitamente los ataques deliberados del alcance de Devnet-11, manteniendo los experimentos adversariales en el entorno Platåberget, de mayor duración.
CoinDesk informó que Devnet-11 completó la transición y llevó el límite de gas hacia los 200 millones sin perder la finalidad. El ajuste de 200 millones es un parámetro de prueba, no un compromiso confirmado del límite de gas de la red principal.
La propia hoja de ruta de Glamsterdam de Ethereum dice que la actualización está diseñada para aumentar la capacidad de la Capa 1 mientras cambia cómo se construyen y verifican los bloques. EIP-7732 extiende la ventana de propagación de la carga útil de ejecución de aproximadamente dos segundos a alrededor de nueve segundos, dando a los nodos más tiempo para distribuir y validar cargas útiles más grandes.
La actualización incluye listas de acceso a nivel de bloque y una serie de cambios en el precio del gas también. La cobertura anterior sobre la compatibilidad de Glamsterdam informó que las carteras, los indexadores y los estimadores de gas que utilizan suposiciones fijas pueden requerir cambios porque la creación de nuevas cuentas y algunas operaciones con mucho estado reciben un tratamiento de gas diferente bajo la bifurcación planeada.
Una revisión de riesgos de contratos inteligentes separada encontró que los contratos que utilizan asignaciones fijas de gas o patrones de ejecución sensibles al gas pueden requerir pruebas antes de que la actualización llegue a la red principal.
La ventana de revisión de clientes de Sepolia se reduce a siete días
El calendario del 6 de octubre da a los equipos de clientes menos tiempo de revisión del que recomienda el proceso de actualización normal de Ethereum.
Durante la llamada del 17 de septiembre, el desarrollador Fredrik Svantes dijo a los participantes que el proceso estándar exige al menos 14 días entre el software de cliente listo para su lanzamiento y la primera activación pública en una testnet. Dijo que esas dos semanas normalmente se utilizan para revisiones de seguridad internas, exposición a recompensas por errores y posible trabajo de seguridad externo.
Con Sepolia acercándose, los desarrolladores discutieron una fecha límite del 29 de septiembre para los lanzamientos de clientes. Siete días entre el 29 de septiembre y el 6 de octubre dejarían la mitad del período de revisión normal. Los participantes aceptaron ese riesgo para Sepolia en parte porque su conjunto de validadores está relativamente centralizado y la red puede recuperarse más fácilmente si el software falla.
El desarrollador principal Alex Stokes instó a los equipos a lanzar el software antes cuando fuera posible para que más revisores pudieran examinarlo. Una vez que los clientes listos para su lanzamiento estén disponibles, pueden entrar inmediatamente en el proceso de recompensas por errores de Ethereum.
El calendario comprimido sigue a varios problemas de pruebas anteriores. Una agenda de desarrolladores del 3 de septiembre registró falta de finalidad durante la activación de Gloas en Devnet-8 que afectó a múltiples clientes de consenso, mientras que pruebas posteriores de Devnet examinaron correcciones y casos límite adicionales.
Otra llamada de pruebas registró problemas en los que un escenario de Platåberget dejó fuera de línea a 12 de 13 nodos Besu y ralentizó los nodos Erigon y Ethrex. Devnet-9 experimentó una falta de finalidad no planificada, lo que empujó a los equipos a más iteraciones antes de Devnet-11.
La activación de la red principal aún no tiene fecha confirmada
La hoja de ruta pública de Ethereum sigue incluyendo Glamsterdam para el cuarto trimestre de 2026, pero afirma que la fecha de la red principal no ha sido confirmada. El próximo hito publicado es la bifurcación de Sepolia del 6 de octubre.
Se espera que Hoodi siga a Sepolia porque proporciona un entorno de validadores abierto para pruebas de staking y actualizaciones. Los desarrolladores discutieron la etapa de Hoodi durante la llamada del 17 de septiembre, pero vincularon su momento al progreso de Sepolia, lo que significa que los problemas en la primera red de prueba pública podrían mover las fechas posteriores.
El borrador del plan de respuesta a incidentes de la red principal de Ethereum todavía no contiene una época de activación ni una marca de tiempo. En su lugar, el documento deja en blanco los campos de información de la actualización mientras enumera los roles de cliente y coordinación que se completarán antes del despliegue en la red principal.
Como informó anteriormente la cobertura de Glamsterdam de crypto.news, la actualización se centra en ePBS, las Listas de Acceso a Nivel de Bloque y la repreciación del gas diseñada para un mayor rendimiento de la Capa 1. Los desarrolladores han seguido tratando las pruebas exitosas con múltiples clientes como un requisito previo antes de establecer la bifurcación de la red principal.
Por ahora, los equipos de clientes enfrentan la fecha límite de software del 29 de septiembre discutida en la llamada, seguida de la activación de Sepolia el 6 de octubre. Los desarrolladores de Ethereum no han publicado una época de red principal ni una marca de tiempo de activación final.
