Define behavior when eon is different that the keyper / config index

[ylembachar]

Summary

This is related to the malformed-config issue (link to be added). If config 14 is invalid and config 15 is accepted next, shuttermint would start eon 14 for keyperConfigIndex 15.

Some code appears to assume eon == keyperConfigIndex, for example: https://github.com/shutter-network/rolling-shutter/blob/main/rolling-shutter/keyperimpl/shutterservice/handlers.go#L40

Impact

A malformed intermediate config can force eon != keyper / config index, and it is currently unclear whether the system should support that state or how recovery should work.

Expected behavior

We should define what to do when eon and keyperConfigIndex become misaligned, especially as a follow-up to the malformed-config issue.

[jannikluhn]

I'm not aware of any code that assumes that the keyper config index must equal the eon. A mismatch is already expected if DKG fails and is retried, albeit only in the other direction.

Some code appears to assume eon == keyperConfigIndex, for example: https://github.com/shutter-network/rolling-shutter/blob/main/rolling-shutter/keyperimpl/shutterservice/handlers.go#L40

This is actually not true, the field on the message is just incorrectly named for backwards compatibility reasons. eon on key share messages and key messages always refers to the keyper set index. See here for the decryption keys message and here for the decryption keys message (the field is copied from the key shares message).

[blockchainluffy]

Confirmed!!
Majorly the Eon and KeyperConfigIndex are mismatched in gossip messages, database schema (specially, keyper core and gnosis impl still calls keyper config index as eon) and events from contract for add new keyper set, these are intentional and is used in right way.

[blockchainluffy]

The gossip message for decryption key sends the keyper set index in eon field. It would be good to check in shutter api codebase if this is handled correctly.

Additional info: the identity registered events have the eon field which is correctly treated in keyper code.

afair, Shutter API treats both of these as same

[blockchainluffy]

Shutter API currently doesn’t support multiple eon keys for the same keyper index and effectively treats the eon as the keyper set index (e.g., in register and getDataForEncryption). The eon key publisher contract also allows only a single eon key and publishes based on the keyper config index, not the actual eon ID.

Since the publisher contract can’t be changed after keyper finalization, supporting multiple keys would likely require a new contract or a mechanism to replace existing eon keys. Overall, contracts assume eon = keyper set index, even if Rolling Shutter uses a different eon ID.

The main inconsistency arises during identity registration, where we pass the keyper config index from shutter-api but it gets interpreted as the eon ID in Rolling Shutter. So, to make it consistent, we decided that the best would be to treat eon from identity registration event as keyper set index in rolling shutter and generate dec keys for latest eon for that keyper set index

issue for this: #692