@Dusk_Foundation La distance de récupération que je surveille réellement sur un nœud DUSK
À 03:17, le nœud était de retour dans le boîtier, mais toujours loin d’être utile. Rusk était installé, la configuration était là où je m’attendais à la trouver, et les clés n’avaient pas été touchées. Le point agaçant, c’était l’état. Le réseau avait continué à avancer pendant que cette machine, elle, ne bougeait pas.
C’est là que le fast-sync de DUSK m’intéresse. Pas parce qu’il ferait disparaître d’anciennes briques. Il fait quelque chose de plus pratique : il remplace l’état local de Rusk et la base de données de la chaîne par un état publié, puis laisse le nœud continuer à partir de là vers le point actuel.
J’ai commencé à voir le “gap” comme une distance de récupération. Si le snapshot se trouve à la hauteur S et que le réseau est déjà à T, alors T moins S représente le travail qui reste encore devant le nœud. Un snapshot plus récent peut réduire cette distance, mais il ne supprime pas le reste du chemin de récupération. Le téléchargement, c’est une étape. Redémarrer, trouver des pairs, avancer en hauteur et vérifier que ça continue d’avancer, ce sont d’autres étapes.
Il y a aussi un cas limite un peu gênant. Le fast-sync ne reconstruit pas les index d’archives à partir d’avant le snapshot ; ainsi, “récupéré” ne veut pas dire la même chose pour un nœud ordinaire et pour un service d’archive.
Ce que je veux surveiller ensuite n’est pas la taille du snapshot. C’est la façon dont la distance de récupération se comporte pendant une panne chaotique, quand le réseau continue d’avancer pendant que l’opérateur corrige encore les choses.#dusk $DUSK
À 03:17, le nœud était de retour dans le boîtier, mais toujours loin d’être utile. Rusk était installé, la configuration était là où je m’attendais à la trouver, et les clés n’avaient pas été touchées. Le point agaçant, c’était l’état. Le réseau avait continué à avancer pendant que cette machine, elle, ne bougeait pas.
C’est là que le fast-sync de DUSK m’intéresse. Pas parce qu’il ferait disparaître d’anciennes briques. Il fait quelque chose de plus pratique : il remplace l’état local de Rusk et la base de données de la chaîne par un état publié, puis laisse le nœud continuer à partir de là vers le point actuel.
J’ai commencé à voir le “gap” comme une distance de récupération. Si le snapshot se trouve à la hauteur S et que le réseau est déjà à T, alors T moins S représente le travail qui reste encore devant le nœud. Un snapshot plus récent peut réduire cette distance, mais il ne supprime pas le reste du chemin de récupération. Le téléchargement, c’est une étape. Redémarrer, trouver des pairs, avancer en hauteur et vérifier que ça continue d’avancer, ce sont d’autres étapes.
Il y a aussi un cas limite un peu gênant. Le fast-sync ne reconstruit pas les index d’archives à partir d’avant le snapshot ; ainsi, “récupéré” ne veut pas dire la même chose pour un nœud ordinaire et pour un service d’archive.
Ce que je veux surveiller ensuite n’est pas la taille du snapshot. C’est la façon dont la distance de récupération se comporte pendant une panne chaotique, quand le réseau continue d’avancer pendant que l’opérateur corrige encore les choses.#dusk $DUSK