TL;DR
- A blockchain is a shared, ordered ledger maintained by multiple computers. Updates are grouped into blocks, proposed under protocol rules, verified by participating nodes and linked to earlier blocks so that later changes to accepted history are easy to detect and difficult to make stick.
- No. A blockchain is a ledger architecture. A cryptocurrency or crypto asset is something represented, transferred or used within that ledger. Bitcoin is both the name of a network and its native asset; other blockchains can track tokens, application state, credentials or business records.
- There is no universal block layout. A typical block includes a reference to a parent block, cryptographic commitments to transactions or state, network-specific metadata and an ordered payload. Bitcoin and Ethereum use different structures because they secure different execution and consensus models.
- Each block normally commits to its own data and references a cryptographic identifier for its parent. Editing an earlier block changes its identifier and breaks every later reference. Nodes can detect the mismatch immediately, but consensus security - not the hash link alone - prevents the altered version from becoming accepted history.
In one block
A blockchain is a distributed ledger that records ordered transactions or state changes in blocks. Each block normally references its predecessor and contains cryptographic commitments to its data. Nodes independently validate proposed blocks and use consensus and fork-choice rules to decide which history to accept.
What is a blockchain in simple terms?
Quick answer
A blockchain is a shared, ordered ledger maintained by multiple computers. Updates are grouped into blocks, proposed under protocol rules, verified by participating nodes and linked to earlier blocks so that later changes to accepted history are easy to detect and difficult to make stick.
Every payment system, asset register and application database needs a record of the current state: who owns what, which instructions have already been processed, and what happened first. A blockchain is one way to coordinate that record across multiple computers without giving one database operator exclusive authority over the accepted history.
The word that matters most here is agreement rather than chain. A hash-linked list can be created on one laptop in seconds. What makes a blockchain operationally different is that many nodes apply shared validation rules, exchange proposed updates and use a consensus process to decide which valid sequence they will treat as canonical.
Public blockchains such as Bitcoin and Ethereum let anyone download software, verify the rules and submit transactions. Permissioned blockchains restrict some roles - such as reading data, submitting transactions or publishing blocks - to authorised participants. Both can be distributed; neither is automatically decentralised in every practical sense.
The copies are not always literally identical. A full node validates blocks and maintains the information needed to enforce the protocol. An archive node may retain more historical state, a pruned node may discard old raw block data after validation, and a light client relies on compact proofs or selected peers. The common requirement is agreement on the accepted state or history, not identical storage on every device.
Is a blockchain the same as a cryptocurrency?
Quick answer
No. A blockchain is a ledger architecture. A cryptocurrency or crypto asset is something represented, transferred or used within that ledger. Bitcoin is both the name of a network and its native asset; other blockchains can track tokens, application state, credentials or business records.
Bitcoin combined a blockchain with digital signatures, peer-to-peer networking, proof of work and an incentive system to create electronic cash without a financial institution. That historical connection is why the words blockchain and cryptocurrency are often used as though they were interchangeable.
They are not. On Ethereum, blocks contain transactions that can transfer ETH, call smart contracts, issue tokens or change application state. In a permissioned business network, blocks may record shipment events or inter-company obligations and may have no publicly traded token at all.
Most permissionless networks use a native asset to pay fees, reward block production or impose economic penalties. Permissioned networks can instead rely on known identities, contracts, access controls and the ability to revoke a participant. A token can be useful to a protocol, but adding a token does not automatically improve a database or create economic value.
What is actually inside a block?
Quick answer
There is no universal block layout. A typical block includes a reference to a parent block, cryptographic commitments to transactions or state, network-specific metadata and an ordered payload. Bitcoin and Ethereum use different structures because they secure different execution and consensus models.
Protocols normally separate summary information from the full payload. In Bitcoin, the 80-byte block header includes the previous block header hash, a Merkle root committing to all transactions, a timestamp, a difficulty target, a nonce and a version field. The block body contains the transactions themselves.
Ethereum has both consensus-layer and execution-layer data. A beacon block identifies its slot and proposer, references a parent, commits to state and contains attestations plus an execution payload. That payload includes ordered transactions and roots committing to the resulting state, receipts and transaction list. The point is that a compact set of commitments lets nodes verify a large body of ordered data; the exact fields vary by protocol.
| Feature | Bitcoin example | Ethereum example |
|---|---|---|
| Parent reference | Hash of the previous block header | Parent root or parent hash |
| Data commitment | Merkle root of the block's transactions | Roots for execution state, receipts, transactions and consensus state |
| Ordering metadata | Height is derived; header contains version, time, target and nonce | Slot, proposer index, block number, timestamp and consensus data |
| Payload | Ordered Bitcoin transactions | Execution transactions, withdrawals, attestations and other consensus objects |
| Block production | Proof-of-work miner finds a valid header hash | A validator proposes in a 12-second slot; other validators attest |
How do hashes and block links make tampering visible?
Quick answer
Each block normally commits to its own data and references a cryptographic identifier for its parent. Editing an earlier block changes its identifier and breaks every later reference. Nodes can detect the mismatch immediately, but consensus security - not the hash link alone - prevents the altered version from becoming accepted history.
Suppose someone copies a blockchain database and changes an old payment. The commitment to that block's transactions changes. That changes the block header or root, which changes the identifier referenced by the next block. Recalculating every later hash can repair the attacker's private copy, so the chain is not protected by mathematics alone.
The hard part is persuading the rest of the network to accept the replacement. Honest full nodes reject any block that violates signatures, balances, smart-contract execution or other consensus rules. If the alternative history is valid, it must still defeat the network's fork-choice and finality rules - for example by accumulating more proof of work on Bitcoin or enough validator support on Ethereum.
Corrections are usually made by appending a new transaction rather than deleting the old one. Applications can mark earlier records as cancelled, superseded or reversed while preserving the audit trail. Protocol communities can also coordinate software upgrades or, in exceptional circumstances, adopt a fork. The result is a strong history of accepted changes, not a magical database that can never evolve.
How are new blocks proposed and checked?
Quick answer
A user signs an instruction, nodes check it against protocol rules, a miner or validator assembles a candidate block, and other full nodes independently verify the result. The block joins the accepted history only if it is valid and wins the network's chain-selection rules.
The process is easier to understand as five separate jobs:
- Submit. A wallet or application creates and signs a transaction, then sends it to one or more nodes. Many transactions spread through public node mempools; some reach block builders through private routes.
- Validate. Nodes check syntax, signatures, available funds or nonces, smart-contract execution and network-specific policy. Each node has its own pending-transaction view, so there is no single universal mempool.
- Propose. A selected validator, proof-of-work miner, authorised publisher or specialised builder orders valid transactions and constructs a candidate block within the protocol's resource limits.
- Verify. Other full nodes independently re-run the checks. They do not trust a block because a miner, validator or company says it is valid.
- Harden. Later blocks, accumulated work, validator attestations or finality checkpoints increase confidence that the accepted branch will not be reorganised.
Block timing also varies. Bitcoin targets an average interval of about ten minutes, but individual blocks can arrive much sooner or later. Ethereum divides time into 12-second slots; a slot can be empty if the selected proposer does not produce a block. Permissioned systems may use faster voting rounds because participants are known and access can be revoked.
How does a network choose one accepted history?
Quick answer
Validation rules decide which blocks are allowed; fork-choice rules decide which valid branch a node should build on; finality rules decide when replacing an older block becomes economically or procedurally unacceptable. These components together form the consensus mechanism.
Temporary disagreement is normal. Two Bitcoin miners can find valid blocks at nearly the same time, or Ethereum nodes can hear competing proposals in a different order. Each node initially follows its local view. As more work or validator attestations accumulate, the protocol's fork-choice rule gives one branch greater weight and the other becomes stale or reorganised.
Bitcoin: accumulated proof of work
Bitcoin full nodes accept only blocks that satisfy the consensus rules and normally follow the valid chain that is most difficult to recreate - commonly described as the chain with the most accumulated proof of work. A transaction becomes progressively harder to reverse as more blocks are built after it, but Bitcoin does not flip to a mathematically absolute final state at a fixed depth.
Ethereum: attestation weight and checkpoint finality
Ethereum validators attest to the chain they consider correct. A fork-choice rule selects the head supported by the greatest effective attestation weight, while checkpoint voting adds cryptoeconomic finality. When two-thirds of the total active stake supports the required checkpoint links, older blocks become finalised. Reverting finalised history would require a critical consensus failure and slashable behaviour involving at least one-third of the stake.
| Layer | Question it answers | Example |
|---|---|---|
| Validity rules | Is this transaction or block permitted by the protocol? | Signature, balance, execution and block-format checks |
| Sybil resistance / proposer selection | Who may compete or be selected to publish? | Bitcoin proof of work; Ethereum proof of stake |
| Fork choice | Which valid branch should a node treat as the head? | Most accumulated work; greatest attestation weight |
| Finality | When is replacing history beyond the accepted risk threshold? | Probabilistic depth on Bitcoin; checkpoint finality on Ethereum |
| Governance | How do the rules themselves change? | Software releases, node adoption, validators/miners and community coordination |
Why is established blockchain history hard to change?
Quick answer
To replace accepted history, an attacker must build an alternative sequence that remains valid and then make it win the relevant fork-choice or finality rules. The required cost grows with confirmation depth, accumulated work, validator participation and the social response of users and node operators.
Four controls reinforce one another:
- Digital signatures restrict spending or authorisation to the required keys or account rules.
- Deterministic validation prevents block producers from inventing balances, bypassing contract code or changing protocol limits in a block that honest nodes will accept.
- Hash commitments reveal any change to earlier transactions, state or block headers.
- Consensus economics make a competing valid history costly: sustained computation on proof-of-work systems, slashable stake on proof-of-stake systems, or accountable voting among permissioned participants.
Even majority influence is not a master key. A majority-hashpower attacker may be able to censor transactions, reorder recent blocks or reverse its own recent payment under suitable conditions. It still cannot produce another user's valid signature, spend assets without the required authorisation or make full nodes accept a block that violates their consensus rules. Likewise, validators cannot unilaterally change Ethereum's protocol merely by controlling block proposals; users and nodes must run software that recognises the rules.
Public versus permissioned blockchains
Quick answer
Public permissionless networks allow broad participation and use economic mechanisms to limit abuse. Permissioned networks restrict publishing or access to authorised identities and can trade some openness for privacy, speed and formal governance. Neither model is automatically superior.
| Dimension | Public, permissionless blockchain | Permissioned or consortium blockchain |
|---|---|---|
| Who can read | Usually anyone, although privacy layers may hide some data | May be public, partly shared or restricted to authorised members |
| Who can submit | Usually anyone who follows transaction rules and pays required fees | May require an approved identity, role or organisation |
| Who can publish blocks | Open competition or selection under protocol rules | Named validators, organisations or administrators |
| Abuse resistance | Work, stake, fees and other economic constraints | Identity, contracts, access control, audit and revocation |
| Native asset | Commonly used for fees, rewards or security | Optional; may have no publicly traded token |
| Privacy and performance | Broad replication can limit privacy and throughput | Can restrict data and use faster consensus among known parties |
| Governance risk | Influence may concentrate among developers, operators, pools, validators or tokenholders | Influence may concentrate in a consortium, administrator or membership authority |
| Best fit | Open settlement where no single operator should control participation | Shared workflows among known organisations that need joint auditability |
A permissioned ledger can still distribute control among several organisations and improve resilience or auditability compared with one company's database. But if one administrator can appoint validators, rewrite policy or deny access, participants still depend on that administrator. The trust model should be stated, not hidden behind the word blockchain.
Blockchain versus a normal database
Quick answer
A conventional database is usually the better choice when one trusted operator can maintain the record. A blockchain becomes relevant when multiple parties need a common ordered history, cannot reasonably give one party exclusive control, and accept the extra cost, latency, governance and privacy trade-offs.
Modern databases can be replicated, digitally signed, encrypted, highly available and extensively audited. Blockchain is not a synonym for secure database. Its distinctive value is coordinating updates and verification across parties with limited mutual trust or no agreed central operator.
| Question | Conventional database | Blockchain or distributed ledger |
|---|---|---|
| Who controls writes? | An administrator or service defines permissions | Protocol rules plus miners, validators or authorised publishers |
| How is consistency reached? | Database replication and operator-controlled consensus | Network-wide validation, fork choice and finality |
| Performance | Usually higher throughput and lower latency | Repeated validation and replication add cost and delay |
| Privacy | Fine-grained access control is straightforward | Public chains expose metadata; permissioned chains can restrict it |
| Corrections | Administrators can update or delete records | Corrections are commonly appended; deep history is designed to resist replacement |
| Auditability | Logs and signatures can provide strong evidence | Accepted history and commitments are independently verifiable under protocol assumptions |
| Failure model | Trust the operator, its security and its backups | Trust distributed rules, implementations, governance and the assumed honest/economic threshold |
| Best fit | Most internal applications and records | Shared settlement or audit where exclusive control is the central problem |
What are blockchains useful for?
Quick answer
Blockchains are strongest when several parties need a shared, independently verifiable order of events and no single party should have unilateral control. Their clearest uses are native digital assets, open settlement, programmable on-chain assets and some multi-organisation audit workflows.
Native digital assets and settlement
Bitcoin uses its blockchain to order transfers and prevent double-spending without a bank maintaining the definitive ledger. Other public networks support assets that can move between applications and counterparties on a common settlement layer. The benefit is open verification and shared settlement; the costs include fees, volatility, key management and limited reversibility.
Smart contracts and programmable state
General-purpose blockchains execute deterministic programs whose results become part of the shared state. This enables tokens, exchanges, lending systems and other applications to interact on one ledger. It also makes software bugs, governance keys, oracle design and transaction ordering part of financial risk.
Shared records among organisations
A consortium ledger can give several companies a synchronised audit trail without allowing one company to silently alter the common record. This can be useful when participants already exchange records but spend significant effort reconciling separate databases. It is less useful when one trusted system already serves everyone adequately.
A practical fit test
A blockchain deserves serious consideration only when most of these conditions are true:
- Several independent parties need to write or verify the record.
- The parties cannot or should not appoint one exclusive ledger operator.
- The order and audit trail of state changes are central to the problem.
- Participants can agree on deterministic validation and governance rules.
- The required privacy, throughput, latency and data-retention constraints are compatible with the design.
- Key recovery, software upgrades, dispute handling and emergency governance have explicit answers.
What are the limits and common misconceptions?
Quick answer
A blockchain can verify signatures, deterministic rules and the accepted sequence of on-chain events. It cannot establish that external information was true, that a user understood a signature request, that an application has no bugs, or that governance will always act wisely.
The oracle and input problem
A ledger faithfully preserves the data it receives; it does not know whether a shipment arrived, a sensor was calibrated or a human made an honest statement. External facts enter through people, devices and oracle systems, each with its own trust and failure model. Better auditability does not turn bad input into truth.
Keys and user intent
A valid signature proves that the required key or account rule authorised an instruction. It does not prove that the human intended the economic result, understood a contract approval or was not being coerced. Stolen keys and malicious signatures can create transactions that are technically valid and personally disastrous.
Smart-contract and implementation risk
Consensus can reproduce a software result consistently and still reproduce a bug. Smart contracts, bridges, wallets, node clients and governance systems need independent security review. Some systems also retain administrator or upgrade keys that can change behaviour after deployment.
Privacy and data permanence
Public blockchains usually expose addresses, amounts, contract calls and timing, even when names are absent. Pseudonymity is not anonymity. Storing personal or confidential data directly on an append-only public ledger can create legal and operational problems; many applications store only commitments on-chain and keep sensitive data elsewhere.
Scalability and concentration
Every validating node must be able to process enough data to enforce the rules. Raising block capacity can improve throughput but increase hardware requirements and reduce the number of people able to validate independently. Mining pools, validator operators, builders, client teams and infrastructure providers can also concentrate influence even when the protocol is open.
Governance does not disappear
Software has maintainers, bugs require fixes and communities disagree about upgrades. Public networks distribute these decisions among developers, node operators, miners or validators, users, businesses and social coordination. Permissioned systems formalise governance through contracts and administrators. In both cases, someone must decide how rules change and how exceptional failures are handled.
Frequently asked questions
What is a blockchain in one sentence?
A blockchain is a distributed ledger that groups ordered records into cryptographically linked blocks and uses shared validation and consensus rules so multiple nodes can agree on an accepted history.
Is blockchain the same thing as Bitcoin?
No. Bitcoin is a monetary network and asset that uses a blockchain. Ethereum and many other networks use different blockchains, and permissioned blockchains can record business events without a public cryptocurrency.
Who controls a blockchain?
It depends. Public networks distribute influence among protocol developers, node operators, miners or validators, users and businesses. Permissioned networks may be governed by a company or consortium. Claiming that nobody controls it is usually too absolute.
Can a blockchain be hacked or changed?
Software, applications, keys and infrastructure can be compromised. The accepted history can also be reorganised before strong confirmation or attacked if the relevant work, stake or governance threshold is captured. Deep, valid history on a large network is designed to be extremely difficult to replace, not metaphysically impossible.
Are all blockchains public?
No. Permissionless chains are normally publicly readable and broadly accessible. Permissioned chains can restrict reading, submitting transactions or publishing blocks to authorised participants.
Can anyone see my blockchain transactions?
On most public blockchains, anyone can inspect transaction data linked to addresses. The address may not display your name. Exchanges, analytics and other information can still connect activity to real identities. Privacy varies by network and tool.
Do blockchains work without cryptocurrency?
Yes, especially in permissioned systems. Most permissionless public networks use a native asset for fees, incentives or economic security, while a consortium can rely on known identities and contractual governance.
Why not use a normal database?
Use one when a trusted operator is acceptable. A database is usually faster, cheaper, more private and easier to correct. Blockchain is justified when shared verification and the absence of one exclusive ledger controller are core requirements.
What is a confirmation?
A confirmation means a transaction is included in an accepted block; later blocks add depth. On proof-of-work systems confidence generally grows probabilistically. Some proof-of-stake systems also define explicit checkpoint finality.
Is blockchain anonymous?
Usually not. Public chains are commonly pseudonymous: addresses are visible while names are not built into the protocol. Transaction patterns and off-chain records can often identify users.
The bottom line
A blockchain is not secured by one trick. Hashes link data and reveal changes. Digital signatures define authorisation. Full nodes independently enforce deterministic rules. Block producers propose an order, fork-choice rules resolve competing valid branches, and confirmations or finality harden the result. The security comes from the full system, not from the word blockchain.
The technology is most useful when several parties need one verifiable history and cannot give a single operator unilateral control. It is usually the wrong tool when a conventional database already solves the problem, when the inputs cannot be trusted, or when privacy and easy correction matter more than public auditability.
For readers continuing through this academy, the natural next questions are how transactions move from a wallet into a block, how proof of work and proof of stake price attacks, and how private keys authorise the state changes that the blockchain records.
Sources and further reading
Key references for this article, current as of July 2026.
- Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, 2008. https://bitcoin.org/bitcoin.pdf
- Bitcoin Developer Guide: Block chain. https://developer.bitcoin.org/devguide/block_chain.html
- Ethereum.org developer documentation: Blocks. https://ethereum.org/en/developers/docs/blocks/
- Ethereum.org developer documentation: Nodes and clients. https://ethereum.org/en/developers/docs/nodes-and-clients/
- Investopedia: Blockchain explained. https://www.investopedia.com/terms/b/blockchain.asp
- Wikipedia: Blockchain. https://en.wikipedia.org/wiki/Blockchain
Quick quiz: did it stick?
Choose an answer before checking the explanations below.
You have completed a quiz on “What Is a Blockchain and How Does It Work?”! Share your achievement on social media.
Was this helpful?
