DKG trigger and chain reorgs

[lukasz-zimnoch]

Currently, the tECDSA DKG is triggered using a simple event listener acting on DKGStarted events. However, small chain reorgs may cause different startBlock to be received by DKG participants. That can lead to invalid signatures over the produced DKG result as the startBlock is one of the signature's components. We need to improve that. See discussion

[pdyraga]

An early idea on how we could approach it...

Things that may happen:

• The block is mined and DKGStarted event is emitted. Given the chain reorg, the block is dropped and DKG start transaction is not mined again. In this scenario, the client should not start the DKG.
• The block with DKGStarted event is emitted. The event is emitted twice with the same block number given the specifics of Ethereum gateway deployment. In this scenario, the client should ignore the second event.
• The block with DKGStarted event is emitted. The event is emitted twice with the same block number given the background event monitoring loop. In this scenario, the client should ignore the second event.
• The block with DKGStarted event is mined. Given the chain reorg, the block is dropped. A moment later, another block with DKGStarted event is mined. Two events were emitted in this scenario but the client should take into account only the second one.

Here is how can we approach it:

• DKGStarted event is emitted at block N. We start the monitoring goroutine and wait for 20 blocks.
• After 20 blocks, we check the DKG state. If it is not in progress, we leave.
• If DKG is in progress we take the last DKGStarted event emitted.
• We start the DKG based on the block number from the latest DKGStarted event.

In this approach, it may happen that the latest DKGStarted event has only 15 confirmations, for example. I think this is fine.

If we want to be more restrictive, we could:

• DKGStarted event is emitted at block N. We start the monitoring goroutine and wait for 20 blocks.
• After 20 blocks, we check the DKG state. If it is not in progress, we leave.
• If DKG is in progress we take the last DKGStarted event emitted.
• We wait until the event has 20 confirmations.
• Optional: We periodically double-check if DKG is in progress to not wait forever if 20 confirmations never happen because the block with the event was dropped.
• We start the DKG based on the block number from the latest DKGStarted event.