lucas' blog


i thought a blog would be quite cool...

Forkology - Why forks don't always lead to a chain split

Written by lucas | 25th Jul, 2017

A couple of weeks ago, I was at the Crypto Investor meetup in Munich and gave a brief talk about the New York agreement (a.k.a. SegWit2x), BIP148 (a.k.a. UASF) and other bitcoin related topics. I realized that, although a lot of people are interested in SegWit, only a few understand the underlying logic and implications of a fork. Soft fork, hard fork and chain-split are often used interchangeably even though they shouldn't. I decided to devote an article to the study of forks - or Forkology - according to Andreas Antonopoulos.

Note: I have to admit that I have a strong opinion on the currently proposed bitcoin forks. I think some of them make sense while others propose a rule change that is particularly advantageous for a specific group. The latter, I would consider bad for the bitcoin environment. That said, I'm not going to talk about any specific forks in this article but try to give a network-independent, generic explanation of forks.

What the fork?

One of the fundamental concepts in a blockchain environment is that there’s only one chain that is continually extended. As a matter of fact, this is one of the major goals of a blockchain and common protocol standards spend a lot of effort to achieve this goal. Achieving consensus is so important that participants are willing to pay for it. The price of consensus may be paid electrically (PoW) or monetarily (PoS). If you neither want to spend electricity nor money, you can still outsource the effort by paying a transaction fee (PoW) or delegate the task (DPoS). No matter what concept you’re using, you’re sacrificing something to achieve consensus, to get one chain, to retrieve a state that is 100% true.

Generally speaking, a fork is a state where more than one truth exist. The state is divided into two different options where either represents a possible extension of the blockchain (= a valid next block). There are two major reasons for parallel states.

Reason 1 - Parallel block creation Two miners find the next valid block at the same time. Since there are multiple options for the next block of a blockchain and either might include a different subset of queued transactions, it is most likely that at some point, two independent miners will each find a valid successor at the same time. This situation represents a potential fork since all nodes will accept the block that they saw first. We end up in a situation where parts of the network adopt chain A while others believe that chain B is the right state.

Luckily, there’s a mechanism that ensures that only one chain succeeds. This mechanism is called Longest Chain Rule and all nodes in the network abide by it. The rule states that every participant should always try to adopt the longest valid chain. The parallel block creation is resolved by the next block that is going to be mined on either chain A or chain B. It is very unlikely that this creation happens at the same time again. As soon as the next block is created, all nodes are going to jump to the longest chain. The fork is resolved and everybody is on one chain again. Btw, this procedure isn’t rare. We can see it happening every week on public blockchains like Bitcoin or Ethereum.

Reason 2 - Rule changes While parallel block creation is ubiquitous in blockchain environments and easily solvable by the longest chain rule, there is a second reason for parallel states that isn’t easily resolvable. Changing the rules in a blockchain environment can be complex. The pain points are described in the following chapter.

Forking, a matter of rules

Changing the rules in a blockchain environment isn’t easy because the rules represent a shared fundament of the decentralized network that all participants have to agree upon. Unless the change is accepted by all participants right away, a rule change might cause trouble in terms of inconsistent states (= forks). Generally speaking, a rule change comes in either of the following forms:

  • A tightening of the rules a.k.a Soft Fork is a replacement of rules with other, stricter rules. This means that new blocks still abide by the old rules but may also follow some new rules.

  • A loosening of the rules a.k.a. Hard Fork is a replacement of rules with other, looser rules. This means that new blocks go against the old rules.

    Both, a hard fork and a soft fork may or may not result in a chain split.

Whether a fork results in a chain split or not completely depends on user acceptance and the reaction of nodes and miners. If all nodes and miners accept the change, the chain is not going to split. That said, when it comes to a large blockchain environment, it’s very likely that some nodes do not update their rule sets and stick to the old rules while others adopt an updated rule set. So, let’s dive deeper into this scenario and see what the possible outcomes in case of a soft or a hard fork are.

Split or no split?

As stated above, whether a chain forks or not depends on the adoption of the rule set. As a rule of thumb, a hard fork is more likely to result in a chain split since it requires a higher adoption than a soft fork. The acceptance of rules changes highly depends on two different roles in a blockchain network: miners (block-creators) and nodes (full nodes that validate the chain).

Hard Fork Chain Split

A hard fork is not backwards compatible, meaning that blocks according to the new rules go against the old rules. For a hard fork scenario to not result in a chain split it takes almost 100% of nodes and miners that accept the new rule set. However, if there is a significant number of miners that doesn’t accept the change, there will still be blocks according to the new rules that are not compatible with the new rule set. A second chain (a different truth) is created. If a significant number of nodes accepts these blocks, the forked chain is maintained and a second blockchain is created.

Soft Fork Chain Split

A soft fork is a tightening of the rules, an updated rule set that implements additional rules that are backwards compatible with the old rules. For example, someone changes the block size from 2MB to 1MB. All nodes that stick to the old rule set will still accept new blocks (1MB is smaller than 2MB and therefore a valid block). However, this is based on the assumption that the majority of miners creates 1MB blocks. A soft fork might still result in a chain split if it is not accepted by the majority of miners.


Comments