Are you able to give some further details on the background to these proposals?
I think these proposals could really do with elaborating the situation a little more in the summary
Hello both! Thanks for raising this, we will try to improve these proposal descriptions moving forward.
@Lorimer is correct in his assessment above. Here some additional context to these type of proposals:
Key generation
Key generation in a subnet happens with a single proposal, like 131391. When this proposal is executed, the registry canister adds the new key ID in the subnet record. Once the node see the new record, they engage in the key generation protocol.
Key Resharing
Key resharing between subnets is a bit more involved as the key material is delivered via catchup packages (CUP). Currently the only way to deliver a CUP to a subnet is by using the recovery proposal, which involves 3 steps:
- The subnet receiving the key is halted at a CUP height, like in 131433. This means that the subnet will continue until the next CUP is created and then it will stop.
- In the second step the registry is updated with a recovery CUP. If the proposal contains key IDs, like 131437, the registry will request the specified subnet to reshare the keys, and these shares are then included in the CUP. If the height of the CUP is larger than the height of the local CUP, then the nodes of the subnet will fetch it from the registry and store it locally.
- The subnet is then restarted, like in proposal 131438. The nodes will restart from the CUP with larger height. Once the subnet is operational again, the nodes will complete the key resharing protocol initiated by the other subnet and obtain a share of the key.
Regarding the current proposals (131449, 131450), the idea is to enable signing on the backup subnet to test that things work correctly there as well. This is the last test we planned, after which we could propose to generate (and backup) the production key. As a side note, switching subnets for the test key seems also a good idea in general because subnet 2fq7c is has a lot of canisters and thus may be better to offload the signing to subnet fuqsr for the foreseeable future.
Would it also be possible to provide a notice of these sorts of proposals on a dedicated topic for each subnet in the future e.g. Subnet Management - 2fq7c (Application) - Developers - Internet Computer Developer Forum (dfinity.org)
I was not aware of these threads, but it sounds like a good idea in general.