How and why blockchain forks occur

By Bram Bosch

Blockchain forks have been a source of confusion, criticism, frustration, but also amazement for many people. They function completely differently compared to other forms of governance existing today. As is human nature, people tend to see blockchain governance through the lens of existing forms of government, causing misconceptions.??

The crucial innovation of blockchain is that of governance. It allows people to centralize data without having to rely on a single authority to govern that data. This authority-less nature, however, is a double-edged sword. Without an authority, settling conflicts in a simple way becomes nearly impossible. If two significant portions of a blockchain ecosystem disagree with each other, there is no way for either party to technically force the other party to stay within the same ecosystem. The result – most likely – will therefore be a so-called fork. But what happens when a blockchain forks??

Forking is a bit like people voting in a referendum. Except, both outcomes will become separate realities. For example, the blockchain equivalent of Brexit would result in 2 planets: one in which Britain remains in the EU and one where it doesn’t.?

This might be hard to wrap your head around, especially since every human would have to exist in both worlds (also, the lack of a reliable way to clone planets is a bit of a niggle). However, I imagine that many people would be interested in seeing how the two different worlds would develop.??

In blockchain, these alternate realities contain merely data, and not people. So, fear not: you can safely stay in the reality we all know and love. That said, your cryptocurrency might have a more complex state of being.?

An Example Fork?

Let’s say you own 10 Ether (currency on the Ethereum blockchain), and the ecosystem is?divided over the issue of whether you’re allowed to move Ethers from your own account into your own account (self-transfer). This might seem like a silly thing to bicker about – and you’d be right – but any disagreement that causes incompatible rules can lead to a fork, no matter how unimportant it might seem.??

Ultimately, we assume no consensus is reached in our fictitious Ethereum network. And before long, someone decides to make the dreaded self-transaction for the first time in Ethereum’s history. Half of the ecosystem (group A) decide that the transaction is valid, whereas the other half (group B) does not.? And despite this transaction having no impact on who owns what, the block added to Group A’s blockchain will now have a different identifier (hash) than the block added to Group B’s chain. What happens after that is visualized in the graphic below.?

Here, the green chain consists of people who do not accept the self-transaction whereas the yellow group does accept them. The blue color indicates that the opinion on this matter was irrelevant as there were no self-transactions in this part of the chain.?

But wait, I hear you ask. Where did the blue chain go? Did it not in fact continue on the green path? The blue part doesn’t contain any self-transactions, and neither does the green part, so it seems logical to conclude they are the same. I mean, it’s the yellow people who decided to change things by adding self-transactions. This may seem like a reasonable position, but on the flip side, the yellow crowd argues that transactions have always been defined as moving funds from one valid account to another valid account, and as such, a self-transaction has always been allowed. Not allowing them would be a change to the network’s rules.?

In other words, both camps believe they are a legitimate continuation of the blue chain. Any intuitive method of deciding who is “the original chain” hinges on being able to decide which of the forked chains is most similar to the old one. Unfortunately, such a mechanism is never objective. Enthusiasts on the green side will see their network as the valid continuation of the blue chain. The opposite is true from a yellow chain supporter.??

So far, this anecdote should have given you some idea of why blockchain forks are so tricky. They basically create two new ecosystems from the previously existing one. Seemingly, without any objective way to tell which to follow. If you are a business hoping to use the Ethereum network, is this anarchic way of governance something that is acceptable? Do I really want to make a choice every time someone decides to add a controversial new feature???

More on that later. First, let’s get a little bit more technical. Because really, all this decision making happens in software. Sure, a human selects which software to run, and they can even modify it however they wish. But ultimately, it’s a computer program that decides which blocks to add to its chain and which ones to ignore. Such a program is often called a blockchain node. Harking back to our blue/yellow/green fork, we are dealing with two distinct node configurations. One which accepts a self-transaction as valid, and one which doesn’t. From the perspective of each node, the graphic below shows how they view reality.?

?As can be seen, both see the blue blocks as part of their chain. This makes sense, since they are valid to both chains. However, an attentive reader might have questioned already why node B does not accept the green chain. The blue blocks do not contain any self-transactions, but neither do the green blocks. Sure, node A will never accept yellow blocks since node A is configured to ignore blocks with self-transactions. But node B should accept both yellow and green blocks, right??

