Performing changes and updating technology can be difficult at the best of times. For permissionless blockchain networks which are comprised of many users, distributed around the world, and governed by the consensus of the users, it becomes extremely difficult. Changes to a blockchain network’s protocol and data structures are called forks. They can be divided into two categories: soft forks and hard forks. For a soft fork, these changes are backwards compatible with nodes that have not been updated. For a hard fork, these changes are not backwards compatible because the nodes that have not been updated will reject the blocks following the changes.

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.

7. Challenges and Limitations of Blockchain Technology

7.6 Malicious Behavior and Hard Forks

Blockchain networks may face malicious users who attempt to disrupt operations.
To counter such threats, networks can perform a hard fork.

Hard Fork

A major update that creates a new version of the blockchain.
Can be used to:
- Reverse damage (e.g., stolen funds)
- Remove malicious effects
Decision depends on:
- Developers
- Community consensus

7.7 Trust in Blockchain Systems

A common misconception is that blockchain is “trustless”.
In reality, blockchain systems still require various forms of trust.

Key Trust Factors

Cryptographic Trust
- Reliance on algorithms like SHA-256
- Vulnerabilities may exist in implementation
Smart Contracts
- Must be bug-free
- May contain loopholes or unintended behavior
Software Developers
- Trust that developers write secure, error-free code
Network Majority Assumption
- Assumes most participants act honestly
- If a group controls >50% power → risk of attack
Node Trust
- Users not running full nodes rely on others to:
  - Process transactions correctly
  - Maintain fairness

7.8 Resource Usage

Blockchain networks, especially those using Proof of Work, consume significant resources.

Energy Consumption

High electricity usage due to mining
Example:
- Bitcoin consumes energy comparable to entire countries

Reasons for High Usage

Continuous puzzle solving
Increasing difficulty levels
Growing network size

Network and Storage Costs

Full nodes must download entire blockchain
Example:
- Bitcoin blockchain size: 175+ GB
Requires:
- High bandwidth
- Large storage capacity

Alternative Approaches

Permissioned blockchains use:
- Less resource-intensive consensus mechanisms
- Different trust models

7.9 Inadequate Block Publishing Rewards

Problem

Mining may become unprofitable due to:
- High electricity costs
- Increased competition
- Market volatility

Consequences

Slower block creation
Delayed transactions
Reduced user confidence
Lower market value

Security Risks

Weak networks become vulnerable to attacks:
- Blockchain manipulation
- Denial of service
- Control by powerful nodes

7.10 Public Key Infrastructure and Identity

Blockchain uses public key cryptography, but it does not inherently provide identity management.

Key Points

No one-to-one mapping:
- One user → multiple private keys
- One public key → multiple addresses

Digital Signatures

Used to:
- Verify transaction ownership
Do NOT:
- Link to real-world identities

Identity Limitations

Blockchain ensures:
- Ownership of keys
But does NOT ensure:
- Real-world identity verification

External Identity Linking

Real-world identity can be linked through:
- External systems (e.g., KYC processes)
These are:
- Not native to blockchain
- Outside its core functionality