Blockchain Technology Overview

• NIST Internal Report 8202 is titled “Blockchain Technology Overview.”Source: NISTIR 8202 · p. 3
• Commercial entities, equipment, or materials identified in the document are not necessarily recommended, endorsed, or considered the best available for the stated purpose.Source: NISTIR 8202 · p. 3
• The publication identifies blockchain-related concepts including distributed ledgers, consensus algorithms, cryptographic hash functions, asymmetric-key cryptography, proof mechanisms, forks, smart contracts, and data oracles.Source: NISTIR 8202 · p. 4

Executive Summary

• Blockchains are distributed ledgers composed of cryptographically linked blocks containing digitally signed transactions, enabling shared recording and verification without a central authority.Under normal network operation, published transactions cannot be changed.Source: Executive Summary · pp. 6–7
• Bitcoin demonstrates the cryptocurrency use case: users sign and transfer rights linked to digital addresses, while distributed maintenance and cryptography make later ledger alteration difficult.The paper focuses on cryptocurrencies because they remain blockchain technology’s primary use case, while noting broader applicability.Source: Executive Summary · p. 6
• The overview promotes informed, appropriate adoption by replacing blockchain hype with an understanding of its capabilities, limitations, and fit for specific organizational needs.Organizations should ask how blockchain could benefit them rather than forcing existing problems into its paradigm.Source: Executive Summary · pp. 6–8
• Blockchain implementations support cryptocurrencies, smart contracts, and business distributed ledgers, with permissionless networks open to anyone and permissioned networks restricting participation and providing finer-grained controls.The technology landscape is continuously changing as new platforms and applications emerge.Source: Executive Summary · p. 7
• The paper explains how blockchain technology works, including how participants reach consensus on transaction validity and how applications represent later transactions as updates while preserving history.Consensus models have different advantages and disadvantages for particular business cases.Source: Executive Summary · pp. 6–7
• Organizations must evaluate blockchain as one component of a broader solution, considering malicious users, controls, implementation limitations, operations, and governance.Permissioned networks require decisions about which entities operate and govern the network for its intended users.Source: Executive Summary · p. 7

1 Introduction

• Blockchains are distributed ledgers of cryptographically signed transactions grouped into linked, validated blocks that are replicated across network copies and become harder to modify over time.Conflicts among ledger copies are resolved automatically using established rules.Source: §1 · p. 12

1.1 Background and History

• Blockchain concepts combined consensus, signed information chains, and electronic cash, culminating in Bitcoin’s 2009 network and subsequent blockchain applications.Bitcoin enabled direct transactions without a trusted third party through distributed administration, mining incentives, and consensus-based validation.Source: §1.1 · p. 13
• Append-only, secure, shared, and distributed ledgers create trust without trusted intermediaries, enabling direct transactions among unfamiliar parties and reinforcing trust in permissioned networks.Increasing node counts can reduce a bad actor’s ability to affect consensus, while permissionless networks may deliver transactions faster and at lower costs.Source: §1.1 · pp. 13–14

1.2 Purpose and Scope

• The document provides a foundational technical overview covering implementation categories, components, consensus models, forks, smart contracts, limitations, misconceptions, and organizational considerations.Its purpose is to help readers understand the technologies comprising blockchain networks.Source: §1.2 · p. 14

1.3 Notes on Terms

• The document uses generic terminology distinguishing the ledger, technology, network, implementation, users, and node types such as full, publishing, and lightweight nodes.Full nodes store the entire blockchain and ensure transactions are valid, while lightweight nodes pass transactions to full nodes.Source: §1.3 · p. 14

1.4 Results of the Public Comment Period

• Public comments led to a tighter foundational scope that excluded rapidly changing use-case and platform sections, while removing an erroneous Bitcoin Cash statement addressed an editing issue.The excluded topics were reserved for possible future work.Source: §1.4 · p. 15

1.5 Document Structure

• The document proceeds from blockchain categorization and architecture through consensus, forking, smart contracts, limitations, application considerations, conclusion, acronyms, glossary, and references.These topics are organized across Sections 2–9 and Appendices A–C.Source: §1.5 · p. 15

2 Blockchain Categorization

• Blockchain networks are categorized as permissionless when anyone can publish blocks, or permissioned when only authorized users can publish them.Permissioned networks are commonly deployed for consortia of organizations and individuals.Source: §2 · p. 16

2.1 Permissionless

