Blockchain forks are events which sometimes determine a major protocol change, which means that forks are an inherent part of software upgrades on blockchain protocols. As forks require some majority of nodes to signal a change, forks can be coercive when it comes to community adoption; nodes are forced to make a decision on which chain or ruleset to follow. Forks can be sometimes be necessary for: - Feature upgrades - Vulnerability or bug fixes - Scalability upgrades to Layer 1 protocols - Community splits on governance Forks can therefore be classified into two main types: hard forks and soft forks. ### Hard Forks A hard fork is a type of blockchain fork that introduces changes to the protocol rules which are not backward-compatible. This means that nodes running older versions of the software will not recognize blocks created by nodes following the new rules. Key differentiators: - Incompatible rule changes - Requires majority network consensus - Can result in two separate chains coexisting >[!examples] Examples: >1. Bitcoin's [[Bitcoin Proposals#BIP 91 (SegWit2x)|Segregated Witness (SegWit)]] Activation: A controversial upgrade aimed at improving scalability and transaction malleability >2. Ethereum's Transition to Ethereum 2.0: The transition from Proof-of-Work (PoW) to Proof-of-Stake (PoS), which aims for improved scalability and energy efficiency. ### Soft Forks A soft fork is another type of blockchain fork where protocol rule changes are backward-compatible. This means that nodes running older versions can still validate blocks created by nodes following the updated rules. Key characteristics: - Compatible rule changes - Does not require majority network consensus - Only one chain remains after implementation >[!example] Example >Bitcoin's [[Bitcoin Proposals#BIP 148 (User Activated Soft Fork)|BIP 148 UASF proposal]] - to activate Segregated Witness - was never implemented as it would have forced or coerced miner adoption. There is a philosophical difference in opinion amongst the community as to which type of fork is (more or less) coercive. One argument is that a hard fork is non-coercive since a node could opt to the keep using the same ruleset in whichever fork they choose. In this frame, soft forks are deemed coercive because there is not an alternative chain ruleset to follow. The flip side is that if a hard fork is set to occur, and it has majority signaling approval, nodes which disagree feel coerced to follow the majority decision and abandon the original chain. >Even though soft forks are backwards compatible, a new ruleset is still being adopted by the majority of nodes. For this reason, communities may signal support of a proposal, and based on that support, determinations are made on whether the protocol will opt for a hard fork, soft fork, or ultimately refusing the proposal altogether.