Closed ok-john closed 9 months ago
Validators will not be changing their stash key as that's the identifier used by other users to nominate in NPoS (I don't think stash keys are even stored on the validator). Validators may change their controller key (using their stash key), in which case we need to either:
a) associate threshold keys with a stash key (where the threshold key can be updated by whichever controller key the stash key points to at the current time)
b) whenever the controller is updated via the stash key, we update the |controller_key| -> threshold_key
mapping.
The former seems much more straightforward as the latter might require a proxy extrinsic or hooks or something to make sure we don't get nonexistant mappings of new controller keys to threshold (and old controller to threshold), so I suggest that.
Okay, so your Stash key can change your Controller key, which can change your threshold key.
We aren't storing Stash keys on chain, and we shouldn't add an option to provide a stash key to a node in my opinion. Rather, a user should sign a transaction offline with their stash to update their controller key on the node. The new controller key could be generated offline with the transaction to update it and encrypted to the nodes public key or the node could generate a new controller key, send the public key to the user, who then signs a transaction verifying the new key is expected.
Okay, so your Stash key can change your Controller key, which can change your threshold key.
Exactly. It would also be inappropriate for a stash key to update a threshold key directly (as it would be inappropriate but possible for a CEO to go over a few managers to tell an intern what to do).
We aren't storing Stash keys on chain, and we shouldn't add an option to provide a stash key to a node in my opinion
Agreed, we should only provide the controller key to the node.
The new controller key could be generated offline with the transaction to update it and encrypted to the nodes public key or the node could generate a new controller key, send the public key to the user, who then signs a transaction verifying the new key is expected
This might be totally over-engineered, but another method could be to have the old controller key sign a message pointing to the new controller pub key, and then the other computer with the stash account could read the new controller account pub key from chain state (instead of authenticated encryption stuff).
We need a way to rotate threshold & controller keys on nodes without requiring the user to generate a new key/send it to the node. The current approach as discussed with @JesseAbram and @jakehemmerle is:
1) When a new node is created, generate keys and stored them in the encrypted kvdb. 2) Additionally, add a cli param for exporting a secret key from the kvdb if a user needs to migrate their keys to a new node. Including documentation that this is not to be used unless migrating/removing the kvdb. Alternatively, do not allow for secret key exporting from the database rather make users generate a new key and submit a signed transaction with the old key updating the new key one chain. (For example, the controller key would sign a transaction saying "this is the new threshold key"). 3) Add command line arguments for alice, bob, charlie, dave, eve and any other test accounts. (Make sure the README gets updated with the test keys). Use the substrate
subkey inspect --scheme sr25519 //{Alice,Bob,Charlie,Dave,Eve}
tool to get the dev keys instead of having build feature flags.