Autora: KarenZ, Foresight News
En la madrugada del 26 de junio, hora de Beijing, Base dio al mercado una tranquila pero fundamental lección sobre infraestructuras.
La línea temporal de esta interrupción es clara:
- A las 00:03, Base informó de una anomalía en el estado de producción de bloques de su red principal y que el equipo estaba investigando.
- A las 00:52, Base determinó que el problema provenía de un bloque específico con errores, que interfería con la construcción de bloques posteriores.
- A las 01:21, Base ya había identificado un problema de consenso que provocaba la ordenación de un bloque inválido. Esto impedía la generación de nuevos bloques después del bloque 47806542. El secuenciador interno y los nodos se habían recuperado inicialmente.
- A las 01:51, se restauró la ordenación de nuevos bloques y la sincronización de los nodos internos era normal.
- A las 01:58, Base confirmó que la construcción saludable de bloques se había reanudado y que las infraestructuras del ecosistema podían recuperar la sincronización.
- A las 03:22, Base añadió que el secuenciador y los sistemas relacionados permanecían estables, los bloques se generaban con normalidad, y declaró que el equipo había identificado la causa raíz de esta interrupción, estaba validando la solución de reparación y publicaría un informe completo posteriormente.
La página de estado de Base muestra que este incidente afectó a los depósitos, retiros, producción de bloques y al software cliente de la red principal de Base.
Un único secuenciador activo hace que la interrupción sea más evidente
Base es un Rollup construido sobre Ethereum. Ejecuta una gran cantidad de transacciones en L2 y luego envía los datos necesarios y la información de estado relacionada a Ethereum.
Lo que los usuarios perciben directamente cada día no es el diagrama de arquitectura, sino si las transacciones pueden incluirse en un bloque, si los nodos pueden sincronizarse, y si las carteras, las transacciones y los servicios de puente pueden usarse con normalidad.
Antes del lanzamiento de Flashblocks, Base utilizaba un sistema de secuenciadores de alta disponibilidad: de 5 instancias de secuenciador, una actuaba como líder, responsable de construir bloques y propagarlos a través de P2P, mientras que las otras 4 funcionaban como seguidoras, sincronizando el estado de la cadena; si el líder actual dejaba de producir bloques, el sistema realizaba un cambio de liderazgo.
Este diseño demuestra que Base no carecía de redundancia. El problema es que la redundancia soluciona más la conmutación por error y la disponibilidad, y no equivale a que múltiples secuenciadores independientes participen simultáneamente en la producción de bloques. La producción diaria de bloques seguía siendo responsabilidad del líder actual, y una vez que surgían problemas en el consenso, la ordenación o la cadena de sincronización de nodos, lo primero que percibían los usuarios era que los nuevos bloques dejaban de avanzar.
Tras el lanzamiento de Flashblocks, la construcción de bloques en Base adquirió una capa adicional de mecanismo de preconfirmación de 200 milisegundos. La documentación de Base establece que Flashblocks está siempre activo en Base, y todos los bloques son construidos por el constructor de Flashblocks; las aplicaciones pueden elegir si usar los datos de preconfirmación o continuar esperando la confirmación estándar de bloques de 2 segundos a través de RPC. En otras palabras, Flashblocks ya es parte de la infraestructura para la construcción actual de bloques en Base, pero es opcional para que las aplicaciones accedan a la experiencia de preconfirmación.
La explicación de la página de estado de seguridad de Base es más específica: un problema de consenso provocó que se ordenara un bloque inválido, lo que a su vez impidió la generación de nuevos bloques después del bloque 47806542. La causa real aún debe esperar al informe completo oficial.
La anterior interrupción de Base se debió a la incapacidad de configurar un nuevo secuenciador
Esta no es la primera vez que Base interrumpe la producción de bloques debido a problemas relacionados con el secuenciador. El 5 de agosto de 2025, la red principal de Base experimentó una interrupción de red de 33 minutos. En el análisis posterior, el equipo oficial declaró que el secuenciador activo comenzó a mostrar retrasos debido a la actividad en la cadena, y el Conductor, responsable de la gestión del clúster de alta disponibilidad (HA), cambió automáticamente el liderazgo a un nuevo secuenciador; sin embargo, el nuevo secuenciador aún estaba en proceso de configuración en ese momento y no podía producir bloques, y como el Conductor aún no estaba completamente habilitado en ese secuenciador, el sistema no pudo iniciar el siguiente cambio. El equipo luego pausó manualmente la HA, transfirió el liderazgo a un secuenciador saludable y luego se recuperó por completo.
Al observar ambos incidentes juntos, se debe ser cauteloso: el problema de agosto de 2025 apuntaba al proceso de conmutación de alta disponibilidad del secuenciador, mientras que el incidente de interrupción de hoy se debió a un problema de consenso que provocó la ordenación de un bloque inválido e impidió la generación de nuevos bloques después del bloque 47806542.
Ambos apuntan a una realidad común: L2 puede depender de Ethereum para la disponibilidad de datos, liquidación, seguridad y finalidad, pero su disponibilidad diaria depende en gran medida del secuenciador y los sistemas de operación relacionados. Mientras no se puedan generar nuevos bloques, los usuarios ven que las transacciones se detienen en el camino.
Esta interrupción ocurrió cerca de la ventana de lanzamiento de B20
El momento del incidente es delicado. Base se encontraba entonces cerca de la ventana de actualización Beryl.
La hora de activación original de la red principal de Beryl era a las 02:00 del 26 de junio, hora de Beijing, y actualmente se ha pospuesto al 27 de junio a las 02:00.
El contenido central de Beryl incluye tres elementos: la introducción del estándar de token nativo B20, la reducción del período de confirmación final para retiros de prueba única de 7 a 5 días, y una reducción de hasta el 50% en el uso de espacio en disco y aproximadamente un 33% de mejora en el rendimiento gracias a Reth V2.
La diferencia de B20 está en su implementación subyacente. Mientras que la mayoría de los ERC-20 se implementan como contratos inteligentes EVM, B20 se implementa mediante un precompilado en Rust y se crea a través de la fábrica única B20Factory. También incorpora capacidades integradas como permisos de roles, límite de suministro, acuñación/quema, pausa, estrategias de transferencia, memo y permiso ERC-2612. En términos más simples, Base ha convertido muchas funciones básicas de tokens que los emisores construyen, auditan y mantienen repetidamente en una caja de herramientas a nivel de cadena.
B20 es lo que más fácilmente provoca asociaciones en el mercado, e incluso algunos usuarios de la comunidad lo asocian con la emisión de un token por parte de Base. Sin embargo, B20 discute "cómo otros pueden emitir activos de manera más estandarizada en Base"; la discusión sobre la emisión de un token por parte de Base se refiere a "si Base introducirá en el futuro su propio token de red".
Lo primero ya está incluido en la actualización Beryl, mientras que lo segundo sigue siendo un tema de interés del mercado que aún no ha sido anunciado oficialmente.
Esta interrupción hará que el debate sobre la emisión de un token por parte de Base se vuelva más realista. En el pasado, el mercado preguntaba: ¿Base emitirá un token?, ¿cuándo?, ¿cómo se distribuirá el airdrop? Después del incidente, vale la pena preguntar: si en el futuro realmente se introduce un token de red, ¿a qué responsabilidad corresponderá? ¿A la descentralización del secuenciador?, ¿a restricciones de gobernanza?, ¿al presupuesto de seguridad?, ¿o a la distribución de derechos y responsabilidades en la respuesta a incidentes?
