J’ai observé quelque chose en triant les tests de forks DUSK par le délai réseau P95. L’alerte de 500 ms semblait utile jusqu’à ce que je vérifie ce qu’elle détectait réellement.
Un seuil peut sembler précis tout en restant un faible prédicteur.
Pour DUSK Network, je ne jugerais pas uniquement la latence. Le ROC-AUC sur le délai P95, la perte de paquets et la disponibilité des validateurs compte, car chaque signal peut séparer différemment les rounds avec fork et sans fork. Ensuite, la matrice de confusion montre la partie que l’AUC peut masquer : fausses alertes, forks manqués, et à quelle fréquence un round à haut risque s’est en réalité révélé inoffensif.
Le seuil de 250 ms peut capter davantage d’événements de fork, mais inonder le système de bruit. À 750 ms, la précision peut s’améliorer tandis que le rappel s’effondre. La ligne des 500 ms se situe entre les deux, mais « équilibré » n’est pas automatiquement utile.
Ce qui compte pour DUSK, c’est le contrôle du risque par rapport au volume d’alertes, pas la latence contre l’absence de latence.
Je surveillerais aussi la hausse du risque de fork dans le quartile de latence le plus élevé. Si ce groupe ne montre pas une concentration significative de forks, la latence peut être corrélée, mais opérationnellement faible.
Mon doute discret est simple : la sécurité du token DUSK s’améliore-t-elle parce que l’alerte est statistiquement bonne, ou seulement lorsqu’elle détecte les rares événements qui comptent vraiment ?
@Dusk #dusk $DUSK
Un seuil peut sembler précis tout en restant un faible prédicteur.
Pour DUSK Network, je ne jugerais pas uniquement la latence. Le ROC-AUC sur le délai P95, la perte de paquets et la disponibilité des validateurs compte, car chaque signal peut séparer différemment les rounds avec fork et sans fork. Ensuite, la matrice de confusion montre la partie que l’AUC peut masquer : fausses alertes, forks manqués, et à quelle fréquence un round à haut risque s’est en réalité révélé inoffensif.
Le seuil de 250 ms peut capter davantage d’événements de fork, mais inonder le système de bruit. À 750 ms, la précision peut s’améliorer tandis que le rappel s’effondre. La ligne des 500 ms se situe entre les deux, mais « équilibré » n’est pas automatiquement utile.
Ce qui compte pour DUSK, c’est le contrôle du risque par rapport au volume d’alertes, pas la latence contre l’absence de latence.
Je surveillerais aussi la hausse du risque de fork dans le quartile de latence le plus élevé. Si ce groupe ne montre pas une concentration significative de forks, la latence peut être corrélée, mais opérationnellement faible.
Mon doute discret est simple : la sécurité du token DUSK s’améliore-t-elle parce que l’alerte est statistiquement bonne, ou seulement lorsqu’elle détecte les rares événements qui comptent vraiment ?
@Dusk #dusk $DUSK
