Refactor DecryptionTrigger mechanism about rolling-shutter HOT 4 CLOSED

I still do not understand this issue. As far as I understand in the snapshot and gnosis case, the keypers could send out the decryption key shares based on time or the state of a blockchain. i.e. there is no need to send a DecryptionTrigger.

I suggest not using compile flags and instead build a dedicated binary for the different use-cases. We can share code by including the same subcommands where possible. I wouldn't mind having multiple keyper subcommands for the different use-cases.

from rolling-shutter.

I still do not understand this issue. As far as I understand in the snapshot and gnosis case, the keypers could send out the decryption key shares based on time or the state of a blockchain. i.e. there is no need to send a DecryptionTrigger.

This may just be a semantics issue.
There needs to be something that decides when / in which conditions to send the key shares. That is (IMO) what this issue is about. If that is actually using the DecryptionTrigger mechanism or something else isn't important as far as I'm concerned.

I suggest not using compile flags and instead build a dedicated binary for the different use-cases. We can share code by including the same subcommands where possible. I wouldn't mind having multiple keyper subcommands for the different use-cases.

Hm, I haven't really understood what the problem with compile flags is and what would be the advantage of splitting out nearly identical code to multiple binaries?
To me it sounds like it would lead to a lot of boilerplate duplication. E.g. when we have keyper-rolling, keyper-snapshot, keyper-gnosis, etc. commands each of them needs to have all the repetitive config, db, libp2p code (even if that is abstracted out into utility modules they still need to be initialized etc.).

from rolling-shutter.

At the moment the following code sends the decryption key shares:

This is being triggered by a p2p message send from the collator.

The keyper installs a handler for this message here:

In the snapshot case we may not need to listen for a p2p DecryptionTrigger message at all and just wait for a certain point in time before calling into SendDecryptionKeyShares. I fail to see how we can define a meaningful interface for the generation of the decryption key shares for both cases.

On the use of compile flags: I think it's better to have some duplication and put in meaningful abstractions where it makes sense instead of code that is sprinkled with if rollingShutter / if snapshotShutter / if ! gnosisShutter statements.

from rolling-shutter.

This is done.

from rolling-shutter.