Forking seems to be an integral part of the Blockchain architecture. This is due to Blockchain’s decentralized nature and the need to establish systemic trust among multiple participants (who are generally unknown to each other and therefore untrustworthy by definition).
To most of the non-technical population and a fair amount of the technical population as well, the forking phenomenon can be baffling and sound like a soap opera. The reasons for forking range from upgrades to the blockchain (for implementing some technical features such as expanded block size), migration of signatures to extended blocks (the SegWit fork on bitcoin), and disagreements on how to handle errors or losses.
To the extent that a chain relies on decentralization, operational forking is inevitable, since all transactions need to be validated and accepted by everybody or by a quorum. The volume of transactions can become huge. The way miners select transactions from the pool to validate and create blocks results in non-determinism. Different validators end up working on different blocks, causing little sub-chains to sprout like weeds in a garden. Eventually, one of the blocks wins out and its branch becomes the official continuation of the chain.
What happens to the other sub-chains? They wither and die. This is an integral part of the technology and perfectly proper, since it is a result of the inherent non-determinism in the generation of transactions and in the selection of transactions to validate. Remember, there is no central authority that coordinates all this, hence the need for a process of continual discovery of the most valid block and the most valid corresponding branch of the chain.
Unfortunately, regardless of the technical necessities, all this sounds like the result of squabbles in the blockchain community. The major forks in the Bitcoin and Ethereum communities, such as Bitcoin Cash and Ethereum Classic, are indeed serious disagreements with proposed changes. Besides the ever-present threat of malicious intent, these disagreements occur between well-meaning participants. In traditional centralized systems (whether software or not), these disagreements also exist, but they get resolved one way or the other before deploying the solution to the users. In some dispersed systems, such as professional associations, the protocol for change management is well-established. However, disputes occur in public blockchains while the chain is “in production” and participants can steer the chain to express their preference. It’s a bit like giving uncooperative front-seat passengers their own steering wheels.
Decentralized systems are double-edged swords, or should we say, spiny hedgehogs? Decentralization brings freedom from central authority. Whether this is viewed as good or bad depends on the issue at hand. But the one thing decentralization guarantees is a lot of debate, some chaos, sometimes no resolution, and (hopefully less often) a break-away of a splinter group in the form of a forked chain.
Decentralization is not necessarily good for everything, every time, and everybody. When pushed to the mat, most people would rather give up privacy for security and safety. Similarly, I suspect most would choose control and certainty over change, chaos, and confusion. As they say in the Six Sigma community, variance is worse than a bad mean. The possibility of forking in blockchains introduces an element of uncertainty that is less in users’ control or understanding than the uncertainty of change driven by a centralized governing body.
Blockchain is not one tool. The right flavor of blockchain must be applied correctly to the appropriate problem. Just as you can’t eat soup with a fork, you can’t deal with the soup of regulated securities with a forked chain, or more accurately, with a spoon that you don’t own or control, and which can splinter into a fork at any time.