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 failure for attackers to compromise. As a result, projects like ‘Mineable Oracle Contract’ [23] have recently arisen to enable oracle ingestion in a way that is inspired by blockchain technology and built atop established consensus models and economic incentives. 7.4

Blockchain Death Traditional centralized systems are created and taken down constantly, and blockchain networks will likely not be different. However, because they are decentralized, there is a chance that when a blockchain network “shuts down” it will never be fully shut down, and that there may always be some lingering blockchain nodes running. A defunct blockchain would not be suitable for a historical record, since without many publishing nodes, a malicious user could easily overpower the few publishing nodes left and redo and replace any number of blocks.

7.5 Cybersecurity The use of blockchain technology does not remove inherent cybersecurity risks that require thoughtful and proactive risk management. Many of these inherent risks involve a human element. Therefore, a robust cybersecurity program remains vital to protecting the network and participating organizations from cyber threats, particularly as hackers develop more knowledge about blockchain networks and their vulnerabilities. Existing cybersecurity standards and guidance remain highly relevant for ensuring the security of systems that interface and/or rely on blockchain networks. Subject to certain adjustments to consider specific attributes of blockchain technology, existing standa

In addition to general principles and controls, there are specific cybersecurity standards with relevance to blockchain technology which already exist and are in wide use by many industries. For instance, the NIST Cybersecurity Framework expressly states that it is “not a one-size-fits-all approach to managing cybersecurity risk” because “organizations will continue to have unique risks—different threats, different vulnerabilities, different risk tolerances—and how they implement the practices in the [Framework] will vary.” With that said, even though the Framework was not designed for blockchain technology specifically, its standards are broad enough to cover blockchain technology and to help institutions develop policies and processes that identify and control risks affecting blockchain technology. 7.5.1 Cyber and Network-based Attacks Blockchain technologies are touted as being extremely secure due to the tamper evident and tamper resistant design – once a transaction is committed to the blockchain, it generally cannot be changed. However, this is only true for transactions which have been included in a published block. Transactions that have not yet been included in a published block within the blockchain are vulnerable to several types of attacks. For blockchain networks which have transactional timestamps, spoofing time or adjusting the clock of a member of an ordering service could have positive or negative effects on a transaction, making time and the communication of time an attack vector. Denial of service attacks can be conducted on the blockchain platform or on the smart contract implemented on the platform. Blockchain networks and their applications are not immune to malicious actors who can conduct network scanning and reconnaissance to discover and exploit vulnerabilities and launch zero-day attacks. In the rush to deploy blockchain-based services, newly coded applications (like smart contracts) may contain new and known vulnerabilities and deployment weaknesses that will be discovered and then attacked through the network just like how websites or applications are attacked today. 7.6 Malicious Users While a blockchain network can enforce transaction rules and specifications, it cannot enforce a user code of conduct. This is problematic in permissionless blockchain networks, since users are pseudonymous and there is not a one-to-one mapping between blockchain network user identifiers and users of the system. Permissionless blockchain networks often provide a reward (e.g., a cryptocurrency) to motivate users to act fairly; however, some may choose to act maliciously if that provides greater rewards. The largest problem for malicious users is getting enough power (be it a stake in the system, processing power, etc.) to cause damage. Once a large enough malicious collusion is created, malicious mining actions can include: • Ignoring transactions from specific users, nodes, or even entire countries. • Creating an altered, alternative chain in secret, then submitting it once the alternative chain is longer than the real chain. The honest nodes will switch to the chain that has the most “work” done (per the blockchain protocol). This could attack the principle of a blockchain network being tamper evident and tamper resistant [24]. • Refusing to transmit blocks to other nodes, essentially disrupting the distribution of information (this is not an issue if the blockchain network is sufficiently decentralized). NISTIR 8202 BLOCKCHAIN TECHNOLOGY OVERVIEW 38 This publication is available free of charge from: https://doi.org/10.6028/NIST.IR.8202 While malicious users can be annoyances and create short-term harm, blockchain networks can perform hard forks to combat them. Whether damages done (money lost) would be reversed would be up to the developers and users of the blockchain network. In addition to there being malicious users of the network, the administrators of the infrastructure for permissioned blockchain networks may also act maliciously. For example, an infrastructure administrator may be able (depending upon the exact configuration) to take over block production, exclude certain users from performing transactions, rewrite block history, double spend coin, delete resources, or re-route or block network connections. 7.7 No Trust Another common misinterpretation comes from people hearing that there is no “trusted third party” in a blockchain and assuming blockchain networks are “trustless” environments. While there is no trusted third party certifying transactions in permissionless blockchain networks (in permissioned systems it is less clear, as administrators of those systems act as an administrator of trust by granting users admission and permissions), there is still a great deal of trust needed to work within a blockchain network: • There is trust in the cryptographic technologies utilized. For example, cryptographic algorithms or implementations can have flaws. • There is trust in the correct and bug free operation of smart contracts, which might have unintended loopholes and flaws. • There is trust in the developers of the software to produce software that is as bug-free as possible. • There is trust that most users of the blockchain are not colluding in secret. If a single group or individual can control more than 50 percent of all block creation power, it is possible to subvert a permissionless blockchain network. However, generally obtaining the necessary computational power is prohibitively expensive. • For blockchain network users not running a full node, there is trust that nodes are accepting and processing transactions fairly. 7.8 Resource Usage Blockchain technology has enabled a worldwide network where every transaction is verified and the blockchain is kept in sync amongst a multitude of users. For blockchain networks utilizing proof of work, there are many publishing nodes expending large amounts of processing time and, more importantly, consuming a lot of electricity. A proof of work method is an effective solution for “hard to solve, easy to verify” proofs; however, it generally requires significant resource usage. Because of their different applications, and trust models, many permissioned blockchain technologies do not use a resource intensive proof, but rather they utilize different mechanisms to achieve consensus. The proof of work consensus model is designed for the case where there is little to no trust amongst users of the system. It ensures that publishing nodes cannot game the system10 by

