In the past weeks we proposed to generate test keys for Schnorr-BIP340 and Ed25519 on subnets 2fq7c and fuqsr. This allowed us to perform various tests, including the end-2-end key generation and xnet resharing protocols on mainnet. As this testing phase of threshold Schnorr is now concluded, we propose to move to the next phase and generate the “production” keys on mainnet on the fiduciary subnet pzp6e, which also holds the production ECDSA key. If proposal 131474 is accepted, the subnet will generate one BIP340 key and one Ed25519 key with key ID key_1.
A crucial step of releasing the production keys is to make sure they are also backed up in at least one other subnet. 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. We acknowledge this is less than ideal and will have some user-facing impact on apps that rely on II. However, this will not affect open sessions on dapps using II; only new sessions will be impacted. If proposal 131474 were successful, DFINITY would plan to initiate the backup process at 10 AM CEST (8AM UTC) on Tuesday 6th of August.
Is there no backup/replicated NNS canister that would failover if the main NNS canister is down for maintenance/updates? Maybe i’m thinking in traditional IT terms but important hardware always as a failover and syncs when the main one gets back up…
All canisters are replicated in all nodes of the same subnets, but not on other subnets by default. I am guessing this kind of replication can be done almost entirely on the application layer, however automatically redirecting users to other canisters may not be necessarily trivial.
The resharing of Schnorr keys from the pzp6e subnet to the uzr34 subnet was successful. The three proposals used in the process were 131506, 131510, 131511. After the last proposal was executed the subnet restarted operating normally. The total downtime of the subnet was of about 11 minutes.