The cryptocurrency and blockchain world is home to constant upgrades and new features. To introduce these changes, developers often have a tough choice to make. Introducing such upgrades is a painstaking process in a decentralized environment and one that can cause networks to fall apart if not executed correctly.
Contrary to updating a mobile banking application, the open-source cryptocurrency ecosystem behaves very differently. Even if you are not interested in the code powering a network, it remains vital to understand everyone has the choice to do so. In a decentralized world, it is all about empowering users by giving them choices. Rather than trusting one centralized entity to provide updates and force changes, crypto developers are more transparent about what they aim to achieve.
Upgrading a network is often done through “forks“. A hard fork and a soft fork are very different and can have varying outcomes when implemented. Both implementations can prove necessary under certain conditions.
Table of contents
The Decision-Making Process
Before we get into the nitty-gritty about code forking, it is essential to get the basics right. In a decentralized ecosystem, there is no figurehead to make the decisions on behalf of all users. Instead, the governance aspect of a network – Bitcoin, for example – is a lot more complex. Making decisions among hundreds, if not thousands of people, is no easy feat.
There are multiple groups of people who all have an important say in the decision-making process. The developers, who are responsible for making changes to the code, are one such group. They need support from the miners – who secure the network – and full node users – who broadcast transactions to the network – to achieve a majority consensus. It may seem straightforward on paper, but the reality can be a bit more complicated.
Without the developers, there would be no real way to introduce network upgrades or changes to keep an ecosystem competitive and appealing. The primary purpose of developers is to create and update code. Anyone can contribute to this process in an open-source environment. All code is publicly visible, allowing for collaboration and peer review.
Miners are the users responsible for securing the network. By running the native software on their machines and contributing resources to adding new blocks to the network, they are an essential part of the Bitcoin ecosystem. Miners receive block rewards and transaction fees in exchange for their network contributions.
Full Node Users
Although this group is often overlooked, the Bitcoin network wouldn’t operate without full node owners. Every full node owner helps validate, send, and receive blocks across the network. Furthermore, every full node stores a local copy of the entire blockchain.
It is not hard to see why there may be some overlapping across these three groups. It is not uncommon for developers to also mine and run a full node, for example. Anyone can belong to none, one, two, or three of the categories outlined above. The majority of users will not play an active role in the network – based on those categories -though, as they mainly rely on the “user” side through wallets, exchanges, and so forth.
Who Has The Most “Control”?
In the current landscape, the developers and miners are the primary decision-makers for Bitcoin. They have the most “active” roles in the ecosystem and can influence the network directly through their behavior. If developers are no longer coding, there is no new software to run, nor will security issues be addressed. Without miners, there is far less network security, making the ecosystem vulnerable to 51% attacks.
Despite their “combined power,” developers and miners cannot exert their dominance over the network either. Without the participation of full node operators, the network cannot validate transactions and blocks any longer. Bitcoin would grind to a halt, making the network useless. Anyone trying to coerce others into following their vision without achieving traditional consensus will risk being left behind for good.
It is essential to remember that all three main “groups” are service providers, not authorities. The opt-in nature of the network gives everyone free choice as to whether they want to run Bitcoin software. It is in the best interest of miners to ensure people keep using the network and bring value to BTC. Developers, on the other hand, face the biggest struggle. Users can ignore their directions entirely if they disagree on specific changes.
As anyone can modify the software used to run the network, there can be different “forks” of the code. As more people run a specific iteration of the code, they will communicate with one another. However, not all forks are innocent, as some of them can cause permanent damage to a network.
What Do Forks Entail?
When it comes to software, forking the code often means copying and modifying the existing data. Doing so allows the project to live on – rather than creating something new entirely – although the future version of the software will differ from the current one. In most cases, the differences will benefit the project users in multiple ways, although there is always a chance some network members will prefer the old version over the new one.
As both versions of the project will share a history, there is an effective “fork” in the road regarding which software version to use. It is prevalent to introduce forks in open-source projects, and by extension, the numerous cryptocurrencies on the market today. However, it is essential to distinguish between soft forks and hard forks, as both have very different consequences.
The Hard Fork Concept
The main reason why hard forks have a bit of a negative reputation is that they are not backward-compatible. When developers add new rules that conflict or overwrite previous ones, there can be communication discrepancies when not everyone uses the same software version. In the worst case, this can create a split in the blockchain ecosystem with two separate networks co-existing for a while.
Once two networks run in parallel, a very annoying situation is created. Every version of the blockchain keeps generating blocks and transactions, yet they are not compatible with one another. Some nodes will only communicate on chain A, whereas the others focus on chain B. Eventually, there will have different blocks and transactions, rather than sharing the same ledger.
For the user, this can have some interesting consequences. Usually, a user will have the same amount of coins on both chains if a network split occurs. Spending them on both chains is possible, but converting a value from chain A to chain B – or vice versa – may prove tricky. More importantly, the value of the coins on these two chains may differ significantly.
One significant hard fork to pay attention to is the Bitcoin and Bitcoin Cash split. Following disputes over scaling the network, some developers opted for a block size increase, whereas others opposed the idea. Raising the block size is a significant rule change that requires a hard fork of the code. The network would automatically reject any block not meeting the threshold.
However, the network nodes would no longer be compatible with the other part of the network opposing these changes. Eventually, both bitcoin and Bitcoin Cash became separate entities, with very different long-term goals and valuations.
A Soft Fork is Different
To avoid a problematic scenario such as a hard fork, developers can opt for a different way to integrate code changes. A soft fork is backward-compatible, allowing the network nodes to continue communicating even if they don’t update the software right away. Avoiding a clashing of old and new rules is essential to keep networks alive over time.
Whereas an increase in the block size requires a hard fork – and potential network split – one can do a downgrade in size via a soft fork. There are – usually- no limits on how small network blocks can be. If there are fewer transactions to complete, it doesn’t make sense to use the maximum block size all the time. Instead, the size can adapt to the needs of the network.
For the nodes which run this software and only accept blocks below a certain size, the option to do so is available. Even if they reject larger-sized blocks, they are not cut off from the network for doing so. Node communication will remain possible, even if some of the data that isn’t relevant to a node’s ruleset is filtered out.
A recent example of a successful short fork for Bitcoin is the Segregated Witness upgrade. SegWit changes the format of blocks and transactions without preventing old nodes from validating data under different rules. Thanks to the SegWit advancement, more transactions fit into every network block. Unfortunately, not all nodes have embraced the upgrade even after all these years.
Which Approach To Forks Is Better?
The ‘scary nature” of hard forks might make them seem unfavorable to developers and users. However, it is impossible to introduce certain protocol changes without a hard fork. A contentious hard fork can trigger a permanent network split, although most of them will not create any issues. Planning a hard fork ahead of time and engaging with community members can help avoid most problems or disagreements.
Soft forks are the “easier” option for all parties involved. They can help sort many smaller issues or improvements but never introduce crucial network changes. Their lack of conflict with older software versions is a big plus.
Both options for forking remain valid, depending on what developers aim to achieve for the network. Open communication and engaging in a dialog with network users will often help avoid any real issues, regardless of a hard or a soft fork.
There are multiple options to explore to introduce crucial changes to open-source software. Every option has upsides and drawbacks, yet sometimes they may prove essential to implement. There will always be soft forks and hard forks in the blockchain industry to upgrade existing infrastructure in a decentralized manner.
In the cryptocurrency world, standing still will lead to becoming irrelevant very quickly. Developers need to keep pushing the boundaries of what is possible and introduce new features accordingly. Forks will prove crucial to maintaining this decentralized approach to upgrading and modifying the network. Without such upgrades, the network will have the same rules for as long as it exists, making it non-competitive.