What Is Blockchain? Blocks, Consensus, and Shared Ledgers Explained

Key takeaways

• A blockchain links blocks cryptographically and uses protocol rules to maintain an accepted history.
• Hashes make changes detectable, while consensus and network assumptions determine resistance to rewriting.
• A recorded claim about the physical world still depends on whoever supplied it.
• Blockchain and cryptocurrency are related concepts, but neither term defines the other.

A blockchain is a ledger organized into cryptographically linked blocks, usually replicated across a network whose participants follow rules for validating and accepting updates.

Its purpose is to maintain an agreed history when responsibility for that history is shared. The NIST blockchain overview describes blockchains as tamper-evident and tamper-resistant distributed ledgers.

Consider several companies tracking a shipment. Each wants to know which handovers were recorded and whether an earlier entry has been altered. A blockchain could provide a shared record, but it would still need rules about who can submit entries and how physical handovers are confirmed.

Blocks Connect Records Into a History

A block groups transactions or other permitted updates with protocol-specific information. It includes a cryptographic reference to earlier history.

A simplified sequence is:

Block A <- referenced by Block B <- referenced by Block C

Changing the data covered by a cryptographic hash normally changes the resulting digest. Later references therefore expose a mismatch if someone edits earlier material.

This is tamper evidence, not a magical barrier preventing anyone from modifying their own copy. Other participants must reject a rewritten history according to the protocol.

For background, the checksum guide explains how cryptographic hashes differ from simpler error-detection values.

Validation and Consensus Answer Different Questions

Validation asks whether a proposed transaction or block follows the rules. For a digital asset, that can include checking authorization and whether the funds are available.

Consensus concerns which valid history participants accept. Two proposals may arrive at different times, and a network needs a way to resolve competing histories.

Proof of Work and Proof of Stake are components of well-known consensus designs. Ethereum’s consensus documentation explains that the complete mechanism also includes proposal rules, fork choice, incentives, and other elements.

Calling a design “Proof of Stake” is therefore not enough to understand all its security assumptions.

A Transaction Moves Through Several States

A submitted transaction has not necessarily been accepted into a block. Inclusion is also distinct from the protocol’s settlement or finality conditions.

A useful high-level sequence is:

1. A participant constructs and authorizes a proposed update.
2. The network checks whether it follows the relevant rules.
3. A block producer proposes including it in the history.
4. Participants apply the protocol’s acceptance rules.
5. Applications decide when the result is sufficiently settled for their purpose.

Details vary by network. Some histories can reorganize near their latest blocks, while other protocols define explicit finality under stated assumptions.

A user interface should not describe every submitted update as completed immediately.

Shared Control Comes in Different Forms

A permissionless network allows participation according to public protocol rules. A permissioned network restricts roles such as transaction submission or block validation.

Neither arrangement automatically means control is evenly distributed. Infrastructure, governance, software development, and validation power can be concentrated.

For the shipment example, ask which companies can validate updates, change membership, or alter the application rules. If one organization retains all those powers, the trust arrangement may resemble a centrally administered system despite having several nodes.

Distribution describes where work occurs. Governance describes who can decide what the system does.

Blockchain Cannot Inspect a Shipment

Suppose a warehouse submits “parcel inspected and undamaged.” The network can validate the submitter’s authority and preserve the entry without knowing whether an inspection occurred.

A person, sensor, or external service supplies that real-world evidence. Systems that bring external information into blockchain applications are commonly called oracles; Ethereum’s oracle documentation explains this boundary.

The practical question remains whether the source is trustworthy and how disputes are handled.

A shared ledger can make conflicting claims easier to investigate. It cannot make an unreliable inspection process accurate.

Smart Contracts Add Executable Rules

Some blockchains support smart contracts: programs executed according to the network’s rules.

In a shipment application, a contract might allow a handover only from the currently recorded custodian. That can enforce a rule about ledger state.

It still cannot establish that the physical parcel changed hands. If a program relies on an external confirmation, the source of that confirmation remains part of the system.

Smart contracts also have ordinary software concerns, including bugs, access control, upgrade paths, and testing. Their execution being shared does not establish that their logic is correct.

When Is a Blockchain Appropriate?

Begin with the control problem. Do several independent parties need shared state without granting one participant unilateral authority over it?

If they already accept a trusted operator, a conventional database with suitable auditing may be simpler. A blockchain introduces coordination, replication, and governance work that should address a real requirement.

Privacy also needs explicit design. Cryptographic validation does not mean all ledger contents are confidential.

Cryptocurrency applies shared-ledger mechanisms to digital assets. Other applications need their own justification. For the shipment system, that justification must come from the participating organizations’ trust requirements and operating processes, not from the name of the technology.

Agreement about what was recorded is different from proof that the original claim was true.