How a Blockchain Works, From Transaction to Block

With hashes and signatures in hand, a blockchain is mostly bookkeeping. Here is one transfer, from start to finish.

1. Build and sign a transaction

A transaction says "move this amount from this address to that one", and carries a signature authorizing it. The sender serializes the transaction, hashes it to z, and signs z with their private key. The network will verify the signature against the public key tied to the sending address.

Two bookkeeping models exist:

• UTXO (Bitcoin). The ledger is a set of unspent outputs. A transaction consumes specific outputs and creates new ones. Each input carries a signature proving the right to spend that output.
• Account (Ethereum). The ledger is a map from address to balance and state. A transaction carries a nonce, a counter that must increase by one per transaction from that account, which prevents replays and fixes ordering.

2. Broadcast to the network

The signed transaction is sent to a node, which checks the signature, the format, and whether the funds exist. If valid, the node forwards it to its peers, and it waits in each node's pending pool, the mempool. Senders attach a fee, and block producers generally prefer higher-paying transactions.

3. Include it in a block

A block producer collects transactions and builds a block with a header that contains, among other things:

prev_block_hash is what makes it a chain. Each header commits to the whole history before it, so rewriting an old transaction means recomputing every block after it.

4. Agree on which block counts

Many producers may build blocks at once, so the network needs a rule for choosing among them. Two main families:

Proof of work (Bitcoin). Producers search for a header whose hash falls below a target:

The header includes a free nonce field that miners vary. Finding a valid one takes many guesses on average, and checking it takes one hash. Nodes follow the chain with the most accumulated work. The difficulty adjusts so a block arrives about every 10 minutes.

Proof of stake (Ethereum). Validators lock up funds as a stake. A validator is chosen to propose each block, and others attest to it. Misbehaving can cost part of the stake, which is where the security comes from. Ethereum's finality gadget lets the network mark checkpoints as final.

5. Confirmations and finality

A block with a transaction is one confirmation, and each block built on top adds another. On proof-of-work chains, a competing chain can still overtake yours, so the odds of a reversal shrink with depth. Other chains have explicit finality. How to treat that in software is covered in What "Confirmed" Means Across Chains.

Why tampering is hard

To change a payment in block b you would need to:

1. change the block, which changes its hash
2. recompute every later block, since each contains the previous hash
3. out-produce the rest of the network, either by redoing more work than everyone else or by controlling a large share of the stake

Each of those is cheap on its own and prohibitive together. Honest nodes just keep following the valid chain with the most support.

What the chain does not do

• It doesn't know who anyone is. It only checks that a valid signature came from the key that owns the funds.
• It doesn't protect you from losing your key, or from signing something you shouldn't have.
• It doesn't hide data. Everything in a block is public.

Those gaps are where wallets, custody, and policy come in, since a valid signature is the only thing the network ever asks for.

Summary