When you’re prompted to update your digital banking app on your smartphone, you probably don’t even think twice. Maybe your phone auto-updates without you even noticing. It’s a necessary process, after all – if you don’t install the latest version of the software, you run the risk of being denied access to its services.
In open-source cryptocurrencies, things are very different. You don’t need to read every line of code that underpins Bitcoin to use it, but having the choice to do so is important. You see, there’s no hierarchy here, and no bank that can just push updates and change things as it pleases. As a result, implementing new features in blockchain networks can be a challenge.
In this article, we’ll explore how cryptocurrency networks can be upgraded, despite the lack of a central authority. To do so, they use two different mechanisms: hard forks and soft forks.
To understand how forks work, it’s important to first understand the participants involved in the decision-making process (or governance) of the network.
In Bitcoin, you could broadly make the distinction between three subsets of participants – developers, miners, and full node users. These are the parties that actually contribute to the network. Light nodes (i.e., the wallets on your phones, laptops, etc.) are used extensively, but they aren’t really “participants” as far as the network is concerned.
Developers are responsible for creating and updating the code. For your typical coin, anyone can contribute to this process. The code is available publicly, so they can submit changes for other developers to review.
Miners are the ones that secure the network. They run the cryptocurrency’s code and dedicate resources to adding new blocks to the blockchain. In the Bitcoin network, for example, they do so via Proof of Work. They’re rewarded for their efforts in the form of a block reward.
You’ll often find overlap in these categories. You could, for instance, be a developer and a full node user, or a miner and full node user. You could be all three or none. In fact, many of what we consider to be cryptocurrency users don’t take on any of these roles. Instead, they opt to use light nodes or centralized services.
Looking at the descriptions above, you could make strong cases for developers and miners making the decisions for the network. Developers create the code – without them, you’d have no software to run and no one to fix bugs or add new features. Miners secure the network – without healthy mining competition, the chain could be hijacked, or it could grind to a halt.
If these two categories tried to strong-arm the rest of the network into following their will, however, it wouldn’t end too well. To many, the real power is concentrated in full nodes. This is largely a function of the network being opt-in, meaning that users can choose what software they’re running.
The developers aren’t breaking into your home and coercing you to download the Bitcoin Core binaries at gunpoint. If miners adopt a “my way or the highway” attitude to force an unwanted change on the users, well, the users will just take the highway.
These parties aren’t all-powerful overlords – they’re service providers. If people decide not to use the network, then the coin will lose value. The loss of value directly impacts miners (their rewards are worth less when denominated in dollars). As for developers, they can just be ignored by the users.
You see, it’s not like the software is proprietary. You can make whatever edits you want to make, and, if others run your modified software, you can all communicate. In that case, you fork the software and create a new network in the process.
A software fork occurs at a point where software is copied and modified. The original project lives on, but it’s now separate from the new one, which takes a different direction. Suppose that the team of your favorite cryptocurrency content website had a major disagreement with how to proceed. One part of the team might replicate the site on a different domain. But going forward, they would post different types of content than the original.
The projects build off a common ground and share a history. Just like a single road that later splits into two, there’s now a permanent divergence in their paths.
Note that this kind of thing happens a lot in open-source projects, and has been happening for a long time before the appearance of Bitcoin or Ethereum. However, the distinction between hard forks and soft forks is one almost exclusive to the blockchain space. Let’s discuss those a bit more.
Despite having similar names and ultimately serving the same purpose, hard forks and soft forks differ significantly. Let’s take a look at each.
Hard forks are backward-incompatible software updates. Typically, these occur when nodes add new rules in a way that conflicts with the rules of old nodes. New nodes can only communicate with others that operate the new version. As a result, the blockchain splits, creating two separate networks: one with the old rules, and one with the new rules.
Nodes turn blue when they update. The older yellow nodes reject them, while blue ones connect to each other.
So there are now two networks running in parallel. They’ll both continue to propagate blocks and transactions, but they’re no longer working on the same blockchain. All nodes had an identical blockchain until the point of the fork (and that history remains), but they’ll have different blocks and transactions afterward.
Because there’s that shared history, you’ll end up with coins on both networks if you were holding them before the fork. Suppose that you had 5 BTC when a fork occurred at Block 600,000. You could spend those 5 BTC on the old chain in Block 600,001, but they haven’t been spent in the new blockchain’s Block 600,001. Assuming the cryptography hasn’t changed, your private keys still hold five coins on the forked network.
An example of a hard fork was the 2017 fork that saw Bitcoin fragmented into two separate chains – the original one, Bitcoin (BTC), and a new one, Bitcoin Cash (BCH). The fork occurred after a lot of arguing over the best approach to scaling. Bitcoin Cash proponents wanted to increase the block size, while Bitcoin proponents opposed the change.
An increase in block size requires modification of the rules. This was before the SegWit soft fork (more on that shortly), so nodes would only accept blocks smaller than 1MB. If you created a 2MB block that was otherwise valid, other nodes would still reject it.
Only nodes having changed their software to allow blocks exceeding 1MB in size could accept those blocks. Of course, that would render them incompatible with the previous version, so only nodes with the same protocol modifications could communicate.
A soft fork is a backward-compatible upgrade, meaning that the upgraded nodes can still communicate with the non-upgraded ones. What you typically see in a soft fork is the addition of a new rule that doesn’t clash with the older rules.
For example, a block size decrease can be implemented by soft-forking. Let’s once again draw on Bitcoin to illustrate this point: though there’s a limit on how big a block can be, there isn’t a limit on how small it can be. If you want to only accept blocks below a certain size, you just need to reject bigger ones.
However, doing so doesn’t automatically disconnect you from the network. You still communicate with nodes that aren’t implementing those rules, but you filter out some of the information they pass you.
A good real-life example of a soft fork was the aforementioned Segregated Witness (SegWit) fork, which occurred shortly after the Bitcoin/Bitcoin Cash split. SegWit was an update that changed the format of blocks and transactions, but it was cleverly crafted. Old nodes could still validate blocks and transactions (the formatting didn’t break the rules), but they just wouldn’t understand them. Some fields are only readable when nodes switch to the newer software, which allows them to parse additional data.
Even two years after SegWit activation, not all nodes have upgraded. There are advantages to doing so, but there’s no real urgency since there’s no network-breaking change.
Fundamentally, both of the above types of forks serve different purposes. Contentious hard forks can divide a community, but planned ones allow the freedom to modify the software with everybody in agreement.
Soft forks are a gentler option. Generally speaking, you’re more limited in what you can do as your new changes can’t conflict with the old rules. That said, if your update can be crafted in such a way that it remains compatible, you don’t need to worry about fragmenting the network.
Hard forks and soft forks are crucial to the long-term success of blockchain networks. They allow us to make changes and upgrades in decentralized systems, despite the lack of a central authority.
Forks make it possible for blockchains and cryptocurrencies to integrate new features as they’re developed. Without these mechanisms, we’d need a centralized system with top-down control. Otherwise, we’d be stuck with the exact same rules for the lifetime of the protocol.