Cryptocurrency networks often undergo forks, which involve changes to the underlying protocol. This section provides a detailed and example-filled explanation of three types of forks: evil forks, soft forks, and hard forks. By comparing their characteristics, motivations, implications, and examples, we will explore the distinctions between these forks and their impact on the cryptocurrency ecosystem.
An evil fork, also known as a malicious fork or contentious fork, occurs when a group of network participants intentionally diverges from the existing chain to create a separate network. Unlike soft or hard forks, evil forks aim to disrupt the original network rather than improve or upgrade it.
Evil forks are typically driven by disagreements, conflicts of interest, or ideological differences within the cryptocurrency community. The intention is to challenge the original network's legitimacy, disrupt its operations, or promote an alternative vision.
Bitcoin Private (BTCP) emerged from an evil fork of Zclassic (ZCL) and Bitcoin (BTC). The malicious actors covertly took a snapshot of the existing Bitcoin and Zclassic blockchain and used the data to create a new chain, Bitcoin Private, without the consent or knowledge of the original communities.
Evil forks often result in network fragmentation, decreased user trust, and potential confusion among participants. The split creates multiple chains with differing rules and consensus, leading to a division of resources, development efforts, and community support.
A soft fork is a protocol upgrade that introduces new rules while maintaining backward compatibility with the existing network. It is implemented in a way that nodes running the old software can still participate and recognize the validity of the new blocks and transactions.
Soft forks are typically motivated by the need for security enhancements, scalability improvements, or the introduction of new features. They aim to upgrade the network while minimizing disruption and maintaining compatibility with older software versions.
The Segregated Witness (SegWit) soft fork in the Bitcoin network was motivated by the need to address transaction malleability, increase transaction capacity, and enhance network scalability.
Soft forks generally lead to temporary network fragmentation until the majority of nodes upgrade their software. Upgraded nodes recognize new blocks as valid, while non-upgraded nodes may accept them without fully understanding or enforcing the new rules. Consensus is maintained through the majority of nodes following the new rules.
A hard fork is a protocol upgrade that introduces significant changes to the network, resulting in a permanent divergence from the existing chain. It creates two separate chains, each following a different set of rules.
Hard forks are often motivated by fundamental protocol changes, governance disagreements, or the desire to introduce substantial modifications to the network. They aim to create a new chain with distinct rules and capabilities.
Ethereum's hard fork resulted in two separate chains, Ethereum (ETH) and Ethereum Classic (ETC), following differences in opinion regarding the immutability of the blockchain after the DAO hack.
Hard forks can lead to network fragmentation, as the community and resources divide between the new and old chains. Users, miners, and developers must choose which chain to support, potentially causing a split in the ecosystem. Compatibility issues may arise, requiring upgrades to software, wallets, and infrastructure to interact with the new chain.
Evil forks aim to disrupt the original network, while soft forks and hard forks aim to upgrade or modify it.
Evil forks do not prioritize compatibility, while both soft forks and hard forks aim to maintain backward compatibility, although to differing degrees.
Evil forks and hard forks result in network fragmentation, while soft forks strive to minimize fragmentation by allowing older software versions to remain operational.
Evil forks lack consensus and typically lack community support, while soft forks and hard forks require consensus among network participants for successful implementation.
This article takes inspiration from a lesson found in 15.S12 at MIT.