Impulsado por
Blockchain

La red Base se bloquea después de que un bloque no válido paralizara el secuenciador

La red principal Base de Coinbase estuvo inactiva durante casi dos horas el jueves después de que un bloque defectuoso bloqueara el secuenciador de la cadena y detuviera la producción de nuevos bloques.

ESCRITO POR
COMPARTIR
La red Base se bloquea después de que un bloque no válido paralizara el secuenciador

Puntos clave

  • La producción de bloques de la red principal de Base se paralizó durante casi dos horas el 25 de junio después de que el bloque n.º 47 806 542 provocara un fallo en el consenso.
  • El equipo de Base de Coinbase confirmó que todos los fondos están a salvo, que la secuenciación se restableció a las 17:51 UTC y que se sigue realizando un seguimiento continuo.
  • La bifurcación dura «Beryl» de Base, que introduce el estándar de tokens nativos B20, sigue prevista para su ventana de activación a las 18:00 UTC.

Qué ocurrió

El incidente comenzó a las 16:03 UTC del 25 de junio de 2026, cuando los ingenieros de Base detectaron una producción de bloques anómala en la red principal. A las 16:52 UTC, el equipo había identificado la causa principal: un problema de consenso provocó que el secuenciador generara un bloque inválido, concretamente el bloque n.º 47 806 542, lo que a su vez interfirió en la creación de todos los bloques posteriores.

En la terminología de OP Stack, el suceso se clasifica como un «bloqueo de cabeza inseguro». Esto significa que el secuenciador dejó de avanzar con los nuevos bloques por completo. La «cabeza insegura» se refiere a los últimos bloques producidos por el secuenciador que aún no se han publicado en la capa uno (L1) de Ethereum para su finalización.

Cronología:

  • 16:03 UTC: La producción de bloques se marca como anómala; comienza la investigación.
  • 16:52 UTC: Los ingenieros identifican el bloque n.º 47 806 542 como el origen del problema.
  • 17:21 UTC: Se aísla el problema de consenso; el secuenciador interno y los nodos muestran una recuperación preliminar.
  • 17:51 UTC: Se reanuda la secuenciación de bloques; los nodos internos comienzan a sincronizarse correctamente.
  • 17:58 UTC: Se confirma que la creación de bloques funciona correctamente; la red entra en fase de monitorización.

Qué significa esto para los usuarios

Los depósitos, retiradas y transacciones en Base se retrasaron durante el parón de aproximadamente dos horas. Los operadores de nodos que gestionan la infraestructura de Base deberán reiniciar sus nodos para recuperar por completo la sincronización.

X post on Base outage.
Fuente de la imagen: X

Los fondos no corren ningún riesgo. Los atascos de cabeza inseguros se producen antes de que los bloques se agrupen y se envíen a Ethereum L1, por lo que no hay riesgo de pérdida permanente ni de reorganizaciones significativas de la cadena.

La actualización Beryl sigue en marcha

El incidente coincidió con el hard fork programado de Beryl, cuya activación estaba prevista para las 18:00 UTC de ese mismo día. Base confirmó que el atasco no está relacionado con la actualización.

Beryl introduce B20, un estándar de tokens nativo integrado directamente en el software de los nodos en lugar de implementarse como un contrato inteligente, lo que hace que la emisión de tokens sea más eficiente para las stablecoins y los proyectos de activos del mundo real. La actualización también reduce los retrasos en los retiros e incorpora las mejoras de Reth V2. Los operadores de nodos deben ejecutar base/node v1.1.1 o una versión posterior. La mayoría de los usuarios y los contratos existentes no necesitan realizar ninguna acción.

Próximos pasos

Los ingenieros de Base siguen investigando la causa raíz del bloque no válido y tienen previsto publicar un análisis exhaustivo una vez concluida la revisión. La página de estado en status.base.org y el explorador de bloques basescan.org siguen siendo los principales recursos de supervisión.

Este tipo de atascos de cabeza inseguros se han producido anteriormente en otras redes de capa dos y en la red principal de Optimism, a menudo relacionados con condiciones de la infraestructura interna, problemas de los nodos de L1 o factores relacionados con la carga. Este incidente duró aproximadamente 115 minutos antes de que se reanudara la secuenciación.

Este artículo fue traducido del inglés mediante IA. La versión original en inglés es la fuente autorizada; las traducciones automáticas pueden contener imprecisiones, especialmente en la terminología legal y regulatoria.

Etiquetas en esta historia