• Permissionless networks allow anyone to read and write to the ledger, so consensus mechanisms such as proof of work and proof of stake deter malicious block publication.These systems often reward publishers of protocol-conforming blocks with native cryptocurrency.Source: §2.1 · p. 16

2.2 Permissioned

• Permissioned networks restrict block publication to authorized users and may separately restrict ledger reading or transaction submission.They can be implemented with either open-source or closed-source software.Source: §2.2 · p. 16
• Permissioned-network consensus is usually faster and less computationally expensive because participants are identified, mutually trusted, and subject to revocation for misconduct.These networks retain distributed, resilient, redundant storage and digital-asset traceability.Source: §2.2 · pp. 16–17
• Organizations can use permissioned networks to share transactions, select consensus according to interorganizational trust, and improve transparency, auditing, oversight, and accountability.If one entity controls block publication, users must trust that entity.Source: §2.2 · p. 17
• Some permissioned networks selectively reveal transaction information by user identity or credentials, allowing transaction occurrence to remain visible while contents stay limited to involved parties.This provides some degree of transaction privacy.Source: §2.2 · p. 17

3.1 Cryptographic Hash Functions

• Cryptographic hash functions produce reproducible digests, so users can detect data changes; even a one-bit input change yields a different output.They are designed to resist preimages, second preimages, and collisions, making matching or reversing digests computationally infeasible.Source: §3.1 · p. 18
• SHA-256 is a widely used blockchain hash function that produces a 256-bit, 32-byte digest usually displayed as 64 hexadecimal characters.Many computers support SHA-256 in hardware, enabling fast computation; other blockchain hash families include Keccak and RIPEMD-160.Source: §3.1 · pp. 18, 20

3.1.1 Cryptographic Nonce

• A cryptographic nonce is a number used once; changing only the nonce generates different digests while preserving the underlying data.This mechanism is used in proof-of-work consensus.Source: §3.1.1 · p. 20

3.2 Transactions

• Transactions represent interactions such as cryptocurrency transfers or asset activity, and blocks may contain zero or more transactions.Some implementations publish blocks continuously, including empty blocks, to help prevent attackers from catching up with and replacing the chain.Source: §3.2 · p. 20
• Transaction data varies by implementation but may include addresses, public keys, digital signatures, inputs, and outputs.Inputs reference asset provenance, while outputs specify recipients, transferred amounts, ownership identifiers, and spending conditions; excess value can return as change.Source: §3.2 · pp. 20–21
• Transactions can transfer digital assets or publicly record data, including smart-contract processing and updates to digitized assets such as shipment locations.Validity requires protocol and format compliance, while authenticity is typically verified through a sender’s private-key signature and associated public key.Source: §3.2 · p. 21

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 and cannot feasibly be derived from public keys.Private-key encryption can be decrypted with the public key, whereas public-key encryption requires the private key for decryption.Source: §3.3 · p. 22
• Digital signatures let blockchain users verify transaction integrity and authenticity without prior trust, although asymmetric-key cryptography is often slow to compute.Private keys sign transactions, public keys verify signatures and derive addresses, and permissioned networks may reuse existing PKI and LDAP directory services.Source: §3.3 · pp. 22–23

3.4 Addresses and Address Derivation

• Addresses are shorter, nonsecret alphanumeric identifiers derived from public keys with cryptographic hashing and additional data, and they commonly serve as transaction endpoints.A representative derivation is public key → cryptographic hash function → address.Source: §3.4 · p. 23
• Permissionless networks allow users to generate unlimited asymmetric-key pairs and addresses, supporting varying degrees of pseudo-anonymity and public-facing identification.Addresses are often converted into QR codes for easier use with mobile devices, and derivation methods may differ across blockchain implementations.Source: §3.4 · p. 23

3.4.1 Private Key Storage

• Wallet software stores private keys, public keys, and addresses, but losing a private key makes associated assets unrecoverable while theft gives an attacker full control.Secure hardware and key-escrow services are alternative storage approaches; escrow services may also satisfy KYC requirements.Source: §3.4.1 · p. 24

3.5 Ledgers

