Hard Fork vs Soft Fork

The hard fork vs soft fork debate is shrouded in mystery and misinformation. In this article, we’ll examine some key points to these arguments and look at why Decred is working towards becoming the first blockchain to be hard fork only.

All software needs to be updated to fix issues, increase performance or improve security, and blockchain protocols are no different. In Blockchain, those upgrades are called forks and there are two main kinds of upgrade, soft fork or hard fork.

Since cryptocurrencies are decentralised networks, all participants in the network need to follow the same rules. These participants are known as nodes, and the data they process is eventually recorded to the blockchain ledger. Any node not following the rules of the network will find their data gets rejected, never to be added to the blockchain.

Soft forks

Soft forks are restrictive upgrades. If the rules get tightened, all older and outdated software will continue to be able to have their data added to the blockchain, as long as they stick within the confines of the new rules. However, if an older node tries to push data to the limits of the previous rules, that data will be rejected by the updated nodes running the new software. Effectively giving the network a multi tiered system, where the dominant software version, will effectively force all other nodes to either upgrade to their version or act more restrictive when applying the rules.

What soft forks actually provide that hard forks don’t is forward compatibility. That’s to say, older versions of the system can accept inputs created by newer versions of the system. In the context of cryptocurrencies, and Decred in particular, this would mean older versions of the software would still be able to follow the chain with the most Proof-of-Work despite not understanding the newer validation rules.

On the surface, it might sound like a desirable property to continue allowing old software to follow the best chain without upgrading, as it retains forward compatibility. However, upon closer examination, it really isn’t desirable. This is because, it undermines the very rules that make cryptocurrencies trust-less and safe to begin with. When a user is running an old version of a node under a soft fork, they are delegating trust to a 3rd party, namely to others who are running the newer versions of the software, instead of actually verifying everything themselves.

Perhaps even more insidious, is that older nodes, are unaware they are not actually validating all the rules. This is because soft forks are specifically designed to trick older software intentionally.

Hard fork

Hard forks are expansive upgrades, that recognises the previous history of the blockchain but going forward will reject incoming data that has not followed the new rules. For instance, the data size has increased, so all older nodes will no longer be able to validate this data as it passes the limits set out in the older software.

This process forces all node operators to update their software to the new version or end up following an obsolete chain. In a hard fork only system, this will guarantee that only one version of the software is running and able to validate data. This eliminates all edge cases from older or alternative implementations and has a desirable impact on security and consistency.

Formal Governance Systems

In a blockchain that doesn’t have formal governance, hard forks can fracture the community and bring into existence a new blockchain, that is the same as the old one up to the point the new rules are implemented. It’s for this reason, there is a dominant argument in favour of soft forks from protocols that don’t have formal governance.

As for Decred, the advantages of being a hard fork only system greatly out weighs the disadvantages. Forcing everyone to run the same software massively reduces complexity, risk and improves elements of the protocols' security. Furthermore, as the process for Decred’s consensus upgrading is already formalised, going to the next step is mostly a formality.

Backwards compatibility

A big misconception in this debate is backwards compatibility, which is a nonsense argument. Because both Hard forks and Soft forks have to be backwards compatible to continue accepting any blocks that were valid up to the point the new rules were enforced.

Decred, for instance, has already had several hard forks and without issue you can still sync the entire chain from scratch, successfully validate every old block, and spend coins created in the very first block. How would that be possible if the latest software or hard forks were not backward compatible?

Soft fork and hard fork example

A simple example of the difference between soft fork vs hard fork could be. Assume you had a rule in version 1 of the software that says, "no blocks larger than 1 MB is allowed". Then, you wanted to raise that to 2 MB in version 2 of the software, to make it less restrictive/more flexible.

You can't do this with a soft fork because version 1 of the software will reject the new blocks because 2 MB is larger than 1 MB.

On the other hand, say you wanted to lower the block size to 500 KB, making it more restrictive. In that case, a soft fork could be used because version 1 of the software will happily accept the new blocks because 500 KB is not larger than 1 MB and therefore the rule in version 1 of the software is not violated.

Notice how, in the first case, the older version of the software (version 1) will no longer accept the inputs or data created by a newer version (version 2) of the software. That is a hard fork.

However, in the second case, the older version of the software (version 1) will still accept the inputs or data created by a newer version of the software. That is a soft fork. This is precisely why soft forks are changes done in a forward compatible way and have nothing to do with backward compatibility.

In both cases, the new software has to continue accepting any blocks that were valid up to the point the new rules are enforced. Otherwise, you could no longer sync or spend the coins from them. That is the very definition of backward compatibility.

As a rule of thumb, soft forks don’t need to be enforced by everyone running the same software because they reduce or restrict the current rule set. Whereas, hard forks need to be enforced by the majority because they expand the rule set, past its current expectations for validity.

But in both cases the older rule set must be seen as valid.

Short-term and long-term effects:

There are some short-term benefits, at the cost of longer-term issues, that soft forking provides. While hard forking typically provides better long-term benefits, typically at the cost of some minor short-term implementation inconveniences.

For example, soft forking, is the only reasonable method for coins without formalised governance or the ability to unambiguously choose the winning fork while simultaneously killing off the side that didn't win.

Moving forward, having the ability to hard fork in a formalised way has streamlined the development process for Decred. And has given the project the ability to react positively to contentious issues.

A prime example of this, is with the reward subsidy split consensus change, which went from start to finish in under six months. And gave everyone in the system a chance to:

• Air their views and discuss
• Vote to build the upgrade
• Get the nodes and miners to upgrade their software with the new version in a dormant mode
• Vote again to apply the consensus change
• and then a final push to all remaining software upgraded
• before the implementation goes live

In a protocol that doesn’t have formal governance, the process of hard fork upgrading is complex, time-consuming, and detrimental to a community. A prime example of this was the Bitcoin Cash hard fork, which took approximately two and a half years to implement and ultimately failed to become the dominant chain.

Decred makes this process look easy and is one of the benefits of the project, understanding the importance of formal governance from day one and understanding that coin holders need a bigger say in how a monetary system progresses.

To date, Decred has had no less than six hard fork consensus changes without any disruption to the network. It’s for this reason, you won’t find a Decred Cash, Decred Classic, Decred Gold, D Cash, Decred TV (Toco’s Vision) or any other contentious hard fork version of the original project.

Sources and references:

• A special thank you to Dave Collins for correcting my understanding of this topic
• https://medium.com/mai-make-ai/pros-and-cons-behind-the-fork-e2ea1a3b6089