Adoption imminente ? L'entreprise était responsable des temps d'arrêt de l'IOTA

Comme indiqué par le CNF, le réseau principal de l’IOTA est resté immobile pendant plus d’une demi-journée du 12 au 13 novembre. Bien qu’il y ait eu des rumeurs sur une cause possible de l’indisponibilité du Tangle, au moment de l’événement, il était clair qu’aucune étape n’avait été générée. par le coordinateur. Dans un article publié hier sur GitHub, la Fondation IOTA a maintenant fourni un rapport détaillé sur les événements.Selon cela, l’incident s’est produit le 12 novembre 2020 à 19h45 UTC et a été entièrement résolu le 13 novembre 2020 à 12h: 37 UTC. La raison pour laquelle le Tangle s’est arrêté était un test de spam initié par la communauté, par lequel le test était coordonné à l’avance avec la Fondation IOTA. Comme le déclare l’organisation derrière l’IOTA, « aucun changement de logiciel de nœud » ou de tout autre composant du réseau n’était responsable de l’incident. Pendant le test, le réseau a atteint plus de 1 000 TPS. Selon la Fondation IOTA, le réseau s’est effondré lors de la phase finale du test, lorsque « l’infrastructure hébergeant certains des composants critiques du réseau a atteint ses limites de traitement IOPS ». En termes de cause, la Fondation IOTA a en outre expliqué: L’infrastructure et par la suite le logiciel déployé n’ont pas été en mesure de traiter toutes les transactions entrant dans le réseau. Cela a conduit le coordinateur à émettre des jalons pour les transactions qui n’étaient pas persistantes en raison du goulot d’étranglement des E / S susmentionné.En raison de la charge sur le réseau dans son ensemble, le coordinateur n’a pas été en mesure de commérages les transactions nécessaires pour solidifier les jalons émis avant son arrêt, Pour résoudre l’incident, une nouvelle version de Hornet a été publiée le 13 novembre et l’infrastructure a été mise à jour vers la nouvelle version du logiciel du nœud. Selon la Fondation IOTA, l’incident et l’événement de spam précédent ont contribué à affiner les « protocoles de réponse » internes. Il a également appris que « les restrictions IOPS sur l’infrastructure autour du coordinateur doivent être améliorées ». En conséquence, un mécanisme de redondance a été mis en place pour assurer le stockage de toutes les transactions envoyées vers et depuis le coordinateur. De plus, un mécanisme a été mis en place pour s’assurer que le coordinateur réagit à l’état du réseau et interrompt automatiquement la sortie des jalons dans les situations où le coordinateur approche de la limite des ressources matérielles.

Détails du test de spam de la communauté IOTA

Via le canal Discord de l’IOTA, un organisateur du test de spam a également révélé plus de détails sur les spécifications du test. Selon cela, plus de 2 000 nœuds étaient utilisés. En moyenne, 1 892 nœuds ont été entièrement synchronisés pendant le test et répartis sur 24 emplacements différents dans le monde.En plus d’expliquer la procédure du test de spam, l’organisateur a également laissé entendre qu’il pourrait y avoir « un peu plus de retard » sur le test, en particulier un plus grande entreprise: il y a eu 3 vagues, 5 minutes environ 600-750, 5 minutes de pause pour calmer le réseau et potentiellement se synchroniser pour les nœuds externes, 10 minutes environ 1000TPS, encore 5 minutes de pause, puis en fait 30 minutes 1800-2000 Le TPS était prévu, mais ici les métriques de surveillance nous ont quittés et le problème mentionné nous a rattrapés. À part ces statistiques, que je ne trouve pas très intéressantes, peut-être une autre approche… n’est-il pas plus excitant de réfléchir à pourquoi quelqu’un ferait un tel test de spam ? Voilà pour ça: pas seulement pour le plaisir. Je veux dire que cela coûte de l’argent, beaucoup d’argent, vous ne pouvez pas simplement prendre ces ordres de grandeur de ressources. N’est-ce pas agréable de savoir qu’il y a un peu plus derrière ? ! Adaptation future en cours. Par conséquent, un petit merci à mon entreprise.