Robinhood Chain siguió produciendo bloques durante la interrupción que afectó a sus aplicaciones el 4 de septiembre, pese a que los usuarios sí experimentaron dificultades para completar transacciones durante aproximadamente 40 minutos. Una medición posterior corrige así el informe inicial que apuntaba a una paralización de la producción de bloques durante al menos 14 minutos.
El análisis publicado por Glass Hull el 29 de septiembre contabilizó 854.255 bloques en los 1.440 minutos del día, según los datos registrados en la cadena. La mayor distancia entre dos marcas de tiempo consecutivas fue de apenas dos segundos. Además, en el minuto que comenzó a las 12:57 UTC —el momento señalado inicialmente como el inicio del supuesto parón— Robinhood Chain produjo 592 bloques.
La confusión entre producir bloques y publicar datos
El error procedía de mezclar dos procesos diferentes. El artículo publicado el 5 de septiembre había concluido que la cadena había dejado de producir bloques durante al menos 14 minutos. Sin embargo, Glass Hull identificó dos pausas separadas en la publicación de datos de transacciones de Robinhood Chain en Ethereum: una entre las 12:29:47 y las 12:38:23 UTC, y otra entre las 12:42:47 y las 12:48:11 UTC.
Ambos intervalos terminaron antes de las 12:57 UTC y no interrumpieron la generación de bloques. L2BEAT también recoge interrupciones comparables en los envíos de datos a Ethereum. En una red de segunda capa como Robinhood Chain, el proceso de creación de bloques puede continuar aunque se retrase el mecanismo encargado de publicar esos datos en la red principal.
La diferencia no es solo técnica. Una cadena puede mantener una actividad aparente normal en sus bloques mientras los servicios que utilizan los usuarios sufren problemas para enviar o confirmar operaciones.
Las aplicaciones sí registraron una caída de actividad
Un análisis de Walnut, publicado el 23 de septiembre, detectó una caída pronunciada del tráfico con transacciones completadas en las aplicaciones más utilizadas de Robinhood Chain entre las 12:37 y las 13:20 UTC. La aplicación mediana dentro de ese grupo completó aproximadamente una quinta parte de sus transacciones habituales durante el descenso.
Walnut interpretó los retrasos en las actualizaciones de los oráculos y los fallos de las transacciones de las carteras inteligentes como indicios de que algunos intentos de envío se perdieron antes de llegar a los bloques. No obstante, los datos públicos de la cadena no permiten determinar con precisión dónde se produjo el fallo.
QuickNode comenzó a investigar un aumento de la latencia en la red principal de Robinhood Chain a las 13:10 UTC. A las 16:20 UTC, el proveedor advirtió de que los usuarios podían encontrarse con un rendimiento degradado y con transacciones que no llegaban a registrarse, mientras analizaba problemas de conexión con el flujo de datos del secuenciador. El registro de QuickNode se refiere a su propio servicio, mientras que la medición de Walnut refleja el tráfico exitoso de las aplicaciones. Ambas observaciones describen dimensiones distintas de la incidencia.
El punto exacto del fallo sigue sin resolverse
En un comunicado del 4 de septiembre, Arbitrum afirmó que Robinhood Chain no había sufrido una caída y que las transacciones enviadas directamente por los usuarios no habían experimentado retrasos. La entidad sí señaló un impacto breve en el rendimiento de algunos proveedores que dependen del flujo de datos de la cadena, en un momento de elevada demanda entre los suscriptores de ese servicio.
Walnut plantea como hipótesis que una comisión baja del publicador de lotes quedó superada durante un repunte de las tarifas en Ethereum, lo que habría retrasado las publicaciones de datos. Glass Hull, en cambio, no determina la causa de esas pausas.
El registro disponible permite establecer dos hechos: Robinhood Chain continuó produciendo bloques y el tráfico de aplicaciones se deterioró durante unos 40 minutos. La relación exacta entre los retrasos en la publicación de datos, una posible cola del secuenciador y los problemas en las capas de acceso remoto sigue abierta.