Appendix A – Glossary of Terms

The following terms used in this document are defined below.

Address

A short, alphanumeric string derived from a user’s public key through the use of a cryptographic hash function, often including additional data for error detection. Addresses are used to send and receive digital assets within a blockchain network.

Assets

Any item of value that can be transferred between participants. In blockchain systems, assets may include cryptocurrencies, digital tokens, digital property, or other forms of digitally represented value.

Asymmetric-Key Cryptography

A cryptographic system in which users possess a private key that is kept secret and used to generate a corresponding public key, which is freely distributed.

Users can digitally sign data using their private key, and the resulting signature can be verified by anyone using the associated public key.

Also known as Public-Key Cryptography.

Block

A structured data unit containing both a block header and block data.

Block Data

The portion of a block that contains a set of validated transactions and ledger events that are to be recorded on the blockchain.

Block Header

The portion of a block that contains metadata about the block. This typically includes:

A timestamp
A hash representation of the block data
The hash of the previous block’s header
A cryptographic nonce (if required by the consensus model)

Block Reward

A reward—typically in the form of cryptocurrency—granted to a publishing node for successfully adding a new block to the blockchain.

Blockchain

A distributed digital ledger consisting of cryptographically signed transactions grouped into blocks. Each block is cryptographically linked to the previous block, making the ledger tamper-evident.

After validation and consensus, blocks are added sequentially. As additional blocks are appended, earlier blocks become increasingly difficult to modify, providing tamper resistance.

Copies of the ledger are replicated across the network, and conflicts are resolved automatically according to established consensus rules.

Blockchain Network User

Any individual, group, business, or organization that uses or operates a blockchain node.

Byzantine Fault Tolerant Proof of Stake Consensus Model

A Proof of Stake (PoS) consensus model in which all staked participants vote on which proposed block should be added next. The system tolerates certain types of faulty or malicious behavior while still achieving consensus.

Centralized Network

A network configuration in which all participants must communicate through a central authority in order to interact with one another.

Because communication depends on a single central source, the failure or loss of that source would prevent all participants from communicating.

Chain-Based Proof of Stake Consensus Model

A Proof of Stake (PoS) consensus model in which the next block producer is selected through a pseudo-random process. Selection is typically weighted based on the ratio of an individual participant’s stake relative to the total system stake.

Checksum

A value computed from a set of data to detect errors or manipulation. Checksums are commonly used to ensure data integrity during transmission or storage.

Confirmed

The state of a transaction or block after consensus has been reached regarding its inclusion in the blockchain.

Conflict

A situation in which one or more participants disagree about the current state of the blockchain system.

Conflict Resolution

A predefined method used to achieve consensus on the valid state of the system when disagreements arise.

For example, if one group of participants recognizes State_A as valid and another group recognizes State_B as valid, a conflict exists. The system resolves the conflict automatically by accepting the state associated with the group that successfully adds the next valid block according to the consensus rules.

Transactions not included in the accepted state may be returned to the pending transaction pool.

Consensus Model

A mechanism used within a distributed system to achieve agreement on the valid state of the ledger.

Also known as:

Consensus algorithm
Consensus mechanism
Consensus method

Cryptocurrency

A digital asset, credit, or unit of value within a blockchain system that is cryptographically transferred between blockchain network users.

In cases where new cryptocurrency is created (such as through mining rewards), the publishing node includes a transaction that allocates the newly generated cryptocurrency to one or more blockchain network users.

These digital assets are transferred using cryptographic signatures and validated according to the rules of the blockchain network.