In on-chain-dkg, we currently only subscribe to live DKG events, we don't backfill historic ones that happened before the subscription is created. This means a keyper who's node starts during a retry does not participate properly (e.g., they may not send a required apology or may consider other keypers as corrupt because they appear to not have apologized).
To fix this, we should backfill DKG events that happened since the start of the retry attempt. Events from passed retries or DKGs are irrelevant as the keyper won't participate in those anymore anyways.
The event syncing logic is generic and does not know about specifics of the DKG contract. We should preserve this property.
Current event syncing uses eth_subscribe. For backfilling, we have to use eth_getLogs and make sure there's no overlap.
What is unclear to me yet is how the consumer (in our case the DKG manager) communicates the backfill start block number to the event syncer and how it should receive backfilled events. We should make sure the consumer can process them in the correct on-chain order and, if they come through a channel, that the channel's buffer doesn't fill (e.g., by merging backfilled events into one channel item).
In
on-chain-dkg, we currently only subscribe to live DKG events, we don't backfill historic ones that happened before the subscription is created. This means a keyper who's node starts during a retry does not participate properly (e.g., they may not send a required apology or may consider other keypers as corrupt because they appear to not have apologized).To fix this, we should backfill DKG events that happened since the start of the retry attempt. Events from passed retries or DKGs are irrelevant as the keyper won't participate in those anymore anyways.
The event syncing logic is generic and does not know about specifics of the DKG contract. We should preserve this property.
Current event syncing uses
eth_subscribe. For backfilling, we have to useeth_getLogsand make sure there's no overlap.What is unclear to me yet is how the consumer (in our case the DKG manager) communicates the backfill start block number to the event syncer and how it should receive backfilled events. We should make sure the consumer can process them in the correct on-chain order and, if they come through a channel, that the channel's buffer doesn't fill (e.g., by merging backfilled events into one channel item).