Well to be honest: yes and no. Let us dive a little deeper into one of the fundamental aspects of blockchain: maintaining consensus.??

Consensus Algorithm?

Because of the decentralized and worldwide nature of many blockchains systems, it is often impossible to have perfect communication. Therefore, the situation depicted below can occur:?

Basically, two “rival” blocks are present. A node configured to follow “blue” rules will find both candidates for block #3 valid. Note that this is completely different from the yellow and green blocks which had different rules. Both block 3a and 3b are valid according to the same node software, so they’re both colored blue.?

It might seem simple to solve the problem of which block to pick: just accept whichever block came first. But actually, that would be a poor solution, since people on opposite sides of the planet are likely to draw conflicting conclusions. If you were to adopt such as “first seen” policy on blocks, a permanent fork could occur where some people view 3a as correct whereas others picked 3b. In other words, a fork occurs even if both parties were running exactly the same node software and did not have any fundamental disagreements whatsoever. They would fall out of sync simply because they are far apart geographically. Surely, that is not an acceptable state of affairs in a worldwide blockchain network.?

This synchronization issue was tackled by Satoshi in his paper “Bitcoin: A Peer-to-Peer Electronic Cash System”. In fact, solving this problem is a crucial component of Satoshi’s invention. Satoshi observed that an objective metric was necessary to prevent accidental forks. A kind of tie breaker, if you will. A choice that computers would be able to make and perform predictably. In other words, if two competing blocks exist and they both appear valid, how can a node choose one of the two blocks and be sure they will make the same choice as all the other nodes in the world??

The answer resides in the so-called consensus protocol – the process that defines how new blocks are made and accepted into the chain. Satoshi’s consensus protocol is called proof-of-work. I assume readers are at least somewhat familiar with how this process works. What people may not know, however, is that it’s possible to possible to calculate a value for how much work was put into a block. This value can be used as an objective tie breaker.??

The idea is simple: tally up the total amount of work for both competing chains, and see which value comes out higher. Chances are they initially have the same value. However, as the two competing chains grow taller, sooner or later one of them will amass slightly more work, causing a domino effect. As more nodes flip to one of the two chains, that chain will also start to grow faster since more nodes are working on extending it. And because it grows faster, even more nodes will follow suit.?

Knowing that, let us return to our colorful Ethereum fork.?

?

We left with Node A that refuses self-transaction and Node B accepting them. We asked whether that means that Node B would theoretically also accept the green chain. And the answer is: yes, assuming the “tie breaker” rule favors the green chain. But as we saw before, the tie breaker depends on which consensus algorithm is used. In case of proof-of-work, the green chain having more accumulated work would cause node B to switch, like so:?

?

Note: More accumulated proof-of-work in this case is visualized as having more blocks. Generally, having more blocks also means having more work, but it’s worth noting that’s not a correct assumption in all cases due to something called difficulty adjustment. We will not go deeper into that, since it’s not extremely relevant for the subject at hand. What’s important to take away is that Node B can swap between both chains, whereas Node A will never accept the yellow chain.?

Forks in-depth?

With the knowledge we gained, the phenomenon of forks can now be generalized a bit better. In case of a fork, there is always the more permissive side and the more restrictive side. Nodes that are configured more restrictively will never accept the permissive chain. However, nodes that are configured to be more permissive have no problem switching to the restrictive chain, assuming it wins the tie break.??

To make it more concrete: let's consider some example reasons for a fork and which side would be permissive and which side would be restrictive.??

1. Adding a rule such as: "blocks must have an even size" would be a restriction in the rules because old nodes have no problem with even sized blocks. New nodes, however, will now reject odd sized blocks produced by old nodes. Thus, the old nodes are more permissive.? ?
2. Allowing the network to accept a new transaction type requires a more permissive ruleset. Old nodes accept a specific set of valid transaction types, and they refuse anything that does not adhere to that. ? To add a new transaction type, we must allow something that previously was not legal. Hence the term permissive. Old nodes are more restrictive since they do not accept the new transaction type as they do not understand it.? ?
3. Changing the consensus algorithm: this results in mutually exclusive rules. For example, what is valid proof of work does not qualify as valid proof of stake and vice versa. Hence, blocks accepted by old nodes will never be accepted by new nodes nor the other way around.?

