How Does Blockchain Work?

Six steps, in order, with nothing skipped. The details vary between chains, but the shape is the same on all of them.

1. A key pair, and what it proves#

Before anything can be sent, an account needs a key pair: a private key kept secret, and a public key derived from it that anyone can see. The address is usually a hash of the public key.

Signing works in one direction. You can produce a signature over a message using the private key, and anyone holding the public key can verify that signature came from the matching private key — without ever seeing it.

This is why key custody is the whole security model. There is no password reset. A leaked private key is not a compromised account, it is the account.

2. Construct and sign#

A transaction is a small structured message. On an account-based chain it looks roughly like this:

  from:      0x71c7...9f3a
to:        0xa39d...04b1
value:     125000000000000000        # 0.125, in the chain's smallest unit
nonce:     47                        # this sender's 47th transaction
gas_limit: 21000
max_fee:   38000000000
data:      0x

Two fields deserve attention.

nonce is a per-sender counter. It fixes the order of your own transactions and makes replay impossible: once transaction 47 is included, another transaction 47 from the same account can never be.

gas_limit and the fee fields buy execution. Every operation the network performs on your behalf has a cost, paid by you, and capped by you. Set the limit too low and execution halts partway — and you still pay for the work done before it stopped.

The wallet serialises those fields, hashes them, and signs the hash. The signature travels with the transaction.

3. Into the mempool#

The signed transaction is submitted to one node, which does cheap checks before accepting it: is the signature valid, is the nonce sensible, can the account cover the maximum fee, is it well formed.

If it passes, the node holds it in its mempool — a pool of valid transactions waiting to be included — and gossips it to its peers, who do the same. Within a second or two most of the network is holding a copy.

4. A block producer builds a block#

Some node gets the right to propose the next block. How it gets that right is the consensus question, and it is the subject of the next episode. Assume for now that one node has been chosen.

That node selects transactions from its mempool — usually highest fee first, subject to the block's gas limit — executes them in order against the current state, and computes the resulting state. Then it assembles the block:

  parent_hash:  0x9f1c...a83e
height:       4813
timestamp:    2026-08-16T09:22:41Z
tx_root:      0x41b7...02dd     # merkle root over the included transactions
state_root:   0x6ea2...bb90     # fingerprint of world state AFTER execution
transactions: [ 214 items ]

state_root is the field that makes the next step possible. It is a single fingerprint of the entire state of the system after these transactions ran.

5. Every other node re-executes it#

This is the part that surprises people. Receiving nodes do not trust the producer's result. They take the parent state, replay every transaction in the block in the given order, and compute their own state_root.

If their root matches the one in the header, the producer's claim was honest and the block is valid. If it does not match — by a single bit — the block is rejected outright.

Determinism therefore becomes a hard requirement. Every node must compute exactly the same result from the same input. That rules out anything that varies between machines: no wall-clock reads, no random numbers, no floating-point, no network calls. It is the reason smart contract languages feel restrictive, and the restriction is not incidental.

6. Finality#

The block propagates and gets appended. Whether it is final depends on the consensus design.

• Probabilistic finality (proof of work, and some proof-of-stake designs). A block can still be displaced if a competing branch grows longer. The chance falls sharply with each block built on top, but never reaches zero. This is where "wait for six confirmations" comes from — a risk threshold, not a guarantee.
• Deterministic finality (BFT-style consensus, common in permissioned networks). Once a supermajority has voted for a block, it cannot be reverted without breaking the protocol's stated assumptions. Final in one round, at the cost of needing a known validator set.

Neither is better in the abstract. One tolerates an open, unknown membership. The other gives faster, harder guarantees but has to know who its validators are.

The whole path, in one line#

Sign → gossip → pool → propose → independently re-execute → agree → append.

Every blockchain you will meet is a variation on those seven steps. What differs is who gets to propose, how disagreement is settled, and how strong the final guarantee is.

All three of those are the same question, and it is the one worth understanding properly next.