Blockchain Basics: How It Works

A blockchain is a way to maintain a digital ledger across a network of computers. Instead of relying on one central database as the sole record, participating computers maintain and update shared ledger state according to the network’s rules. Cryptographic links between blocks and a consensus process help the network organize records and agree on state. The details vary by blockchain, so “blockchain basics” describes a family of designs rather than one universal transaction system.

What Blockchain Basics means

The National Institute of Standards and Technology (NIST) defines a blockchain as a tamper-evident and tamper-resistant digital ledger implemented in a distributed fashion. Such systems are commonly implemented without a central repository and usually without a central authority. Those qualifications matter: “distributed” does not by itself establish that every participant has equal control, that all data is public, or that no organization has a governance role.

In Ethereum.org’s introductory explanation, a blockchain is a database updated and shared across networked computers. Blocks cryptographically reference earlier blocks, while nodes use consensus to agree on state. This description links three ideas:

  • Shared ledger: Networked computers maintain views of recorded information.
  • Cryptographic references: Blocks are linked to earlier blocks, making the sequence tamper-evident.
  • Consensus: Nodes follow a process for agreeing on the network’s state.

A blockchain’s system boundary includes more than its ledger data. It also includes the software that interprets transactions, the network participants that receive and validate them, the rules used to form and accept blocks, and the mechanisms by which nodes reach agreement. The exact boundaries and roles depend on the design. Blockchain systems differ in participation, consensus, data visibility, finality, execution capability, and governance.

“Tamper-evident” and “tamper-resistant” should not be read as “impossible to change.” They describe properties of the ledger design, not a guarantee that every related service, device, or operational process is secure or that every accepted record is correct in the real world.

Core components of Blockchain Basics

Transactions and authorization. A transaction is a proposed change or action that a network may process. At a high level, NIST describes a blockchain transaction as becoming part of the shared ledger after cryptographic authorization, validation under network rules, grouping into a block, and a consensus decision. The exact authorization method and validation checks depend on the network.

Nodes. Nodes are computers running network software. In the Ethereum introduction, nodes use consensus to agree on state. What a particular node stores, validates, or can do depends on its software and role; the broad description does not imply that every node has identical capabilities or access.

Blocks and ledger state. Transactions that pass the applicable process may be grouped into blocks. In Ethereum’s block structure, each block cryptographically references its parent block, creating an ordered chain of network state. This is an example, not a universal structure: other networks can use different data structures and consensus rules.

Consensus rules. Consensus is the mechanism through which nodes coordinate on accepted state. It is not a synonym for universal agreement about a transaction’s real-world meaning. The network’s rules determine what it checks and how it decides whether a proposed update is accepted. Consensus mechanisms and finality rules differ among networks.

Software and interfaces. Users and other systems typically interact with a blockchain through software, but the accepted source claims here do not prescribe a particular wallet, API, node configuration, or service. Such interfaces are part of an implementation’s operational environment and should be assessed separately from the ledger’s protocol rules.

How Blockchain Basics works

A simplified lifecycle can be mapped in stages. The sequence captures the high-level process described by NIST; individual networks may implement its steps differently.

  1. A transaction is prepared and authorized. The transaction must carry the cryptographic authorization required by the relevant network. Authorization supports the network’s checks, but does not alone establish that every requested action is valid under the protocol.
  2. The network receives and evaluates it. Participating software checks the transaction against network rules. The precise checks are implementation-dependent; no single checklist applies to every blockchain.
  3. Eligible transactions are grouped. Transactions that meet the applicable requirements can be assembled into a block. Block contents and formation procedures vary.
  4. The network reaches a consensus decision. Nodes apply the network’s consensus process to determine whether a proposed block or state update is accepted. The details, including what counts as final, differ by network.
  5. The accepted update becomes part of shared ledger state. In the high-level NIST lifecycle, the transaction becomes part of the shared ledger after authorization, validation, grouping, and a consensus decision. In Ethereum’s example, cryptographic references between parent and later blocks create an ordered chain of network state.

This flow separates transaction processing from verification. A reader can inspect evidence about a recorded transaction or block only in ways supported by the particular network and its interfaces. The accepted claims establish the general architecture and lifecycle, not a universal method for independently checking a transaction, a standard confirmation threshold, or a guarantee of immediate or irreversible finality.

Trust and control boundaries

A blockchain can distribute ledger maintenance without eliminating trust assumptions. Participants rely on the rules implemented by network software and on the relevant consensus process. They may also rely on interfaces or services that present ledger information. The NIST characterization says blockchains are usually without a central authority and commonly without a central repository; it does not say every design lacks central influence or operational dependencies.

It is useful to distinguish three questions:

  • What does the protocol require? This concerns transaction authorization, validation, block formation, and consensus rules.
  • Who operates or controls the surrounding services? This concerns software, access points, and other services used to submit or inspect transactions. Their specific properties are not established by the general blockchain definition.
  • What does the ledger record prove? A shared record can show that a transaction was accepted under network rules. That is distinct from proving the truth, quality, or legal effect of any off-network fact associated with it.

This distinction prevents a common category error: consensus can coordinate a network’s ledger state without resolving disputes about external events or guaranteeing that a participant’s process was correctly designed.

Limitations and failure modes

Blockchain properties are conditional on the network design and its operation. Participation, consensus, privacy, finality, execution capability, and governance vary. A description of one network should not be generalized to all blockchains, and Ethereum’s parent-block structure should be treated as an example rather than a universal architecture.

The high-level transaction lifecycle also leaves implementation details open. Validation checks, block structures, consensus rules, and finality differ by network. Consequently, the phrase “recorded on a blockchain” is not enough to establish how quickly a transaction is considered final, what data is visible, who can participate, or what recourse exists if a transaction is mistaken. Those points require network-specific evidence.

Finally, tamper resistance is a ledger property, not a blanket assurance about inputs or surrounding systems. The accepted sources describe a ledger that is tamper-evident and tamper-resistant; they do not support claims that all records are accurate, all interfaces are safe, or every blockchain offers the same privacy or security properties.

What teams should verify

Before relying on a blockchain for a technical workflow, teams can use the following evidence-led questions:

  1. Identify the specific network and version. Confirm which protocol documentation applies; do not infer behavior from blockchain terminology alone.
  2. Map participants and roles. Establish who can submit transactions, which nodes validate or maintain state, and how participation is governed. These details vary by system.
  3. Trace transaction requirements. Locate the network’s documentation for cryptographic authorization and validation rules, and determine which checks apply to the intended transaction.
  4. Examine block and state organization. Verify how the network groups transactions and links or otherwise organizes state. Do not assume every network uses Ethereum’s parent-block structure.
  5. Read consensus and finality rules. Determine how the network reaches a decision and what its documentation means by acceptance or finality. Avoid treating a generic lifecycle description as a network-specific guarantee.
  6. Check data visibility and execution scope. Confirm what information is visible and what operations the system supports; blockchain designs differ on both dimensions.
  7. Separate protocol evidence from service claims. If a workflow uses software or services to submit or display transactions, assess those components independently. The general definition does not establish their behavior.
  8. Document unresolved assumptions. Record questions about governance, operational dependencies, and the meaning of an accepted record rather than treating “distributed” or “tamper-resistant” as answers to them.

These checks turn blockchain basics into a practical system map: identify the ledger, the nodes and rules that update it, the process that establishes shared state, and the boundaries beyond which the protocol does not provide an answer.

Sources and references