Base dice que el mismo error del secuenciador causó las interrupciones del 25 y 26 de junio

Base ha explicado por qué su mainnet dejó de producir bloques dos veces en dos días

Resumen

• El último postmortem de Base muestra que un error del secuenciador causó dos paradas de la mainnet en dos días consecutivos.
• Los fondos permanecieron seguros, pero las colas de transacciones se desbordaron mientras Base dejaba de producir nuevos bloques L2 temporalmente.
• El equipo planea pruebas de fuzz más sólidas, pruebas de carga, monitoreo y herramientas de recuperación después de la interrupción.

La red de capa 2 de Ethereum respaldada por Coinbase dijo que ambas interrupciones provinieron del mismo error en su lógica de construcción de bloques del secuenciador.

La primera interrupción comenzó el 25 de junio y duró aproximadamente 116 minutos. La segunda comenzó el 26 de junio y duró aproximadamente 20 minutos. Base dijo que los fondos permanecieron seguros durante ambos incidentes.

El error del secuenciador detuvo la producción de bloques

En su postmortem oficial, Base dijo que una transacción inválida falló durante la ejecución, como se esperaba. El problema surgió después de ese fallo, cuando el estado obsoleto del journal permaneció dentro del constructor de bloques.

El 25 y 26 de junio, la mainnet de Base experimentó dos interrupciones en la producción de bloques, ambas causadas por el mismo error subyacente en la lógica del constructor de bloques.

Hemos identificado y corregido la causa raíz, y hemos comunicado el post mortem a las cadenas OP como retroalimentación.

Todos los fondos estaban seguros… pic.twitter.com/eArnK12AgZ

— Base Build (@buildonbase) 27 de junio de 2026

Ese estado obsoleto incluía cuentas y slots de almacenamiento tocados por la transacción fallida. Cuando llegó una transacción válida a continuación, el sistema usó el estado del journal incorrecto y cobró gas incorrectamente.

Esto creó un bloque con una transición de estado inválida. Otros nodos no pudieron aceptar el bloque, por lo que la cadena dejó de producir nuevos bloques L2.

“La integridad de la cadena no se vio comprometida y todos los fondos en Base estaban seguros”, dijo Base.

El equipo agregó que la producción de bloques se reanudó de manera segura después de la mitigación.

Transacciones en cola durante la parada

Durante las interrupciones, los usuarios no pudieron incluir nuevas transacciones en la cadena. Base dijo que las transacciones se pusieron en cola en el mempool mientras la cadena esperaba que se recuperara la producción de bloques.

El pool de transacciones luego creció más allá de lo que podía almacenar. Como resultado, las nuevas solicitudes eth_sendRawTransaction devolvieron errores durante la ventana de interrupción.

La parada también afectó el progreso del secuenciador y del validador. Base dijo que estos nodos no podían avanzar más allá del bloque inválido hasta que el secuenciamiento regresara.

Como se informó anteriormente, Base primero señaló una producción de bloques no saludable el 25 de junio antes de que los ingenieros aislaran un problema de consenso vinculado a un bloque inválido.

El parche corrigió el problema del estado obsoleto

Base dijo que corrigió el error principal aplicando un parche al secuenciador. El parche asegura que el estado del journal se actualice correctamente durante la ejecución después de una transacción fallida.

El equipo también encontró un segundo problema durante la recuperación. Base dijo que la mitigación tomó más tiempo porque una condición de carrera en la función de reinicio del motor impidió que los secuenciadores se pusieran al día después del reinicio.

Ese segundo problema ayudó a explicar por qué el incidente regresó al día siguiente. Base dijo que el problema afectó a los secuenciadores, no a los nodos validadores, pero aún así ralentizó la recuperación.

La página de estado de Base mostró que el secuenciamiento se reanudó el 25 de junio. También indicó a los operadores de nodos del ecosistema que reiniciaran los nodos de Base si aún estaban atascados.

Pruebas y cambios de recuperación planificados

Base dijo que fortalecerá las pruebas de fuzz del protocolo y las pruebas de carga. Estos métodos ayudan a los equipos a encontrar patrones de transacciones extraños que puedan exponer errores ocultos.

El equipo también planea un mejor monitoreo y controles operativos. Dijo que estos cambios deberían ayudar a los ingenieros a detectar problemas similares antes y responder más rápido.

Base también quiere agregar recuperación gradual a base-consensus. Ese cambio facilitaría que los nodos validadores continúen sincronizándose después de fallos similares.

La interrupción ocurrió durante una semana ocupada para la red. Base también avanzó con su actualización Beryl, que agrega el estándar de token B20 y reduce el período estándar de retiro de Base a Ethereum de siete días a cinco días.

El incidente brinda a los desarrolladores y usuarios una visión más clara del punto débil. Base ahora ha nombrado el error, lanzó un parche y enumeró las pruebas que planea mejorar.