Nakamoto Signer[3.0] - A signer must be able to save multiple DKG aggregate key round states and load it where appropriate

jferrant commented 3 months ago

See: https://github.com/stacks-network/stacks-core/blob/5d2cbdd1ab6bd6cfde8f4528eb5fae5777037af5/stacks-signer/src/signer.rs#L1372

If signers see that a threshold has been reached and no approved key set, they may trigger a new DKG round. However, the key could have been approved but not yet set in the contract and this new round should be aborted once they read that it is actually set in the contract. However, they must also load the appropriate DKG shares associated with this successful round to successfully participate.

As part of this ticket, store DKG private shares per round. If DKG is set in the contract, abort any ongoing rounds and update state.

Overwrite local shares with the ones corresponding to the winning round (also be sure to update current_dkg_id to match)
If the signer has no shares for that DKG round, print a warning that it cannot participate in signing asit did not participate in the winning DKG round and ignore any incoming sign requests

netrome commented 3 months ago

Implementation note: We need to ensure the structure we store in StackerDB has a bounded size as discussed here https://github.com/stacks-network/stacks-core/pull/4659#discussion_r1560353035

netrome commented 3 months ago

If signers see that a threshold has been reached and no approved key set, they may trigger a new DKG round. However, the key could have been approved but not yet set in the contract.

So I'm working on an integration test for this, and I suspect that this scenario is not attainable in the current implementation. If the threshold has been reached, the vote has been concluded and the approved key must be set in the contract. This is happening in the same transaction, so there shouldn't exist an intermediate inconsistent state as I

Has this scenario been observed in practice? Am I missing something here? Ping @jferrant

That being said, I still think the feature of storing a few previous aggregate keys makes sense. There could potentially be other scenarios where a redundant DKG round is triggered. I'll see if I can figure out any good scenario to test.

netrome commented 2 months ago

Closing this ticket given that the premise has been invalidated, and recent discussions have lead to a different direction in the signer development.

saralab commented 2 months ago

We deprioritized this for a later time, is this still needed for when we kick off the WSTS work?

stacks-network / stacks-core

Nakamoto Signer[3.0] - A signer must be able to save multiple DKG aggregate key round states and load it where appropriate #4654