• Blockchain ledgers hold accepted transactions and require nodes to validate them, rather than relying on a central owner to provide complete and trustworthy records.Distributed ownership addresses concerns about centralized ledgers being incomplete, opaque, altered, or dependent on a single trusted operator.Source: §3.5 · pp. 24–25
• Blockchain networks distribute ledger copies across peers, so new full nodes can obtain the ledger and loss or destruction of one copy is difficult.Private transactions or channels may restrict information to participating nodes rather than the entire network.Source: §3.5 · p. 25
• Distributed, geographically diverse blockchain nodes make the ledger resilient to losing individual nodes or entire regions and provide no centralized point of attack.Peer-to-peer replication and node diversity help the system withstand localized failures and attacks; compromising an unpatched node does not compromise the overall system.Source: §3.5 · pp. 25–26
• Cryptographic hashes and digital signatures make blockchain ledgers tamper evident and tamper resistant, while nodes detect and ignore invalid transactions.Blocks reference prior blocks, and nodes reject a newly published block that does not reference the latest block.Source: §3.5 · pp. 25–26

3.6 Blocks

• Transactions submitted through blockchain software propagate among nodes but remain pending until a publishing node adds them to a block.Distributed transactions may wait in a queue after reaching nodes, including non-publishing full nodes and publishing nodes.Source: §3.6 · p. 26
• Each block contains a metadata-bearing header and block data listing validated, authentic transactions.Full nodes reject published blocks containing invalid transactions.Source: §3.6 · p. 26
• Transaction validity and authenticity are checked through formatting and cryptographic signatures proving asset providers controlled the relevant private keys.Other full nodes independently verify every transaction before accepting the block.Source: §3.6 · p. 26
• Blockchain implementations can define their own fields, but common block metadata includes block number, previous-header hash, block-data hash, size, nonce, and included transactions or ledger events.Block-data hashes may use a Merkle-tree root or a hash of combined block data; nonce use varies across implementations.Source: §3.6 · pp. 26–27
• Mining-based networks may manipulate the nonce to solve a hash puzzle, while other networks may omit it or use it differently.Nonce behavior is implementation-dependent.Source: §3.6 · p. 27

3.7 Chaining Blocks

• Blocks form a chain because each block contains the hash digest of the previous block’s header.Figure 3 depicts a generic chain of blocks.Source: §3.7 · p. 28, Figure 3 · p. 28
• Changing a published block changes its hash and therefore the hashes of all subsequent blocks, enabling altered blocks to be detected and rejected.The cascading hash changes arise because each later block includes the previous block’s hash.Source: §3.7 · p. 28

4 Consensus Models

• Consensus models resolve competing block proposals and enable mutually distrustful users to cooperate, while users independently validate each block from the genesis block onward.When two valid chains appear, most networks adopt the longer chain because it represents the most accumulated work.Source: §4 · p. 29

4.1 Proof of Work Consensus Model

• Proof of Work selects the first node to solve a difficult hash puzzle, making verification easy but requiring substantial computation, time, electricity, and hardware.Increasing leading zeros raises difficulty; one example required 10,730,896 guesses in 54 seconds, while a harder target required 934,224,175 guesses in 1 hour, 18 minutes, 12 seconds.Source: §4.1 · pp. 30–31

4.2 Proof of Stake Consensus Model

• Proof of Stake makes block-publication likelihood proportional to a user’s staked cryptocurrency, reducing resource-intensive computation but creating nothing-at-stake and wealth-concentration risks.Some algorithms allow users to support competing chains at little cost, potentially prolonging multiple branches; obtaining majority control is generally cost prohibitive.Source: §4.2 · pp. 32–34

4.3 Round Robin Consensus Model

• Round Robin lets permissioned nodes take turns creating blocks with low power requirements, but it requires trust and is vulnerable to malicious nodes adding identities.Timeouts can allow available nodes to publish when the scheduled node is unavailable.Source: §4.3 · p. 34

4.4 Proof of Authority/Proof of Identity Consensus Model

• Proof of Authority relies on permissioned nodes staking verified real-world identities and reputations, with lower reputation reducing their likelihood of publishing blocks.Publishing nodes are expected to maintain high reputations by acting in ways users accept.Source: §4.4 · p. 34

4.5 Proof of Elapsed Time Consensus Model

• Proof of Elapsed Time assigns each publishing node a random wait using secure hardware, after which the node publishes a block with a certificate of elapsed time.Trusted execution environments must ensure both that the wait was random and that the node actually waited the assigned duration.Source: §4.5 · pp. 34–35

4.6 Consensus Comparison Matrix

