Une série de clés est régénérée, mais cela ne signifie pas que le portefeuille est déjà restauré. J’ai vu dans la documentation W3sper de Dusk une mise en garde très ferme : ne pas utiliser directement le nouveau profil généré pour construire un transfert, car il n’a pas les enregistrements de Bookkeeper après synchronisation ; il ne permet donc pas d’obtenir le solde et le nonce nécessaires. W3sper décrit très clairement la limite : le client qui signe lui-même, en plus de conserver un stockage de clés récupérables, doit aussi maintenir l’état des actifs déjà synchronisés, y compris le nonce des comptes publics et les notes shielded. Ce détail sépare “j’ai la clé privée” de “je peux dépenser cet argent en toute sécurité”.
La pression survient généralement après une restauration. Par exemple, si une application efface les données locales puis régénère une identité, la page affiche encore le compte d’origine ; l’utilisateur pense alors naturellement que tout est revenu. Mais si la synchronisation n’est pas terminée, le transfert ne peut pas être correctement construit. Les actifs ne disparaissent pas : l’utilisateur se retrouve d’abord bloqué par un problème qui ressemble à un solde insuffisant ou à une défaillance réseau. Si les développeurs ne font qu’une restauration de clés sans afficher la restauration d’état, ils reportent le coût de diagnostic sur l’utilisateur et le support client. Ce n’est pas un défaut du protocole $DUSK , au contraire : cela montre que l’état “déposable” des actifs shielded ne peut pas être remplacé par une simple chaîne d’adresse. @Dusk , l’écosystème a besoin de séparer l’affichage de “l’identité a été retrouvée” et celui de “l’état des fonds a été synchronisé”, et de bloquer explicitement les transferts tant que la seconde condition n’est pas terminée. #dusk