A blockchain is a record of transactions that’s copied across many independent computers instead of stored on one central server, with new entries added in blocks that are cryptographically linked to the block before them. That link is what makes the record extremely difficult to alter after the fact — changing an old entry would break every block that comes after it, across every copy of the chain at once.
The mechanism: blocks, hashes, and the chain
When a transaction happens, it’s broadcast to the network and grouped together with other pending transactions into a block. Each block includes a hash — a short fingerprint generated from the block’s contents — and also stores the hash of the block immediately before it. That’s the “chain” part: block 10 references block 9’s hash, block 11 references block 10’s hash, and so on, back to the very first block. Change anything in block 9 and its hash changes, which breaks the reference stored in block 10, and every block after it. On a network with many independent copies of the chain, an altered version is immediately inconsistent with everyone else’s copy.
How consensus keeps everyone in sync
With no central authority, the network needs a way for independent computers (“nodes”) to agree on which version of the chain is correct. That agreement mechanism is called consensus. Bitcoin uses proof-of-work, where nodes compete to solve a computational puzzle to add the next block, making it expensive to rewrite history. Many newer networks, including Ethereum since 2022, use proof-of-stake, where validators lock up (“stake”) the network’s own currency as collateral, and can lose it if they validate dishonestly. Different consensus mechanisms trade off speed, energy use, and security assumptions differently, but the goal is the same: get independent computers to agree on one shared, tamper-evident record.
Why it matters for coins and tokens
Every coin has its own blockchain running this process independently. Every token relies on its host blockchain’s consensus and validators instead of running its own — see coin vs. token: what’s the real difference for how that changes what creating one actually involves. Bitcoin was the first network to combine these pieces — a shared ledger, cryptographic linking, and decentralized consensus — into a working system; see when was Bitcoin created for that history.
Tokens specifically depend on one more piece: a smart contract, which is just code stored on the blockchain that runs automatically when called, following rules nobody can quietly change after the fact. A token’s balance sheet — who owns how much — is data the smart contract maintains, and every transfer is a rule the contract enforces the same way for everyone, including its own creator. That’s what lets a token inherit a host blockchain’s trust guarantees instead of needing its own: the code runs the same, verifiable way on every node that processes it. That’s also why a bug in a smart contract can be so costly: the same “nobody can quietly change the rules” property that makes it trustworthy also means an error, once deployed, usually can’t be quietly patched either.
What a blockchain doesn’t do
A blockchain doesn’t verify that the real-world information feeding into it is true — it can only guarantee that once something is recorded, it hasn’t been altered. It also isn’t free to run: more participants and more security generally means more computing resources, which is part of why blockchain transactions often cost more and move slower than a centralized database. Those trade-offs are a deliberate cost of not needing to trust a single central operator.
Public vs. private blockchains
Everything above describes a public blockchain — anyone can run a node, anyone can submit a transaction, and anyone can read the full history. Bitcoin and Ethereum both work this way. A private (or “permissioned”) blockchain restricts who can run a node or write to the ledger, usually to a known set of organizations — a group of banks settling transactions with each other, for example. Private blockchains keep the tamper-evident, block-and-hash structure, but they trade away the “no central authority needed” property, since the permissioned group effectively acts as a collective authority. Coins and tokens, as most people encounter them, run on public blockchains — that’s what makes them usable by anyone without permission from a gatekeeper.
Reading a block explorer
Because public blockchains are, by design, readable by anyone, every major network has a “block explorer” — a website that lets you look up any transaction, block, or wallet address and see its full history. That transparency is a direct consequence of the mechanism described above: since every node holds a full copy of the ledger, making that data browsable is mostly a matter of building a friendly interface on top of information that was already public. This is also why blockchain transactions are usually described as “pseudonymous” rather than anonymous — wallet addresses aren’t tied to a name by the protocol itself, but every transaction they’ve ever made is permanently visible to anyone who looks.
Blockchain vs. a normal database
It’s fair to ask why any of this is necessary when centralized databases have solved “store data reliably” for decades. The honest answer is that a normal database is better in most ways that matter for typical software: it’s faster, cheaper to run, easier to update when a mistake needs fixing, and doesn’t require anyone to reach consensus before writing a row. A blockchain gives up all of that speed and flexibility to solve one specific problem a normal database can’t: letting mutually distrustful parties agree on a shared record without any of them controlling it. If a single organization is trusted to run the database — a bank managing its own accounts, a company managing its own inventory — a blockchain is usually the wrong tool. It earns its cost specifically in situations where no single party should be the one holding the master copy.
Hashing, in more depth
A cryptographic hash function takes any input — a single character or an entire block of transactions — and produces a fixed-length output that looks nothing like the input and can’t practically be reversed back into it. The property that matters most for blockchains is the avalanche effect: changing even one character of the input produces a completely different, unrecognizable hash, with no partial resemblance to the original. That’s what makes tampering detectable — there’s no way to make a small, undetected edit to old data and have its hash still match what every other node already recorded.
Hash functions are also deterministic and fast to compute in one direction: the same input always produces the same hash, and any node can verify a hash in a fraction of a second. What they’re deliberately not fast at is working backward — finding an input that produces a specific target hash requires, in practical terms, guessing inputs until one happens to work. Proof-of-work mining exploits exactly that asymmetry: it’s what makes finding a valid block hard, while verifying someone else already found one is nearly instant.
Merkle trees: fitting thousands of transactions into one small proof
A block can contain thousands of transactions, but each block header stores only a single hash representing all of them — a Merkle root. It’s built by hashing transactions in pairs, then hashing those results in pairs, repeating until one hash remains at the top of the tree. Changing any single transaction anywhere in the block changes the Merkle root, which means the block header alone is enough to detect tampering with any transaction inside it, without needing to store every transaction directly in the header.
This structure also enables something called a Merkle proof: a way to prove a specific transaction is included in a block using only a small handful of hashes, rather than downloading the entire block. Lightweight wallets that don’t store a full copy of the blockchain rely on exactly this — verifying a transaction happened without needing every byte of history a full node keeps.
UTXO vs. account-based ledgers
Not every blockchain tracks balances the same way. Bitcoin uses what’s called the UTXO model (unspent transaction output): rather than storing an account balance directly, the network tracks discrete chunks of value created by past transactions. Spending means consuming one or more of those chunks as inputs and creating new ones as outputs — your “balance” is really just the sum of every UTXO a wallet can prove it controls.
Ethereum and most token-hosting chains instead use an account-based model, closer to a traditional ledger: each address has a balance that increases or decreases directly with each transaction, similar to how a bank account statement works. The account model is generally simpler to reason about and is what makes smart contract state — a contract’s own stored data, separate from any one user’s balance — straightforward to implement. The UTXO model, by contrast, makes certain properties (like parallel transaction validation) easier to reason about, at the cost of being less intuitive for anything beyond simple transfers.
Finality: when is a transaction actually final?
“Added to the blockchain” and “permanently settled” aren’t quite the same moment. In proof-of-work networks like Bitcoin, finality is probabilistic: each additional block mined on top of a transaction’s block makes reversing it exponentially more expensive, but there’s no single instant where it becomes mathematically impossible to undo — just increasingly unlikely, which is why services often wait for several confirmations before treating a large transaction as settled.
Some proof-of-stake systems instead offer deterministic finality: after a specific process completes, a block is finalized in a way the protocol guarantees can’t be reversed without an extreme, economically self-destructive action from a large share of validators. Neither approach is strictly better; they represent different engineering tradeoffs between settlement speed and the assumptions the security model rests on.
Byzantine fault tolerance: the underlying theoretical problem
Blockchains are, at a theoretical level, one practical answer to something computer science calls the Byzantine Generals Problem: how can a group of parties coordinate reliably when some of them might be faulty, offline, or actively lying, and nobody knows in advance which ones? A system that can still function correctly despite some participants behaving arbitrarily badly is described as Byzantine fault tolerant. Consensus mechanisms are, functionally, blockchain-specific solutions to this decades-old distributed-systems problem, adapted to work at internet scale with participants nobody has to trust individually.
Consensus mechanisms beyond proof of work and proof of stake
Proof of work and proof of stake are the two most widely known consensus mechanisms, but not the only ones in production use. Delegated proof of stake has token holders vote for a limited set of validators to produce blocks on their behalf, trading some decentralization for higher transaction throughput. Proof of authority relies on a small set of pre-approved, identified validators — appropriate for permissioned or private networks where participants are already known and don’t need to be anonymous. Solana’s network combines proof of stake with proof of history, a mechanism for cryptographically timestamping the order of events before consensus even happens, reducing how much validators need to communicate to agree on ordering.
How nodes actually find each other
None of this works without nodes being able to locate and communicate with each other in the first place. Public blockchains typically run on a peer-to-peer gossip protocol: a node connects to a handful of other nodes, and new transactions or blocks propagate outward as each node relays what it receives to its own connections. There’s no central directory of “all nodes” — a new node discovers peers through a combination of hardcoded bootstrap addresses and peers introducing it to other peers, gradually building up its own view of the network.
Scaling: sharding, rollups, and why it’s genuinely hard
Every node in a typical public blockchain processes every transaction — which is part of what makes the security model work, but also puts a hard ceiling on throughput, since the network can’t process transactions faster than a single node reasonably can. Sharding splits the network into multiple parallel groups that each handle a subset of transactions, increasing total throughput at the cost of added coordination complexity between shards. Rollups (a Layer 2 technique) instead process transactions off the main chain and periodically submit a compressed summary back to it, inheriting the base chain’s security while handling the bulk of computation elsewhere. Both approaches are attempts to solve the same underlying tension: the properties that make a blockchain trustworthy — every node verifying everything — are the same properties that limit how fast it can go.
State vs. ledger: what a node actually stores
A blockchain’s ledger is its full history — every transaction, in order, back to the genesis block. Its state is the current result of applying that entire history — current balances, current contract data — which is what most day-to-day operations actually need to check. A full node typically stores both: the complete ledger for verification and audit purposes, and the current state for fast, everyday lookups without replaying the entire history every time. Some lighter node configurations trade off storing the full historical ledger to reduce hardware requirements, at the cost of relying more on other nodes for deep historical queries.
The blockchain trilemma
A widely referenced framing holds that a blockchain design tends to optimize for at most two of three properties at once: decentralization (how many independent participants can meaningfully validate the network), security (resistance to attack), and scalability (how much transaction throughput the network can handle). A network that maximizes throughput by relying on a small number of powerful validators trades away some decentralization to get there. A network that maximizes decentralization by letting anyone with modest hardware run a full node tends to cap how fast it can process transactions, since the whole point is that ordinary hardware can keep up. Different networks make deliberately different tradeoffs here — there’s no configuration that maximizes all three simultaneously without some other compromise, such as the added complexity of Layer 2 scaling.
Difficulty adjustment
In proof-of-work networks, the computational puzzle miners solve isn’t a fixed difficulty — it adjusts periodically based on how quickly recent blocks were found, targeting a roughly constant average time between blocks even as the total computing power dedicated to mining rises or falls. Bitcoin, for example, recalculates its difficulty roughly every two weeks based on how fast the previous set of blocks was actually mined. This is what keeps block production pace relatively stable over time despite huge swings in how much hardware is pointed at the network.
Chain reorganizations
Occasionally, two miners or validators produce competing valid blocks at nearly the same time, temporarily splitting the network’s view of the most recent history. Nodes resolve this by eventually converging on one branch — typically whichever accumulates more subsequent work or validator support — and discarding the other, an event called a chain reorganization or “reorg.” Small, shallow reorgs of one or two blocks happen occasionally as a normal part of network operation; the deeper a transaction is buried under subsequent blocks, the more expensive and less realistic a reorg reaching back that far becomes, which is the actual mechanism behind “waiting for confirmations” as a practical measure of finality.
Light clients vs. full nodes
A full node downloads and independently verifies the entire blockchain’s history, trusting no other party’s claims about what it contains. A light client — common in mobile wallets — instead downloads only block headers and relies on Merkle proofs (see above) to verify that specific transactions it cares about are genuinely included, without processing every transaction on the network itself. Light clients trade a small amount of trust in the data they’re given for a dramatic reduction in storage and bandwidth requirements, which is what makes running a wallet on a phone practical at all.
Data availability
Publishing data and making it usably available aren’t quite the same guarantee. A network can technically publish transaction data while making it impractically difficult for ordinary participants to actually retrieve and verify it — a concern that’s become particularly relevant for Layer 2 rollups, which need the underlying data behind their compressed summaries to remain genuinely accessible so anyone can independently reconstruct and verify the full transaction history if needed, not just trust the summary at face value.
Cross-chain communication
Because each blockchain is its own independent, self-contained ledger with no built-in awareness of any other chain, getting information or assets from one to another requires an external mechanism — commonly a bridge (see the glossary on the homepage) — that itself has to be trusted to accurately represent what happened on the source chain. This is a meaningfully different trust model than a transaction within a single chain, which is verified directly by that chain’s own consensus rather than relayed by an intermediary system, and it’s part of why cross-chain bridges have historically been a common target for exploits — they concentrate trust in a place the underlying blockchains’ own security models don’t cover.
Technical FAQ
Why can’t a blockchain just increase its block size to process more transactions?
Larger blocks take longer to propagate across the network and require more storage and bandwidth from every full node, which can push out participants running on modest hardware — directly trading away decentralization for throughput, the tradeoff described in the trilemma above.
What actually happens when two blocks are mined at the same time?
Different parts of the network temporarily see different “latest” blocks. Nodes keep both as valid candidates until subsequent blocks extend one of them further, at which point the shorter branch is discarded — a normal, expected occurrence handled automatically by the protocol’s rules, not an error condition.
Is a hash function the same thing as encryption?
No — encryption is designed to be reversible with the right key; a cryptographic hash function is designed to not be reversible at all. Hashing verifies that data hasn’t changed; encryption hides data from parties without the key to unlock it. Blockchains primarily rely on hashing, not encryption, for their core integrity guarantees.
Why does Bitcoin’s block time target ten minutes specifically?
It’s a deliberate design tradeoff between transaction confirmation speed and the network’s ability to propagate each new block globally before the next one is found — too fast a target increases the rate of temporary forks described above, since blocks wouldn’t have time to fully propagate before competing blocks appear.
What’s a 51% attack, concretely?
If a single party controls more than half of a proof-of-work network’s total mining power, they gain the ability to consistently out-mine everyone else, letting them potentially reverse recent transactions by building an alternative, longer chain in secret. It doesn’t let them steal funds from arbitrary wallets or change old, deeply buried history — only rewrite relatively recent blocks, at significant computational cost.
Can a node lie about the current state without anyone noticing?
Not to a node that verifies independently — the entire point of running a full node is not having to trust any other single party’s claims. A node that only trusts data from one source without independent verification (some light clients, some centralized services) is making a different, weaker trust tradeoff than a full node does.
Why do some networks have multiple different node client implementations?
Relying on a single software implementation means a bug in that one codebase could affect the entire network identically. Multiple independent implementations of the same protocol rules reduce that risk, since a bug specific to one client’s code is unlikely to affect a differently-written client following the same rules.
What does “trustless” mean at the node level, specifically?
A full node doesn’t have to trust any peer’s claims — it independently re-derives and checks every rule (valid signatures, valid hashes, valid state transitions) itself using only the raw data it receives, rather than accepting another node’s summary or conclusion.
How do nodes agree on the order of transactions within the same block?
The block’s creator (miner or validator) determines the ordering when assembling the block; other nodes verify the block is internally valid given that ordering, but don’t independently reorder it themselves. This is part of why transaction ordering within a block can matter for certain applications sensitive to exactly which transaction executes first.
What’s the practical difference between a testnet and a fork of a live mainnet?
A testnet is typically a separate, ongoing network maintained specifically for testing, with its own history. A fork of mainnet is a one-time snapshot of real mainnet state used to test against realistic, current data — useful for testing how a contract or upgrade would behave against actual existing balances and contracts, not just synthetic test data.
Extended glossary: mechanism-level terms
Avalanche effect
The property of a hash function where a tiny change to the input produces a completely different output, with no partial resemblance to the original — what makes tampering detectable.
Merkle root
The single hash at the top of a Merkle tree, summarizing every transaction in a block well enough that changing any one of them changes this value.
Byzantine Generals Problem
A foundational distributed-systems problem: how independent parties can coordinate reliably when some participants might be faulty or actively dishonest, and nobody knows in advance which ones.
Delegated proof of stake
A consensus variant where token holders vote for a limited set of validators to produce blocks, trading some decentralization for higher throughput.
Proof of authority
A consensus mechanism relying on a small set of pre-approved, identified validators, suited to permissioned networks where participants are already known.
Proof of history
A mechanism (used by Solana) for cryptographically timestamping the order of events before consensus happens, reducing how much validators need to communicate to agree on ordering.
Gossip protocol
The peer-to-peer method by which new transactions and blocks propagate across a network, each node relaying what it receives to its own connections.
Sharding
Splitting a network into parallel groups that each handle a subset of transactions, increasing throughput at the cost of coordination complexity between shards.
Rollup
A Layer 2 technique that processes transactions off the main chain and periodically submits a compressed summary back to it, inheriting the base chain’s security.
Blockchain trilemma
The framing that a design tends to optimize for at most two of decentralization, security, and scalability at once.
Difficulty adjustment
The periodic recalibration of a proof-of-work network’s puzzle difficulty, targeting a roughly constant average time between blocks.
Chain reorganization (reorg)
An event where the network converges on a different recent chain branch than it initially had, discarding the shorter one — usually shallow and routine, occasionally deeper and disruptive.
Light client
A node that verifies specific transactions via Merkle proofs rather than processing the entire blockchain itself, trading some independent verification for dramatically lower resource requirements.
Data availability
The guarantee that published data is genuinely retrievable and checkable by network participants, not merely technically published somewhere impractical to access.
Finality (deterministic)
A guarantee that a finalized block cannot be reversed without an extreme, economically self-destructive action by a large share of network validators.
Finality (probabilistic)
A model where reversing a transaction becomes exponentially less likely — but never mathematically impossible — as more blocks are added on top of it.
State transition
The change from one valid blockchain state to the next as a block’s transactions are applied — what every node independently recomputes and checks.
Node client
A specific software implementation of a blockchain’s protocol rules; multiple independent clients for the same network reduce the risk of a single shared bug affecting everyone.
Comparing security models directly
“Which consensus mechanism is more secure” doesn’t have a single answer, because each one is secure against a different kind of attack, with different costs and assumptions.
| Proof of work | Proof of stake | |
|---|---|---|
| Security source | Cost of hardware + electricity | Economic stake at risk of slashing |
| Attacker needs | >50% of network hash power | A large share of total staked value |
| Main assumption | Hardware/energy cost exceeds attack payoff | Losses from slashing exceed attack payoff |
| Energy use | High | Low |
| Concentration risk | Mining pool concentration | Large-staker concentration |
Proof of work’s security comes from the cost of the hardware and electricity required to out-compute the rest of the network — an attacker needs to control more raw computing power than everyone else combined, which for an established network represents an enormous, ongoing physical resource commitment that’s difficult to hide or acquire quickly. Its main assumption is that acquiring that much hardware and energy is harder than the potential payoff justifies.
Proof of stake’s security instead comes from economic risk: validators put up the network’s own currency as collateral, and provably dishonest behavior gets that collateral destroyed (“slashed”). Its main assumption is that validators have more to lose from acting dishonestly than they could gain from it — which depends on the staked asset actually holding meaningful value, creating a certain circularity between the network’s security and its own token’s market value that proof-of-work security doesn’t share in the same way.
Neither model eliminates the need for enough independent participants — a proof-of-stake network where a handful of validators control most of the stake has a similar concentration problem to a proof-of-work network where a handful of mining pools control most of the hash power. The specific mechanism differs; the underlying requirement — broad, genuine independence among validators — doesn’t.
What a blockchain can’t verify about the physical world
Everything described so far explains how a blockchain keeps its own internal records honest. None of it extends to verifying claims about anything outside itself. If a smart contract needs to know a real-world price, a shipment’s delivery status, or an election result, the blockchain has no native way to check that — it can only process whatever data an oracle (see the homepage glossary) feeds it, and it will faithfully process false data exactly as reliably as it processes true data. This is sometimes called the “oracle problem,” and it’s a genuine, unsolved-in-general limitation: the trustlessness a blockchain provides for its own internal state doesn’t automatically transfer to any external fact the contract depends on.
Why upgrading a live blockchain is harder than upgrading normal software
Ordinary software gets updated by the team that controls the server running it. A public blockchain has no single server and no single controlling party — every node operator independently chooses whether to run new software implementing a proposed change. A change gets adopted only if enough of the network’s participants voluntarily choose to run it; there’s no mechanism to force adoption on node operators who decline. This is why blockchain protocol upgrades are typically preceded by extensive public discussion, testing, and coordination well in advance of an activation date — the upgrade only works if the coordination actually succeeds.
Reading a raw block, conceptually
Stripped down, a block header typically contains: a reference to the previous block’s hash (the “chain” link), a Merkle root summarizing its transactions, a timestamp, and — depending on the consensus mechanism — either a proof-of-work solution or validator signatures attesting to the block’s validity. Everything else a block explorer displays (transaction details, addresses, amounts) is derived from the block’s full transaction list, which the header’s Merkle root anchors but doesn’t itself contain directly. Understanding this structure is what makes it possible to reason about what a light client can verify from a header alone versus what requires the full transaction data.
What this means practically for anyone building on top of a blockchain
Someone deploying a token contract doesn’t need to implement any of the mechanisms described above — hashing, consensus, networking — themselves. The host blockchain handles all of it. What does carry over practically is an understanding of what the chosen chain’s specific tradeoffs mean for the application: a chain optimized for high throughput at the cost of some decentralization behaves differently under stress than one that prioritizes decentralization over speed, and a chain with probabilistic finality means an application handling high-value transactions should wait for more confirmations than one handling low-stakes activity.
It also explains why “just move to a faster blockchain” isn’t a free upgrade — every one of the tradeoffs above is a deliberate design decision somewhere in that chain’s architecture, and a faster chain got that speed by giving up something else, whether that’s decentralization, a longer security track record, or a different, less-tested set of assumptions about validator honesty.
Common misconceptions specific to blockchain mechanics
Misconception: a blockchain stores files, like a hard drive.
Reality: most blockchains store transaction and state data, not arbitrary files — storing large files directly on-chain is technically possible but prohibitively expensive on most networks, which is why applications needing to reference large files typically store a hash or pointer on-chain and the actual file elsewhere.
Misconception: more nodes always means a faster network.
Reality: more nodes generally means more security and decentralization, not more speed — since every node still has to independently verify the same transactions, adding nodes doesn’t parallelize the verification workload in a way that increases throughput.
Misconception: a 51% attack lets an attacker steal any wallet’s funds.
Reality: a 51% attack lets an attacker rewrite recent transaction history and potentially double-spend their own funds — it doesn’t let them forge a signature they don’t have the private key for, so other people’s existing holdings aren’t directly stealable through this specific attack.
Misconception: proof of stake means the richest validator always wins.
Reality: having more stake increases the probability of being selected to produce a block, but selection is still probabilistic in most implementations, not a guaranteed outcome purely proportional to wealth on every single block.
Misconception: a blockchain transaction happens “instantly.”
Reality: a transaction has to be broadcast, included in a block, and then reach whatever finality threshold the application considers safe — a process that can take anywhere from seconds to tens of minutes depending on the network and how much confirmation depth a given use case requires.
Misconception: forking a blockchain’s code creates a competing, equally valuable network.
Reality: copying the code is the easy part — the actual value and security of an established network comes from its existing validator base, its holders, and its integrations, none of which transfer automatically to a code fork starting from zero participants.
The relationship between block time and security assumptions
A network’s target block time isn’t an arbitrary setting — it interacts directly with several of the mechanisms already described. A shorter block time means faster nominal confirmation but a higher rate of temporary forks, since blocks have less time to propagate fully before the next one appears; this is part of why very fast networks often pair short block times with additional mechanisms (like Solana’s proof of history) specifically to keep ordering consistent despite the speed. A longer block time reduces fork frequency but means each individual confirmation represents a longer wait, which networks often compensate for by considering a transaction reasonably safe well before waiting for the same number of confirmations a shorter-block-time network would need for equivalent security.
Why “decentralized” is a spectrum, revisited with more precision
Given everything above, decentralization can now be pinned down more concretely than a vague sense of “lots of people involved”: it’s a function of how many independent entities would need to collude to control block production (mining pools or staking pools), how many independent node client implementations exist (reducing shared-bug risk), how widely full nodes are geographically and organizationally distributed, and how concentrated token or hash-power ownership is. A network can score differently on each of these dimensions independently — high validator count but concentrated stake, for instance — which is why serious comparisons between networks look at several of these measures together rather than a single “decentralized or not” label.
How a transaction actually moves through the system, end to end
Putting the pieces above together, here’s the full path an ordinary transaction takes:
- Creation and signing. A wallet constructs the transaction and signs it with the sender’s private key, producing a signature anyone can verify against the corresponding public key without ever seeing the private key itself.
- Broadcast. The signed transaction is sent to one or more nodes the wallet is connected to, which relay it onward through the gossip protocol.
- Mempool. Nodes hold pending, not-yet-included transactions in a waiting area often called the mempool, from which block producers select transactions to include in their next block — typically prioritizing by fee, among other criteria.
- Inclusion in a block. A miner or validator assembles a block containing the transaction, computes the block’s Merkle root and header, and either solves the proof-of-work puzzle or gets the block validated according to the network’s proof-of-stake rules.
- Propagation and verification. The new block propagates across the network via gossip; every full node independently verifies every transaction and signature in it before accepting the block as valid.
- Confirmation accumulation. Subsequent blocks build on top of the one containing the transaction, each one making a reversal progressively less likely (proof of work) or the block progressively closer to deterministic finality (many proof-of-stake designs).
- State update. Every node updates its local view of the current state — balances, contract data — to reflect the now-included transaction, ready to be queried by wallets and applications.
Every mechanism covered earlier in this guide is doing work somewhere in that seven-step path — hashing in step 1 and 4, Merkle trees in step 4 and 5, consensus in step 4 and 6, networking in step 2 and 5, and state management in step 7.
Continue with the history of the network that started all of this: when was Bitcoin created, and why does it matter?