Answers>Learn about blockchain security fundamentals>What is a chain fork?
什麼是鏈條分叉？
// Tags
chain forkhard forksoft fork
TL;DR: A chain fork occurs when a blockchain's protocol rules diverge, creating two or more potential paths for the chain to follow. Soft forks introduce backward-compatible rule changes that tighten the existing rules, so non-upgraded nodes still accept new blocks and the network remains unified. Hard forks introduce non-backward-compatible changes, meaning upgraded and non-upgraded nodes follow different rules and the chain permanently splits into two separate networks if not everyone upgrades. Forks are the primary mechanism by which blockchains evolve, upgrade, and resolve community disagreements, but they also create risks around asset duplication, replay attacks, and ecosystem fragmentation.
簡單的解釋
Think of a blockchain fork like a fork in a road. Everyone has been traveling the same path, following the same rules. At the fork, a new set of rules is proposed. If the change is backward-compatible (a soft fork), everyone can continue on the same road regardless of whether they adopt the new rules. The road narrows slightly (stricter rules), but all travelers can still use it. If the change is not backward-compatible (a hard fork), the road splits into two separate paths. Travelers must choose which path to follow, and those on different paths can no longer interact with each other.
In blockchain terms, "rules" means the consensus protocol: which transactions are valid, how blocks are structured, what the maximum block size is, how gas is calculated, how rewards are distributed. Every node on the network enforces these rules when validating blocks. When the rules change, nodes that have adopted the new rules and nodes still running the old rules may disagree about which blocks are valid. How this disagreement is resolved determines whether the fork is a soft fork (the network stays together) or a hard fork (the network splits).
Soft Forks
A soft fork tightens the existing rules. Blocks that are valid under the new rules are also valid under the old rules, but some blocks that were valid under the old rules are no longer valid under the new rules. This means upgraded nodes enforce stricter validation, while non-upgraded nodes still accept the new blocks because they do not violate the old rules.
Bitcoin's Segregated Witness (SegWit) upgrade in 2017 is the classic example of a soft fork. SegWit changed how transaction signatures were stored, reducing the effective size of transactions and enabling the Lightning Network. Non-upgraded nodes still accepted SegWit blocks because the blocks were valid under the old size limit rules. Upgraded nodes enforced additional rules about how signature data was organized, but this was invisible to old nodes.
Soft forks are generally considered safer than hard forks because they do not risk splitting the chain. As long as a majority of miners or validators adopt the new rules, the chain stays unified. Non-upgraded nodes may not understand or validate the new features, but they do not reject the blocks, so the network remains a single chain. The downside of soft forks is that they are limited in what they can accomplish. Because new rules must be backward-compatible, fundamental protocol changes (like changing the block structure, modifying the account model, or altering the consensus mechanism) are typically impossible to implement as soft forks.
Hard Forks
A hard fork relaxes or fundamentally changes the rules, making new blocks invalid under the old rules. Non-upgraded nodes reject the new blocks, and the network splits into two chains: one following the new rules and one following the old rules. Both chains share the same history up to the fork point and diverge from that point forward.
Most hard forks are planned and coordinated upgrades where the entire community agrees to move to the new rules. Ethereum's transition from Proof of Work to Proof of Stake (The Merge, September 2022) was a hard fork. Every node operator, staking provider, exchange, and application developer coordinated to upgrade their software before the designated block. Because the community was unified, the old Proof of Work chain (briefly marketed as "EthereumPoW") attracted minimal support and quickly became irrelevant.
Ethereum's regular network upgrades (Shanghai, Dencun, and others) are also hard forks, activated at predetermined block numbers or timestamps. The entire ecosystem upgrades in advance, and the old rules are abandoned. These coordinated hard forks are routine maintenance, not contentious events.
Contentious Hard Forks
The most dramatic forks occur when the community cannot agree on the direction of the protocol, and both sides have enough support to sustain an independent chain. These contentious hard forks result in two living blockchains, each with its own community, miners/validators, token value, and development team.
The most famous contentious fork is Ethereum Classic. In 2016, a bug in The DAO smart contract was exploited, draining millions of dollars worth of ETH. The Ethereum community debated whether to hard fork to reverse the theft. The majority supported the fork, creating a new chain (today's Ethereum) where the stolen funds were returned. A minority rejected the fork on philosophical grounds (arguing that "code is law" and the blockchain should never be retroactively modified), and they continued running the original chain, which became Ethereum Classic (ETC). Both chains persist today, with Ethereum being overwhelmingly larger and more valuable.
Bitcoin Cash is another major contentious fork. In 2017, the Bitcoin community debated how to increase transaction throughput. One faction favored increasing the block size from 1MB to 8MB. Another faction opposed larger blocks, preferring the SegWit soft fork and off-chain scaling solutions like Lightning Network. The disagreement was irreconcilable, and in August 2017, the big-block faction forked Bitcoin to create Bitcoin Cash (BCH). BCH subsequently forked again in 2018, splitting into Bitcoin Cash and Bitcoin SV.
What Happens During a Fork
When a hard fork occurs, every holder of the original cryptocurrency suddenly holds the same amount on both chains. If you held 10 ETH before the Ethereum/Ethereum Classic split, you had 10 ETH on the new chain and 10 ETC on the old chain. This asset duplication can create economic complexity, including replay attacks where a transaction valid on one chain is rebroadcast on the other chain.
For developers, a fork means deciding which chain to support (or whether to support both), updating node software, verifying that smart contracts behave correctly under the new rules, and communicating changes to users. For node operators, a fork requires upgrading client software before the fork block to follow the intended chain. Nodes that fail to upgrade are left on the old chain, serving stale data and potentially causing applications to break.
What is the difference between a soft fork and a hard fork?
The core difference comes down to backward compatibility. A soft fork tightens the rules in a way that older software still accepts, so the network stays as one chain. A hard fork changes the rules in a way older software rejects, which can split the network into two chains. The table below compares the two side by side.
屬性
Soft fork
Hard fork
Rule change
Tightens existing rules
Relaxes or redefines rules
Backward compatible
是的
不
Non-upgraded nodes
Still accept new blocks
Reject new blocks
Chain outcome
Network stays unified
Network can split into two chains
New asset created
不
Yes, holders get coins on both chains
範例
Bitcoin SegWit (2017)
The Merge, Ethereum Classic split
Both kinds of fork are how a blockchain upgrades over time. Soft forks are lower risk but limited in scope, while hard forks unlock deeper protocol changes at the cost of requiring everyone to upgrade in lockstep.
What is an accidental or temporary fork?
Not every fork is a deliberate protocol change. Accidental forks happen when two validators produce competing blocks at almost the same time, leaving the network briefly split over which block extends the chain. The network resolves this within a block or two by converging on the heaviest valid chain, and the orphaned block is discarded. This short-lived split is closely related to a blockchain reorg.
These temporary forks are normal and usually invisible to users, but applications that treat unconfirmed blocks as settled can show transactions that later disappear. Waiting for finality before treating funds as final is the standard defense against acting on a block that gets reorged out.
What are replay attacks during a fork?
When a hard fork creates two chains that share history, a transaction signed for one chain may also be valid on the other, because the account, balance, and signature scheme are identical at the split point. An attacker can rebroadcast (replay) your transaction on the second chain to move funds you did not intend to move. Well-managed forks add replay protection, such as a unique chain ID, so a transaction is only valid on its intended network. Wallet and node operators should confirm replay protection is in place before transacting after a contentious split.
How do developers prepare for a blockchain fork?
Preparing for a planned fork is mostly about timing and testing. The checklist below covers the steps most teams follow ahead of a scheduled hard fork.
Step
What to do
Why it matters
Track the schedule
Note the fork block or timestamp
Missing it leaves you on the old chain
Upgrade clients
Update node software in advance
Old clients reject new blocks
Test on testnet
Validate contracts against new rules
Catches breaking changes early
Confirm replay protection
Check for a unique chain ID
Prevents cross-chain replay
Use managed infrastructure
Offload upgrades to a provider
Removes single points of failure
Teams that rely on managed RPC avoid most of this work, because the provider upgrades nodes before activation. For event-driven apps, Webhooks and Streams deliver post-fork data without manual client management.
常見問題
Do you get free coins from a hard fork?
If a hard fork creates a second persistent chain, holders of the original asset hold an equal balance on the new chain at the fork point. This is how Ethereum Classic and Bitcoin Cash holders received coins. The new asset only has value if the forked chain attracts real community and market support, which most forks never do.
Is a soft fork or a hard fork safer?
Soft forks are generally lower risk because they keep the network unified and do not require every participant to upgrade at once. Hard forks are more powerful but riskier, since nodes that fail to upgrade are stranded on the old chain and contentious splits can fragment the community.
What is the difference between a fork and a reorg?
A fork is a divergence in the protocol rules or the chain history, while a reorg is the network replacing recently added blocks with a competing branch. A short accidental fork is resolved by a reorg, whereas a hard fork is a permanent rule change that can create two lasting chains.
Can a blockchain fork be reversed?
A planned or contentious hard fork is permanent once both chains have independent support, because each network keeps producing blocks under its own rules. Accidental forks, by contrast, resolve automatically within a block or two as the network converges on a single canonical chain.
How does a fork affect my application?
During a planned fork your node must run upgraded software to keep following the canonical chain, or it will serve stale data. Using a managed RPC provider that handles fork transitions means your endpoints keep returning canonical data through the upgrade without any action on your part.
How Quicknode Handles Forks
Quicknode's infrastructure team monitors all planned hard forks across 80+ supported networks and ensures that nodes are upgraded before fork activation. This means developers using Quicknode do not need to manage client upgrades themselves or risk their applications ending up on the wrong side of a fork. When a chain undergoes a planned hard fork, Quicknode handles the transition seamlessly, and your RPC endpoints continue serving data from the canonical, upgraded chain.
For contentious forks where both chains continue operating, Quicknode evaluates community support, security, and developer demand before deciding whether to add the new chain as a supported network. Quicknode's multi-chain infrastructure means adding support for a newly forked chain is an infrastructure decision, not a development burden for customers.
Quicknode Streams handles fork transitions gracefully by delivering data in finality order, ensuring that any temporary chain ambiguity during the fork activation period does not result in incorrect data being delivered to your pipeline. Built-in reorg handling covers the edge cases that can arise during fork activation blocks.
