Robinhood Chain no dejó de producir bloques durante la interrupción

Robinhood Chain produjo bloques durante toda la interrupción del 4 de septiembre, pese a un informe anterior que afirmaba que la producción se había detenido durante al menos 14 minutos. Glass Hull contabilizó 854.255 bloques a lo largo de los 1.440 minutos del día, con un intervalo máximo de dos segundos entre las marcas de tiempo de los bloques registrados. En el minuto que empezó a las 12:57 UTC, cuando supuestamente se habría iniciado la interrupción, la red produjo 592 bloques.

Por qué importa

Que la producción de bloques no se interrumpiera no significa que los usuarios tuvieran una experiencia normal. Un análisis de Walnut del 23 de septiembre reveló que el tráfico completado con éxito en las apps más activas de Robinhood Chain cayó bruscamente entre las 12:37 y las 13:20 UTC. Durante la caída, la app activa mediana completó alrededor de una quinta parte de sus transacciones habituales con éxito. Walnut señaló los retrasos en las actualizaciones de los oráculos y los fallos en las transacciones de smart wallets como indicios de que algunos envíos podrían haberse perdido antes de llegar a los bloques, aunque los datos públicos de la cadena no permiten determinar dónde se produjo el fallo.

Al parecer, el informe anterior confundió la producción de bloques con la publicación de datos de transacciones en Ethereum. Glass Hull midió dos pausas en esas publicaciones: de las 12:29:47 a las 12:38:23 UTC y de las 12:42:47 a las 12:48:11 UTC. Ambas terminaron antes de las 12:57 y ninguna detuvo la producción de bloques. El registro de actividad de L2BEAT recoge interrupciones similares en los envíos de datos a Ethereum.

Impacto en el mercado

QuickNode empezó a investigar el aumento de la latencia de la red principal de Robinhood Chain a las 13:10 UTC y más tarde advirtió que, mientras examinaba problemas de conexión con el flujo del secuenciador, los usuarios podían sufrir un rendimiento inferior y que sus transacciones no llegaran a incluirse. Ese registro describe el servicio de QuickNode, no la red en su conjunto. Arbitrum afirmó que la cadena no sufrió interrupciones y que las transacciones directas de los usuarios no se retrasaron, aunque reconoció un breve impacto en el rendimiento de algunos proveedores que dependen de su flujo de datos.

El incidente pone de relieve una diferencia importante para los usuarios de las redes de capa 2: una cadena puede seguir generando bloques mientras el tráfico de las apps o los servicios de los proveedores se ven afectados. Los datos públicos confirman la interrupción de las apps, pero no aclaran dónde se produjo exactamente el fallo fuera de la cadena ni cómo se relacionó con las pausas en la publicación de datos.