Subnet Management - fuqsr (Application)

[Lorimer]

@andrea

@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.

Thanks for providing further context @andrea. I have some questions about CUP proposals:

• How should a community member go about verifying that the proposed CUP is valid? This is particularly relevant for manually created CUPs during subnet recovery.
• Why does key resharing require a catchup package? Is this simply to ensure that in a worst case scenario the subnet does not recover to an earlier state prior to acquring the key (thereby loosing the key)?
• Subnets create a CUP every epoch without halting and restarting. Why does the subnet need to be halted and restarted when resharing keys?

@andrea

I was not aware of these threads, but it sounds like a good idea in general.

Thanks @andrea, I’m looking forward to these sorts of proposals being announced on these threads in the future if that’s feasible