A particular highlight is the rollout of the DTS feature for all message on all subnets.
Here is a summary of the changes since the last release:
* Consensus: Fix Size during CanisterHttp payload construction
* Crypto: Use constant-time linear search for recovering NIDKG plaintexts
* Crypto: added enum variant to rotate iDKG dealing encryption keys
* Crypto: remove sks key id from PublicKeyData
* Execution: Add error counter for execution refunds
* Execution: Bitcoin: Add ability to set lock time in TransactionBuilder
* Execution: Route bitcoin requests to the bitcoin canisters
* Message Routing: Add some conversion helper commands to state tool
* Message Routing: Parallel-ready scratchpad_to_checkpoint
* Message Routing: Only fsync once during checkpointing
* Networking: Call notify_all on when the AdvertBroadcaster receives the gossip object
* Networking: Limit the visibility of some networking packages
* Networking: Remove periodic logging
* Networking: Remove the extra nesting provided by GossipRetransmissionRequest
* Networking: [H2 Transport Migration]Enable read/write
* Orchestrator: Unelect replica versions
* Runtime: Add dummy ic0.global_timer_set()
* Runtime: Composite queries: limit the maximum call-graph depth
* Various tech-debt management: code refactoring, docs, bug fixes, test updates
And a complete list of changes can of course be found on GitHub.
Please reply to this message if you have any questions or comments.
I was curious about the process of updating the canister and subnets, when the new feature is in beta, all the canisters are still updated but without being able to use it? is an update sent enabling a feature (such as integration with bitcoin) when moving to mainnet ?
I add one more question since it is free , when the canisters or subnets are not updated manually, is it forced to do it automatically?
Hey @FranHefner, thanks for asking for clarifications. It’s important that people understand how things work
So what we do here is updating subnets, so the replicas running canisters. BUT, we do not update the canisters themselves. We can’t update the canisters actually since canisters are provided by users and we don’t even have access to the canister code, which would be necessary to build a new version of a canister and update the canister.
With that sorted out, the question is how does a canister talk with the rest of the world? Canister has something called System API that is provided by the subnet replicas. We (for the time being) provide a guarantee that the System API will always be backwards compatible. This means that canisters will always be able to work, in spite of the replica upgrades.
Note that this creates a problem for us, since we should be developing new features (System API extensions) and this typically involves making changes to the System API during the development process, as we discover new use cases with different user groups. But the System API always needs to be backwards compatible as we wrote above. So we are limited in changes we can make during the development. Hm…
To solve this conundrum, we came up with experimental System API. This allows us to stay agile and rapidly prototype and experiment with various user groups. The experimental System API will have the experimental keyword in the API function name. For the experimental System API we provide no guarantees of backwards compatibility.
A “beta” feature typically means that it is available to the canisters through an experimental System API, so you may need some support in the canister SDK/CDK to use this functionality. To provide you a bit more assistance, you may have to provide a bit more details on which SDK you are using (e.g. Motoko/Rust/…?) and which functions are you trying to call.
The subnets (IC replicas) are updated semi-automatically at the moment. There is a weekly release cadence, and a new IC build is voted in with NNS proposals and then (again with NNS proposals) rolled out to different subnets over the course of the week. The public dashboard team made a nice dashboard to oversee the progress and history of releases.
So, in summary:
subnets are updated semi-automatically (by us)
canisters are only updated manually, by the users
beta features may be available on the mainnet, and they may be available on the testnet.
you have to talk directly with the developers of the particular beta feature to know the status on the mainnet
you have to talk with the SDK/CDK devs or the community members to get support for using beta features with the particular SDK/CDK that you are using locally
It helps me a lot to understand topics (basic for many), but super interesting for me and for other people who are added. I want to learn and start programming within IC. I already downloaded courses.
The hardest challenge is keeping everything backwards compatible and making major changes at the same time, it must be an incredible challenge.
Thanks for your time! I know you are very busy and you dedicated yourself to writing the entire explanation.
, when the canisters or subnets are not updated manually, is it forced to do it automatically?
