Upgrading Blockchains without Hard Forking

How can a blockchain be upgraded without a hard-fork? Substrate-based chains have an interesting trick up their sleeve that makes this possible.

Video version of this post:

Hard Fork

Traditionally, if you wanted to upgrade a blockchain, like add some new functionality into Bitcoin or Ethereum, you would have to do what's called a hard-fork. A hard-fork is when entities running the software powering the blockchain update their software to a newer version.

It's called a fork because everyone who does not upgrade is left behind on an obsolete, outdated fork, producing blocks according to the rules in the old code, incompatible with the now new main chain. Once these stragglers update, their nodes will reconnect to the main chain and sync-up, and the fork will die off.

Hard-forks are typically a very difficult process, in particular because you're never really aware of who's running your software and organizing a global update of code is extremely difficult. This is especially true in decentralized systems with reasonable anonymity. You need to rely on the people running your nodes to actively seek out information about updates and you have to trust them to update when they're supposed to update.

The Substrate Way

Substrate-based chains like Kusama and Polkadot have a unique solution to this problem.

Substrate-based chains can be upgraded without having to coordinate a large number of people around the effort of updating some software. Here's how.

In Substrate-based chains, there is something called a WebAssembly blob, or a WASM blob, stored on the chain itself. This blob contains all the logic that a chain needs to build new blocks. The runtime of the chain itself is contained in this WASM blob.

All nodes connecting to this blockchain are constantly aware of this WASM blob and the rules it gives them for producing new blocks. That same logic is also present in the nodes' native code: all nodes (programs running the chain) are built in Rust, and these programming instructions tell them how to build blocks too. The instructions are identical to what's in the WASM blob. So what's the point?

There's a switch in these nodes which tells them: "If the WASM code on the chain is newer than what you have in your native code, ignore your native code and prefer WASM code. If they are the same, then run the native code because it's faster."

All one needs to do to upgrade a blockchain that's based on Substrate is to upload a new version of the WASM blob, and all the nodes connected to it will fall into place and respect the new rules. But isn't it dangerous to let just anyone change the code of the chain like that?

On-chain Governance

On-chain governance lets any token holder of a Substrate-based chain propose a change to the chain itself. This proposal can be something dramatic like changing the entire runtime of the chain, or it can be something less impactful like changing a constant on-chain - for example, the maximum number of validators allowed.

The proposal enters a queue and while it's there other token holders can second it. If it gets enough support, the proposal is tabled as a referendum and can then be voted on. Every token holder has a right to vote with their tokens, and if they feel strongly about an outcome they can also vote with conviction, by locking down their tokens for a period of time to get a vote multiplier.

If a referendum passes, the logic behind it is executed automatically - no human intervention is necessary. So changing the runtime code of the chain by updating a WASM blob is a matter of submitting it into the system and getting people to vote for it, and the blockchain itself takes care of the rest.

Remember to subscribe to our newsletter to be kept up to date on new posts and to be kept in the loop about Web 3.0 developments.