Imagine Anita wants to send Chidi a digital asset without asking a bank, payment company or marketplace to update its private database. A normal digital file can be copied, so the network needs a reliable way to answer three questions: Does Anita control the asset? Has she already spent it? Which version of the transaction history should everyone accept?
A blockchain answers those questions through a combination of cryptography, replicated records, network communication and consensus rules. None of those ingredients is magical by itself. The important idea is that they work together so strangers can share one history without appointing a single database owner.
Think of blockchain as a public accounting system with thousands of synchronized copies, strict rules for accepting entries and a built-in method for resolving disagreements. |
This guide follows one transaction from Anita’s wallet to final confirmation. Along the way, you will see what wallets, nodes, miners, validators, hashes, blocks, fees and confirmations actually do.
Different blockchains use different account models, fee rules, block times and consensus mechanisms. Our main example uses an account-based network, similar in spirit to Ethereum. Where Bitcoin or other networks behave differently, the guide points it out.
What blockchain actually is
It is a system, not merely a data structure.
At the data-structure level, a blockchain is an ordered set of blocks. Each block contains records and a cryptographic reference to an earlier block. At the network level, many independent computers store and check that history. At the governance level, shared software rules determine which transactions and blocks count as valid.
Part | Meaning | Its job |
|---|---|---|
Transaction | A signed instruction | Requests a state change: send value, call a contract or register data. |
Block | A batch of ordered transactions | Packages accepted activity with metAnitata and a link to prior history. |
Node | A computer running network software | Receives, checks, stores and forwards data. |
Ledger/state | The accepted history and current result | Answers who owns what and what smart contracts currently store. |
Consensus | Rules for choosing an accepted history | Lets distributed computers settle on order despite delays or conflict. |
Cryptography | Mathematical tools | Proves authorization and detects changed data. |
Distributed does not automatically mean decentralized
A database can be copied across many servers while one company still controls every server. A blockchain becomes meaningfully decentralized when control over block production, validation, software changes or participation is spread across independent parties. Decentralization is a spectrum, not an on/off switch.
Ledger versus state
The ledger is the ordered history of accepted transactions. The state is the latest result after applying them. If the ledger says Anita received 10 units and later sent 3, the current state may show her balance as 7. Nodes can replay the history to reconstruct the state, although many also store efficient snapshots.
A blockchain does not make every message true. It makes accepted messages ordered, auditable and difficult to rewrite. The validity rules decide what may enter the record. |
The transaction lifecycle
What happens after Anita presses Send?
Suppose Anita wants to send Chidi 0.2 units of a blockchain’s native asset. Her wallet does not move a file from one phone to another. It prepares an instruction that the network can independently verify.
Step | What happens | Who does it |
|---|---|---|
1. Construct | The wallet creates a message: sender, recipient, amount, fee settings and a sequence number or reference to spendable funds. | Anita’s wallet |
2. Sign | The wallet uses Anita’s private key to create a digital signature over the transaction data. | Anita’s wallet |
3. Broadcast | The signed transaction is sent to a node, which shares it with peer nodes. | Wallet and peer network |
4. Validate | Nodes check the signature, available funds, format, fee and anti-replay rules. | Full nodes |
5. Wait | A valid transaction enters a temporary pool of pending transactions. | Node mempools |
6. Propose | A miner or validator selects transactions, orders them and proposes a block. | Block producer |
7. Agree | The consensus mechanism determines whether the proposed block becomes part of the accepted history. | Consensus participants |
8. Confirm | Nodes execute the block, update their state and build later blocks on top of it. | The network |
The pending pool is not one global waiting room
People often say “the mempool” as if it were a single place. In reality, each node may have its own view. Network delays, local policies and fee thresholds mean one node may know about a transaction before another. A transaction shown as pending has usually been broadcast but has not yet been included in an accepted block.
Keys, addresses and digital signatures
How does the network know Anita authorized the payment?
A wallet manages cryptographic keys. The private key is a secret number used to authorize actions. A public key is derived from it and can be shared. An address is usually a shorter, formatted identifier derived from the public key or from a smart contract.
Item | Safe to share? | What it does |
|---|---|---|
Private key/seed phrase | No - never | Controls the ability to sign. Anyone who gets it can usually control the assets. |
Public key | Yes | Allows software to verify signatures associated with the private key. |
Address | Yes | Acts like a destination or account identifier on the network. |
Digital signature | Yes | Proves that the key holder approved specific transaction data. |
What signing means
The wallet takes the transaction data and uses Anita’s private key to produce a signature. Nodes combine the signature, transaction data and public information to verify authorization. The verification works without revealing or reconstructing the private key.
A signature proves control of a key, not a person’s legal identity, honesty or intention. If a scammer tricks Anita into signing a harmful transaction, the signature can still be cryptographically valid. |
Why can transaction details not be changed silently
The signature is tied to the exact message. If an attacker changes Chidi’s address or the amount after Anita signs, signature verification fails. Anita must inspect what she is signing because an authorized instruction is often irreversible after final settlement.
Wallets do not literally store coins
The ledger records which addresses can spend which assets. The wallet stores or accesses keys and reads blockchain data. This is why recovering the same seed phrase in a compatible wallet can restore access: the assets remained on the blockchain; the new app regained the signing capability.
Account model and UTXO model
Account-based chains track balances and sequence numbers. Bitcoin tracks unspent transaction outputs (UTXOs): pieces of value created earlier and consumed later. Both prevent double-spending but organize the records differently.
Hashes and the chain of blocks
The tamper-evident glue.
A cryptographic hash function turns data of any size into a fixed-length fingerprint. The same input produces the same hash. A tiny input change produces a very different result. Good hash functions are designed so that it is impractical to reverse the fingerprint or find two useful inputs with the same output.
Property | Why it matters |
|---|---|
Deterministic | Every node hashing the same block data gets the same result. |
Sensitive to change | Editing even one transaction changes the relevant hashes. |
Fixed length | Large data can be represented by a compact fingerprint. |
Hard to reverse | A hash does not reveal the original private data by itself. |
Inside a block
A block typically contains an ordered list of transactions plus a header. The header includes information such as the previous block’s hash, a compact commitment to the block’s transactions, a timestamp or slot reference, and consensus-specific fields.
Many chains summarize transactions with a Merkle root or a related cryptographic commitment. This lets software prove that a transaction was included in a block without downloading every transaction in that block.
Why changing history is difficult
Block 103 points to Block 102’s hash. If someone edits a transaction in Block 102, its hash changes, so Block 103’s reference no longer matches. The attacker would need to rebuild the altered block and every dependent block, and then overcome the honest network’s consensus weight before the network accepts that alternate history.
Blockchains are tamper-evident and costly to rewrite; they are not metaphysically immutable. Rewrite resistance depends on the consensus mechanism, network participation, time elapsed and the attacker’s resources. |
Example
Imagine Block B contains the fingerprint of Block A. Block C contains the fingerprint of Block B. Changing Anita’s payment in Block A changes A’s fingerprint, which invalidates B’s reference and therefore the chain leading to C. Honest nodes reject the altered sequence unless it also satisfies the network’s consensus rules.
How the network agrees
Validation asks, “Is this allowed?” Consensus asks, “Which valid history wins?”
Two blocks can both contain individually valid transactions yet compete for the same place in history. This may happen because network messages arrive at different times or because two producers act almost simultaneously. Consensus supplies a method for choosing and extending one history.
Two broad approaches: computational competition and stake-backed participation.
Proof of Work | Proof of Stake | |
|---|---|---|
Who proposes | Miners | Validators selected under protocol rules |
Scarce resource | Computational work and energy | Capital locked or delegated as stake |
Security penalty | Cost of hardware, electricity and lost rewards | Lost rewards and, on some chains, slashed stake |
History choice | Usually the valid chain with the most accumulated work | Chain justified/finalized by stake-weighted votes |
Main tradeoff | Strong battle-tested security with high energy use | Lower energy use with economic and governance complexities |
Consensus is more than voting
Protocols specify who may propose, when proposals are valid, how participants attest or compete, how conflicting blocks are resolved, and when a block is considered final. Different chains make different choices about speed, cost, validator requirements and tolerance of malicious actors.
What miners and validators actually do
They propose and secure blocks; full nodes independently enforce the rules.
A block producer usually selects pending transactions, orders them, executes or checks them, builds a candidate block and publishes it. Other participants do not simply trust the producer. They independently verify that the block follows the protocol.
Proof of Work
Miners repeatedly change a value in the block header and hash it, searching for an output below a network target. Finding a qualifying hash is difficult and consumes resources; checking it is easy. The winning miner publishes the block. Other nodes verify the work and every transaction before accepting it.
Proof of Stake
Validators lock or are delegated value under the protocol. One validator may propose a block, while others attest to it. The protocol combines these messages to choose and eventually finalize history. Dishonest or unavailable behavior may lose rewards; certain provable violations may also trigger penalties.
Common misconception: Miners and validators do not decide whether an invalid payment becomes valid. A producer can propose nonsense, but correctly operating full nodes reject a block that breaks the rules. |
Why producers receive fees and rewards
Block production costs resources and requires reliable infrastructure. Protocol rewards and transaction fees encourage participation. Fee markets also ration limited block space: users compete for timely inclusion when demand exceeds capacity.
Role | Stores/checks history | Produces blocks | Needs stake or work? |
|---|---|---|---|
Full node | Yes | Usually no | No, beyond hardware and bandwidth |
Miner | Yes or works with Node software | Yes on PoW | Computational work |
Validator | Yes | Proposes/attests on PoS | Stake under protocol rules |
Light client | Checks compact proofs/headers | No | No |
Wallet app | Usually queries nodes/providers | No | No |
Confirmations, finality and forks
“Confirmed” is not identical on every network.
Get new Decode Web3 posts in your inbox.
Add any other topics you want to receive.
A transaction receives its first confirmation when it appears in an accepted block. Each later block built on top adds another confirmation in a chain that uses this convention. More confirmations generally mean a deeper reorganization would be required to remove it.
Probabilistic finality
In many Proof-of-Work systems, confidence grows as more work accumulates after a block. There is no single magical moment when reversal becomes mathematically impossible; instead, the probability becomes increasingly small under normal security assumptions.
Economic or protocol finality
Many Proof-of-Stake systems add explicit finalization rules. After enough stake-weighted attestations, reverting a finalized block would require severe protocol violations and potentially large penalties. Applications still choose their own risk thresholds.
What is a fork?
A temporary fork occurs when honest nodes briefly see competing valid blocks. Consensus normally resolves it, and one branch becomes canonical while the other is abandoned. Transactions from the abandoned block may return to pending status if they remain valid.
Term | Meaning |
|---|---|
Confirmation | Evidence that a transaction is inside an accepted block, often strengthened by later blocks. |
Reorganization | Replacement of recent blocks by a competing valid branch selected by consensus. |
Soft fork | A rule change that tightens validity conditions while aiming for backward compatibility. |
Hard fork | A rule change not accepted by older software; incompatible communities can continue as separate networks. |
Finality | The point or confidence level at which reversal is considered extraordinarily unlikely or protocol-expensive. |
For example: A coffee purchase, an exchange deposit and a million-dollar transfer may require different confirmation thresholds. The right threshold depends on the network and the value at risk. |
Smart contracts and state changes
A blockchain can execute shared programs, not only transfer coins.
A smart contract is code stored at a blockchain address and executed according to network rules. A user sends a transaction that calls a function. Every validating node computes the same permitted state transition. If the call succeeds, the resulting changes are recorded; if it fails, state changes are normally reverted, though a fee may still be charged for the computation attempted.
Example: an escrow
Anita deposits 100 units into an escrow contract for a design project.
The contract records Anita as the buyer, Chidi as the seller and a release condition.
After delivery, Anita sends a signed transaction calling the release function.
Nodes execute the same contract logic. If Anita is authorized and the conditions are met, the state changes and Chidi can receive the funds.
The contract does not know whether the design is beautiful or whether a real-world delivery happened. It only knows the on-chain data and trusted external inputs provided to it.
Oracles: the bridge to outside data
An oracle supplies information such as an exchange rate, weather result or match score. The blockchain can verify how the oracle’s signed data is used, but it cannot independently guarantee that the outside fact was measured correctly. Oracle design, therefore, introduces additional trust and security assumptions.
Gas and deterministic execution
General-purpose chains meter computation using gas or a similar unit. Users pay fees based on the work and storage their transactions require. Execution must be deterministic: honest nodes given the same prior state and transaction should reach the same new state.
A smart contract can be transparent and still contain bugs. Upgrades, administrator keys, external dependencies and user-interface tricks can also change the real risk. |
Security: what protects the ledger
Blockchain security is a stack of assumptions.
Threat | What it looks like | Typical defenses |
|---|---|---|
Double-spend | One asset is used in conflicting transactions. | Validation rules, transaction ordering and consensus. |
Majority / 51% attack | An attacker controls enough work or stake to influence recent history. | Broad participation, high attack cost, monitoring and finality rules. |
Sybil attack | One actor creates many fake identities. | Weight influence by scarce work, stake or permission—not account count. |
Key theft | An attacker obtains a user’s private key or seed phrase. | Hardware wallets, backups, multisig, limited approvals and careful signing. |
Smart-contract exploit | A bug or economic loophole drains or locks assets. | Audits, testing, formal methods, limited permissions and emergency controls. |
Bridge/oracle failure | A connected system lies, is compromised or loses backing. | Distributed designs, limits, proofs, monitoring and diversified dependencies. |
The blockchain trilemma
Networks often balance decentralization, security and scalability. Increasing throughput with powerful hardware may reduce the number of people who can run nodes. Adding many validators can increase communication overhead. Layer-2 systems move some work away from the base chain and later settle compressed results or proofs back to it.
Public versus permissioned blockchains
Question | Public/Permissionless | Private/Permissioned |
|---|---|---|
Who can participate? | Usually, anyone under protocol rules | Approved organizations or identities |
Trust model | Economic and cryptographic incentives among open participants | Governance and agreements among known parties |
Visibility | Often broadly reAnitable | May restrict data and access |
Best fit | Open assets and applications | Shared workflows among institutions |
What blockchain can and cannot guarantee
Separate the real properties from the marketing language.
Blockchain can help with… | Blockchain cannot guarantee… |
|---|---|
A shared, ordered record across independent participants | That every recorded claim reflects truth in the physical world |
Public verification of signatures and protocol rules | That the person controlling a key is honest or legally authorized |
Resistance to unilateral database editing | Perfect decentralization or immunity from governance pressure |
Programmable ownership and settlement | Bug-free code, stable prices or profitable investments |
Auditability of on-chain actions | Privacy—public records may reveal patterns even without real names |
Why blockchains are not ideal for everything
If one trusted organization already owns the process, must edit errors easily and needs very high private throughput, a conventional database may be faster, cheaper and simpler. Blockchain is most useful when multiple parties need a shared record, do not want one party to control it, and can express the rules digitally.
Where the trust moves
Blockchain reduces reliance on a central ledger operator, but it does not eliminate trust. Users trust cryptography, software implementations, hardware, economic incentives, governance processes, wallet interfaces, bridges, oracles and their own key management. Good analysis asks not “Is it trustless?” but “What must I trust now, and what happens if that assumption fails?”
Blockchain is a coordination technology. Its breakthrough is enabling many parties to verify and update a shared digital state under common rules, even when they do not fully trust one another. |
A five-question test
Are multiple independent parties writing to or relying on the same record?
Would giving one party full control create a meaningful risk?
Can the important rules and assets be represented digitally?
Does public verification or programmable settlement create real value?
Do the benefits justify fees, complexity, privacy limits and governance tradeoffs?
See it yourself with a block explorer
Observe the system without spending money.
A block explorer is a search interface for public blockchain data. It does not own the blockchain; it reads data from nodes and presents it in a human-friendly form. Use a reputable explorer for the network you want to study.
Excercise
Open a block explorer and choose a recent block.
Find the block number or slot, timestamp, producer, transaction count and parent-block reference.
Open one transaction. Identify its hash, status, sender, recipient, amount, fee and block location.
Notice that the transaction hash identifies the signed instruction, while the block hash identifies a container in the accepted history.
Refresh after a new block appears and watch the confirmation depth increase if the explorer uses that display.
Field | How to read it |
|---|---|
Transaction hash | A unique-looking fingerprint is used to locate the transaction. |
Status | Whether execution succeeded, failed or remains pending. |
From / To | The sending account and destination; “To” may be a smart contract. |
Value | The native asset amount transferred may be zero during a contract call. |
Fee | What the sender paid for inclusion and computation. |
Block | Where the transaction was included in the ordered history. |
Input data / logs | Encoded function calls and events; explorers may decode known contracts. |
Safety rule: Exploring public data requires no wallet connection and no seed phrase. Never enter a seed phrase into an explorer, support chat, form or website. |
The whole mechanism in one story
Anita sends Chidi 0.2 units.
Anita’s wallet builds a transaction containing Chidi’s address, the amount, a fee and anti-replay information.
Her wallet signs the exact message with her private key. The key stays secret.
The wallet broadcasts the signed transaction. Peer nodes forward it across the network.
Nodes verify their format, signature, balance and other protocol rules. Valid nodes may keep it pending.
A miner or validator selects it, orders it among other transactions and proposes a block.
Other nodes verify the block and execute its transactions. Consensus decides whether this block belongs to the accepted history.
The block includes a cryptographic link to earlier history. Nodes update their copies of the state: Anita’s spendable balance falls, and Chidi’s rises.
Later blocks or finality votes make reversal increasingly difficult. Chidi’s wallet reads the updated state and shows the payment as confirmed.
Remember this: Keys authorize. Nodes verify. Producers order. Consensus chooses. Hashes expose changes. Confirmations deepen confidence. |
Quick knowledge check
Question | Answer |
|---|---|
Does a wallet hold coins? | It primarily holds or accesses keys; the network ledger records ownership/state. |
Does every node mine or validate? | No. Full nodes can enforce rules without producing blocks. |
Can a valid transaction stay pending? | Yes. It may wait because of fees, capacity, network propagation or producer choice. |
Can blockchain verify an offline fact? | Only through an external input such as an oracle, which adds trust assumptions. |
Is a confirmed transaction instantly irreversible? | Not always. Finality rules and recommended confirmation depth vary by network. |
GLOSSARY
Term | Definition | Term | Definition |
|---|---|---|---|
Address | Public source, destination or contract identifier. | Gas | Unit measuring execution or storage work. |
Block | Ordered transaction batch linked to prior history. | Mempool | A node’s pool of valid pending transactions. |
Block explorer | An interface that presents public chain data. | Miner | PoW participant competing to propose blocks. |
Consensus | Protocol for choosing and finalizing shared history. | Node | Computer exchanging or checking chain data. |
Hash | Fixed-length fingerprint used to detect changes. | Private key | Secret value used to authorize transactions. |
Digital signature | Proof that a key holder authorized exact data. | Proof of Stake | Consensus secured by locked/delegated value. |
Finality | Point or confidence where reversal is highly unlikely. | Proof of Work | Consensus secured by verifiable computation. |
Full node | Software independently enforcing protocol rules. | Smart contract | Code that reads and updates on-chain state. |
Validator | PoS participant proposing or attesting to blocks. | Wallet | Software or hardware that manages signing keys. |
Final takeaway
A blockchain works because thousands of small, verifiable actions reinforce one another: wallets sign, peers relay, nodes check, producers order, consensus resolves conflict and cryptographic links preserve the integrity of the accepted history. Understanding that sequence is more valuable than memorizing buzzwords.
Next step: Pick one public blockchain, inspect five transactions and two blocks in an explorer, then explain the lifecycle aloud in your own words. If you can do that clearly, you understand the foundation. |
Join the conversation
What stayed with you? Leave a thought or a question. Comments appear after approval.
Loading comments…