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.
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 second feature release (IC NNS Proposal 128806) introduces the first part of our feature 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. Initially, we propose to only upgrade the tECDSA test key subnets, which are:
fuqsr; the backup subnet of Secp256k1:test_key_1
2fq7c; the signing subnet of Secp256k1:test_key_1
For compatibility reasons, we 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 rollout will be scheduled as follows, where each point represents a single proposal:
Enable signing on fuqsr
Upgrade backup subnet fuqsr
Disable signing on signing subnet 2fq7c
Upgrade signing subnet 2fq7c
Re-enable signing on signing subnet 2fq7c
Disable signing on backup subnet fuqsr
Note that if signing is enabled on two subnets, requests are handled by the subnet that signing was enabled on first.
Just to double-check: the Proposal 128806 elects a version that includes the changes from the Proposal 128805 too.
This means that the new p2p for consensus will also be enabled with 128806’s version. Is it intentional?
Yes, this is intentional. p2p is already rolled out to all subnets except NNS, so it wouldn’t make much sense to exclude some of those subnets for this release.
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, 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.
Just a brief side note, we’re not discussing a new “protocol feature”, but refer to the change as a “feature” due to internal Jira-related nomenclature.
This change does not alter the functionality, but significantly improves the existing one: the ECDSA signatures requested by the canister will now take less time to complete. We want to deploy it to a separate subnet first because the amount of code changes is substantial and we want to roll it out in the safest possible manner.
Proposal 128804 failed since we had a bug in the new version of release automation. Specifically, there was a version proposed to unelect which was still active on unassigned nodes. Since the unassigned nodes got upgraded today, we’ll resubmit proposal 128804 exactly as it was proposed and adopted before.
As you may have noticed, there was an issue with the new version that was being rolled out and a subnet recovery was necessary on two subnets (cv73p and 4ecnw) yesterday:
We have a hotfix for the issue, and I will soon send a proposal with the hotfix.
In addition, we noticed another critical problem with the pjljw subnet which manifests in the finalization rate on subnets reducing over time. The hotfix will include a fix for that problem as well, and it would be really good to urgently roll out the hotfix to all affected subnets, to avoid bigger incidents.
Will there be a post mortem regarding this incident? I’d like to get a deeper understanding of what caused it and how the hotfix addresses it.
For instance, I’ve noticed the proposed build has reverted some components of the P2P stack to the legacy ones, why was this necessary?
So just to be clear both Fixes were in the same commit ? Thanks .
Yes, all fixes are in the same commit. We did this to save CI time. Going through the entire CI testing suite takes multiple hours.
Will there be a post mortem regarding this incident? I’d like to get a deeper understanding of what caused it and how the hotfix addresses it.
There will certainly be a post mortem internally, yes. We can also make a public post mortem if there is enough interest. Please react to this message if you would like to have this.
For instance, I’ve noticed the proposed build has reverted some components of the P2P stack to the legacy ones, why was this necessary?
It was not necessary, but it was again done just for technical reasons, to save the CI time.
This will be one of the primary topics for improvements in the future, we want to improve our flexibility and reduce the toil in this area.
DRE team stands for Decentralized Reliability Engineering.
It’s envisioned as a community that would maintain GitHub - dfinity/dre: Decentralized Reliability Engineering – a set of tools and docs / processes to keep the IC up and running.
Although at the moment it’s pretty much only DFINITY maintaining the repo. I do hope that this will change in the future though, since it’s the interest of many parties that the IC runs well. Right?