As can be seen, a 3rd situation exists where neither of the chains is the more permissive one. In general, though, this is quite rare and mostly occurs when complete technical overhauls are implemented.?

Let’s go back to the above example. We concluded that a node can switch from a more permissive to a more restrictive ruleset. However, constantly switching chains is not desirable from a functional standpoint.? That is why, assuming both chains continue to develop at a comparable rate, Node B would need to be configured in a way to prevent the switching. A common tactic used to accomplish this is a so is called a “fork block”. What this would mean in the context of our example fork is that Node B would adopt the rule: “block #4 must contain a self-transaction”. Doing this makes the yellow chain appear invalid to Node B, allowing the network to split cleanly without any possibility of confusion for the node software. In other words, this technique intentionally creates a situation 3) as described above when it didn't naturally occur.?

In a more general sense: a clean split occurs when the rulesets are mutually exclusive. Or: a clean split occurs when chain A is always invalid to node B, and chain B is always invalid to node A.??

What I’ve explained so far, however, is not in line with the terminology that is common in the blockchain space. Searching around on the internet will likely result in articles in which creating a more permissive chain is called a “hard fork”.? Conversely, the production of a more restrictive chain is called a “soft fork”. I specifically chose to not use this terminology, as it is not very helpful in my eyes. Most importantly, it implies that one side is responsible for the fork. Whereas, fundamentally, a fork always has two sides.??

For example, had the Ethereum chain split example from above been real, many blockchain commentators would probably have written that the yellow community are performing a hard fork. This is a problematic view, because it implies the green chain is not performing a fork. However, as they say, it takes two to tango. Had the green community accepted to implement self-transactions, the entire ecosystem would still be in one piece.?

The terms hard and soft fork can only be used if one defines what the “old” rules were. Often, this is not possible. And if it is, it is rarely objective.?

Furthermore, the term “soft fork” implies it is not dangerous. Or, at least, less dangerous than a hard fork. However, soft forks can in some occasions be more dangerous since it allows powerful actors to narrow the rules of the system without nodes realizing that this is happening. For instance, it is possible for a soft fork to remove functionality. If this new, more restrictive chain wins the tie break, your node will start accepting a chain which could lack the specific functionality you depend upon.?

On top of that, features even can be added while still technically remaining a soft fork, if coded cleverly. The most famous example of this would be Bitcoin’s “Segregated Witness”. This soft fork upgrade added an entirely new transaction type, while still being forward compatible. That is, non-upgraded nodes would accept blocks containing Segregated Witness transactions, even though they were not explicitly coded to do so.?

In conclusion, soft forks are not inherently safer than hard forks. Most importantly because a hard fork requires every node to consent explicitly, whereas a soft fork may change things without participants realizing.?

Real World Examples?

Let’s look at some real-life examples of blockchain forks and how they played out. In May 2016, the real world Ethereum network split in two. The more permissive side (also known as “hard fork”) added a feature specifically to reverse and fix an exploit that occurred. The more restrictive side acknowledged the attack had happened, but that undoing it fundamentally contradicts the nature of blockchain, and as such, were not willing to accept the more relaxed ruleset.?

Ultimately, the more permissive chain/hard fork side kept the original chain’s name. The more conservative side obtained the name “Ethereum Classic”.?

Another famous example is the Segwit vs Bitcoin Cash split. In July 2017, the Bitcoin ecosystem was struggling with capacity issues. Two solutions were proposed:?

1. A slight capacity increase called Segwit combined with increasing the blocksize limit to 2MB??
2. Increasing the blocksize limit to 8MB?

Solution 1 was basically a compromise between those who wanted a higher blocksize limit and those who wanted Segwit. The resulting combination was often dubbed “Segwit2x”.? ?

Segwit would be implemented using a soft fork, whereas both the 2MB and 8MB blocksize increases would be hard forks.?

