The last lesson assumed the happy path. One block producer proposes a block, the network accepts it, the chain grows by one. In reality, the network is geographically spread across the planet and messages take time to travel. Two qualified block producers can finish their work at almost the same instant, in different parts of the world. Each broadcasts a block. Both blocks contain different transactions but point back at the same parent block. For a few seconds, half the network thinks the chain looks like one thing and the other half thinks it looks like something else. This lesson is about what happens in those moments and why it matters even when everything goes right.

The disagreement comes from physics. Light moves fast but not instantly. A block produced in one city does not appear in every node in the world simultaneously. It propagates outward through the gossip network, hop by hop, and during the seconds it takes to reach everyone, another producer somewhere else might finish their own block. Both blocks are valid. Both follow the rules. Both point at the same parent block as the next link. The chain now has a temporary fork: two competing versions of what block N+1 should be.

For the moment, the chain has two heads. A node that received producer A's block first is treating block N+1 from A as the current tip. A node that received producer B's block first is treating block N+1 from B as the tip. Both are doing the right thing according to the rules they know.

If nothing else happened, the network would stay split forever. Two separate histories, each consistent within its own population of nodes, each unable to tell which is "real." That outcome is unacceptable. The whole point of consensus is that everyone ends up with the same view.

Every blockchain protocol includes a fork choice rule, which is a deterministic procedure for picking one branch over another whenever a fork appears. The rule has to satisfy two requirements. It has to be computable by any node from local information, no central referee. And it has to be the same rule on every node, so that two honest nodes seeing the same fork will independently arrive at the same answer.

The specific rule depends on the chain. Different protocols use different criteria. A common family of rules pick the branch that has the most work or stake behind it, on the theory that more cumulative effort means more credibility. Another family uses voting from validators to mark certain blocks as definitively chosen. The shapes vary, but the underlying logic is the same. Take some property that is hard to fake, measure it across the competing branches, and pick the branch that has more of it.

In the moment a fork appears, no branch has any advantage yet. Both branches are just one block past the shared parent. The deciding factor is what happens next.

Producers keep producing. Each producer in the network builds on the version of the chain they currently see as the tip. Some producers are building on top of A's block, others on top of B's. The next block in either branch extends that branch's lead.

The moment one branch gets a second block before the other, fork choice rules across the network start swinging in its favour. Nodes that were on the losing branch see the new, longer branch coming through gossip, recognise it as more credible under their fork choice rule, and switch over. Their copy of the chain rewrites recent history: they discard the block they had as N+1 and replace it with the winning branch's blocks N+1 and N+2.

The block on the losing branch is now called an orphan. It was valid when it was produced, the network briefly accepted it, but the fork choice rule no longer points at it. The transactions inside it never made it to the canonical chain. Their effects on state are undone everywhere.

This rewriting of recent history is called a reorganization, usually shortened to reorg. Reorgs of one or two blocks happen routinely on most networks. They almost never cause problems in practice, because no application built on top of the chain treats a brand-new block as final. The convention is to wait for some number of additional blocks to build on top of any given block before considering its contents settled.

A direct practical consequence falls out of all this. If your transaction has just been included in the most recent block, that block is the most likely block in the chain to be replaced by a reorg. Each additional block built on top of it makes a reorg exponentially less likely. The alternative branch would have to outproduce the current canonical branch by enough to overtake it, and the gap doubles for each new block.

This is why exchanges, payment processors, and any high-value application waits for some number of additional blocks (called confirmations) before treating a transaction as final. The specific number depends on the chain and the value at stake. Small payments might be safe after one or two confirmations. Multi-million-dollar transfers wait for many more. The exact threshold is a risk-management choice, but the underlying principle is the same. Depth in the chain equals safety from reorganisation.

Some chains have an additional mechanism that explicitly marks blocks as finalised after a certain depth or after enough validators sign off on them. Once a block is finalised under such a mechanism, the protocol guarantees it will never be reorganised. The notion of "wait for finality" replaces "wait for confirmations" in those chains. The practical effect is similar from the application's perspective: do not treat new blocks as permanent immediately.

The forks discussed so far are temporary. The network self-heals within seconds, and nodes that had different views converge on the same view as the fork choice rule plays out. The chain ends up with one canonical history again.

A different kind of fork is not temporary. It happens when the rules of the protocol themselves change, and not every node updates to the new rules at the same time. Two populations of nodes end up running different software. They no longer agree on what counts as a valid block. The fork between them is permanent, because no fork choice rule can bridge a disagreement at the rules level.

Permanent forks come in two flavours.

A soft fork tightens the existing rules. Some blocks that used to be valid are no longer valid under the new rules. Critically, every block that's valid under the new rules is also valid under the old rules. Nodes running old software will still accept the new chain. They might be missing some new features, but they aren't excluded. The fork resolves itself if enough block producers move to the new rules, because the old-software nodes follow along automatically.

A hard fork changes the rules in a way that's not backwards-compatible. Some blocks valid under the new rules are not valid under the old rules. Nodes running old software will reject new blocks. The two populations split into two separate chains, each with their own state, their own history of transactions after the fork point, and their own future. Both can continue to exist independently, but they are now different networks.

Hard forks are how rule changes that the community can't agree on play out in the open. Each side runs their own version of the software, and the market decides which one accumulates value. Several well-known blockchain projects exist today as the surviving side of a hard fork that split the original community.

You now have the full operational picture of a blockchain, including the cases where the happy path doesn't quite hold. The last lesson in this module steps back from network behaviour and looks at a constraint that runs through every layer you've seen so far. Every node has to compute the same result from the same input, or the whole system falls apart. That constraint has consequences for what kinds of programs can run on a blockchain and what kinds cannot. The next lesson is about determinism.