Rotate Bls keys PR missing historical storage for PubKeyHashToOperator

[iStrike7]

Hi,

Reference PR:
#249

How is the operatorStateRetriever's getOperatorFromPubkeyHash supposed to work with rotate bls keys PR?
In the current state of the PR won't it get the latest operator that is mapped to the pub key hash and not the operator that was using that pubKeyHash at the block the operatorStateRetriever is interested in?

Generally, there seems to be missing historical storage for PubKeyHashToOperator in the BlsApkRegistry...

Also, in the current state of the PR, multiple operators, at different times, may use the same bls keys? Is this intentional? Wouldn't this be problem if we wanted to know which operator to slash upon misbehavior of a pubKeyHash (operatorId) especially since we don't have historical storage?

I am concerned because I am implementing something that requires me to store the snapshot of the (relevant bits of the) registry contracts. And I was wondering if I should use the operator address as an identifier or the operatorId.
The current state of the PR suggests that I should use operator address. But since the operatorStateRetriever's getOperatorFromPubkeyHash issue will remain, you may introduce the missing historical storage for PubKeyHashToOperator.
It would be nice if you could comment on this (op address vs op Id) given eigenlayer's design philosophy/future decisions...

Thank you

[iStrike7]

Also, I noticed that the usual pattern followed in eigenlayer middleware contracts, that in history only one entry can correspond to a block number (subsequent updates in the same block cause an update in the same entry in history rather than a new one), is not followed here the PR. Is this intentional?
Isn't this antithetical to eigenlayer querying pattern and related guarantees? Which is especially a problem since getOperatorPubkeyHashAtBlockNumber returns the first entry with forward traversal of history, whereas querying the operatorPubKeyHash at that block number would return differently if two updates were made in the same block...

Edit: Seems to be addressed by #249 (comment)

[stevennevins]

Yeah that's a good point about updating the BLSOperatorStateRetriever to handle the key rotation changes

I would say you should use the operator address and then retrieve the operator Id with it when needed

Thanks for feedback!

[iStrike7]

Thanks a lot @stevennevins !!