Most publications on blockchain technology describe blockchain ledgers as being immutable. However, this is not strictly true. They are tamper evident and tamper resistant which is a reason they are trusted for financial transactions. They cannot be considered completely immutable, because there are situations in which the blockchain can be modified. In this section we will look at different ways in which the concept of immutability for blockchain ledgers can be violated. The chain of blocks itself cannot be considered completely immutable. For some blockchain implementations, the most recently published, or ‘tail’ blocks are subject to being replaced (by a longer, alternative chain with different ‘tail’ blocks).

As noted earlier, most blockchain networks use the strategy of adopting the longest chain (the one with the most amount of work put into it) as truth when there are multiple competing chains. If two chains are competing, but each include their own unique sequence of tail blocks, whichever is longer will be adopted. However, this does not mean that the transactions within the replaced blocks are lost – rather they may have been included in a different block or returned to the pending transaction pool. This degree of weak immutability for tail blocks is why most blockchain network users wait several block creations before considering a transaction to be valid. For permissionless blockchain networks, the adoption of a longer, alternate chain of blocks could be the result of a form of attack known as a 51 % attack [19].

For this, the attacker simply garners enough resources to outpace the block creation rate of rest of the blockchain network (holding more than 51 % of the resources applied towards producing new blocks). Depending on the size of the blockchain network, this could be a very cost prohibitive attack carried out by state level actors [20]. The cost to perform this type of attack increases the further back in the blockchain the attacker wishes to make a change. This attack is not technically difficult (e.g., it is just repeating the normal process of the blockchain implementation, but with selected transactions either included or omitted, and at a faster pace), it is just expensive. For permissioned blockchain networks, this attack can be mitigated. There is generally an owner or consortium of blockchain network users who allow publishing nodes to join the blockchain network and remove publishing nodes from the blockchain network, which gives them a great amount of control. There is less likely to be competing chains since the owner or consortium can force publishing nodes to collaborate fairly since non-cooperating publishing nodes can simply have their privileges removed.

There are likely additional legal contracts in place for the blockchain network users which may include clauses for misconduct and the ability to take legal action. While this control is useful to prevent misconduct, it means that any number of blocks can be replaced through legitimate methods if desired by the owner or consortium. NISTIR 8202 BLOCKCHAIN TECHNOLOGY OVERVIEW 35 This publication is available free of charge from: https://doi.org/10.6028/NIST.IR.8202 7.2 Users Involved in Blockchain Governance The governance of blockchain networks deals with the rules, practices and processes by which the blockchain network is directed and controlled. A common misconception is that blockchain networks are systems without control and ownership. The phrase “no one controls a blockchain!” is often exclaimed. This is not strictly true. Permissioned blockchain networks are generally setup and run by an owner or consortium, which governs the blockchain network. Permissionless blockchain networks are often governed by blockchain network users, publishing nodes, and software developers.

Each group has a level of control that affects the direction of the blockchain network’s advancement. Software developers create the blockchain software that is utilized by a blockchain network. Since most blockchain technologies are open source, it is possible to inspect the source code, and compile it independently; it is even possible to create separate but compatible software as a means of bypassing pre-compiled software released by developers. However, not every user will have the ability to do this, which means that the developer of the blockchain software will play a large role in the blockchain network’s governance. These developers may act in the interest of the community at large and are held accountable.

For example, in 2013 Bitcoin developers released a new version of the most popular Bitcoin client which introduced a flaw and started two competing chains of blocks. The developers had to decide to either keep the new version (which had not yet been adopted by everyone) or revert to the old version [21]. Either choice would result in one chain being discarded

and some blockchain network user’s transactions becoming invalid. The developers made a choice, reverted to the old version, and successfully controlled the progress of the Bitcoin blockchain. This example was an unintentional fork; however, developers can purposely design updates to blockchain software to change the blockchain protocol or format. With enough user adoption, a successful fork can be created. Such forks of blockchain software updates are often discussed at length and coordinated with the involved users. For permissionless blockchain networks, this is usually the publishing nodes.

