Runtime upgrades allow CERE to change the logic of the chain without the need for a hard fork.
You may have encountered the term "hard fork" before in the blockchain space. A hard fork occurs when a blockchain's logic changes such that nodes that do not include the new changes cannot remain in consensus with nodes that do. Such changes are backward incompatible. Hard forks can be political due to the nature of the upgrades and logistically demanding due to the number (potentially thousands) of nodes in the network that need to upgrade their software. Thus, hard forking is slow, inefficient, and error-prone due to the levels of offline coordination required and, therefore, the propensity to bundle many upgrades into one large-scale event.
By using Wasm in Substrate (the framework powering Cere), parachains are given the ability to upgrade their runtime (a chain's "business logic") without hard forking.
Rather than encoding the runtime in the nodes, Cere nodes contain a WebAssembly execution host. They maintain consensus on a very low-level and well-established instruction set. Upgrades can be small, isolated, and very specific by deploying Wasm on-chain and having nodes auto-enact the new logic at a particular block height.
The Cere runtime is stored on the Cere blockchain itself. Cere can upgrade its runtime by upgrading the logic stored on-chain and removes the coordination challenge of requiring thousands of node operators to upgrade in advance of a given block number. Cere stakeholders propose and approve upgrades through the on-chain governance system, which also enacts them autonomously.
As a result of storing the Runtime as part of the state, the Runtime code itself becomes state sensitive, and calls to Runtime can change the Runtime code itself. Therefore, the Cere Host must always ensure it provides the Runtime corresponding to the state in which the entry point has been called.
The existing runtime logic is followed to update the Wasm runtime stored on the blockchain to a new version. The upgrade is then included in the blockchain itself, meaning that all the nodes on the network execute it. Generally, there is no need to upgrade your nodes manually before the runtime upgrade, as they will automatically start to follow the new logic of the chain. Nodes only need to be updated when the runtime requires new host functions, or there is a change in networking or consensus.
Transactions constructed for a given runtime version will not work on later versions. Therefore, a transaction constructed based on a runtime version will not be valid in later runtime versions. If you can’t submit a transaction before the upgrade, it is better to wait and construct it afterward.
Although upgrading your nodes is generally not necessary to follow an upgrade, we recommend following the Cere releases and upgrading promptly, especially for high-priority or critical releases.
The details about the latest client releases can be found in the release section of the Cere Blockchain Node repository.
The runtime and client versions are distinct from each other. The runtime versioning typically looks like network-xxxx, whereas the client versioning looks like vx.x.xx. For instance, the runtime version shown on the top left section of Cere Explorer below is node/47000, and the client (node) version shown on the top right section is v4.7.0.
The runtime version can be queried on-chain through Cere Explorer by navigating to the Developer tab > Chain State > Storage > system and query lastRuntimeUpgrade().
The node version can be queried by navigating to the Developer tab > RPC calls > system and query version().