** Jinjin Finance Blockchain, 10 juin ** Un bogue dans le code de tri d'Arbitrum cette semaine a provoqué une brève interruption de la capacité du réseau à soumettre des transactions par lots, et les transactions n'ont pas pu être confirmées sur la chaîne principale. La vulnérabilité a depuis été corrigée et la fonction de soumission de lots de transactions a été restaurée. Le 10 juin, la Fondation Arbitrum a publié le rapport d'analyse après coup sur le bogue du trieur Arbitrum. Ensuite, examinons et voyons pourquoi cet événement de bogue n'a pas entraîné la perte des fonds des utilisateurs.
Chronologie de l'événement de bogue Arbitrum Sorter
À 06:04:53 le 7 juin 2023, l'émetteur du lot n'a pas réussi à mettre à jour sa vue d'état L1 en raison d'un problème temporaire avec le nœud L1 de l'assembleur Arbitrum. En raison d'un problème de cause racine, le trieur Arbitrum a continué à essayer d'interroger l'état de son numéro de bloc de vue L1 précédent. Cela signifie que même après la résolution du problème de nœud L1 temporaire, l'éditeur de lots continuera d'essayer d'interroger l'état de l'ancien numéro de bloc L1, et le nœud L1 n'a plus son état car il ne s'agit pas d'un nœud d'archive.
À 09 h 38 min 28 s le 7 juin 2023, l'affiche par lots d'Arbitrum a cessé de publier des transactions car elle a atteint la limite maximale de transactions en file d'attente configurée (256), qui est identique à la limite de mempool. Si cette limite n'est pas atteinte, la publication groupée se poursuivra comme d'habitude.
À 11h09 le 7 juin 2023, en raison de lots non publiés, une alerte a été déclenchée sur le contrat intelligent Sequencer Inbox pour vérifier les nouveaux lots, et un avertissement a été envoyé au canal Slack.
À 11 h 10, l'absence de versions récentes de lots a déclenché une alerte basée sur le journal et envoyé une alerte de niveau critique au canal Slack.
À 11 h 13, un membre de l'équipe communautaire a lancé PagerDuty avec un membre de l'équipe SRE, qui a rapidement reconnu l'incident et a commencé à réagir.
À 11 h 19 min 02 s, l'équipe SRE a redémarré l'affiche de lot, mais en raison de la limite maximale de transactions en file d'attente mentionnée précédemment, l'affiche de lot a été empêchée de publier des transactions. L'équipe SRE a remarqué ce problème et a commencé à passer à un fournisseur RPC L1 tiers pour tenter d'atténuer le problème.
À 11 h 24 min 16 s, 5 minutes après le début de l'affiche du lot, il a mis à jour la vue d'état L1 et publié le premier lot de transactions.
À 11 h 25 min 09 s, la configuration de l'affiche du lot a été modifiée pour utiliser un fournisseur RPC L1 tiers et redémarrée car l'équipe SRE avait déjà commencé à apporter cette modification et n'a pas remarqué le lot. Après un redémarrage, les transactions par lots continuent de se produire.
À 11 h 30 min 21 s, 5 minutes après le début de l'affiche du lot, la vue de l'état L1 a été mise à jour, ce qui a déclenché la désynchronisation de l'état L1, ce qui était également la cause première du problème. L'état L1 a été mis à jour avec le numéro de bloc final 17428199, mais il a utilisé le dernier nonce 178078, correspondant au dernier bloc à l'époque, au lieu du dernier bloc stocké dans son état, ce qui a entraîné l'effacement de toutes les transactions en file d'attente dans Redis Sauf, car Redis considère ces transactions comme confirmées.
À 11 h 30 min 26 s, l'affiche du lot a affiché un nouveau lot. Redis s'appuie sur la vue d'état L1 pour déterminer ce qu'il faut publier, mais à ce stade, la file d'attente Redis est vide, comme indiqué précédemment, l'état L1 est incorrect et un lot a été publié avec un nombre aléatoire dans l'état 178078, mais pour Déterminer le lot à publier, en utilisant un numéro de bloc non pertinent 17428199, ce qui a entraîné la publication d'un ancien lot avec un numéro de série de 229209, qui a en fait été publié à 11:24:16 avant, puis l'affiche du lot a redémarré. Étant donné que l'ancien lot 229209 a déjà été publié, la transaction L1 soumise par le lot a été annulée.
À 11 h 36 min 35 s, l'adresse de l'affiche du lot était à court d'éther parce qu'elle n'avait pas remboursé les frais de gaz, elle a donc cessé de publier. Il s'agit d'un mécanisme intentionnel pour empêcher l'affiche du lot de consommer tout le gaz stocké dans le coût du lot de récupération.
À 11 h 46, un membre de l'équipe Nitro a reçu un appel pour résoudre un problème logiciel avec la récupération par lots.
Vers 11 h 58, Arbitrum a commencé à recevoir des rapports indiquant que certains utilisateurs avaient constaté qu'il y avait un problème avec le trieur (diffusion des transactions nouvellement triées vers les nœuds RPC), car de plus en plus de transactions commandées étaient dues à des problèmes d'affichage par lots Plutôt que de publier à la chaîne, ce problème affecte principalement les clients de flux avec de mauvaises connexions Internet ou une allocation de mémoire insuffisante, car ils sont plus susceptibles de tomber et de rencontrer des problèmes de reconnexion. Arbitrum recommande aux utilisateurs exécutant plusieurs nœuds RPC d'exécuter un relais de flux local pour réduire la bande passante externe requise.
À 12 h 03, Arbitrum a supprimé la limitation du débit d'alimentation de Cloudflare pour atténuer le problème des clients atteignant la limite de débit lorsqu'ils tentent de se reconnecter après avoir été déconnectés en raison d'une connexion Internet.
À 12h05, Arbitrum a supprimé toutes les limitations de débit Cloudflare pour permettre une utilisation accrue du RPC public pour ceux dont les nœuds avaient du mal à maintenir les connexions au flux.
À 12 h 12 min 09 s, l'affiche de lot défectueuse a été arrêtée et le magasin de file d'attente Redis a été effacé pour supprimer l'état défectueux.
À 12 h 12 min 40 s, l'affiche du lot a démarré sur l'ancienne version v2.0.14 et il n'y avait pas de problème racine.
À 12 h 21 min 56 s, le premier lot d'affiches de lot nouvellement ouvertes a réussi, et elles ont fonctionné sans interruption depuis lors.
** Leçons tirées de l'événement de bogue du trieur Arbitrum **
Cet échec a été causé par un bogue dans l'affiche du lot. Le séquenceur lui-même n'a pas été affecté ou interrompu et a continué à traiter les transactions tout au long du processus. Les rapports indiquant que le séquenceur était à court de fonds sont incorrects. Le mécanisme de financement Arbitrum se compose de deux portefeuilles, à savoir : le portefeuille « séquenceur » et le portefeuille « rembourseur de gaz ». Ce n'est que lorsque le séquenceur peut libérer le lot avec succès qu'il sera remboursé. Le réseau Arbitrum n'a pas remboursé le séquenceur pour cela. les fonds et les problèmes connexes n'ont pas été causés par le séquenceur à court de fonds, donc aucun fonds d'utilisateur n'était en danger.
Arbitrum nettoiera les options de configuration qui ont été ajoutées dans la solution temporaire. Plus tard, il prévoit de réévaluer les problèmes de temporisation du client et du serveur du séquenceur afin d'améliorer la fiabilité du réseau en cas d'arriérés de transactions. Une nouvelle "v2.1.0- beta .2" version bêta. De plus, Arbitrum créera une page d'état du réseau public pour réduire la confusion en cas de problème avec le service.
Cet article est référencé sur le site officiel de la Fondation Arbitrum
Voir l'original
Le contenu est fourni à titre de référence uniquement, il ne s'agit pas d'une sollicitation ou d'une offre. Aucun conseil en investissement, fiscalité ou juridique n'est fourni. Consultez l'Avertissement pour plus de détails sur les risques.
Golden Observation | Examen de l'événement de bogue du trieur Arbitrum
Auteur: Golden Finance Jason
** Jinjin Finance Blockchain, 10 juin ** Un bogue dans le code de tri d'Arbitrum cette semaine a provoqué une brève interruption de la capacité du réseau à soumettre des transactions par lots, et les transactions n'ont pas pu être confirmées sur la chaîne principale. La vulnérabilité a depuis été corrigée et la fonction de soumission de lots de transactions a été restaurée. Le 10 juin, la Fondation Arbitrum a publié le rapport d'analyse après coup sur le bogue du trieur Arbitrum. Ensuite, examinons et voyons pourquoi cet événement de bogue n'a pas entraîné la perte des fonds des utilisateurs.
Chronologie de l'événement de bogue Arbitrum Sorter
À 06:04:53 le 7 juin 2023, l'émetteur du lot n'a pas réussi à mettre à jour sa vue d'état L1 en raison d'un problème temporaire avec le nœud L1 de l'assembleur Arbitrum. En raison d'un problème de cause racine, le trieur Arbitrum a continué à essayer d'interroger l'état de son numéro de bloc de vue L1 précédent. Cela signifie que même après la résolution du problème de nœud L1 temporaire, l'éditeur de lots continuera d'essayer d'interroger l'état de l'ancien numéro de bloc L1, et le nœud L1 n'a plus son état car il ne s'agit pas d'un nœud d'archive.
À 09 h 38 min 28 s le 7 juin 2023, l'affiche par lots d'Arbitrum a cessé de publier des transactions car elle a atteint la limite maximale de transactions en file d'attente configurée (256), qui est identique à la limite de mempool. Si cette limite n'est pas atteinte, la publication groupée se poursuivra comme d'habitude.
À 11h09 le 7 juin 2023, en raison de lots non publiés, une alerte a été déclenchée sur le contrat intelligent Sequencer Inbox pour vérifier les nouveaux lots, et un avertissement a été envoyé au canal Slack.
À 11 h 10, l'absence de versions récentes de lots a déclenché une alerte basée sur le journal et envoyé une alerte de niveau critique au canal Slack.
À 11 h 13, un membre de l'équipe communautaire a lancé PagerDuty avec un membre de l'équipe SRE, qui a rapidement reconnu l'incident et a commencé à réagir.
À 11 h 19 min 02 s, l'équipe SRE a redémarré l'affiche de lot, mais en raison de la limite maximale de transactions en file d'attente mentionnée précédemment, l'affiche de lot a été empêchée de publier des transactions. L'équipe SRE a remarqué ce problème et a commencé à passer à un fournisseur RPC L1 tiers pour tenter d'atténuer le problème.
À 11 h 24 min 16 s, 5 minutes après le début de l'affiche du lot, il a mis à jour la vue d'état L1 et publié le premier lot de transactions.
À 11 h 25 min 09 s, la configuration de l'affiche du lot a été modifiée pour utiliser un fournisseur RPC L1 tiers et redémarrée car l'équipe SRE avait déjà commencé à apporter cette modification et n'a pas remarqué le lot. Après un redémarrage, les transactions par lots continuent de se produire.
À 11 h 30 min 21 s, 5 minutes après le début de l'affiche du lot, la vue de l'état L1 a été mise à jour, ce qui a déclenché la désynchronisation de l'état L1, ce qui était également la cause première du problème. L'état L1 a été mis à jour avec le numéro de bloc final 17428199, mais il a utilisé le dernier nonce 178078, correspondant au dernier bloc à l'époque, au lieu du dernier bloc stocké dans son état, ce qui a entraîné l'effacement de toutes les transactions en file d'attente dans Redis Sauf, car Redis considère ces transactions comme confirmées.
À 11 h 30 min 26 s, l'affiche du lot a affiché un nouveau lot. Redis s'appuie sur la vue d'état L1 pour déterminer ce qu'il faut publier, mais à ce stade, la file d'attente Redis est vide, comme indiqué précédemment, l'état L1 est incorrect et un lot a été publié avec un nombre aléatoire dans l'état 178078, mais pour Déterminer le lot à publier, en utilisant un numéro de bloc non pertinent 17428199, ce qui a entraîné la publication d'un ancien lot avec un numéro de série de 229209, qui a en fait été publié à 11:24:16 avant, puis l'affiche du lot a redémarré. Étant donné que l'ancien lot 229209 a déjà été publié, la transaction L1 soumise par le lot a été annulée.
À 11 h 36 min 35 s, l'adresse de l'affiche du lot était à court d'éther parce qu'elle n'avait pas remboursé les frais de gaz, elle a donc cessé de publier. Il s'agit d'un mécanisme intentionnel pour empêcher l'affiche du lot de consommer tout le gaz stocké dans le coût du lot de récupération.
À 11 h 46, un membre de l'équipe Nitro a reçu un appel pour résoudre un problème logiciel avec la récupération par lots.
Vers 11 h 58, Arbitrum a commencé à recevoir des rapports indiquant que certains utilisateurs avaient constaté qu'il y avait un problème avec le trieur (diffusion des transactions nouvellement triées vers les nœuds RPC), car de plus en plus de transactions commandées étaient dues à des problèmes d'affichage par lots Plutôt que de publier à la chaîne, ce problème affecte principalement les clients de flux avec de mauvaises connexions Internet ou une allocation de mémoire insuffisante, car ils sont plus susceptibles de tomber et de rencontrer des problèmes de reconnexion. Arbitrum recommande aux utilisateurs exécutant plusieurs nœuds RPC d'exécuter un relais de flux local pour réduire la bande passante externe requise.
À 12 h 03, Arbitrum a supprimé la limitation du débit d'alimentation de Cloudflare pour atténuer le problème des clients atteignant la limite de débit lorsqu'ils tentent de se reconnecter après avoir été déconnectés en raison d'une connexion Internet.
À 12h05, Arbitrum a supprimé toutes les limitations de débit Cloudflare pour permettre une utilisation accrue du RPC public pour ceux dont les nœuds avaient du mal à maintenir les connexions au flux.
À 12 h 12 min 09 s, l'affiche de lot défectueuse a été arrêtée et le magasin de file d'attente Redis a été effacé pour supprimer l'état défectueux.
À 12 h 12 min 40 s, l'affiche du lot a démarré sur l'ancienne version v2.0.14 et il n'y avait pas de problème racine.
À 12 h 21 min 56 s, le premier lot d'affiches de lot nouvellement ouvertes a réussi, et elles ont fonctionné sans interruption depuis lors.
** Leçons tirées de l'événement de bogue du trieur Arbitrum **
Cet échec a été causé par un bogue dans l'affiche du lot. Le séquenceur lui-même n'a pas été affecté ou interrompu et a continué à traiter les transactions tout au long du processus. Les rapports indiquant que le séquenceur était à court de fonds sont incorrects. Le mécanisme de financement Arbitrum se compose de deux portefeuilles, à savoir : le portefeuille « séquenceur » et le portefeuille « rembourseur de gaz ». Ce n'est que lorsque le séquenceur peut libérer le lot avec succès qu'il sera remboursé. Le réseau Arbitrum n'a pas remboursé le séquenceur pour cela. les fonds et les problèmes connexes n'ont pas été causés par le séquenceur à court de fonds, donc aucun fonds d'utilisateur n'était en danger.
Arbitrum nettoiera les options de configuration qui ont été ajoutées dans la solution temporaire. Plus tard, il prévoit de réévaluer les problèmes de temporisation du client et du serveur du séquenceur afin d'améliorer la fiabilité du réseau en cas d'arriérés de transactions. Une nouvelle "v2.1.0- beta .2" version bêta. De plus, Arbitrum créera une page d'état du réseau public pour réduire la confusion en cas de problème avec le service.
Cet article est référencé sur le site officiel de la Fondation Arbitrum