#708 does not require handling reorgs. This may, in rare cases, lead to some keypers having different views on which DKGs were successful and which ones failed, and with which result, resulting in keypers not participating during key generation later on.
A simple way to fix this is the following approach we've been following in other parts of the code:
- record the latest head
- on new heads, check that it's a descendant of the previously latest head
- if not, rollback the state a configurable number of blocks, corresponding to the deepest reorg we assume to happen
- replay the events from this block
The main challenge is to identify what exactly to roll back and how this affects other potentially running services. State to roll back includes DKG events, ECIES key registrations (both easy), success status, and DKG results (more difficult).
Note that we currently do not handle reorgs in the keyper set syncing logic. This is usually fine because during a reorg transactions are typically replayed across the branches (if there's no conflicts) and the exact time a KeyperSetAdded event occurs is not relevant to the keypers.
As part of this issue, we should consider consolidating the different event syncing logic currently in use in rolling shutter.
#708 does not require handling reorgs. This may, in rare cases, lead to some keypers having different views on which DKGs were successful and which ones failed, and with which result, resulting in keypers not participating during key generation later on.
A simple way to fix this is the following approach we've been following in other parts of the code:
The main challenge is to identify what exactly to roll back and how this affects other potentially running services. State to roll back includes DKG events, ECIES key registrations (both easy), success status, and DKG results (more difficult).
Note that we currently do not handle reorgs in the keyper set syncing logic. This is usually fine because during a reorg transactions are typically replayed across the branches (if there's no conflicts) and the exact time a
KeyperSetAddedevent occurs is not relevant to the keypers.As part of this issue, we should consider consolidating the different event syncing logic currently in use in rolling shutter.