How blockchains work: from transaction to confirmation

A blockchain combines an ordered history with rules for accepting changes to it. Computers participating in a network do not need to trust a website’s balance display: they can run software that checks the history and its resulting state. This is useful when participants need a shared record, but it is not a guarantee that every application built on that record is correct.

Key takeaways

• Signing, broadcasting, inclusion and finality are different stages of a transaction.
• Blocks order transactions and link to earlier blocks; consensus rules help participants agree on the accepted history.
• Bitcoin and Ethereum use different consensus mechanisms. Do not apply one network’s confirmation assumptions to every chain.
• A blockchain checks protocol rules. It does not independently verify every real-world claim an application records.

Start with a transaction

In a basic Ethereum account transfer, the sender authorizes an instruction with a signature and broadcasts it. The instruction identifies the recipient, amount and fee parameters; an account nonce helps order the sender’s transactions. The instruction still needs inclusion and execution. A wallet saying submitted therefore describes an earlier stage than a successful transaction receipt. Ethereum’s transaction documentation describes these fields and stages.

An application can also ask a user to interact with a smart contract: code and stored data at an address. The operation might update a token balance or perform several application actions. The visible button label is only an interface description; the contract’s actual execution determines the state changes. A contract is not a person who decides what the user intended. See the introduction to smart contracts.

Why transactions are grouped into blocks

A block packages an ordered set of transactions and references its predecessor through a cryptographic hash. Changing earlier data changes its hash, so later references would no longer match. This makes alteration detectable. It does not mean hashes alone decide which history is accepted: the network also needs rules for valid blocks and for choosing among competing histories. Ethereum’s blocks guide explains this structure.

Order matters because transactions can depend on the same resources. Imagine a classroom ledger with a balance of ten units. An instruction to spend seven followed by another to spend five cannot both succeed under a rule that forbids a negative balance. Copying both instructions to every student does not resolve the conflict. The class needs an agreed order and must apply the same rules to that order. This analogy illustrates the problem; real networks use signatures and protocol-specific validation rather than a classroom coordinator.

Consensus: agreeing on a history

Bitcoin’s proof-of-work design makes block production require computational work. Its chain-selection rule compares accumulated work, while valid transactions must also satisfy the network’s rules. The original Bitcoin white paper explains how this addresses conflicting payment histories. More confirmations increase the work an alternative history would need; a confirmation is not a promise that no reorganization is possible.

Ethereum uses proof of stake. Validators place ETH at stake, propose blocks and attest to the chain. Its protocol includes checkpoint finality, with penalties for specified misconduct. Finalized and merely included are therefore meaningfully different states. The guarantees depend on the protocol’s assumptions and participation, rather than a universal rule that every blockchain becomes final after the same number of blocks. Read Ethereum’s proof-of-stake documentation.

Worked example: reading a transaction’s progress

Consider a hypothetical transfer appearing in a wallet at 09:00. At 09:01 an explorer reports pending. At 09:02 it shows a successful receipt in a block. Later the network reports that block as finalized. These invented timestamps illustrate three observations, not an expected completion schedule. Pending means the transfer has not yet produced the displayed successful execution. The receipt supplies execution evidence. Finality answers a further question about the accepted history.

If the recipient’s app still shows the old balance, compare its network and address with the receipt before concluding the chain failed. Your research note should include the transaction identifier, network, execution status and block reference. This makes the question precise: is the transaction waiting, did it fail, or is a separate interface slow to reflect the result? Screenshots without those identifiers make these cases harder to distinguish.

Nodes, explorers and the limits of verification

A node runs client software; on Ethereum, execution and consensus clients work together to track and verify the chain. A block explorer presents information through a searchable interface. Reading an explorer is convenient, but it remains an interface to data. Ethereum’s nodes and clients guide explains the underlying roles.

• Do not confuse a broadcast notification with a successful receipt.
• Check the correct network before comparing addresses or transaction identifiers.
• Read the execution result as well as the block number; inclusion alone does not mean every intended action succeeded.
• For a claim about an external event, seek external evidence too. A permanent record can faithfully preserve an inaccurate input.

Frequently asked questions

Can a failed transaction appear in a block? Yes. Execution can fail while the attempt is recorded. On Ethereum, computation already performed can still incur a fee; failure does not mean no processing occurred.

Are all nodes miners? No. Mining is a proof-of-work role. A computer can verify blockchain data without mining, and Ethereum uses validators rather than proof-of-work miners.

Does blockchain mean the information is true? It establishes what the protocol accepted under its rules. Whether an off-chain claim is accurate remains a separate evidence question.