There is often a long discussion and adoption period before an event occurs where all users must switch to the newly updated blockchain software at some chosen block to continue recording transactions on the new “main” fork. For permissionless blockchain networks, although the developers maintain a large degree of influence, users can reject a change by the developers by refusing to install updated software. Of the blockchain network users, the publishing nodes have significant control since they create and publish new blocks. The user base usually adopts the blocks produced by the publishing nodes but is not required to do so. An interesting side effect of this is that permissionless blockchain networks are essentially ruled by the publishing nodes and may marginalize a segment of users by forcing them to adopt changes they may disagree with to stay with the main fork.

For permissioned blockchain networks, control and governance is driven by members of the associated owner or consortium. The consortium can govern who can join the network, when members are removed from the network, coding guidelines for smart contracts, etc. In summary, the software developers, publishing nodes, and blockchain network users all play a part in the blockchain network governance. NISTIR 8202 BLOCKCHAIN TECHNOLOGY OVERVIEW 36 This publication is available free of charge from: https://doi.org/10.6028/NIST.IR.8202 7.3 Beyond the Digital Blockchain networks work extremely well with the data within their own digital systems.

However, when they need to interact with the real world, there are some issues (often called the Oracle Problem [22]). A blockchain network can be a place to record both human input data as well as sensor input data from the real world, but there may be no method to determine if the input data reflects real world events. A sensor could be malfunctioning and recording data that is inaccurate. Humans could record false information (intentionally or unintentionally).

These issues are not specific to blockchain networks, but to digital systems overall. However, for blockchain networks that are pseudonymous, dealing with data misrepresentation outside of the digital network can be especially problematic. For example, if a cryptocurrency transaction took place to purchase a real-world item there is no way to determine within the blockchain network whether the shipment took place, without relying on outside sensor or human input. Many projects have attempted to address the ‘Oracle problem’ and create reliable mechanisms to ingest external data in a way that is both trustworthy and accurate. For example, projects like ‘Oraclize’ provide mechanisms to take web API data and convert it into blockchain readable byte/opcode. Within the context of decentralized applications, these projects may be considered centralized as they provide single points of failed

1. Industry Guidance and Research

Several organizations and experts have developed frameworks to help determine whether blockchain is appropriate for a given use case.

1.1 ACT-IAC Contributions

The American Council for Technology and Industry Advisory Council is a public-private partnership that promotes collaboration between government and industry.

They have developed:

A blockchain primer → provides a general overview of the technology
A blockchain playbook → offers structured questions (with weighted criteria) to evaluate blockchain adoption

1.2 Academic Perspective

Researchers from ETH Zürich authored the paper “Do You Need a Blockchain?”

Key insights:

Many use cases do not require blockchain
Decision frameworks often lead to:
- “No” in most cases
- “Maybe” in limited scenarios

Core message:
Organizations should critically evaluate whether traditional technologies can solve their problem more effectively.

1.3 IEEE Perspective

The Institute of Electrical and Electronics Engineers highlighted blockchain considerations in its Spectrum publication.

Key points:

Blockchain can act as an anti-censorship tool
Eliminates reliance on central authorities
Requires coordination among unaffiliated participants
Governance can become complex

Important takeaway:

Organizations should seriously consider whether they actually need blockchain at all.

1.4 Industry Commentary

The blockchain-focused platform CoinDesk emphasizes:

Blockchain’s main advantage is decentralization
However, it is computationally inefficient

Key idea:

Use blockchain only when decentralization is necessary
Otherwise, traditional systems are more efficient

1.5 Developer Perspective

Developers have also contributed practical viewpoints through platforms like C# Corner.

Core principle:

Blockchain introduces trust into low-trust systems

They recommend:

Asking targeted questions
Using decision flowcharts before adoption

2. Key Takeaway

Across academic, industry, and developer perspectives, the consensus is clear:

Use blockchain only when it is the most appropriate solution—not simply because it is new or trending.

3. Additional Blockchain Considerations

When deciding to implement blockchain, organizations must evaluate several technical and operational factors:

3.1 Data Visibility

Permissioned Blockchains

Data access may be restricted
Suitable for controlled environments
Must consider regulations like:
- Personally Identifiable Information (PII)
- Data protection laws (e.g., GDPR)