As discussed previously, for some blockchain networks it is possible that multiple blocks will be published at approximately the same time. This can cause differing versions of a blockchain to exist at any given moment; these must be resolved quickly to have consistency in the blockchain network. In this section, we discuss how these situations are generally handled. With any distributed network, some systems within the network will be behind on information or have alternative information. This depends on network latency between nodes and the proximity of groups of nodes. Permissionless blockchain networks are more prone to have conflicts due to their openness and number of competing publishing nodes. A major part of agreeing on the state of the blockchain network (coming to consensus) is resolving conflicting data. For example: • node_A creates block_n(A)with transactions #1, 2 and 3. node_A distributes it to some nodes.
• node_B creates block_n(B)with transactions #1, 2 and 4. node_B distributes it to some nodes. • There is a conflict. o block_n will not be the same across the network. block_n(A) contains transaction #3, but not transaction #4. block_n(B) contains transaction #4, but not transaction #3. Conflicts temporarily generate different versions of the blockchain, which is depicted in Figure 4. These differing versions are not “wrong”; rather, they were created with the information each node had available. The competing blocks will likely contain different transactions, so those with block_n(A) may see transfers of digital assets not present in block_n(B). If the blockchain network deals with cryptocurrency, then a situation may occur where some cryptocurrency may both be spent and unspent, depending on which version of the blockchain is being viewed.
This can lead to a split in the blockchain network creating multiple versions of the same blockchain. Permissioned blockchain networks, due to the publishing nodes and users being known, can mitigate the issues of forking by requiring software updates. Note that the term fork is also used by some blockchain networks to describe temporary ledger conflicts (e.g., two or more blocks within the blockchain network with the same block number) as described in Section 4.7. While this is a fork in the ledger, it is temporary and does not stem from a software change. 5.1 Soft Forks A soft fork is a change to a blockchain implementation that is backwards compatible. Nonupdated nodes can continue to transact with updated nodes. If no (or very few) nodes upgrade, then the updated rules will not be followed.
An example of a soft fork occurred on Bitcoin when a new rule was added to support escrow8 and time-locked refunds. In 2014, a proposal was made to repurpose an operation code that performed no operation (OP_NOP2) to CHECKLOCKTIMEVERIFY, which allows a transaction output to be made spendable at a point in the future [14]. For nodes that implement this change, the node software will perform this new operation, but for nodes that do not support the change, the transaction is still valid, and execution will continue as if a NOP 9 had been executed.
A fictional example of a soft fork would be if a blockchain decided to reduce the size of blocks (for example from 1.0 MB to 0.5 MB). Updated nodes would adjust the block size and continue to transact as normal; non-updated nodes would see these blocks as valid – since the change made does not violate their rules (i.e., the block size is under their maximum allowed). However, if a non-updated node were to create a block with a size greater than 0.5 MB, updated nodes would reject them as invalid. 5.2 Hard Forks A hard fork is a change to a blockchain implementation that is not backwards compatible.
At a 8 Funds placed into a third party to be disseminated based on conditions (via multi-signature transactions) 9 NOP meaning No Operation NISTIR 8202 BLOCKCHAIN TECHNOLOGY OVERVIEW 30 This publication is available free of charge from: https://doi.org/10.6028/NIST.IR.8202 given point in time (usually at a specific block number), all publishing nodes will need to switch to using the updated protocol. Additionally, all nodes will need to upgrade to the new protocol so that they do not reject the newly formatted blocks. Non-updated nodes cannot continue to transact on the updated blockchain because they are programmed to reject any block that does not follow their version of the block specification. Publishing nodes that do not update will continue to publish blocks using the old format. User nodes that have not updated will reject the newly formatted blocks and only accept blocks with the old format.
This results in two versions of the blockchain existing simultaneously. Note that users on different hard fork versions cannot interact with one another. It is important to note that while most hard forks are intentional, software errors may produce unintentional hard forks. A well-known example of a hard fork is from Ethereum. In 2016, a smart contract was constructed on Ethereum called the Decentralized Autonomous Organization (DAO). Due to flaws in how the smart contract was constructed, an attacker extracted Ether, the cryptocurrency used by Ethereum, resulting in the theft of $50 million [15]. A hard fork proposal was voted on by Ether holders, and the clear majority of users agreed to hard fork and create a new version of the blockchain, without the flaw, and that also returned the stolen funds. With cryptocurrencies, if there is a hard fork and the blockchain splits then users will have independent currency on both forks (having double the number of coins in total). If all the activity moves to the new chain, the old one may eventually not be used since the two chains are not compatible (they will be independent currency systems).
In the case of the Ethereum hard fork, the clear majority of support moved to the new fork, the old fork was renamed Ethereum Classic and continued operating. 5.3 Cryptographic Changes and Forks If flaws are found in the cryptographic technologies within a blockchain network, the only solution may be to create a hard fork, depending on the significance of the flaw. For example, if a flaw was found in the underlying algorithms, there could be a fork requiring all future clients to use a stronger algorithm. Switching to a new hashing algorithm could pose a significant practical problem because it could invalidate all existing specialized mining hardware.
Hypothetically, if SHA-256 were discovered to have a flaw, blockchain networks that utilize SHA-256 would need a hard fork to migrate to a new hash algorithm. The block that switched over to the new hash algorithm would “lock” all previous blocks into SHA-256 (for verification), and all new blocks would need to utilize the new hashing algorithm. There are many cryptographic hash algorithms, and blockchain networks can make use of whichever suits their needs.
For example, while Bitcoin uses SHA-256, Ethereum uses Keccak-256 [8]. One possibility for the need to change cryptographic features present in a blockchain network would be the development of a practical quantum computer system, which would be capable of greatly weakening (and in some cases, rendering useless) existing cryptographic algorithms. NIST Internal Report (NISTIR) 8105, Report on Post-Quantum Cryptography [16] provides a table describing the impact of quantum computing on common cryptographic algorithms. Table 2 replicates this table.
1. Introduction to Forking
Updating and modifying blockchain systems can be complex, especially in permissionless networks where users are globally distributed and decisions rely on consensus.
A fork refers to changes in a blockchain’s:
Protocol
Data structures
Forks are categorized into:
Soft Forks
Hard Forks
In permissioned blockchain networks, forking issues are easier to manage because:
Participants are known
Updates can be enforced
Additionally, the term fork can also describe temporary ledger conflicts (e.g., multiple blocks with the same number). These are short-lived and not related to protocol changes.
2. Soft Forks
2.1 Definition
A soft fork is a blockchain update that is backwards compatible.
Updated and non-updated nodes can still interact
Older nodes continue functioning without upgrading
However, if most nodes do not upgrade, new rules may not be enforced
2.2 Example (Bitcoin Soft Fork)
An example occurred in Bitcoin:
A proposal modified an operation code:
From:
OP_NOP2(No Operation)To:
CHECKLOCKTIMEVERIFY
This allowed:
Time-locked transactions (funds spendable in the future)
Behavior:
Updated nodes → enforce new rule
Non-updated nodes → treat it as a no-op and still accept the transaction
2.3 Hypothetical Example
If block size is reduced:
From 1.0 MB → 0.5 MB
Outcome:
Updated nodes → enforce 0.5 MB limit
Non-updated nodes → still accept smaller blocks
But:
Blocks larger than 0.5 MB created by old nodes → rejected by updated nodes
2.4 Key Characteristics
Backwards compatible
Safer and less disruptive
Requires majority adoption for effectiveness
3. Hard Forks
3.1 Definition
A hard fork is a blockchain update that is not backwards compatible.
All nodes must upgrade to the new protocol
Non-updated nodes:
Reject new blocks
Continue operating on old rules
3.2 Effects of a Hard Fork
Blockchain splits into two separate chains
Each chain follows different rules
Users on different chains cannot interact
3.3 Ethereum DAO Hard Fork Example
A well-known hard fork occurred in Ethereum in 2016:
A smart contract called the DAO (Decentralized Autonomous Organization) had a flaw
An attacker stole $50 million worth of Ether
The community voted to:
Reverse the effects of the attack
Create a new version of the blockchain
Result:
New chain → retained the name Ethereum
Old chain → became Ethereum Classic
3.4 Currency Impact
After a hard fork:
Users hold coins on both chains
These become independent currencies
If most users migrate:
The old chain may lose relevance
3.5 Key Characteristics
Not backwards compatible
Requires full network upgrade
Can create permanent blockchain splits
4. Cryptographic Changes and Forks
4.1 Need for Cryptographic Updates
If a flaw is discovered in blockchain cryptography:
A hard fork may be required
The system must transition to stronger algorithms
4.2 Hash Algorithm Changes
Example:
Bitcoin uses SHA-256
Ethereum uses Keccak-256
If SHA-256 becomes insecure:
A hard fork would:
Keep old blocks using SHA-256 (for verification)
Require new blocks to use a new algorithm
4.3 Challenges
May invalidate specialized mining hardware
Requires full ecosystem transition
High coordination effort
4.4 Quantum Computing Threat
Future quantum computers could:
Break current cryptographic algorithms
Force blockchain networks to:
Upgrade cryptographic systems
Implement quantum-resistant algorithms
5. Conclusion
Forking is essential for the evolution of blockchain systems but comes with trade-offs:
Soft forks → gradual, compatible upgrades
Hard forks → major changes, possible network splits
While forks enable innovation and security improvements, they also require strong consensus and coordination among network participants to avoid fragmentation.
0 Comments