Ethereum advierte que la red de pruebas Glamsterdam enfrenta abuso de constructores

La transcripción de la reunión de desarrolladores principales de Ethereum del 17 de septiembre muestra que los participantes aceptaron la fecha del 6 de octubre tras revisar los resultados recientes de la red de desarrollo Glamsterdam, aunque los desarrolladores expresaron simultáneamente su preocupación por cómo podría comportarse la Separación Proponente-Constructor Consagrada en una red pública donde el ETH de prueba no tiene un coste económico significativo.

En el centro de la advertencia está el EIP-7732, el diseño de Separación Proponente-Constructor Consagrada de Glamsterdam. Ethereum.org describe ePBS como un cambio de protocolo que separa la tarea de ensamblar las cargas útiles de transacciones de las funciones 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 presentar ofertas por el derecho a suministrar una carga útil de ejecución. Una vez que un proponente se compromete con la oferta ganadora, se espera que el constructor publique las transacciones que la respaldan. La especificación de consenso de Ethereum define a los constructores como actores con participación separados que presentan ofertas 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 red de pruebas porque los atacantes pueden obtener ETH de prueba sin pagar su valor de mercado de la red principal. Un operador malicioso podría crear muchas identidades de constructor, presentar ofertas muy superiores a las de los competidores legítimos y luego negarse a proporcionar la carga útil prometida tras ganar.

«Puedo simplemente poner en marcha 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 planteó la preocupación como un problema de disponibilidad de la red de pruebas pública, no como una nueva vía para robar ETH de la red principal. En la red principal, un participante ya puede pagar para producir un bloque vacío, pero el coste económico de obtener espacio de bloque limita ese comportamiento. El ETH de prueba hace que la interrupción persistente sea mucho más barata.

Los clientes pueden necesitar disyuntores a nivel de constructor

Las salvaguardas existentes pueden no ser suficientes para el entorno de Sepolia. Potuz dijo a los desarrolladores que algunos disyuntores de los clientes solo recurren a bloques construidos localmente después de que se pierdan varias cargas útiles, y que no tenía constancia de protecciones universales que pudieran rechazar a constructores abusivos individuales.

Su preocupación se centraba en que los atacantes volvieran con identidades nuevas. Incluso si un cliente reacciona ante cargas útiles faltantes, los constructores desechables podrían seguir pujando a menos que la lógica defensiva identifique y restrinja el comportamiento con la suficiente rapidez.

Los desarrolladores no presentaron el ataque de constructores 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 personas ajenas puedan participar bajo las condiciones de ePBS. Potuz argumentó que las redes de pruebas 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 los equipos de clientes y pruebas, mientras que Hoodi tiene un conjunto de validadores abierto destinado a pruebas de staking y de protocolo. La estructura de Sepolia da a los desarrolladores de Ethereum más control operativo si el primer despliegue público de larga duración de Glamsterdam encuentra problemas.

Como informó anteriormente 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 de la red de desarrollo 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 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 por bloque de 60 millones a 200 millones poco después.

La red de pruebas utilizó 84.000 validadores en una configuración multicliente y llevaba el mismo conjunto básico de EIP planeado para las pruebas de Glamsterdam. Sus organizadores excluyeron explícitamente los ataques deliberados del alcance de Devnet-11, manteniendo los experimentos adversarios en el entorno Platåberget de mayor duración.

CoinDesk informó de que Devnet-11 completó la transición y movió el límite de gas hacia 200 millones sin perder finalidad. El ajuste 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 la forma en que se construyen y verifican los bloques. EIP-7732 amplía la ventana de propagación de la carga útil de ejecución de aproximadamente dos segundos a unos 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 la fijación de precios del gas. La cobertura anterior de compatibilidad con Glamsterdam informó de que los monederos, indexadores y 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 planificada.

Una revisión separada de riesgos de contratos inteligentes 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.

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 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 exige al menos 14 días entre el software de cliente listo para su lanzamiento y la primera activación en la red de pruebas pública. Dijo que esas dos semanas se utilizan normalmente para revisiones de seguridad internas, exposición a recompensas por errores y posible trabajo de seguridad externo.

Con Sepolia acercándose, los desarrolladores discutieron el 29 de septiembre como fecha límite 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 se rompe.

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ó no finalidad durante la activación de Gloas en Devnet-8 que afectó a múltiples clientes de consenso, mientras que las 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ó no finalidad no planificada, empujando a los equipos a más iteraciones antes de Devnet-11.

La activación en la red principal aún no tiene fecha confirmada

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 siguiente 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 calendario al progreso de Sepolia, lo que significa que los problemas en la primera red de pruebas 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 ninguna época o marca de tiempo de activación. 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 cubrirá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, Listas de Acceso a Nivel de Bloque y reajuste de precios del gas diseñado para un mayor rendimiento de la Capa 1. Los desarrolladores han seguido tratando las pruebas multicliente exitosas como un requisito previo antes de fijar la bifurcación de la red principal.

Por ahora, los equipos de clientes se enfrentan a 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.