If you are following the crypto news at all, there has been a lot of activity around Bitcoin and various factions of its users who are “forking” the protocol resulting in many different “Bitcoins”: Bitcoin Cash, Bitcoin Gold, (and Bitcoin Silver?) and the upcoming duel for market share between Bitcoin Segwit1x vs Segwit2x. I would like to briefly explain what forking means from the perspective of a blockchain and its users. I’ll conclude with some thoughts on why we are seeing so much forking and explain the tradeoffs inherent in such a decision.
In general, cryptocurrencies give us a way to track some shared state between potentially mutually trustless parties. This shared state is usually implemented with a data structure called a blockchain. To review, a data structure in this context is just a particular way to organize binary data; a particular class of consensus algorithms are used along with this type of data structure to get the unique properties of cryptocurrencies. We can break down the word “blockchain” to better understand what is going on here: taken apart, a blockchain is just a “chain” of “blocks”. The chain notion reflects a chain like you see on your bicycle or fence — a series of links that are connected with one link after the other. The blocks here contain cryptocurrency transactions (e.g. “Send 1 BTC to my friend”) and a cryptocurrency transaction should not be considered to have taken place until the computers maintaining the network have all agreed that a transaction should go into a particular block on the chain. This network-wide agreement process gives us a total ordering of individual blocks (each with a batch of transactions) so that we have a single history of activity amongst the cryptocurrency’s users. Having a single history is what lets us avoid issues like double spend because you shouldn’t be able to spend a particular token more than once. This property follows our intuitions around classical money (e.g. fiat cash).
A cartoon of some portion of some blockchain follows. We see four blocks that are lettered A-D. The arrows in the diagram refer to the fact that some data in that block contains a reference to the block it points to. This sequence of references is what gives a blockchain its “chainness” — we can clearly see the “chain of blocks”. The squiggly lines on each block are representative of transactions in that block (e.g. “send 1 BTC from this address to that address”).
Borrowing some terminology from computer science, we call the block before some block in the blockchain its parent. The block following a parent block is the parent’s child. Here, we can say that block B is a child of block A and block B’s parent is block A. Block D is a child of block C.
An important point to remember here is that the public cryptocurrencies are permissionless. This fact means that any computer participating can suggest a new block of transactions. We get a fork in the chain when multiple computers on the network issue proposals for child blocks that all have the same parent block. A fork can happen for a variety of reasons; some an expected part of operating the blockchain and some considered attacks against the protocol. For example minor forks occur pretty frequently in public systems due to some randomness in timing associated with the protocol — you could honestly think it is your turn to add a new block just because you haven’t yet heard that someone else is actually “first in line” to add the next block.
Cryptocurrencies are designed to work this way such that these forks naturally resolve over a nominal amount of time given the consensus rules of the protocol. The opportunity for attack arises when a fork is created that is not resolved via the network consensus. In this case, a malicious actor causes a fork on purpose and now there are two competing histories of what has happened according to the protocol. You can start to see how dangerous this situation is for belief in a cryptocurrency as this malicious actor could issue a transaction on one branch that results in receipt of some expensive good and the same transaction on the other branch actually just sends the funds back to the attacker. If the network decides to accept the alternative branch after the exchange of goods, the seller could have a huge loss on their hands. The way Bitcoin (and other proof-of-work cryptocurrencies) are designed is that it takes a majority of computing power on the network to successfully pull off this kind of attack (a “51% attack”) and as long as there is incentive to apply the majority compute power honestly, the network will remain secure.
Let’s explore a double spend attack executed with a 51% attack with another cartoon.
We see two orderly blocks, the purple and blue blocks, in this chain until we get to a fork with two choices— the gray and green blocks which are both children of the blue block. Importantly, notice that there are two transactions between the blocks from the same sender (gold line) to two different recipients (blue and red dots). In this situation, it means that some part of the network thinks the next block is the gray one and some other part of the network thinks the next block is the green one. As long as a majority of the computers on the network pick one branch over the other, this fork will be resolved in time and the selected block will be the one that goes into the single consistent history of transactions on the network.
Until this agreement has taken place, which transaction is the “correct” one is ambiguous and an attacker can use this to their advantage as just described. To make this attack concrete, consider an attacker who wants to buy a Tesla in Bitcoin. The attacker creates two slightly different transactions that are gold on the diagram above. One transaction sends the Bitcoins to the Tesla dealer’s address represented with the blue dot. The other transaction with the red dot sends the Bitcoins to an address the attacker controls. The attack unfolds when the Tesla dealer is convinced temporarily that the honest transaction has been included in the blockchain and hands over the keys to the car. The attacker then uses their majority weight on the network to indicate that the other block is actually the correct block. If this happens, the Tesla dealer may not have any recourse against the thief.
It turns out that changing certain parts of the protocol results in a fork just like in the 51% attack. If you change the types of messages you are using to come to consensus, or you change how you interpret those messages, you are going to get different subsets of the network following different sets of rules — consensus failure by definition. If you follow the stories presented in the media, you will find that different factions of a given cryptocurrency’s users want to add or change some feature (like the size of each block) in some way that is not compatible with the existing protocol. When we have inconsistent messages in the protocol, we get a fork.¹
Offhand you would expect unnecessary forking to be a bad thing — and you would be correct. If lasting forks were common, then it would be very hard to use blockchains to represent currency as there would be as many different types of currencies as you would have forks. An overly forked chain could not give us a record of a store-of-value and this event would reflect a quickly diminishing market cap. This fear is what drives much of the anxiety around forks: a bad fork greatly threatens the legitimacy of your chain. This danger is highlighted with Bitcoin which now has a market cap around $100 billion USD. Serious amounts of capital is at risk and has driven the press coverage mentioned earlier. The alternative — to make no change or very slow change — is not particularly viable either as it holds back the continued adoption of the currency whether due to scalability limits or lack of features offered to users in other chains. This tension between experimentation and conservatism drives the debates around whether to fork or not.
So what can we do? We should acknowledge it can be very risky to introduce a new feature into a cryptocurrency due to a risk of consensus failure from some bug in your upgraded code. This risk slows down experimentation with new blockchain features and elevates the rate of accumulation of technical debt for a given cryptocurrency project. At the end of the day, a fork for the right reasons may be a good thing for a given cryptocurrency and this rationale is supporting the teams forking Bitcoin and producing all of the cloned currencies you have been hearing about. The ability of blockchains to organize humans across space and time is a paradigm shift in technology and it is too early to say that we have found the final answer to a public chain already. Accordingly, experimentation is a highly desired outcome and forking is currently the best tool we have to tackle this problem. If we commit to move in unison as a community we will be able to survive a bad fork and be able to continue to build towards what comes after. Until next time, fork on!
1: There is a technical distinction to make here between hard and soft forks. A hard fork is a fork where each branch has a conflicting set of rules so that users have to choose one branch or the other. A soft fork is named in analogy and refers to a change that adds some extra feature but still remains compatible with users who do not upgrade to the new rule set.
Create your free account to unlock your custom reading experience.