The two SHA256 sums printed above from a) the downloaded CDN image and b) the locally built image, must be identical, and must match the SHA256 from the payload of the NNS proposal.
The two SHA256 sums printed above from a) the downloaded CDN image and b) the locally built image, must be identical, and must match the SHA256 from the payload of the NNS proposal.
This week’s release continues the rollout of our effort to reduce the latency of tECDSA signature requests. After upgrading to this version, the Internet Computer’s tECDSA signing subnets will require one less consensus round when answering signature requests. This week, we propose to upgrade the tECDSA production key subnets, which are:
uzr34: the backup subnet of Secp256k1:key_1
pzp6e: the signing subnet of Secp256k1:key_1
For compatibility reasons, we again propose to temporarily handle signature requests on the backup subnet, while the signing subnet is being upgraded. This switch will be made with additional update subnet proposals. In particular, the proposed rollout will be scheduled as follows, where each point represents a single proposal:
Upgrade backup subnet uzr34
Enable signing on uzr34
Disable signing on signing subnet pzp6e
Upgrade signing subnet pzp6e
Re-enable signing on signing subnet pzp6e
Disable signing on backup subnet uzr34
Note that while signing is handled on the backup subnet, signature throughput may be reduced.
At the time of this comment on the forum there are still 2 days left in the voting period, which means there is still plenty of time for others to review the proposal and vote independently.
We had several very good reviews of the Release Notes on these proposals by @Zane, @cyberowl, @ZackDS, @massimoalbarello, @ilbert, @Gekctek, and @hpeebles. The IC-OS Verification was also performed by @jwiegley and @tiago89. I recommend folks talk a look and see the excellent work that was performed on these reviews by the entire CodeGov team. Feel free to comment here or in the thread of each respective proposal in our community on OpenChat if you have any questions or suggestions about these reviews.
Can we get an update why this FAILED with “Rejection message: IC0503: Canister rwlgt-iiaaa-aaaaa-aaaaa-cai trapped explicitly: Panicked at ‘[Registry] Cannot retire versions {“88e489c293ce2d6ede5aef1866775ca7eab614a6”}, because they are currently deployed to a subnet!’, rs/registry/canister/src/mutations/do_update_elected_replica_versions.rs:153:13”
? Thanks.
We had a bug in the automation that publishes releases. As the message says, version is currently active on some subnets and therefore cannot be unelected.
We’re resubmitting the 128865 proposal because it failed. To avoid the proposal failing again, we have to empty the unelect_versions list since 88e489c293ce2d6ede5aef1866775ca7eab614a6 version is active on a subnet.
Looking back @ Proposal 128804 that also failed but a proposal to update unassigned nodes fixed the problem, I am curious if updating the subnets related would have solved the problem. Also what is the downside of not unelecting may that be one ore more prior versions ? Thank you.
Looking back @ Proposal 128804 that also failed but a proposal to update unassigned nodes fixed the problem
proposal Proposal 128804 failed because of similar bug where unassigned nodes version was not excluded from unelect nodes version. The bug we experienced with this week’s release proposal is slightly different.
I am curious if updating the subnets related would have solved the problem.
It would, but there’s a reason why the subnets are not yet upgraded. If you look at a thread from previous release, you’ll see that we had some issues on the last week’s release and as a result the rollout for previous release still did not finish.
Also what is the downside of not unelecting may that be one ore more prior versions ?
We would want to avoid updating to older versions because there are no strong guarantees that newer versions are backwards compatible with much older ones. For each new release we verify that the new versions is backwards compatible only with the latest version rolled out to mainnet. However, there’s very little downside to not unelecting an old version since anyhow all the upgrades go through governance. Unelecting versions is just used as an extra precaution to keep the possibility of untested upgrade proposal to a minimum.
Finally, as you may have guessed from what I explained above, unelect versions list we propose highly depends on the state of the mainnet. Last week when the proposal was placed, rollout was complete so we could unelect many versions that are not used anymore. This week however, the rollout is not yet finished so there are no versions that should be unelected.
The two SHA256 sums printed above from a) the downloaded CDN image and b) the locally built image, must be identical, and must match the SHA256 from the payload of the NNS proposal.
Ok cool, it’s all clear now, thank you so much for the detailed answer. So in a normal flow all the subnets would be updated before the replica update executes and would work normally as before. Thanks again.
Reviewers for the CodeGov project have completed our review of these replica updates. All reviews consisted of IC-OS verification only. There was one report of failing the IC-OS verification on the first attempt, but all others were successful.
At the time of this comment on the forum there are still 2 days left in the voting period, which means there is still plenty of time for others to review the proposal and vote independently.
The rollout was completed successfully and signing requests are again handled by the signing subnet pzp6e using the new implementation. Summary of all proposals: