Robinhood Chain a continué à produire des blocs pendant la panne

Robinhood Chain a produit des blocs pendant toute la perturbation du 4 septembre, contrairement à un rapport antérieur qui affirmait que la production s’était interrompue pendant au moins 14 minutes. Glass Hull a comptabilisé 854 255 blocs sur les 1 440 minutes de la journée, avec un intervalle maximal de deux secondes entre les horodatages des blocs enregistrés. Pendant la minute débutant à 12 h 57 UTC, heure à laquelle l’arrêt supposé aurait commencé, le réseau a produit 592 blocs.

Pourquoi c’est important

La production continue de blocs ne signifie pas que les utilisateurs ont bénéficié d’un service normal. L’analyse de Walnut publiée le 23 septembre a révélé une forte baisse du trafic aboutissant à des transactions réussies via les applications très utilisées de Robinhood Chain, entre environ 12 h 37 et 13 h 20 UTC. Pendant cette baisse, l’application très utilisée médiane n’a effectué qu’environ un cinquième de son volume habituel de transactions réussies. Walnut a relevé des mises à jour retardées des oracles et des échecs de transactions via des smart wallets. Ces éléments suggèrent que certaines transactions soumises ont pu être perdues avant d’être incluses dans des blocs, même si les données publiques de la chaîne ne permettent pas de déterminer où le problème s’est produit.

Le rapport initial semble avoir confondu la production de blocs et la publication des données de transaction sur Ethereum. Glass Hull a mesuré deux interruptions de ces publications, de 12 h 29 min 47 s à 12 h 38 min 23 s UTC, puis de 12 h 42 min 47 s à 12 h 48 min 11 s UTC. Elles avaient toutes deux pris fin avant 12 h 57 et n’ont interrompu la production d’aucun bloc. Le relevé de disponibilité de L2BEAT fait état d’interruptions comparables dans l’envoi de données à Ethereum.

Impact sur le marché

QuickNode a commencé à enquêter sur une hausse de la latence du mainnet de Robinhood Chain à 13 h 10 UTC. Le service a ensuite averti les utilisateurs d’une possible dégradation des performances et d’échecs de transactions, le temps d’examiner des problèmes de connexion au flux du séquenceur. Ce relevé décrit le service de QuickNode, pas l’ensemble du réseau. Arbitrum a déclaré que la chaîne n’avait subi aucun temps d’arrêt et que les transactions directes des utilisateurs n’avaient pas été retardées, tout en reconnaissant un bref impact sur les performances de certains fournisseurs qui dépendent de son flux de données.

L’incident met en évidence une distinction importante pour les utilisateurs des réseaux de couche 2 : une chaîne peut continuer à produire des blocs alors que le trafic des applications ou les services des fournisseurs sont perturbés. Les données publiques confirment la perturbation des applications, mais ne permettent pas de déterminer précisément où la défaillance hors chaîne s’est produite ni son lien avec les interruptions de publication des données.