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. Figure 4: Ledger in Conflict Conflicts are usually quickly resolved. Most blockchain networks will wait until the next block is published and use that chain as the “official” blockchain, thus adopting the “longer blockchain”. As in Figure 5, the blockchain containing block_n(B) becomes the “official” chain, as it got NISTIR 8202 BLOCKCHAIN TECHNOLOGY OVERVIEW 28

This publication is available free of charge from: https://doi.org/10.6028/NIST.IR.8202 the next valid block. Any transaction that was present in block_n(A), the orphaned block, but not present in the block_n(B) chain, is returned to the pending transaction pool (which is where all transactions which have not been included within a block reside). Note that this set of pending transactions is maintained locally at each node as there is no central server in the architecture. Figure 5: The chain with block_n(B) adds the next block, the chain with block_n(A) is now orphaned

Due to the possibility of blocks being overwritten, a transaction is not usually accepted as confirmed until several additional blocks have been created on top of the block containing the relevant transaction. The acceptance of a block is often probabilistic rather than deterministic since blocks can be superseded. The more blocks that have been built on top of a published block, the more likely it is that the initial block will not be overwritten. Hypothetically, a node in a proof of work blockchain network with enormous amounts of computing power could start at the genesis block and create a longer chain than the currently existing chain, thereby wiping out the entire blockchain history. This does not happen in practice due to the prohibitively large amount of resources that this would require. Also, some blockchain implementations lock specific older blocks within the blockchain software by creatin

Soft Forks DSD:

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.

3.8 Smart Contracts

The term smart contract was first introduced in 1994 by Nick Szabo, who defined it as “a computerized transaction protocol that executes the terms of a contract.” The primary objectives of smart contract design include satisfying common contractual conditions (such as payment terms, liens, confidentiality, and enforcement), minimizing malicious and accidental exceptions, and reducing reliance on trusted intermediaries.

Smart contracts extend and leverage blockchain technology by embedding executable logic directly into the distributed ledger environment.

3.8.1 Definition and Structure

A smart contract is a collection of code and associated data (often referred to as functions and state) deployed to a blockchain network through cryptographically signed transactions. Once deployed, the smart contract resides on the blockchain and is executed by participating nodes.

Examples of blockchain platforms that support smart contracts include:

Ethereum (smart contracts)
Hyperledger Fabric (chaincode)

All nodes executing a smart contract must produce identical results when given the same input. The results of execution—including any updates to state—are recorded on the blockchain, ensuring transparency and immutability.

It is important to note that not all blockchain implementations support smart contract functionality.

3.8.2 Execution and Functionality

Blockchain users interact with smart contracts by creating transactions that invoke publicly accessible functions defined within the contract. These transactions provide input parameters, which the contract processes to perform the requested operation.

Because smart contract code is stored on the blockchain, it is tamper-evident and tamper-resistant. This property allows smart contracts to function, in certain contexts, as a trusted third-party mechanism without requiring centralized oversight.

Smart contracts can:

Perform computations
Store and manage information
Expose publicly viewable state variables
Automatically transfer digital assets
Facilitate complex business logic

Importantly, smart contracts are not limited to financial applications. For example, researchers have deployed a smart contract on Ethereum capable of generating publicly verifiable random numbers.

3.8.3 Multi-Party Transactions and Business Processes

Smart contracts can represent multi-party transactions, often within broader business processes. In such scenarios, smart contracts provide:

Attestable and transparent records
Reduced need for reconciliation between organizations
Improved operational efficiency
Faster transaction completion
Increased trust among participants

By automating contractual logic, smart contracts reduce administrative overhead and minimize the potential for disputes arising from inconsistent recordkeeping.

3.8.4 Determinism Requirement

Smart contracts must be deterministic. Given a specific input, they must always produce the same output. Furthermore, all nodes executing the contract must agree on the resulting state.

To ensure determinism, smart contracts cannot directly access external data sources (e.g., web services) during execution. Any required external data must be provided as an input parameter.

When a smart contract depends on data from outside the blockchain environment, it is said to rely on an oracle. The challenge of securely integrating external data into blockchain systems is commonly referred to as the “oracle problem.”

3.8.5 Execution in Permissionless Blockchain Networks

In permissionless blockchain networks such as Ethereum, publishing nodes execute smart contract code when including transactions in new blocks.

Users submitting transactions to smart contracts must pay for the computational cost of execution. On Ethereum, this cost is measured in gas, which reflects the amount of computational effort required. There is a limit to how much computation a smart contract call may consume. If execution exceeds this limit, it is halted and the transaction is discarded.

This mechanism serves two purposes:

It compensates publishing nodes for performing computation.
It protects the network from denial-of-service attacks, such as contracts containing infinite loops designed to exhaust system resources.

3.8.6 Execution in Permissioned Blockchain Networks

In permissioned blockchain networks, such as those utilizing Hyperledger Fabric, participants are known and authenticated entities. In these environments, users may not be required to pay transaction fees for smart contract execution.

Because participants are identifiable and access-controlled, alternative governance mechanisms can be implemented to prevent malicious behavior. For example:

Access privileges can be revoked.
Participation rights can be restricted.
Organizational policies can be enforced.

These governance controls reduce the need for computational cost-based protections commonly used in permissionless networks.

3.8.7 Summary

Smart contracts represent a significant advancement in blockchain technology by enabling automated, transparent, and tamper-resistant execution of contractual logic. By combining cryptographic security, distributed consensus, and deterministic computation, smart contracts reduce reliance on intermediaries and increase trust in digital transactions across diverse applications.