What is a blockchain?

In brief

A blockchain is a data structure and a set of rules that let many independent computers agree on, and keep, one shared history of state changes, without any single one of them being trusted to report that history honestly. New entries are grouped into batches, cryptographically linked to the batch before them, and validated against a shared rule set before every participant's copy is updated.

It helps to separate two things that get flattened together in casual use: a blockchain is the data structure itself, while a blockchain network is the group of computers (usually called nodes) that store, validate, and extend it. Bitcoin, Ethereum, and Solana are all networks running different blockchain designs; none of them is "the" blockchain, and none of them defines what every other blockchain must look like.

The problem it tries to solve

The underlying problem is old: how do several parties who do not fully trust each other agree on one version of events, especially when money or property rights depend on getting it right? A conventional database solves this by putting one operator in charge. That operator decides what counts as valid, who can write, and who can read, and everyone else trusts that operator to run the system honestly and stay online.

That arrangement works well when a trusted authority is genuinely acceptable, and it is usually cheaper and faster than the alternative. A blockchain becomes interesting specifically when a single trusted operator is not acceptable to the participants, or is not available, and they still need a shared, verifiable record. NISTIR 8202, the National Institute of Standards and Technology's technical overview of blockchain technology, frames this as a way to achieve a shared, append-only ledger among mutually distrusting parties without a central administrator.

Core components

Most blockchain designs share a common set of ingredients, even though the details differ sharply between systems.

• Transactions or state changes. A record of something happening: a transfer, a contract call, a vote. Exactly what a "transaction" can contain varies enormously between chains.
• Blocks, or an equivalent batch. Transactions are grouped together rather than committed one at a time, mainly for efficiency and to give the network a stable unit to agree on.
• Cryptographic hashes and links. Each block typically includes a hash of the previous block, so blocks form a chain. Changing an old block would change its hash, which would break every block linked after it, unless an attacker redoes all of that work too.
• Nodes. Independent computers that hold a copy of the chain (or enough of it to do their job), check that new blocks follow the rules, and pass valid data along to others.
• Validation and consensus rules. The precise logic that says what a valid transaction and a valid block look like, and the mechanism nodes use to agree on which chain of blocks is the accepted one when there is disagreement.

The underlying challenge that consensus rules have to solve, getting a group of participants to agree on one shared answer even though some participants might be unreliable, offline, or actively dishonest, is older than blockchains themselves. Lamport, Shostak, and Pease formalized it in 1982 as the Byzantine Generals Problem: a set of generals communicating only by messenger must agree on a single battle plan even if some of them are traitors sending conflicting messages. Blockchain consensus mechanisms are best understood as practical engineering responses to that older theoretical problem, adapted to a setting where anyone can potentially participate, rather than as a novel problem blockchains invented from scratch.

A transaction's path

The general shape of "how a transaction happens" is similar across many chains, even though the exact ordering and terminology differ:

