Polkadot is a blockchain developed based on the Substrate framework. It is also a cross-chain protocol, which acts as a relay chain to realize cross-chain interactions between different blockchains. It uses the upgrade solution provided by Substrate to upgrade the system without forks, which perfectly solves the problems existing in traditional blockchain upgrades.
Runtime introduction
To explain how Polkadot performs a fork-free upgrade, first I have to introduce a few concepts in Polkadot. From a technical point of view, the Polkadot protocol can be divided into two parts: Runtime and Runtime Environment. Runtime contains the execution logic of most state transition functions of the Polkadot protocol, and Runtime Environment contains some common modules of the blockchain, such as network communication, Block generation and consensus engine, etc. Runtime Environment passes external data to Runtime and interacts with it to execute state transition functions. The upgrade to Polkadot is actually an upgrade to the Runtime part.
Users can choose to use FRAME to develop Runtime. Its full name is Framework for Runtime Aggregation of Modularized Entities, which is a set of modules and support libraries that can simplify Runtime development. Polkadot's Runtime is a code written in rust. It is compiled into a native executable file and a WebAssembly (wasm) binary file at the same time. The native executable file is part of the entire node executable file, and the wasm binary is used as the state Part of it is stored on the chain. When the node is executed, both native runtime and wasm runtime can be used. Although wasm runtime is a bit less efficient than native runtime, it has the following
advantages:
Cross-platform. Although wasm is a platform-independent binary format, no matter what kind of hardware is used, running wasm in the VM will get the same execution result.
It can ensure that a valid block is generated. The logic executed in wasm can always run in the native runtime, but not the other way around.
Good community support. The tool chain and ecology have received strong support from the community, and rust currently supports wasm the best.
The first step to upgrade Runtime is to propose a proposal to submit the updated Runtime wasm binary to the chain
In the Polkadot upgrade process, there is another important point that cannot be ignored is storage migration, which refers to developers re-adjusting existing storage to meet new requirements.
Why do you need storage migration?
A simple example: suppose that in the old runtime logic, the data type of the user account balance is represented by an unsigned integer, that is, it is stored in an unsigned integer; and in the new runtime logic, the data Types are represented by signed integers. If storage migration is not used, when the new Runtime executes the state transition logic, it is possible to read a negative number when reading the user account balance, which may cause unpredictable results.
The changes that need to be migrated in Runtime must be specified using the D1-runtime-migration tag provided by Substrate. At the same time, FRAME provides the on_runtime_upgrade function, the logic of this function will be executed immediately after the Runtime upgrade, so you can add relevant logic to this function to implement storage migration.
Summary
Polkadot's upgrade plan (in fact, the upgrade plan of substrate) divides Runtime into native and wasm and uses on-chain governance to upgrade. It does not need to interrupt the node, does not affect business operations, and does not require too much personnel investment. The efficiency is greatly improved, and it is perfect. It solves the problems caused by the fork upgrade, and it is indeed a very good blockchain upgrade program.