Dos parones en 48 horas: qué pasó con la red Base y por qué es una advertencia para Ethereum L2

Ese bloque inválido desencadenó un fallo de consenso: el secuenciador produjo un bloque inválido tras el bloque 47.806.542, bloqueando la capacidad de la red para construir más bloques. Los operadores de nodos no pudieron continuar con la sincronización normal hasta que se solucionó el problema.

Cronología de los dos parones

El segundo parón, ocurrido el 26 de junio, se describió como la misma clase de fallo en la producción de bloques que se repitió poco después del primer incidente, aunque la red se recuperó más rápido en esta ocasión.

Durante ambos periodos, la creación de nuevos bloques se congeló o detuvo, interrumpiendo el procesamiento normal de transacciones en la cadena. Sin embargo, se informó que ningún fondo de los usuarios estuvo en riesgo durante ninguno de los incidentes.

La solución aplicada

El equipo de ingeniería de Base aplicó un parche al secuenciador para garantizar que el estado del journal se actualice correctamente durante la ejecución después de una transacción fallida. La corrección se puede seguir en una solicitud de extracción (pull request) pública de GitHub (#3806).

Tras el parche, las operaciones normales se reanudaron, pero Base recomendó a los operadores de nodos validadores reiniciar o resincronizar sus nodos para restaurar el estado de sincronización. El equipo señaló que ambas interrupciones se originaron a partir del mismo error, y que un segundo problema relacionado (PR #3805) provocó que el incidente se repitiera al día siguiente.

Como consecuencia, Base retrasó un día el lanzamiento de su actualización planificada Beryl mainnet y la activación del estándar de tokens B20 para estabilizar la red.

Arquitectura de un solo secuenciador: una preocupación latente

Las interrupciones consecutivas reavivaron el debate sobre la resiliencia del diseño de un solo secuenciador de Base, común en muchos rollups optimistas, pero que introduce un claro punto único de fallo.

Las principales preocupaciones planteadas por el post-mortem y la cobertura del sector incluyen:

• Punto único de fallo: Un error a nivel de secuenciador en la lógica de construcción de bloques podría detener por completo la producción de bloques de Base, congelando la red entera.
• Recuperación manual: La recuperación requirió que los operadores de nodos validadores reiniciaran o resincronizaran sus nodos manualmente, en lugar de que la red se autocorrigiera.
• Riesgo de fiabilidad: Los fallos consecutivos plantearon nuevas preguntas sobre la fiabilidad del ecosistema L2, que está escalando rápidamente, especialmente durante periodos de alta actividad o actualizaciones programadas.
• Mejoras planificadas: Base anunció que reforzará sus pruebas con pruebas de fuzzing, pruebas de carga, monitorización y mejores herramientas de recuperación para reducir las probabilidades de que se repita.

El incidente demuestra que incluso las redes L2 más grandes de Ethereum pueden quedar fuera de línea por un caso extremo de gestión de estado en un único secuenciador, y que los sistemas automatizados de conmutación por error y recuperación siguen siendo una asignatura pendiente en el ecosistema de rollups.