Can we reason through FHE key rotation, to make sure this is the right change?

Am I correct in my interpretation that this relates to an FHEVM smart contract's state?

Procedural Scenario

1. FHEVM network is launched, with FHEPubKey-Alpha (generated by the KMS Core) and set as the FHEPubKey in the initial Smart Contract (SC)
2. User Data is encrypted to Ciphertext based on FHEPubKey-Alpha
3. Update Point FHEPubKey-Beta is generated by the KMS Core, and is now the preferred key
   4a. If the original SC updates the FHEPubKey to Beta, does the Ciphertext encrypted with Alpha become inoperable?
   4a.1 If yes to the above, should the proper procedure be to launch a new smart contract with the Beta key,.. IOW the FHEPubKey must remain immutable per contract
   4a.2 Also does there become a migration path for Ciphertext encrypted with Alpha to re-encrypt to Beta? Does the KMS Core need to retain both FHE Keys, so Alpha Ciphertext can be decrypted later?

You raise good questions. If we change the FHE key pair, ciphertexts under Alpha will have to be converted to ones under Beta. We discussed that we will be doing it on the fly, when we detect that input ciphertexts to an FHE operation are under different keys, i.e. we will do it lazily.

This PR only deals with not storing the hash of the public key in a global place in storage (not per smart contract). We did store the hash initially just to protect from accidental changes of the key on disk, nothing more to it. Idea was that there was a commitment to the key on-chain (though it isn't used by anyone right now). To make it simpler, we could just push the hash or the key itself anywhere publicly (even on-chain) and expect that clients check it. Doesn't have to be the node checking it (as it was before this PR).

What I meant is that this PR removes a "feature" that brought more complication than benefit in the current Go-based fhEVM. For key rotation in the future, we will implement it outside of this repo (most likely) and with proper design.