Firo cale Spark Name sur une échéance réseau

Firo demande aux utilisateurs de mettre à jour wallets, nœuds et masternodes vers Firo v0.14.16.0 avant le bloc 1 329 000, attendu autour du 22 juin 2026. La publication GitHub du projet présente cette version comme obligatoire et indique qu’elle introduit la possibilité d’étendre la validité d’un Spark Name. Pour une chaîne spécialisée dans la confidentialité, le point n’est pas seulement cosmétique : il touche à la manière dont les identités lisibles, les clients et les opérateurs de nœuds restent synchronisés au moment d’une échéance de protocole.

Les Spark Names sont des alias lisibles par un humain associés aux adresses Spark, c’est-à-dire des adresses conçues pour préserver la confidentialité des transactions. L’idée est simple à décrire : remplacer une longue chaîne cryptographique par un nom plus facile à transmettre, tout en évitant que ce nom devienne une fenêtre ouverte sur l’historique de paiement. La mise à jour v0.14.16.0 ajoute, selon les notes de version, la capacité de prolonger la validité de ces noms et corrige aussi plusieurs détails de portefeuille, dont le rafraîchissement de la liste des Spark Names détenus par l’utilisateur.

L’enjeu concret est celui d’une transition propre. Quand une fonctionnalité liée aux noms, aux preuves de propriété ou aux règles de validité change, les clients qui restent en retard peuvent produire des comportements divergents, gêner les opérateurs de services ou créer de la confusion pour les utilisateurs. Firo insiste donc sur la mise à jour avant le bloc indiqué, avec une recommandation classique mais importante : sauvegarder le portefeuille avant l’installation. La présence de hachages SHA-256 pour les binaires Linux, macOS et Windows donne aussi aux opérateurs un moyen de vérifier ce qu’ils déploient.

Cette brève ne dit pas que Firo gagne une adoption nouvelle ni que Spark Names devient un standard. Elle signale plutôt un jalon d’exploitation : un réseau de paiement privé doit gérer ses fonctions d’usage courant avec la même rigueur que ses primitives cryptographiques. Pour les utilisateurs, le changement le plus visible sera la gestion de durée des alias. Pour les opérateurs, la priorité est plus prosaïque : mettre les logiciels à niveau avant que le réseau n’atteigne le bloc d’activation.