• The comparison matrix characterizes PoW as computationally intensive and vulnerable to a 51 % attack based on computational power, while PoS is less computationally intensive but vulnerable to financial-power attacks and stakeholder centralization.Delegated PoS is described as more computationally efficient than PoW, with elected delegates economically incentivized to remain honest.Source: §4.6 · p. 36
• Round Robin is straightforward and publishes blocks among approved or trusted nodes, but it requires substantial trust and can create centralized failure points.A constrained operating set increases compromise risk, while known delegates may have incentives to collude or accept bribes.Source: §4.6 · pp. 36–37
• Proof of Authority/Identity enables dynamic block production rates and is used in permissioned or hybrid sidechain systems, but depends on trusted, uncompromised validating nodes.The reputation of a node carries high tail-risk because it may be compromised at any time.Source: §4.6 · p. 37
• Proof of Elapsed Time is less computationally expensive than proof of work and supports more economic consensus, but it assumes uncompromised hardware clocks and has synchronization limits.Its security and operation rely on hardware-derived time, while true time synchronicity is essentially impossible in distributed systems because of latency limits.Source: §4.6 · p. 37

4.7 Ledger Conflicts and Resolutions

• Ledger conflicts temporarily create competing blockchain versions, which networks usually resolve by adopting the chain that receives the next valid block as official.Transactions from the orphaned chain return to each node’s local pending pool because the architecture has no central server.Source: §4.7 · pp. 38–39
• Transactions require several subsequent blocks for confirmation because blocks can be superseded, making acceptance probabilistic and increasingly likely with additional blocks.A proof-of-work attacker could theoretically rewrite history by creating a longer chain from genesis, but the required resources are prohibitively large; checkpoints can also prevent this.Source: §4.7 · p. 39

5 Forking

• Forks change blockchain protocols or data structures; soft forks preserve compatibility, whereas hard forks can create multiple blockchain versions.The term fork can also describe temporary ledger conflicts that do not result from software changes.Source: §5 · p. 40

5.1 Soft Forks

• Soft forks are backward-compatible changes allowing non-updated nodes to transact with updated nodes, although the new rules require sufficient node adoption.For example, updated nodes may enforce a smaller block-size limit while non-updated nodes still regard compliant blocks as valid.Source: §5.1 · p. 40

5.2 Hard Forks

• Hard forks are incompatible changes requiring nodes to upgrade; otherwise, old and new formats produce simultaneous blockchain versions whose users cannot interact.Most hard forks are intentional, but software errors can also produce unintentional hard forks.Source: §5.2 · pp. 40–41

5.3 Cryptographic Changes and Forks

• Cryptographic flaws may require hard forks to replace algorithms, but migration can invalidate specialized mining hardware and lock historical verification to the previous hash algorithm.A practical quantum computer would especially threaten asymmetric-key algorithms based on integer factorization or discrete logarithms, while weakening hashes less severely.Source: §5.3 · pp. 41–42

6 Smart Contracts

• Smart contracts are cryptographically signed blockchain deployments of code and data whose execution must produce identical results across participating nodes, with outcomes recorded on-chain.They are implemented through platforms such as Ethereum smart contracts and Hyperledger Fabric chaincode.Source: §6 · p. 43
• Smart contracts expose functions that process user-supplied data and can calculate, store information, expose state, or automatically transfer funds; they can also support nonfinancial services such as trustworthy random-number generation.Because their code is tamper evident and tamper resistant, smart contracts can serve as trusted third parties, although not every blockchain supports them.Source: §6 · p. 43
• Smart contracts can represent multi-party business transactions, providing attestable transparency that can foster trust, improve decisions, reduce reconciliation costs, and shorten completion times.Source: §6 · p. 43
• Smart contracts must be deterministic and cannot directly access external data; outside information must be supplied as input through an Oracle.This restriction ensures nodes agree on the resulting blockchain state.Source: §6 · p. 43
• On permissionless networks, users pay for execution and calls exceeding the execution-time limit are discarded, preventing resource-exhaustion attacks such as infinite loops.Permissioned networks may instead rely on access controls because participants are known.Source: §6 · pp. 43–44

7.1 Immutability

• Blockchain ledgers are tamper evident and tamper resistant, but not completely immutable: tail blocks can be replaced, 51% attacks can rewrite history, and permissioned owners can replace blocks legitimately.Longer competing chains can replace recent blocks without necessarily losing their transactions; changing older blocks becomes more expensive for attackers.Source: §7.1 · p. 45

7.2 Users Involved in Blockchain Governance

