Runtime upgrade
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.
The usage of WebAssembly in the Polkadot SDK (the framework powering Polkadot, Kusama and their respective parachains), give the relay chain, its parachains, as well as any other standalone solo chains built with the Polkadot SDK the ability to upgrade their runtime (the chain's "business logic") without a hard fork of the respective network.
Rather than encoding the runtime in the nodes, Polkadot 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 WebAssembly on-chain and having nodes auto-enact the new logic at a particular block height. The runtime is stored on the blockchain itself.
Decentralized Polkadot runtime upgrade
Polkadot 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. Polkadot stakeholders propose and approve upgrades through the on-chain governance system, which also enacts them autonomously once the runtime upgrade referendum is approved through on-chain voting.
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 Polkadot Host must always ensure it provides the runtime corresponding to the state in which the entry point has been called.
Last updated