However, some proponents of the 8MB blocksize increase so fundamentally disagreed with the implementation of Segwit that they did not accept Segwit2x as an acceptable compromise. Therefore, when Segwit was in the process of being activated in August 2017, those who opposed it, hard forked the blocksize limit to 8MB (using the “fork block” technique describe before to prevent chain flipping). This series of events resulted in two separate ecosystems emerging. The soft fork (Segwit) side is now known simply as “Bitcoin”. The 8MB side is currently called “Bitcoin Cash”. The planned 2MB increase for Bitcoin never happened (Segwit2x didn’t occur, it simply became Segwit). For all intents and purposes, we can therefore say that both the Segwit soft fork and the Bitcoin Cash hard fork activated at the same time.?

?

So, what about nodes? How would node software react to this sequence of events? This is slightly more complex, as we have 4 configurations to consider:??

• Old nodes.?
• Old nodes, but used to produce new blocks (by a miner).?
• Nodes upgraded to support Segwit.?
• Nodes upgraded to support Bitcoin Cash.?

After the Bitcoin/Segwit/Cash split, the result was roughly as follows:?

?

As can be seen, old nodes will actually follow the upgraded Segwit chain, since it’s more restrictive than the pre-fork chain. However, miners who run old nodes run into a problem. They produce blocks according to the more relaxed ruleset, and Segwit miners will invalidate those blocks. The result is the grey block as seen in the image above – also known as an “orphan block”. Again, I wish to remark the chosen terminology here is unfortunate since an orphan block does in fact have a parent. A better term that has a similar ghastly ring to it would be “abandoned block”.?

That said, if the grey chain would have grown faster than the Segwit chain, we would get something like this:?

?

The complicated nature of this three-way fork comes to light with this example. There are basically 3 potential chains. However, due to the nature of the tie breaker rule in proof-of-work, it is likely that either the grey/orange or the light orange chain would eventually die. In the real world, it was the grey chain that did. Therefore, one could say the “old” Bitcoin died, whereas Bitcoin+Segwit and Bitcoin Cash survived.??

This method of judging forks, however, relies on being able to timestamp node software. We are assuming there is some well-defined “old node”. Additionally, it relies on being able to define whether a node behaves the same or behaves differently from this old node. However, in reality, many different types of node software exist – often written in different programming languages. It’s impossible to (mathematically) prove they behave 100% similarly.??

Consider for example that 4 different nodes exist, tuned to accept blocks up to 1MB, 2MB, 4MB and 8MB respectively. In this case, what can we say about the blocksize limit of the network? What happens when a block of 2 MB is found? Are the people running 1MB nodes performing a soft fork? Are the others performing a hard fork? Is it just an unfortunate accident??

All in all, going in-depth on the technical nature of blockchain seems to offer no answers to decide which fork is the “legitimate” successor of the old chain.?

Looking at forks that occurred throughout history does not yield much better results, unfortunately. In Ethereum, the hard forked chain ended up being considered the continuation of the original chain. Conversely, in Bitcoin, it was the soft fork that did. So apparently, being a hard or soft fork can’t be an objective metric by which to judge “the original” chain either.?

What we see in practice, is more of a “majority rules” mechanism. Unfortunately, measuring the majority by some objective metric is hard. Market value in a cryptocurrency seems like reasonably objective, but it is also subject to interpretation and manipulation. Furthermore, different exchanges can have deviating values. Another option is to judge by proof-of-work, but that would create a situation where an attacker who gains >50% of the network’s hashing power would be automatically legitimized. Furthermore, it completely disregards the opinion of the users since they do not produce blocks.?

Unfortunately, there seems to be no simple solution. We can’t define a fool-proof way of determining “which side forked off?” or “which is the real Bitcoin?” or comparable questions. The general consensus seems to be that more proof of work and a higher market value together are good indicators of ecosystem support.??

Conclusion?

In conclusion, forks are an unavoidable phenomenon of public, permission-less blockchain networks. They can cause some hassle, but with some relatively basic techniques and knowledge it becomes quite manageable.?

Hopefully this article has provided you with insight in how blockchain forks work and how to mitigate them in a business context.?