Crypto Prices

Ethereum advierte sobre abusos de constructores en el testnet Glamsterdam

antes de 4 horas
3 minutos leídos
1 vistas

Activación de Glamsterdam en Sepolia

Los desarrolladores de Ethereum han confirmado la activación de Glamsterdam para el 6 de octubre en Sepolia, mientras advierten que el uso de ETH de prueba podría permitir que constructores maliciosos ganen repetidamente subastas de bloques y retengan sus cargas útiles de transacción durante la fase de prueba pública.

Preocupaciones sobre el EIP-7732

La transcripción de la reunión de consenso de Todos los Desarrolladores de Ethereum del 17 de septiembre muestra que los participantes aceptaron la fecha del 6 de octubre tras revisar los resultados recientes de la devnet de Glamsterdam. Sin embargo, los desarrolladores expresaron preocupaciones sobre cómo el diseño de Separación de Proposer-Builder Enshrined (EIP-7732) podría comportarse en una red pública donde el ETH de prueba no tiene un costo económico significativo.

«Solo puedo crear mil constructores», dijo Potuz, explicando que el atacante podría rotarlos, ofertar agresivamente y retener cargas útiles. Más tarde agregó: «Cualquier adolescente puede hacer esto».

En el centro de la advertencia se encuentra el EIP-7732, que establece la separación del trabajo de ensamblar cargas útiles de transacción de las funciones de consenso del validador, trasladando una relación que actualmente depende en gran medida de la 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.

Riesgos en el Testnet Público

Durante la llamada de desarrolladores, el desarrollador de consenso Potuz advirtió que la economía en un testnet cambia, ya que los atacantes pueden obtener ETH de prueba sin pagar su valor de mercado en mainnet. Un operador malicioso podría crear múltiples identidades de constructor, presentar ofertas muy por encima de las de competidores legítimos y luego negarse a proporcionar la carga útil prometida tras ganar.

El desarrollador enmarcó la preocupación como un problema de disponibilidad en el testnet público, no como una nueva forma de robar ETH de mainnet. En mainnet, un participante ya puede pagar para producir un bloque vacío, pero el costo económico de obtener espacio en el bloque limita este comportamiento. El ETH de prueba hace que la interrupción persistente sea mucho más barata.

Salvaguardias y Control Operativo

Las salvaguardias existentes pueden no ser suficientes para el entorno de Sepolia. Potuz indicó que algunos interruptores de circuito de cliente retroceden a bloques construidos localmente solo después de que se pierden varias cargas útiles, mientras que no estaba al tanto de protecciones universales que pudieran rechazar a constructores abusivos individuales.

Los desarrolladores no presentaron el ataque de constructor 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.

Desarrollo y Cronograma de Glamsterdam

Como se informó anteriormente, los desarrolladores habían seleccionado tentativamente el 6 de octubre antes de la última llamada, con la fecha aún dependiendo 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.

La 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. El EIP-7732 extiende la ventana de propagación de 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.

Desafíos en el Proceso de Actualización

El cronograma 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 que el proceso estándar requiere al menos 14 días entre el software de cliente listo para lanzamiento y la primera activación del testnet público.

El plan de respuesta a incidentes de mainnet de Ethereum aún no contiene ninguna época de activación o marca de tiempo. El documento, en cambio, deja en blanco los campos de información de actualización mientras enumera los roles de cliente y coordinación que se llenarán antes del despliegue de mainnet.

Los desarrolladores han continuado tratando las pruebas exitosas de múltiples clientes como un requisito previo antes de establecer la bifurcación de mainnet. 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.