How does blockchain work?
Lesson 33 · practical guide
A blockchain is a replicated record updated by a network following agreed rules. Blocks group transactions, hashes link records and consensus decides which valid history is accepted.
What you will learn
Build a mental model of how a blockchain records transactions and why “immutable” has limits.
Key terms
- Block — a batch of transactions linked to earlier blocks.
- Node — a computer that verifies and relays network data.
- Finality — the point at which reversing a transaction becomes increasingly difficult under the protocol.
Follow these steps
- Start with a signed transaction, then follow broadcast, validation, inclusion and confirmation.
- Ask which participants can censor, reorder, upgrade or reorganise activity.
- Check whether your wallet shows a confirmed transaction on the correct network.
- Remember that blockchain history does not reverse a wrong address, scam or bad contract call.
Practical advice
A ledger can be difficult to alter while the application around it remains vulnerable. “On-chain” proves that data was recorded; it does not prove that the promise behind the transaction was honest.
Long-form explainer
The full guide
Read this lesson as a chapter: understand the mechanism, test the assumptions and apply the idea with a clear risk limit.
A blockchain is a chain of verifiable state
A block is a batch of transactions linked to earlier blocks. Nodes store, verify and relay network data according to the protocol. Consensus is the process by which participants agree which history is valid. Finality describes when reversing a transaction becomes increasingly difficult under those rules; it is not always an absolute guarantee in every design.
“Immutable” should therefore be used carefully. A confirmed record may be extremely difficult to alter, but software bugs, reorganisations, governance changes, key compromise and social coordination can still affect the system. The strength comes from the cost and coordination required to change state, not from a magical property of the database.
Read a transaction as a state change
Ask which account or output changed, what asset moved, who authorised it and which rules validated it. A block explorer can show an event, but it does not by itself prove that the application behaved as intended. Contract events, balances and permissions may all matter.
This mental model helps with custody and smart contracts. Before signing, you should know what state change you expect. After signing, verify that the network recorded the intended result and keep enough information to reconstruct the transaction later.
What usually goes wrong
The first mistake is believing that immutability makes data true. A blockchain records that something was written and makes it hard to alter afterwards; it cannot verify that the statement was accurate when it was made. Anything describing the physical world still depends on whoever entered it. The second error is treating every chain as equally difficult to attack. Security comes from the cost of rewriting history, and a small network with little participation can be far cheaper to disrupt than headlines suggest.
People also assume that public means anonymous. Addresses are pseudonymous, permanently visible and increasingly easy to connect to identities through exchanges, on-chain patterns and off-chain data. The final mistake is expecting the technology to remove trust rather than relocate it. You still trust the client software, the developers who maintain it, the miners or validators, the bridge, the front end and the wallet. Understanding where trust has moved is more useful than repeating that trust has been eliminated, because that is where the failures actually occur.
How it works
A wallet signs a transaction; nodes check it; a block producer includes it; other nodes validate the block. More confirmations can reduce reversal risk depending on the network.
Proof of work, proof of stake and other systems make different trade-offs around security, cost, finality and participation. A blockchain records data; it does not make the input true or the application safe.
Worked example
Numbers make an idea concrete. Here is a small, illustrative one — not a forecast.
A transaction visible on an explorer may not yet satisfy a merchant’s confirmation policy. High-value transfers need the network’s required finality, not just a visible hash.
Before you act
Run through these questions before you commit any money or make a decision based on this lesson:
- Who validates transactions?
- What does one confirmation mean here?
- Is recorded data actually verified?
- What if the app or oracle is wrong?
Practice this lesson
Reading is a start; doing the exercise is what makes the idea stick.
Explain a transaction using sign, broadcast, validate, include and confirm. Add one risk at each step.
Further reading
Educational content only: This guide is not personal financial, legal or tax advice. Markets involve risk, including the possible loss of capital. Verify current rules, fees and product availability in your country.