Subnet Management - uzr34 (II)

[Lorimer]

@andrea kindly provided a reference for the recent urz34 (II system subnet) proposals here → Subnet Management - pzp6e (Fiduciary) - Developers - Internet Computer Developer Forum (dfinity.org)

@andrea

For the Schnorr keys, we are proposing to back them up on subnet uzr34, which has the same size as the fiduciary subnet and serves as backup subnet of the ECDSA production key. Note that the key backup process requires the backup subnet to pause while the key is being reshared. Since the proposed backup subnet hosts the II canister smart contract, this will not process new messages while the backup is in progress.

As this process is not yet fully automated, it requires 3 NNS proposals to be submitted, voted on, and executed in sequence. The result is downtime for the II subnet, estimated to be between 6-10 minutes

1. Proposal: 131506 - ICP Dashboard (internetcomputer.org)

   • “Halt subnet uzr34 at the next CUP height and update ssh readonly access. This is the first proposal (out of three) for resharing the threshold Schnorr keys Bip340Secp256k1:key_1 and Ed25519:key_1 from subnet pzp6e to subnet uzr34.”

2. Proposal: 131510 - ICP Dashboard (internetcomputer.org)

   • “Reshare the threshold Schnorr keys Bip340Secp256k1:key_1 and Ed25519:key_1 to subnet uzr34 by updating its recovery CUP. This is the second proposal (out of three) for resharing the threshold Schnorr keys Bip340Secp256k1:key_1 and Ed25519:key_1 from subnet pzp6e to subnet uzr34”

3. Proposal: 131511 - ICP Dashboard (internetcomputer.org)

   • “Unhalt subnet uzr34 and remove ssh readonly access. This is the third and last proposal for resharing the threshold Schnorr keys Bip340Secp256k1:key_1 and Ed25519:key_1 from subnet pzp6e to subnet uzr34”

I adopted the 1st and 3rd proposals, but rejected the update recovery CUP proposal, as discussed here. Nevertheless, I’m super excited to see these signature schemes used outside the context of the test key subnets