I am marking this PR as a draft hoping for an internal review process before I open a PR to bnb-chain/tss-lib.
Generating DKG pre-parameters is a computationally expensive operation. As GeneratePreParams documentation explains, it is recommended to do it out of band. Keep ECDSA (TBTC) client has a pre-parameters pool from which the DKG process pulls pre-parameters to do not have the entire group wait with kicking off DKG until pre-parameters are generated. This approach was sufficient for TBTC v1 when signing groups were 3-of-3. For TBTC v2, we need much larger signing groups (51-of-100) and for clients having multiple seats in the signing group, generating multiple pre-parameters in a row eliminates other processes run by the client from the access to the CPU.
To fix this problem, we plan to run pre-parameters generator only when no other processes are currently executed by the client. That is, when the client would normally be idle, it will keep generating pre-parameters, and when the client starts a protocol execution (e.g. DKG), pre-parameters generation should be stopped.
GeneratePreParams allows specifying a timeout which is really helpful but is not enough in this case. We want to stop the generator immediately when some protocol is about to start.
To achieve it, the code has been refactored to accept a context as a parameter of all long-running generator functions. The context can be canceled or can be constructed in such a way that it times out after a certain time. To achieve backward compatibility, GeneratePreParams signature does not change and a new function accepting the context GeneratePreParamsWithContext has been introduced.
pdyraga
commented
2 years ago
Refs #3161
I am marking this PR as a draft hoping for an internal review process before I open a PR to
bnb-chain/tss-lib.Generating DKG pre-parameters is a computationally expensive operation. As
GeneratePreParamsdocumentation explains, it is recommended to do it out of band. Keep ECDSA (TBTC) client has a pre-parameters pool from which the DKG process pulls pre-parameters to do not have the entire group wait with kicking off DKG until pre-parameters are generated. This approach was sufficient for TBTC v1 when signing groups were 3-of-3. For TBTC v2, we need much larger signing groups (51-of-100) and for clients having multiple seats in the signing group, generating multiple pre-parameters in a row eliminates other processes run by the client from the access to the CPU.To fix this problem, we plan to run pre-parameters generator only when no other processes are currently executed by the client. That is, when the client would normally be idle, it will keep generating pre-parameters, and when the client starts a protocol execution (e.g. DKG), pre-parameters generation should be stopped.
GeneratePreParamsallows specifying a timeout which is really helpful but is not enough in this case. We want to stop the generator immediately when some protocol is about to start.To achieve it, the code has been refactored to accept a context as a parameter of all long-running generator functions. The context can be canceled or can be constructed in such a way that it times out after a certain time. To achieve backward compatibility,
GeneratePreParamssignature does not change and a new function accepting the contextGeneratePreParamsWithContexthas been introduced.