Una cadena de claves se vuelve a generar, pero eso no significa que la billetera ya se haya recuperado. En la documentación de Dusk para W3sper vi un aviso muy contundente: no uses directamente el nuevo Profile generado para construir una transferencia, porque no tiene los registros del Bookkeeper después de la sincronización; entonces no podrás obtener el saldo requerido ni el nonce. W3sper define muy claramente los límites: el cliente que firma por sí mismo, además de mantener un almacenamiento de claves recuperable, también debe gestionar el estado de los activos ya sincronizado, incluyendo el nonce de las cuentas públicas y las notas shielded. Este detalle separa “tengo la clave privada” de “puedo gastar ese dinero de forma segura”.
La presión suele ocurrir después de la recuperación. Si una aplicación borra los datos locales y regenera la identidad, pero la página aún muestra la cuenta original, el usuario naturalmente asumirá que todo ha vuelto a la normalidad; pero si la sincronización aún no se ha completado, la transferencia no puede construirse correctamente. Los activos no desaparecen, pero el usuario primero queda atrapado por un problema que parece un saldo o un fallo de red. Si los desarrolladores solo implementan la recuperación de claves y no muestran la recuperación del estado, dejan el costo de la depuración al usuario y al soporte. Esto no es una falla del protocolo de $DUSK ; al contrario, indica que el estado gastable de los activos shielded no puede sustituirse por una cadena de direcciones. @Dusk el ecosistema necesita mostrar por separado “identidad encontrada” y “estado de fondos sincronizado”, y bloquear explícitamente la transferencia hasta que se complete lo segundo. #dusk