1. A user creates a transaction and signs it with a private key, proving they authorized it without revealing the key itself.
2. The transaction propagates across the network of nodes.
3. Nodes check it against the protocol's validity rules (correct signature, sufficient balance or resources, correctly formed instructions, and so on).
4. Some process proposes that the transaction be included in the next block. Depending on the chain, this might be a competitive process (as in Bitcoin's proof-of-work mining) or a scheduled turn among validators.
5. The network reaches consensus on which block, and therefore which set of transactions, becomes part of the accepted chain.

Do not assume every chain follows this exact sequence. Ethereum groups transactions differently from Bitcoin, executes programs (smart contracts) as part of validating them, and, since a coordinated network upgrade called The Merge on September 15, 2022, reaches consensus through proof-of-stake validators rather than proof-of-work miners. Solana's whitepaper describes a different approach again, using a verifiable clock called Proof of History alongside a separate consensus mechanism to help validators agree on transaction order at high throughput.

Why old data becomes difficult to change

A blockchain's resistance to tampering is often summarized as "immutability," but that word overstates what is actually guaranteed. What a well-designed blockchain provides is closer to tamper-evidence and, depending on the consensus mechanism and network size, tamper-resistance: altering old data requires redoing the cryptographic linking work for every subsequent block and getting the rest of the network to accept that alternate history instead of the one everyone else already has.

This is a practical and economic property, not an absolute one. Short-lived disagreements about which block comes next, called forks or reorganizations, happen routinely and are usually resolved automatically within the protocol's own rules. Deeper changes are also possible in principle: if participants who control enough of the network's validating power (hashpower, stake, or equivalent) agree to rewrite history, or if the community agrees to change the rules through a coordinated upgrade, the chain's history or its rules can change. Ethereum's own history includes a concrete example: after over 3.6 million ETH was drained from a smart contract called The DAO in a June 2016 exploit, the community coordinated a hard fork, activated on July 20, 2016, that moved the affected funds (and related balances) out of the exploited contract and into a new recovery contract from which the original participants could withdraw funds; it did not erase the attack transaction from history or alter Ethereum's rules going forward, and a minority of participants who rejected the fork continued the original, unmodified chain as Ethereum Classic. Whether this kind of change is easy or difficult in practice depends heavily on how many independent parties would have to cooperate, which is a question about a specific network's decentralization and its community's willingness to coordinate, not a universal property of "blockchain," and not something that happens routinely or lightly.

Public, private, permissionless, and permissioned designs

"Blockchain" does not automatically mean "open to everyone." Two independent design choices are often confused:

• Permissionless vs. permissioned: can anyone join as a participant and propose or validate transactions, or must they be approved by some authority first?
• Public vs. private: can anyone read the chain's data, or is visibility restricted to approved parties?

Bitcoin and Ethereum are both permissionless and public. Many enterprise and consortium chains are permissioned, restricting who can validate or even see transactions, and some resemble a shared database among a known set of organizations more than an open network. Wüst and Gervais's 2018 analysis, "Do you need a Blockchain?", treats this distinction explicitly, arguing that permissioned blockchains share important properties with conventional databases and that the case for using either a permissionless blockchain, a permissioned blockchain, or a plain database depends on the specific trust assumptions of the application, not on blockchain being categorically superior.

Blockchain versus a conventional database

A blockchain is not simply "a database, but better." Compared with a conventional, centrally administered database, a blockchain typically trades some things away to gain others:

• Trust model: a database requires trusting the operator; a permissionless blockchain distributes that trust across the network's validation rules and participants instead.
• Performance: conventional databases generally offer far higher throughput and lower latency, because they do not need many independent parties to reach agreement on every write.
• Governance: changing a database's rules is an administrative decision; changing a public blockchain's rules usually requires broad coordination among node operators, validators, and users, which is slower and can be contentious.
• Auditability: a public blockchain gives every participant the same verifiable history; many databases can be altered by an administrator without the same independently checkable trail.
• Privacy: most public blockchains expose transaction data to anyone who looks, which is a very different privacy posture from a permissioned, access-controlled database.
• Recovery: losing the credentials to a blockchain account is often unrecoverable by design, whereas a conventional system's operator can usually reset access through an administrative process.

Where a single authority is acceptable and trusted, a conventional database is very often the simpler, cheaper, and faster tool, and dressing it up as a blockchain adds cost without adding a benefit anyone needed.

What blockchains can and cannot prove

A blockchain can establish, with a high degree of verifiability, what the protocol's own rules accepted as valid state and history, given the assumptions behind its consensus mechanism. That is a genuinely useful and unusual property.

It cannot prove that data entered onto it from the outside world is true. If a transaction records "delivery confirmed" or "temperature was 4°C," the chain can only guarantee that this claim was recorded and has not been altered since, not that the claim was accurate when it was made. This is often called the "oracle problem": bridging trustworthy off-chain facts onto a blockchain is a separate, unsolved-in-general challenge, distinct from the blockchain's own internal consistency. Likewise, a blockchain does not by itself establish legal ownership of a real-world asset, guarantee that an application built on top of it is secure, or protect a user from an unwise or coerced transaction that the protocol still considers validly signed.

Examples, briefly

• Bitcoin functions primarily as an electronic-cash ledger. Its whitepaper describes a peer-to-peer system for transferring value directly between parties, using proof-of-work and a UTXO (unspent transaction output) model to track ownership.
• Ethereum generalizes the idea into a programmable state machine: rather than only moving a native currency, its blocks can also execute smart contract code, and its state model is account-based rather than UTXO-based.
• Solana pursues a different architecture again, aimed at high throughput and low latency, combining Proof of History with a separate Byzantine-fault-tolerant consensus mechanism.

These are illustrations of different design choices, not evidence that every blockchain works like Bitcoin, or that Bitcoin's terminology (blocks, mining, UTXOs) applies universally.

Trade-offs

Every blockchain design makes trade-offs, often summarized loosely as a "trilemma" between decentralization, security, and scalability, though the exact framing is debated. Relevant dimensions include:

• Throughput and latency versus the overhead of getting many independent parties to agree.
• Resource cost: proof-of-work systems consume significant energy for mining; other consensus mechanisms shift the cost toward capital (stake) or specialized hardware instead.
• Privacy: most public chains trade transparency for privacy by default.
• Governance: upgrading rules that many independent, potentially disagreeing parties must adopt is slower and can fracture a network, as Ethereum/Ethereum Classic illustrates.
• Key loss and irreversibility: without a central administrator to reset access, losing control of the keys that authorize a transaction is often permanent.
• Decentralization is not one number. How distributed a given network's validation, client software, and infrastructure actually are is a separate, measurable question, not something guaranteed by the mere existence of a blockchain. (See the companion article on decentralization for how to think about that more carefully.)

What to learn next

Readers who want to go deeper from here should look at how transactions, blocks, and consensus work in more depth, how decentralization is actually measured rather than assumed, and how specific networks such as Bitcoin, Ethereum, and Solana apply these ideas differently in practice.