Introduction

You probably don't give it a second thought when asked to update your smartphone's digital banking app. Perhaps your phone automatically upgrades without your knowledge. After all, if you don't install the most recent version of the software, you face the danger of not being able to use its services.
Things are significantly different with open-source cryptocurrencies. To use a cryptocurrency, you don't have to know every line of code that powers it, but having the option to do so is crucial. You see, there is no hierarchy present, and there is no bank that has the authority to impose changes and upgrades at will. Because of this, adding new functionality to blockchain networks might be difficult.
In this post, we'll look at how crypto networks can be improved without a centralized control system. They accomplish this by utilizing two distinct mechanisms, hard forks and soft forks.

Who decides what to do in a blockchain network?

It's crucial to first comprehend the individuals involved in the network's decision-making process (or governance) in order to comprehend how forks function.
In general, there are three categories of players: developers, miners, and full node users. These are the entities that genuinely make network contributions. Although widely utilized, light nodes (i.e., the wallets on your phones, laptops, etc.) aren't actually considered "participants" by the network.

Developers

The code has to be written and updated by developers. Anyone can contribute to this process for a standard coin. Since the source code is accessible to everyone, developers can submit updates for review.

Mine workers

Network security is the responsibility of the miners. They invest resources in creating new blocks for the blockchain while also running the cryptocurrency's code. For instance, they carry it out via Proof of Work on the network. They receive a block reward as payment for their labor.

Users of full nodes

The core of the network is made up of full nodes. They keep a copy of the blockchain and validate, send, and receive blocks and transactions.

These categories frequently overlap one another. You may be both a miner and a full node user, for example, or both a developer and a full node user. All three are possible, or none at all. In actuality, a large portion of those who we classify as crypto users don't fulfill any of these functions. They choose to employ centralized services or light nodes instead.
You could make compelling arguments for developers and miners running the network based on the descriptions above. Without developers, you wouldn't be able to operate software or add new features or address faults. Developers write the code. Without strong mining competition, the chain may be taken over or come to a halt. Miners protect the network.
But it wouldn't go well if these two groups tried to bully the rest of the network into doing what they wanted. Many believe that entire nodes contain the true power. This is largely due to the network being opt-in, which allows users to pick the software they use.
The users will just take the highway if miners adopt a "my way or the highway" mentality to impose an undesired alteration on them.
These organizations are service providers, not all-powerful masters. The value of the coin will decrease if users choose not to use the network. The decline in value immediately affects miners because their awards are worth less in dollars. As for developers, users can simply ignore them.
It's not like the program is proprietary, you see. You can change anything you want, and if other people use your altered program, you can all converse. In that instance, you fork the program and subsequently build a new network.

A fork?

When software is copied and altered, a software fork happens. The initial project continues, but it is now distinct from the new one, which follows a different course. Imagine that the staff of your favorite crypto news website was at odds about the best course of action. The site might be duplicated by one member of the team on a different domain. However, they would afterwards release stuff that was different from the original.
The initiatives share a foundation and a similar past. There is now a permanent divide in their trajectories, like a single road that eventually divides into two.
It should be noted that this sort of thing frequently occurs in open-source projects and did so long before the invention of Ethereum. The distinction between a hard fork and a soft fork, however, is almost unique to the blockchain industry.

Let's talk about those a little more.

Comparison of hard and soft forks

Despite sharing a name and eventually doing the same task, hard forks and soft forks differ greatly from one another. Let's examine each in turn.

A hard fork, what is it?

Software updates with hard forks are incompatible with earlier versions. These frequently happen when nodes introduce new rules in a way that is incompatible with the rules of previous nodes. Only other nodes running the latest version can communicate with new nodes. As a result, the blockchain separates into two distinct networks: one that adheres to the previous regulations and one that does not.

When nodes update, they turn blue. While the blue nodes link with one another, the older yellow nodes reject them.

As a result, two networks are currently active simultaneously. Although they are no longer operating on the same blockchain, they will both continue to propagate blocks and transactions. Prior to the fork, all nodes shared a single blockchain, and that history is still available. However, moving forward, each node will have its own set of blocks and transactions.

One instance of a hard fork was the 2017 split of Bitcoin into two distinct chains: the original chain and the new chain. After much debate about the ideal scaling strategy, the fork took place. While supporters opposed the change, the others desired to expand the block size.

A larger block size necessitates changing the regulations. Nodes would only accept blocks smaller than 1MB at that time since SegWit had not yet undergone a soft fork (more on that in a moment). Other nodes would still reject a 2MB block that you created even though it was otherwise legitimate.

Only nodes whose software had been modified to accept blocks bigger than 1MB could accept those blocks. Naturally, that would make them incompatible with the earlier version, preventing communication between nodes without the same protocol updates.

How About a Soft Fork?

A soft fork is an update that is backward-compatible, allowing upgraded nodes to still connect with unupgraded ones. A soft fork often involves the insertion of a new rule that doesn't conflict with the existing ones.
For instance, soft-forking can be used to execute a block size reduction.
You won't immediately lose connection to the network if you do this, though. You still exchange information with nodes that aren't adhering to certain criteria, but you filter out some of it.
The aforementioned Segregated Witness (SegWit) fork, which took place soon after the split, is a nice illustration of a soft fork in practice. SegWit was a well designed update that altered the format of blocks and transactions. The formatting didn't violate any rules, so old nodes could still validate blocks and transactions, but they wouldn't be understood. Some fields can only be accessed by nodes running the more recent software, which enables them to process more data.

Not all nodes have updated even after SegWit's activation for two years. Although there are benefits to doing so, there isn't a pressing need because there won't be any network-breaking changes.

Which is better: hard forks or soft forks?

Fundamentally, the functions of the two fork types mentioned above differ. Hard forks that are contentious have the potential to split communities, but planned forks provide developers the ability to change the software as they see fit.
Using soft forks is a kinder solution. In general, you have fewer options because your new modifications cannot be in conflict with the previous regulations. However, you need not be concerned about fragmenting the network if your upgrade can be designed in a way that it remains compatible.

Concluding remarks

The long-term success of blockchain networks depends on both hard and soft forks. In spite of the lack of a centralized authority, they enable us to make improvements and changes to decentralized systems.
Blockchains and cryptocurrencies can incorporate new features as they're built thanks to forks. We would require a centralized system with top-down control if these processes didn't exist. Otherwise, the protocol would always be governed by the same set of rules.