Bear in mind that a particular node isn't inherently associated with a particular on chain validator. Node X is only validator X because to happens to have the current session keys for that validator. A user could rotate the keys to another node, and that would become validator X a few sessions later. At least in theory node X could also be validator X and validator Y if it has the current session keys for both (this breaks finality signing, but it'll still make blocks as both validators).
Bearing that in mind, I think the offchain worker could do something like this:
- Make a WS RPC call (to any RPC node) to check the current ilst of
validators and their associated session keys (you could probably pull
it from raw storage with the HTTP RPC if you prefer).
- Use the HTTP RPC on the (local?) node to check if it has the keys for
each validator address in turn - there's an author_hasKey method
which I think would work (I'm pretty sure it tells you if the node
you are talking to has that key). There's an author_hasSessionKeys
too, which might be more useful - not sure.
- When you find a matching key, you know the local node is acting as
the validator for that key.
I'm pretty sure that would work. I'm not sure it's optimal.
If the offchain worker is using the HTTP RPC to insert keys, and they are then being assigned to the chain as validator keys, I suspect you are going to have some fun with security... You'd need to be sure someone external couldn't access the HTTP RPC and insert their own key, I think. (If both are on the same machine, or one can ssh into the other, you might be better off grabbing / inserting the private from/to the node keystore folder, rather than using the RPC. Indeed, with direct access to the keystore, you can just check the keys directly against the list of session keys - and it's probably quicker.
You'd potentially have to recheck every session - I think you could check ahead of the start of the session by looking at the queued keys list.
In case you aren't aware - when you update keys for a validator on-chain, they go into the pending session key list at the start of the next session, and then the active list at the start of the session after that - so it can take up to two sessions for the change to take effect. You might know that already.