• Blockchain governance is not control-free: permissioned consortia govern membership and rules, while developers, publishing nodes, and users collectively influence permissionless networks.Users can reject developer changes, but publishing nodes have substantial practical control because they create and publish blocks.Source: §7.2 · p. 46

7.3 Beyond the Digital

• Blockchain records cannot independently verify real-world events, so faulty sensors, false human inputs, and external shipment status create the Oracle Problem.External-data projects can introduce centralized points of failure, motivating oracle designs based on consensus and economic incentives.Source: §7.3 · p. 47

7.4 Blockchain Death

• A decentralized blockchain may never fully shut down, yet a defunct network with few publishing nodes would be vulnerable to block-history replacement and unsuitable as a historical record.Lingering nodes can remain after a network effectively “shuts down.”Source: §7.4 · p. 47

7.5 Cybersecurity

• Blockchain use does not eliminate cybersecurity risks: unpublished transactions, timestamps, platforms, smart contracts, and newly deployed applications remain vulnerable to attacks and implementation weaknesses.Existing cybersecurity standards and guidance remain relevant, with adjustments for blockchain-specific attributes.Source: §7.5 · p. 47, §7.5.1 · p. 48

7.6 Malicious Users

• Permissionless networks can be harmed by sufficiently powerful malicious users through transaction exclusion, secret alternative chains, disrupted block transmission, or collusion, while permissioned administrators may rewrite history or exclude users.Hard forks may counter malicious activity, but reversing resulting losses depends on developers and users.Source: §7.6 · pp. 48–49

7.7 No Trust

• Blockchain networks are not trustless: participants must trust cryptography, smart contracts, software developers, noncolluding users, and fair transaction processing, while proof-of-work can consume substantial resources.Some estimate that Bitcoin uses electricity comparable to Ireland, and a full node may download over 175 gigabytes of blockchain data.Source: §7.7 · p. 49, §7.8 · pp. 49–50

7.9 Inadequate Block Publishing Rewards; 7.10 Public Key Infrastructure and Identity

• Insufficient publishing rewards can delay block production, reduce cryptocurrency confidence and value, and expose weakened networks to attacks; typical blockchain implementations also do not provide standalone real-world identity management.A blockchain signature links transactions to private-key owners but does not itself associate them with real-world identities.Source: §7.9 · p. 50, §7.10 · pp. 50–51

8 Application Considerations

• Organizations should first understand blockchain’s fit and identify suitable new or existing systems, rather than searching for a blockchain application because of fear of missing out.The section recommends investigating blockchain and using it only when appropriate, not merely because it is new.Source: §8 · pp. 52, 55
• Blockchain solutions may fit systems with many or distributed participants, limited trusted-third-party availability, transactional workflows, scarce digital identifiers, registries, ownership security, or shared provenance needs.Other potential benefits include reducing reconciliation and dispute-resolution work and enabling real-time monitoring between regulators and regulated entities.Source: §8 · p. 52

8.1 Additional Blockchain Considerations

• Blockchain selection must consider whether data should be public or restricted, including the appropriateness of storing PII or GDPR-governed data even on permissioned networks.Permissionless networks generally allow anyone to inspect and contribute, while permissioned networks may restrict data to participants.Source: §8.1 · p. 55
• Applications must assess immutable history and false inputs: blockchain preserves original records even after amendments, while validating user-submitted data remains difficult.Smart contracts may provide additional checks where possible, but they cannot automatically verify all incoming data.Source: §8.1 · p. 55
• Transaction speed and legal requirements can limit blockchain use, since many permissionless networks process transactions more slowly and applicable laws may restrict data placement or transfers.Permissioned or hybrid approaches may be required for regulatory needs, including PII, GDPR, geographic-transfer, financial-record, and federal-record requirements.Source: §8.1 · pp. 55–56
• Permissioned designs must provide sufficiently granular, administrable, and revocable roles, while node diversity reduces risks associated with shared hardware, software, geography, or messaging schemas.Permissioned networks can support roles such as administrators, users, validators, and auditors, but permission governance must be evaluated.Source: §8.1 · p. 56

Conclusions

