stacks-network
Nakamoto Signer[3.0] - A signer must be able to save multiple DKG aggregate key round states and load it where appropriate
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
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
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.
Closing this ticket given that the premise has been invalidated, and recent discussions have lead to a different direction in the signer development.
We deprioritized this for a later time, is this still needed for when we kick off the WSTS work?
