Los desarrolladores de Ethereum han confirmado una activación de Glamsterdam el 6 de octubre en Sepolia, al tiempo que advierten que el ether de prueba barato podría permitir a los constructores maliciosos ganar repetidamente subastas de bloques y retener sus cargas útiles de transacciones durante la fase de prueba pública.
La transcripción del Consenso de Todos los Desarrolladores Centrales 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 expresaron preocupaciones sobre cómo la Separación Incorporada de Proponente-Constructor (Enshrined Proposer-Builder Separation) podría comportarse en una red pública donde el ETH de prueba no tiene un costo económico significativo.
En el centro de la advertencia se encuentra la EIP-7732, el diseño de Separación Incorporada de Proponente-Constructor de Glamsterdam. Ethereum.org describe ePBS como un cambio de protocolo que separa la tarea de ensamblar cargas útiles de transacciones de los deberes de consenso del validador, trasladando una relación que actualmente depende en gran medida de infraestructura externa a las reglas de consenso de Ethereum.
Bajo este 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 que la respaldan. La especificación de consenso de Ethereum define a los constructores como actores participativos separados que envían pujas firmadas de cargas útiles de ejecución antes de difundir la envoltura de carga útil correspondiente.
Durante la llamada de desarrolladores del jueves, el desarrollador de consenso Potuz advirtió que la economía cambia en una red de prueba 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 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 red de prueba 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 en el bloque limita el comportamiento. El ETH de prueba hace que la interrupción persistente sea mucho más barata.
Las salvaguardias existentes podrían no ser suficientes para el entorno de Sepolia. Potuz dijo a los desarrolladores que algunos interruptores de circuito de clientes recurren a bloques construidos localmente solo después de que se pierden varias cargas útiles, mientras que él no estaba al tanto de protecciones universales que pudieran rechazar constructores abusivos individuales.
Su preocupación se centró en los atacantes que regresan bajo nuevas identidades. Incluso si un cliente reacciona a la falta de cargas útiles, los constructores desechables podrían seguir pujando a menos que la lógica defensiva identifique y restrinja el comportamiento lo suficientemente rápido.
Los desarrolladores no presentaron el ataque del constructor como un exploit confirmado contra Sepolia. La discusión se refería a 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 redes de prueba de Ethereum necesitan salvaguardias más sólidas porque los equipos de aplicaciones e infraestructura confían en ellas para probar el software contra bloques funcionales.
Ethereum.org señala que Sepolia utiliza un conjunto de validadores permisionados 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 da 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, y la fecha aún dependía de otra transición estable de devnet privada. La llamada de consenso del 17 de septiembre adelantó ese cronograma después de que Devnet-11 completara su ensayo de bifurcación programado.
Glamsterdam Devnet-11 fue creado como un ensayo controlado de “camino feliz” en lugar de una red de ataque adversario. Su especificación oficial programó el génesis para el 14 de septiembre, la transición Gloas para el 16 de septiembre y un aumento del límite de gas del bloque de 60 millones a 200 millones poco después.
La red de prueba utilizó 84,000 validadores en una configuración multicredencial y llevó el mismo conjunto central de EIP planificado para las pruebas de Glamsterdam. Sus organizadores excluyeron explícitamente ataques deliberados del alcance de Devnet-11, manteniendo los experimentos adversarios en el entorno de Platåberget, de mayor duración.
CoinDesk informó que Devnet-11 completó la transición y movió el límite de gas hacia los 200 millones sin perder la finalidad. La configuración de 200 millones es un parámetro de prueba, no un compromiso confirmado de límite de gas para 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. La 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 también incluye Listas de Acceso a Nivel de Bloque y una serie de cambios en la fijación de precios del gas. La cobertura anterior sobre compatibilidad con Glamsterdam informó que las billeteras, 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 gran cantidad de estado reciben un tratamiento de gas diferente bajo la bifurcación planificada.
Una revisión de riesgos de contratos inteligentes separada encontró que los contratos que utilizan estipendios de gas fijos o patrones de ejecución sensibles al gas pueden requerir pruebas antes de que la actualización llegue a la red principal.
El calendario del 6 de octubre da a los equipos de clientes menos tiempo de revisión del que recomienda el proceso normal de actualización de Ethereum.
Durante la llamada del 17 de septiembre, el desarrollador Fredrik Svantes dijo a los participantes que el proceso estándar requiere al menos 14 días entre el software cliente listo para su lanzamiento y la primera activación de la red de prueba pública. Dijo que esas dos semanas se utilizan normalmente para revisiones internas de seguridad, exposición a programas de recompensas por errores (bug bounties) 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 es relativamente centralizado y la red puede recuperarse más fácilmente si el software falla.
El desarrollador central 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 cronograma comprimido se produce después de varios problemas de prueba anteriores. Una agenda de desarrolladores del 3 de septiembre registró no-finalidad durante la activación Gloas de 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 prueba registró problemas en los que un escenario de Platåberget desconectó 12 de 13 nodos Besu y ralentizó los nodos Erigon y Ethrex. Devnet-9 experimentó no-finalidad no planificada, impulsando a los equipos a iteraciones adicionales antes de Devnet-11.
La hoja de ruta pública de Ethereum sigue listando 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 validador abierto para staking y pruebas de actualización. Los desarrolladores discutieron la etapa de Hoodi durante la llamada del 17 de septiembre, pero vincularon su calendario al progreso de Sepolia, lo que significa que los problemas en la primera red de prueba pública podrían mover fechas posteriores.
El borrador del plan de respuesta a incidentes de la red principal de Ethereum todavía no contiene ninguna época o marca de tiempo de activación. El documento, en cambio, deja en blanco los campos de información de la actualización mientras lista los roles de cliente y coordinación que se ocuparán antes del despliegue en la red principal.
Como informó la cobertura anterior de crypto.news sobre Glamsterdam, la actualización se centra en ePBS, las Listas de Acceso a Nivel de Bloque y la revalorización del gas diseñada para un mayor rendimiento de la Capa 1. Los desarrolladores han seguido tratando las pruebas multicliente exitosas como un prerrequisito antes de establecer la bifurcación de la red principal.
Por ahora, los equipos de clientes se enfrentan a la fecha límite del software del 29 de septiembre discutida en la llamada, seguida por la activación de Sepolia el 6 de octubre. Los desarrolladores de Ethereum no han publicado una época de la red principal o una marca de tiempo de activación final.
ETH