Add new registration flow test to TSS side #997
Conversation
I think this makes sense since we're going to have a few test flows in there that utilize it.
The verifying key that's being used in there is wrong (we need to derive it), and it's easier to go through the registration flow ourselves due to the prereq that the network has been jumpstarted.
| rpc: &LegacyRpcMethods<EntropyConfig>, | ||
| signature_request_account: &Sr25519Keyring, | ||
| program_modification_account: subxtAccountId32, | ||
| program_instance: BoundedVec<ProgramInstance>, |
There was a problem hiding this comment.
i know this is just copied from the fn above, but i feel like this should be called program_instances
There was a problem hiding this comment.
Agreed. I'm not running the CI again to fix it in this PR though lol. Will do in a different one
| @@ -1471,3 +1599,25 @@ pub async fn get_sign_tx_data( | |||
|
|
|||
| (validators_info, generic_msg, validator_ips_and_keys) | |||
| } | |||
|
|
|||
| pub async fn jump_start_network( | |||
There was a problem hiding this comment.
i was gonna say 'don't we already have something like this?' but +1 for making it generic
| @@ -143,15 +143,6 @@ pub mod pallet { | |||
| version_number: T::KeyVersionNumber::get(), | |||
| }, | |||
| ); | |||
|
|
|||
| RegisteredOnChain::<T>::insert( | |||
There was a problem hiding this comment.
So no more pre-registered accounts
There was a problem hiding this comment.
For the moment no. I wrote a little thing out in the commit message removing this why it doesn't make sense to have them. tl;dr registration requires a jumpstarted network as a pre-req and that's a bit of a tricky setup using the Genesis config code.
It's something we might want to look at in the future if we find that manually setting everything up with extrinsics becomes cumbersome
| submit_transaction(api, rpc, &signature_request_account, ®istering_tx, None).await?; | ||
|
|
||
| // Since we're only submitting one request above, looking for the first event as opposed to | ||
| // say, all events, should be fine. |
There was a problem hiding this comment.
This is nice. But in our actual production client code we will still need a loop to filter out the events of other users, right?
While working on the signing flow I realized that there wasn't a test checking the new
registration flow on the TSS side (which is a pre-requisite to doing signing).
I've added a mostly happy-path test for registration. I don't really want to get bogged
down in checking all the failure scenarios until after the signing flow is done.