Base ha explicado por qué su red principal dejó de producir bloques dos veces en dos días.
La red de capa 2 de Ethereum respaldada por Coinbase dijo que ambas interrupciones se debieron al 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 se mantuvieron seguros durante ambos incidentes.
En su análisis post-mortem oficial, Base dijo que una transacción inválida falló durante la ejecución, como era de esperar. El problema surgió después de ese fallo, cuando un estado de diario obsoleto permaneció dentro del constructor de bloques.
Ese estado obsoleto incluía cuentas y ranuras de almacenamiento afectadas por la transacción fallida. Cuando una transacción válida llegó a continuación, el sistema utilizó el estado de diario incorrecto y cobró el gas de forma errónea.
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 añadió que la producción de bloques se reanudó de forma segura después de la mitigación.
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 creció más allá de su capacidad de almacenamiento. Como resultado, las nuevas solicitudes de eth_sendRawTransaction devolvieron errores durante el período de interrupción.
La interrupción también afectó el progreso del secuenciador y del validador. Base dijo que estos nodos no pudieron avanzar más allá del bloque inválido hasta que se reanudó la secuenciación.
Como se informó anteriormente, Base señaló por primera vez una producción de bloques deficiente el 25 de junio antes de que los ingenieros aislaran un problema de consenso ligado a un bloque inválido.
Base dijo que solucionó el error principal aplicando un parche del secuenciador. El parche asegura que el estado del diario 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 tardó más 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 se repitió al día siguiente. Base dijo que el problema afectó a los secuenciadores, no a los nodos validadores, pero aun así ralentizó la recuperación.
La página de estado de Base mostró que la secuenciación se reanudó el 25 de junio. También indicó a los operadores de nodos del ecosistema que reiniciaran los nodos Base si seguían atascados.
Base dijo que fortalecerá las pruebas de fuzzing y las pruebas de carga del protocolo. Estos métodos ayudan a los equipos a encontrar patrones de transacción extraños que pueden exponer errores ocultos.
El equipo también planea una mejor monitorización y comprobaciones operativas. Dijo que estos cambios deberían ayudar a los ingenieros a detectar problemas similares antes y a responder más rápidamente.
Base también quiere añadir una recuperación elegante a base-consensus. Ese cambio facilitaría que los nodos validadores continúen sincronizándose después de fallos similares.
La interrupción se produjo durante una semana ajetreada para la red. Base también avanzó con su actualización Beryl, que añade el estándar de token B20 y reduce el período de retiro estándar de Base a Ethereum de siete a cinco días.
El incidente ofrece a los desarrolladores y usuarios una visión más clara del punto débil. Base ya ha nombrado el error, ha lanzado un parche y ha enumerado las pruebas que planea mejorar.
