dkg

[JesseAbram]

Adds DKG to user signup, removing the CKG

Considerations for future PRs (there are task cards made)

• combine protocol function of dkg and signing to one function
• check that key makes sig in confirm done
• report validators not accepting key in send and receive key
• thread dkg

[vercel]

Someone is attempting to deploy this pull request to the entropyxyz Team on Vercel.

To accomplish this, the commit author's email address needs to be associated with a GitHub account.

Learn more about how to change the commit author information.

[ameba23]

This is great! Its a lot bigger than i was expecting, but now i see why all this stuff is needed.

So if i have understood right, the propagation pallet is back, and used so that the chain can inform the threshold servers of the 'registering group' for a particular user.

So now the user/new http endpoint called when registering is called by the offchain worker, not the user, and serves to let validators know whether they need to perform a DKG, or just wait to be sent a keyshare via user/receive_key.

This gets the thumbs up from me.

Just for clarity - if i've understood right DKG is now the only key generation method and it is no longer possible for the user to submit keyshares they generated themselves. The only place we use KeyShare::new_centralized is when mocking the key generation in tests.

Maybe once this is merged we will want do some renaming, eg:

• SigningMessage could now be ProtocolMessage (as it is no longer only used for signing)
• SigningErr -> ProtocolErr
• new_party/signing_protocol.rs -> protocol_execution.rs

My only other nit would be that execute_dkg and execute_protocol share a lot of common code and could maybe be refactored. That would definitely be something for another PR though.

Also - i never really understood the swap_keys stuff which is now commented out.

[JesseAbram]

This is great! Its a lot bigger than i was expecting, but now i see why all this stuff is needed.

ya, it seemed smaller to me but then when I got into it took a bit more.

So if i have understood right, the propagation pallet is back, and used so that the chain can inform the threshold servers of the 'registering group' for a particular user.

So now the user/new http endpoint called when registering is called by the offchain worker, not the user, and serves to let validators know whether they need to perform a DKG, or just wait to be sent a keyshare via user/receive_key.

Pretty much

This gets the thumbs up from me.

Just for clarity - if i've understood right DKG is now the only key generation method and it is no longer possible for the user to submit keyshares they generated themselves. The only place we use KeyShare::new_centralized is when mocking the key generation in tests.

Yup, as of now, there is an issue open talking if we should allow a ckg, but as of now dkg only

Maybe once this is merged we will want do some renaming, eg:

• SigningMessage could now be ProtocolMessage (as it is no longer only used for signing)
• SigningErr -> ProtocolErr
• new_party/signing_protocol.rs -> protocol_execution.rs

This all makes sense to me, wanna make a card for this in the projects board and feel free to take it on

My only other nit would be that execute_dkg and execute_protocol share a lot of common code and could maybe be refactored. That would definitely be something for another PR though.

Yup, I made a card to fix this, bogdan has an example of how it can be done in his tests in synedrion, just the PR is taking too long and blocking ppl, so It is in a refactor card, it would also help a lot when we add a proactive refresh

Also - i never really understood the swap_keys stuff which is now commented out.
It was for if a personal threshold key got compormised but as of now we don't have a personal threhsold key so we can decide to add it back in if we want later

[jakehemmerle]

Couple nits about code style and naming but otherwise lgtm.