Source-linked AI summary
Blockchain Technology Overview
Dylan Yaga, Peter Mell, Nik Roby, Karen Scarfone
TL;DR
Blockchain technology is widely hyped but insufficiently understood, motivating this paper’s high-level technical overview. It explains common blockchain mechanisms and approaches to support more informed decisions about when to use the technology, while noting important limitations.
Problem
Blockchain technology is surrounded by hype and misconceptions despite being insufficiently understood, creating a need to explain how it works for correct application.
Method
The paper synthesizes blockchain fundamentals, including distributed blocks, cryptographic links, digital signatures, consensus, deployment changes, and differences among approaches.
Results
The overview describes how blockchain networks support shared transaction records and how smart contracts can provide transparency, insight, and faster multi-party transactions.
Takeaways & Limitations
The document provides information for developing a high-level understanding of blockchain technology and judging when a blockchain network should be considered.
Takeaways & Limitations
Permissionless blockchains can face 51% attacks that allow attackers to create longer alternate chains and potentially alter selected transaction histories.
Abstract
from arXiv · showhide
Blockchains are tamper evident and tamper resistant digital ledgers implemented in a distributed fashion (i.e., without a central repository) and usually without a central authority (i.e., a bank, company, or government). At their basic level, they enable a community of users to record transactions in a shared ledger within that community, such that under normal operation of the blockchain network no transaction can be changed once published. This document provides a high-level technical overview of blockchain technology. The purpose is to help readers understand how blockchain technology works.
NISTIR 8202
NISTIR 8202 provides a high-level technical overview of blockchain technology, explaining how distributed ledgers let communities record transactions without a central repository or authority. It focuses on blockchain mechanisms and concepts including consensus models, cryptography, forks, smart contracts, and data oracles.
- NISTIR 8202 is a National Institute of Standards and Technology internal report.
- The overview covers consensus models, cryptographic techniques, distributed ledgers, proof mechanisms, forks, smart contracts, and data oracles.
Executive Summary
This document explains how blockchain technology works as a distributed, tamper-evident ledger and examines its approaches, core mechanisms, applications, and considerations for use. It emphasizes that blockchain is not a universal solution and should be applied where appropriate.
- Foundations: Blockchains are distributed digital ledgers that let communities record shared transactions so published transactions normally cannot be changed.They operate without a central repository and usually without a central authority.
- Blockchain approaches: Permissionless blockchains allow anyone to read and write without authorization, whereas permissioned networks restrict participation and provide finer-grained controls.This distinction helps organizations identify suitable subsets of blockchain technologies.
- Core concepts and applications: Common blockchain implementations use linked blocks containing metadata, transactions, and related data, and support functions such as cryptocurrencies, smart contracts, and business ledgers.Each block header, except the first, contains a cryptographic link to the previous block.
- Scope and purpose: The document explains blockchain fundamentals, including how networks validate transactions, handle changes, and determine when blockchain use is appropriate.It focuses on the method behind blockchain technology rather than the surrounding hype.
- Considerations: Blockchain adoption requires consideration of malicious users, controls, implementation limitations, operational factors, and governance issues rather than treating the technology as a silver bullet.Organizations are advised to evaluate potential benefits and use blockchain in appropriate situations.
1 Introduction
Blockchain technology is presented as a distributed, tamper-evident and tamper-resistant ledger for recording transactions without a central repository or usually a central authority. The overview explains its core components, trust mechanisms, implementation categories, and network effects.
- Core definition: Blockchains are distributed digital ledgers that record cryptographically signed transactions in shared, append-only histories without a central repository or usually a central authority.Under normal operation, published transactions cannot be changed; blockchain records are not overridden like traditional database values.
- Origins and Bitcoin: Bitcoin’s 2009 launch made blockchain technology widely known by enabling publicly recorded, independently verifiable transfers of digitally signed electronic cash rights.Blockchain implementation removed single-user control and a single point of failure, while enabling direct transactions without a trusted third party.
- Core definition: Transactions are grouped into validated blocks, cryptographically linked to previous blocks, replicated across network copies, and governed by automatic conflict resolution.As new blocks are added, older blocks become more difficult to modify, creating tamper resistance.
- Trust mechanisms: Blockchain trust relies on cryptographic security, shared transparency, append-only history, and distribution across multiple nodes.Increasing the number of nodes can improve resilience to attacks by reducing a bad actor’s ability to affect consensus.
- Network categories: Permissionless networks can establish trust among previously unknown parties, enabling direct transactions that may be faster and lower-cost than intermediary-based transactions.Permissioned networks control access more tightly, but the supplied passage does not provide the remainder of their effects.
2 Blockchain Categorization
Blockchain networks are categorized by their permission model: permissionless networks let anyone publish blocks, while permissioned networks require authorization. Permissioned networks can restrict participation and access, support organizational collaboration and privacy, and typically use faster, less computationally expensive consensus models.
- Permission models: Blockchain networks are categorized by who is allowed to maintain them by publishing blocks: anyone in permissionless networks, but only authorized users in permissioned networks.The permission model determines who can maintain the network.
- Permissionless networks: Permissionless networks are open to anyone publishing blocks without authority approval, and anyone can read the blockchain and issue transactions.They are often open-source software freely available for download.
- Permissioned networks: Permissioned networks can restrict block publication, read access, and transaction submission to authorized users, although some allow unrestricted reading or transaction submission.Authorization may be controlled by a centralized or decentralized authority.
- Permissioned networks: Permissioned networks usually use faster and less computationally expensive consensus models because participants are identified, authorized, and potentially subject to revocation for misconduct.Authorized maintainers have a level of trust with one another.
- Permissioned networks: Organizations can use permissioned networks to protect blockchain access, collaborate with business partners, and selectively reveal transaction information based on users’ identities or credentials.Selective disclosure can make transaction contents accessible only to involved parties while recording that the transaction occurred.
3 Blockchain Components … 3.3 Asymmetric-Key Cryptography
Blockchain technology combines cryptographic primitives with record-keeping mechanisms to support shared, tamper-resistant ledgers. Its components include hash functions, transactions, and asymmetric-key cryptography, which supports public transaction verification and private-key control.
- 3 Blockchain Components: Blockchain technology combines cryptographic hash functions, digital signatures, asymmetric-key cryptography, and append-only ledgers.These mechanisms and record-keeping concepts are presented as the technology’s main components.
- 3.1 Cryptographic Hash Functions: Hashing maps input data of nearly any size to a relatively unique message digest that users can independently reproduce to detect changes.Even a small change to the input affects the resulting digest.
- 3.1 Cryptographic Hash Functions: Cryptographic hash functions are preimage resistant and second preimage resistant, making it computationally infeasible to recover an input or find a different input with a specified output.These properties support the use of hashes for data integrity and tamper detection.
- 3.1 Cryptographic Hash Functions: SHA-256 produces a 256-bit, 32-byte digest commonly displayed as a 64-character hexadecimal string and is supported in hardware by many computers.SHA-256 is one cryptographic hash function used in many blockchain implementations.
- 3.2 Transactions: A transaction represents an interaction between parties, can transfer cryptocurrency or record asset activity, and blocks can contain zero or more transactions.Transaction data varies by blockchain implementation, although the transacting mechanism is largely the same.
- 3.2 Transactions: Transactions can transfer data, publicly post information, or send, process, and store data through smart contract systems.They can also change attributes of digitized assets, such as a shipment’s location.
- 3.3 Asymmetric-Key Cryptography: Asymmetric-key cryptography uses mathematically related public and private keys: public keys may be shared, while private keys must remain secret.Private keys digitally sign transactions, public keys derive addresses and verify signatures, and signatures demonstrate possession of the signing private key.
3.4 Addresses and Address Derivation · 3.5 Ledgers
Blockchain addresses are typically derived from public keys through cryptographic hashing and can identify users or deployed smart contracts. Blockchain ledgers distribute ownership, copies, validation, and storage across networks to improve resilience and tamper resistance.
- 3.4 Addresses and Address Derivation: Addresses are short alphanumeric identifiers typically derived from a user’s public key with a cryptographic hash function and additional data.Addresses commonly serve as transaction “to” and “from” endpoints.
- 3.4 Addresses and Address Derivation: A standard address-generation sequence is public key → cryptographic hash function → address.
- 3.4 Addresses and Address Derivation: Permissionless networks allow users to generate as many asymmetric-key pairs and addresses as desired, supporting pseudo-anonymity.Addresses may serve as public-facing identifiers and are often converted into QR codes.
- 3.4.1 Private Key Storage: Users often store private keys, public keys, and associated addresses in wallet software, but losing a private key permanently loses its associated digital assets.A stolen private key gives an attacker full access to the assets it controls.
- 3.5 Ledgers: A ledger is a collection of transactions, and blockchain technology enables distributed ownership alongside a distributed physical architecture.Blockchain networks often involve more computers than centrally managed distributed architectures.
- 3.5 Ledgers: Each user can maintain a copy of the ledger, while new full nodes can request a full copy, making ledger loss or destruction difficult.The network’s distributed design creates many backup copies that update and synchronize among peers.
- 3.5 Ledgers: Geographically diverse, peer-to-peer nodes make the network resilient to losing any node or even an entire region of nodes.Blockchain networks also validate transactions and cause other nodes to detect and ignore invalid transactions.
- 3.5 Ledgers: Cryptographic mechanisms provide tamper-evident and tamper-resistant ledgers, while the distributed network has no centralized point of attack.An attack on an unpatched individual node affects that node rather than the overall system.
3.6 Blocks · 3.7 Chaining Blocks
Blocks package validated transactions with metadata and are published by blockchain nodes to add transactions to the blockchain. Blocks are chained through previous-header hashes, making altered blocks detectable and rejectable.
- 3.6 Blocks: Users submit candidate transactions through software to blockchain nodes, which propagate them across the network without immediately adding them to the blockchain.Propagation alone does not place a transaction in the blockchain.
- 3.6 Blocks: A publishing node adds transactions by publishing a block containing a block header and block data.Block data contains validated and authentic submitted transactions; the header contains metadata.
- 3.6 Blocks: Blockchain implementations can define their own fields, but common block data includes the block number, previous block-header hash, and block-data hash.A block-data hash may use a Merkle-tree root hash or a hash of combined block data.
- 3.6 Blocks: Blocks may also include the block size, nonce value, transaction and ledger-event lists, and other data.In mining networks, the nonce is manipulated to solve a hash puzzle; other networks may omit it or use it differently.
- 3.7 Chaining Blocks: Blocks are chained because each block contains the hash digest of the previous block’s header, forming the blockchain.This linkage establishes the chain across successive blocks.
- 3.7 Chaining Blocks: Changing a published block changes its hash and consequently the hashes of all subsequent blocks that reference it.The resulting differences make altered blocks easy to detect and reject.
4 Consensus Models
Consensus models let mutually distrusting blockchain users agree on which block is added next and resolve competing publications without a trusted third party. They require independently valid, verifiable blocks and must tolerate temporary disagreement and potentially malicious users, while different models trade resource use, trust, and participation mechanisms.
- Consensus models: Consensus models determine which user publishes the next block and enable mutually distrusting users to coordinate and resolve competing block proposals.Permissionless networks may have many competing publishing nodes, often motivated by cryptocurrency or transaction fees.
- Consensus models: Every block follows the agreed consensus model, links to the previous block through its header hash, and can be independently validated by network users.The genesis block establishes the initial system state and is the only pre-configured block.
- Proof of work: Proof of work selects the first user to solve a computationally intensive puzzle whose solution is difficult to find but easy for other nodes to verify.Proposed blocks that fail the puzzle are rejected, and puzzle difficulty can be adjusted over time.
- Proof of work: 10,730,896 guesses took 54 seconds to solve a SHA-256 puzzle requiring six leading zeros, while seven leading zeros required 934,224,175 guesses and 1 hour, 18 minutes, 12 seconds.The example illustrates how an additional leading zero sharply increases proof-of-work difficulty and resource consumption.
- Proof of stake: In multi-round proof-of-stake voting, selected staked users propose blocks and all staked users vote, but “nothing at stake” can let users support competing chains and sustain multiple branches.Several voting rounds may occur before a block is decided, giving all staked users a voice in each block selection.
5 Forking
Forks are protocol or data-structure changes that are categorized as soft or hard according to whether they remain backwards compatible. Hard forks require broader coordinated upgrades, can split incompatible blockchain versions, and may be necessary for significant cryptographic flaws.
- Fork categories: Blockchain changes to protocols and data structures are called forks and divided into soft forks and hard forks.In permissionless networks, changes are difficult because users are globally distributed and governance depends on consensus.
- Soft forks: Soft forks are backwards compatible, allowing non-updated nodes to transact with updated nodes, but updated rules require sufficient adoption.If no or very few nodes upgrade, the updated rules will not be followed.
- Hard forks: Hard forks are not backwards compatible, requiring nodes to adopt the updated protocol or reject newly formatted blocks.Non-updated nodes can continue using the old format, producing two simultaneous blockchain versions whose users cannot interact.
- Cryptographic changes: A hard fork may be required to replace cryptographic algorithms after significant flaws, but changing hashing algorithms can invalidate specialized mining hardware.Powerful quantum computers could break many asymmetric-key algorithms based on integer factorization or discrete logarithms, while hashing algorithms are much less susceptible.
6 Smart Contracts
Smart contracts are blockchain-deployed code and data executed by network nodes, which must produce consistent results and agree on the resulting state. They can support transparent multi-party business processes while requiring deterministic execution and resource controls.
- Smart Contract Fundamentals: Smart contracts are collections of code and data deployed through cryptographically signed blockchain transactions and executed by network nodes.Examples include Ethereum smart contracts and Hyperledger Fabric chaincode.
- Smart Contract Fundamentals: Users send data to smart-contract functions, which execute methods to perform services and can calculate, store information, and expose public state.Because the code is tamper evident and tamper resistant, it can serve as a trusted third party.
- Business Processes: Smart contracts can represent multi-party business transactions, providing attestable data and transparency while reducing reconciliation costs and transaction-completion time.These properties can foster trust and provide insight for better business decisions.
- Execution Constraints: Smart contracts must be deterministic, and all executing nodes must agree on the new state; therefore, external data must be passed directly as input.They cannot obtain web-services data from within the contract without receiving it as a parameter.
- Execution Constraints: On some permissionless networks, exceeding the execution limit stops and discards a transaction, while also preventing resource-exhaustion attacks such as infinite loops.The mechanism also rewards publishing nodes for executing smart-contract code.
7 Blockchain Limitations and Misconceptions
Blockchain technology is often overhyped and misunderstood, and its ledgers are tamper evident and tamper resistant rather than completely immutable. Key limitations include governance and control, real-world data reliability, network shutdown and cybersecurity risks, and substantial energy use.
- Immutability: Blockchain ledgers are tamper evident and tamper resistant, but not completely immutable because some implementations allow recent tail blocks to be replaced.Networks commonly adopt the longest chain as truth when competing chains exist.
- Governance: Blockchain networks are not systems without control: owners, consortia, software developers, publishing nodes, and users all influence governance.Permissioned consortia control membership and governance, while permissionless users can reject developer changes and publishing nodes control block creation.
- Oracle Problem: When blockchain networks interact with the real world, the Oracle Problem makes it difficult to determine whether human or sensor inputs accurately reflect external events.For example, the blockchain cannot determine whether a purchased real-world item was shipped without outside sensor or human input.
- Network Limitations: A blockchain network may never fully shut down because lingering nodes can remain, while a defunct network cannot reliably preserve history if few publishing nodes remain.A malicious user could overpower the remaining publishing nodes and redo and replace blocks.
- Energy Use: Around the same amount of electricity as the entire country of Ireland is used by the Bitcoin blockchain network, according to one estimate.It has also been speculated that the network would consume as much electricity as Denmark by 2020; efficiency improvements may reduce consumption.
8 Application Considerations
Blockchain should be investigated based on where its features fit a system or activity, rather than adopted because it is new. Suitability also depends on visibility, transaction speed, compliance, permissions, and node diversity.
- Application fit: Organizations should first understand blockchain technology and identify suitable new or existing systems, rather than seek applications solely because of its novelty.The paper describes fear of missing out and recommends determining where blockchain fits before selecting systems.
- Application fit: Blockchain may suit systems with many or distributed participants, limited trust in third parties, transactional workflows, scarce digital identifiers, or ownership and reconciliation needs.Listed use cases include decentralized naming or ordered registries, cryptographically secure ownership, and reducing manual reconciliation and disputes.
- Data and governance: Application design must assess whether blockchain data should be public or restricted, including policy and regulatory constraints on information such as PII or GDPR-governed data.Permissioned networks may restrict visibility, while permissionless networks generally make data public and allow broad inspection and contribution.
- Operational constraints: Systems must tolerate relatively slow transaction processing and preserve compliance with applicable laws and regulations when using blockchain.The paper notes that applications may slow while waiting for data to be posted and that blockchain use does not remove legal or regulatory obligations.
- Permissions and security: Permissioned deployments require sufficiently granular role permissions and administration processes that determine who can grant and revoke access.Traditional roles may include administrator, user, validator, and auditor, but permission management must support required roles and revocation.
- Permissions and security: Node diversity affects security because homogeneous hardware, software, locations, and messaging schemas increase the risk of undiscovered vulnerabilities.The paper identifies decentralization across heterogeneous devices as a mitigation for this risk.
9 Conclusions
Blockchain technology enables secure, distributed transaction recording without central authority, using cryptographic mechanisms to preserve transaction history. Although built on established principles and attracting substantial hype, it remains an emerging tool whose adoption requires careful assessment of advantages, disadvantages, and appropriate use.
- Conclusions: Blockchain enables organizations to conduct secure transactions without a central authority, with Bitcoin-based solutions increasing since 2009.The Bitcoin network launched in 2009, although its whitepaper was published in 2008.
- Conclusions: Cryptographic hashes, asymmetric-key signatures, and verification secure a distributed ledger containing transaction history.Editing a past transaction requires recalculating all subsequent transaction blocks.
- Conclusions: Blockchain remains in its early stages despite sound cryptographic foundations, and current hype is expected to subside as it becomes another usable tool.The passage notes that many proposed uses currently surround the technology.
- Conclusions: Organizations should assess blockchain’s advantages and disadvantages because widely adopted implementations may be difficult to change and recorded data usually remains forever.This persistence means mistakes may remain in the blockchain.
- Conclusions: Organizations should use blockchain only in appropriate situations, treating it like any other technological solution.The technology is still new, so suitability should be evaluated rather than assumed.
Appendix A—Acronyms
Appendix A defines selected acronyms and abbreviations used throughout the paper, including organizations, technical components, protocols, algorithms, and regulatory terms.
- Appendix A—Acronyms: The appendix identifies selected acronyms and abbreviations used in the paper.It introduces the definitions listed in the appendix.
- Appendix A—Acronyms: It defines organizations and institutions such as ACM, DHS, IEEE, ITL, and NIST.These stand for Association for Computing Machinery, Department of Homeland Security, Institute of Electrical and Electronics Engineers, Information Technology Laboratory, and National Institute of Standards and Technology.
- Appendix A—Acronyms: Other entries cover governance, identity, privacy, records, and legal concepts, including DAO, DID, GDPR, FOIA, NARA, NISTIR, and PII.The appendix also defines ACT-IAC, CRUD, FIPS, and I2P.
- Appendix A—Acronyms: Technical terms include ASIC, CPU, DAG, EVM, GPU, LDAP, and PoET.The entries expand these as Application-Specific Integrated Circuit, Central Processing Unit, Directed Acyclic Graph, Ethereum Virtual Machine, Graphics Processing Unit, Lightweight Directory Access Protocol, and Proof of Elapsed Time.
- Appendix A—Acronyms: Cryptographic and blockchain-related entries include BFT, DSA, ECDSA, RIPEMD, RSA, SegWit, and SHA.They refer to Byzantine Fault Tolerant, Digital Signature Algorithm, Elliptic Curve Digital Signature Algorithm, RACE Integrity Primitives Evaluation Message Digest, Rivest-Shamir-Adleman, Segregated Witness, and Secure Hash Algorithm.
Appendix B—Glossary · Appendix C—References
Appendix B defines the paper’s core blockchain concepts, including ledger structure, cryptographic mechanisms, consensus, network configurations, transactions, and participating nodes. No reference content is included among the supplied passages for Appendix C.
- Appendix B—Glossary: Addresses identify users through public-key-derived strings, wallets manage keys and addresses, and transactions record events such as asset transfers or asset creation.Digital assets are purely digital or digital representations of physical assets, and cryptocurrency transfers use asymmetric-key digital signatures.
- Appendix B—Glossary: Asymmetric-key cryptography uses a secret private key to generate a public key, enabling private-key signatures that anyone can verify with the corresponding public key.Digital signatures support authenticity, non-repudiation, and message integrity.
- Appendix B—Glossary: Blocks contain headers and data: block data stores validated transactions and ledger events, while headers typically include metadata, hashes, timestamps, and a nonce when needed.A hash chain records each preceding block’s hash, making modifications detectable through changed hash digests.
- Appendix B—Glossary: Blockchain is a distributed ledger of cryptographically signed transactions grouped into validated, sequentially linked blocks that become increasingly tamper resistant as new blocks are added.New blocks are replicated across network ledger copies, with conflicts resolved automatically using established rules.
- Appendix B—Glossary: Blockchain networks may be centralized, partially centralized, or peer-to-peer, while full nodes store, relay, and validate blockchain data.Peer-to-peer configurations provide multiple communication pathways, so losing one participant does not prevent communication.
- Appendix B—Glossary: Consensus is the process of agreeing on a distributed system’s valid state, using models such as stake-based voting, pseudo-random stake selection, proof of work, and round robin selection.Proof of work requires expending time, energy, and computation to solve a hard-to-solve but easy-to-verify problem.
- Appendix B—Glossary: Additional glossary terms cover double spending, smart contracts, forks, permission models, tamper evidence, tamper resistance, rewards, fees, and temporary ledger conflicts.Smart-contract execution results must be identical across nodes and are recorded on the blockchain.