• Blockchain technology enables secure transactions without a central authority and has supported increasing blockchain-based solutions since Bitcoin launched in 2009.Bitcoin leveraged blockchain technology, although its network launched in 2009 after the 2008 publication of its whitepaper.Source: §9 · p. 57
• Cryptographic hashes, asymmetric-key signatures, and verification secure a distributed transaction history whose past edits require recalculating subsequent blocks.The first applications were electronic cash systems built around a global ledger containing all transactions.Source: §9 · p. 57
• Blockchain technology remains early despite relying on widely understood cryptographic principles, amid substantial hype and many proposed uses.The publication anticipates that the hype will diminish and blockchain will become another available tool.Source: §9 · p. 57
• Immutable blockchain data can preserve a full change history, while software abstractions represent later transactions as updates to working data.This persistence may be desirable for some organizations but a deal breaker for others, especially when mistakes remain recorded.Source: §9 · p. 57
• Organizations should evaluate blockchain’s advantages and disadvantages and use it only where appropriate, because widespread adoption can make changes difficult.Recorded data is usually permanent, even when incorrect, so suitability depends on organizational needs.Source: §9 · p. 57

Acronyms

• The appendix provides definitions for selected acronyms and abbreviations used in the paper.Entries span organizational names, computing components, blockchain concepts, standards, privacy and records terminology, and cryptographic algorithms.Source: Appendix A · p. 58
• Institutional and standards-related entries include ACM, ACT-IAC, DHS, IEEE, ITL, NARA, NIST, NISTIR, FIPS, FOIA, and GDPR.These refer to organizations, government bodies, standards, and regulatory or records-access frameworks named in the appendix.Source: Appendix A · p. 58
• Blockchain and computing terms include BFT, DAG, DAO, DID, EVM, PoET, ASIC, CPU, and GPU.These are defined as Byzantine Fault Tolerant, Directed Acyclic Graph, Decentralized Autonomous Organization, Decentralized Identifier, Ethereum Virtual Machine, Proof of Elapsed Time, Application-Specific Integrated Circuit, Central Processing Unit, and Graphics Processing Unit.Source: Appendix A · pp. 58–59
• Additional entries cover CRUD, I2P, LDAP, PII, and related identity, networking, privacy, and data-management terminology.The appendix defines CRUD as Create, Read, Update, Delete; I2P as Invisible Internet Project; LDAP as Lightweight Directory Access Protocol; and PII as Personally Identifiable Information.Source: Appendix A · pp. 58–59
• Cryptography and data-integrity terms include DSA, ECDSA, RIPEMD, RSA, SHA, and SegWit.The entries expand these as Digital Signature Algorithm, Elliptic Curve Digital Signature Algorithm, RACE Integrity Primitives Evaluation Message Digest, Rivest-Shamir-Adleman, Secure Hash Algorithm, and Segregated Witness.Source: Appendix A · pp. 58–59

Appendix B—Glossary

• Asymmetric-key cryptography uses secret private keys to generate public keys, enabling digital signatures that verify authenticity, non-repudiation, and integrity.Addresses are derived from public keys and are used to send and receive digital assets.Source: Appendix B · pp. 60, 62
• Blocks contain validated transactions and ledger events, while headers record metadata such as timestamps, data hashes, previous-header hashes, and optional nonces.This structure links blocks cryptographically and provides evidence of tampering when data changes.Source: Appendix B · pp. 60, 63
• A blockchain is a distributed ledger of cryptographically signed transactions grouped into validated, consensus-linked blocks that are replicated across the network.Older blocks become harder to modify, and conflicts are resolved automatically using established rules.Source: Appendix B · p. 60
• Blockchain networks may be centralized, partially centralized, or peer-to-peer, with peer-to-peer configurations providing multiple communication pathways without a centralized point.The glossary also distinguishes permissioned systems, where access is granted by an administrator or consortium, from permissionless systems.Source: Appendix B · pp. 61, 62, 64
• Consensus is the process of reaching agreement on a distributed system’s valid state, with proof-of-work and proof-of-stake among the defined models.Proof of work uses computational effort to select a publishing node, whereas proof of stake weights consensus participation by locked cryptocurrency holdings.Source: Appendix B · pp. 61, 64
• Nodes store, validate, relay, or publish blockchain data, with full nodes maintaining blockchain data and publishing nodes extending the chain by creating new blocks.Publishing nodes may receive block rewards or transaction fees for their activities.Source: Appendix B · pp. 60, 63, 64, 65
• The glossary defines transactions, digital assets, smart contracts, and double spending as core blockchain concepts governing recorded events, transferable value, executable code, and repeated asset use.Smart-contract execution is performed by network nodes, which must derive identical results that are recorded on the blockchain.Source: Appendix B · pp. 62, 63, 65