How Blockchain Works | Forks and Changing Histories

A fictional club has a shared notebook ending at page 20. Two authorised writers hear different requests and each prepares a possible next page. Both pages refer back to page 20.

The drawing now has one common beginning and two possible continuations. This is the simplest way to picture a fork in a blockchain’s block history.

It does not mean every participant is dishonest. Different information can arrive at different times. Depending on the network’s rules, competing proposals may occur before participants converge on an accepted continuation.

Our notebook story is a conceptual model, not an exact description of every consensus protocol. It introduces a question: when several candidates exist, which one does a participant treat as the current accepted history?

That question is distinct from checking whether each candidate is internally valid. A valid candidate is not automatically the one that the network ultimately follows.

Contents · Next chapter

Call the two fictional candidates 21A and 21B. Each has page 20 as its predecessor. Their contents may differ, even though their position follows the same common history.

If more pages are proposed, one branch might become 21A, 22A, 23A, while another starts 21B, 22B. The numbers alone do not identify a unique page.

A blockchain block’s identity and its position are therefore different pieces of information. Two competing blocks can occupy a comparable height while having different hashes.

For a beginner exercise, draw the common pages once and then split the line. This makes the relationship clear without duplicating the whole notebook.

The fork is about continuations from a common point. It does not imply that every earlier record has been rewritten. Describe the point of divergence before making claims about the scope of the disagreement.

Contents · Previous chapter · Next chapter

One club member receives 21A first; another receives 21B first. For a short period they report different latest pages. Neither can assume its first message was the only possible message.

Distributed systems have communication delays. A participant’s local view is shaped by the information it has received and the rules it applies.

The relevant network design specifies how participants handle candidates, timing and agreement. A fictional notebook cannot supply those exact details.

This explains why “my screen shows this” is an observation, not necessarily a final statement about the entire network. The view may be provisional or delayed.

When two displays differ, first compare their context and observation time. The block-explorer guide introduced this habit for website data. Here we add another possibility: the underlying current views themselves may briefly differ while the protocol’s selection process is still operating.

Contents · Previous chapter · Next chapter

The club checks whether 21A and 21B follow its page rules. Perhaps each contains properly authorised requests and valid references. Both candidates can pass those checks in the fictional model.

The club still needs a way to choose its accepted continuation. A validity rule and a selection rule answer different questions.

A blockchain’s consensus design supplies the relevant process. It may combine rules about valid blocks, proposal timing, voting, accumulated work or other evidence.

Do not replace that process with the vague statement that the longest line always wins. Different networks use different criteria, and even proof-of-work systems compare accumulated work rather than a simple count of pictures on a page.

A beginner explanation should state the mechanism’s scope. First ask whether a candidate is valid under the rules. Then ask how the protocol chooses among the valid candidates visible to a participant.

Contents · Previous chapter · Next chapter

Our fictional club agrees on a selection procedure before accepting requests. Members do not choose a branch because its colour looks more attractive or its writer is more popular.

Fork choice names the rule a participant uses to select the current branch from its relevant view. The exact rule depends on the protocol.

For Ethereum’s proof-of-stake design, fork choice uses the weight of validator attestations according to its defined algorithm. This is not a universal rule for all blockchains.

The beginner lesson is the separation between a human impression and protocol evidence. A participant follows a defined procedure, with assumptions and inputs that can be described.

When reading a chain-selection claim, ask what evidence is counted and what constraints apply. Saying “the network agreed” can be a useful summary only after the explanation has identified what agreement means in that particular system.

Contents · Previous chapter · Next chapter

A club member initially treats 21A as current. Later it receives additional valid information and its agreed procedure selects the branch beginning with 21B instead.

The member’s local accepted history changes after the common page 20. This is a conceptual picture of a chain reorganisation, often shortened to reorg.

The old candidate does not need to disappear from every record or device. It is no longer part of that participant’s selected branch. Stored evidence about it may remain.

This chapter does not describe an administrator editing a single paragraph in place. The participant is switching which continuation it follows under the relevant rules.

That distinction explains why a transaction’s inclusion status can change near a chain’s unsettled head. A record seen inside a once-selected block may no longer be included in the currently selected history at that position.

Contents · Previous chapter · Next chapter

Request T is included in 21A. A member’s first observation says, “T appears in the current branch after page 20.” Later the selected branch changes to 21B, which does not contain T.

The first observation had a time and a context. It was not necessarily false when made. It became insufficient as a description of the later selected history.

T might be considered again and included in a later accepted block, if the system’s rules and surrounding conditions allow it. That is not guaranteed. The request could no longer be valid or might not be selected again.

Do not automatically resubmit an action merely because a display changes. This guide is about reading the concept, not giving operational transaction advice.

For our paper timeline, keep separate rows for the initial observation, the branch switch and any later inclusion. This avoids treating several distinct events as one continuous status.

Contents · Previous chapter · Next chapter

The fictional equipment application computes its cupboard count from the accepted requests. If the selected branch changes, the state derived from that branch can change too.

Suppose 21A contains a ball request and 21B does not. The application should not keep counting that request as accepted solely because a website displayed it earlier.

Actual systems manage these transitions according to their architecture. Indexers and applications need to interpret the relevant chain context. The details are not identical everywhere.

The teaching lesson is that a displayed outcome may depend on the history used to compute it. A branch change is not only a change in a block list; it can affect what the application reports.

When investigating a mismatch, ask which state each display represents. A cached count based on an older branch and an updated count based on the new branch may disagree for an understandable reason.

Contents · Previous chapter · Next chapter

In our drawing, the member replaces 21A and 22A with 21B and 22B after the common page 20. The affected suffix contains two old selected pages.

This introduces reorganisation depth as a way to describe how much recent selected history changed. Precise terminology can vary by tool, so check the definition used in a real report.

The drawing should show the common ancestor and both continuations. Without them, a statement such as “two blocks changed” leaves room for misunderstanding.

Do not infer the cause merely from depth. A report needs evidence about what occurred, not just a count of affected blocks.

Our paper model is useful because it keeps scope visible. Earlier pages before the divergence are shared. The altered suffix is the part under discussion. A careful explanation names that boundary instead of announcing that all blockchain history has been rewritten.

Contents · Previous chapter · Next chapter

A record may gain later blocks on its selected branch. Some systems describe this using a confirmation count. The meaning and usefulness of that count depend on the network and task.

A fixed number should not be borrowed casually from one blockchain and presented as a guarantee for every other one. Different consensus mechanisms and finality designs provide different evidence.

In the fictional club, several later pages make a branch look established under one imagined procedure. They do not automatically create a mathematical guarantee outside that procedure.

The confirmations and finality guide explains this distinction in more detail. Here the important connection is to changing views: early inclusion can be provisional.

A careful reader asks which settlement condition applies and whether it has been met. The answer should name the protocol context rather than relying on a reassuring count without explanation.

Contents · Previous chapter · Next chapter

A protocol may provide a defined finality condition. Once that condition is reached, reverting the relevant history requires a failure of particular assumptions or consequences specified by the design.

Do not translate this into an absolute claim that no extraordinary failure or coordinated intervention is conceivable. Do not treat finality as meaningless either.

The useful explanation names the guarantee and its boundary. What evidence establishes finality? Which assumptions support it? What kind of failure would be needed to contradict it?

Our fictional notebook has no real finality algorithm. It can only illustrate the difference between a provisional latest page and a page whose settlement condition has been met under a defined process.

When reading a changing-history report, ask whether the affected blocks were provisional or finalised in the applicable system. That distinction can materially change the interpretation of the event and the seriousness of the claimed failure.

Contents · Previous chapter · Next chapter

So far, 21A and 21B have followed the same fictional page rules. Their competition concerns which history is selected, not which rules exist.

The word fork is also used for changes to blockchain rules. That is another meaning, and it needs separate explanation.

Imagine the club adopts a new policy allowing two outstanding loans instead of one. Members running old and new rulebooks may disagree about which future requests are valid.

This is not the same situation as two otherwise valid candidate pages reaching members at different times. One concerns competing histories under a rule set; the other concerns compatibility between rule sets.

Always identify which meaning of fork is being used. A headline can use the same word for a routine temporary divergence, a planned software change or a lasting network split. Those events have different causes and consequences.

Contents · Previous chapter · Next chapter

In simplified terms, a soft-fork change tightens what upgraded participants accept, so the new valid set is contained within what older rules allowed. A hard-fork change is not backward-compatible in that way.

These labels describe rule compatibility. They do not by themselves tell us whether a lasting split occurred, whether adoption was smooth or whether an application is safe.

Our club analogy can introduce the set relationship. A new rule permitting fewer loan types may be accepted by old checkers that allow a broader set. A change permitting previously forbidden requests creates a different compatibility problem.

The analogy is incomplete because real protocols include activation and consensus details. Use it to understand why old and new software might classify the same candidate differently.

The governance and upgrades guide examines who proposes and adopts changes. Here the focus is narrower: the relationship between the old validity rules and the new ones.

Contents · Previous chapter · Next chapter

The club updates its rulebook, and all relevant participants adopt the agreed change. There is a rule transition, but no continuing second club using the old policy.

A hard fork does not automatically produce two enduring chains. A lasting split requires groups that continue to support incompatible histories and rules, along with the practical operation of those networks.

Conversely, a community disagreement can matter even when the technical change looks small. People, software and operational coordination all affect adoption.

Avoid explaining network identity purely by drawing a branching line. The line can show divergence, but it cannot supply evidence about who continued which system afterward.

A careful history names the change, the adoption process and the continuing networks, if any. It does not assume that every planned upgrade creates another asset or that every use of fork describes the same kind of division.

Contents · Previous chapter · Next chapter

Two fictional clubs separate after a shared notebook history. Each continues with its own later entries. A slip from the shared past can appear in both histories.

That common beginning does not make every later action interchangeable. A request recorded in one continuing network may not exist in the other.

Network context therefore matters after a lasting split, just as it matters between unrelated chains. Identifiers and familiar labels need to be interpreted within the intended system.

Our lesson does not require sending any transaction. On paper, write the two network names beside their later pages and track one imaginary request.

The result illustrates a broader checking principle: identical historical references can coexist with different current states. A claim about what exists now must identify which continuing system is meant. The shared origin is relevant history, not a substitute for current context.

Contents · Previous chapter · Next chapter

A fictional explorer screenshot shows T in 21A at noon. At a later time, another view shows the branch beginning with 21B. Comparing the screenshots requires their network, block identifiers and observation times.

A screenshot alone cannot establish finality or tell us which view was current at every later moment. It records what a display presented at the captured time.

This does not make screenshots worthless. It means their role must be described accurately.

For a changing-history question, build a timeline: first observation, new information, branch selection change and later status. Distinguish the explorer’s display from independently verified protocol evidence.

The same habit helps avoid dramatic but unsupported conclusions. A disappeared entry could reflect a reorganisation, indexing delay, wrong network or another issue. The event needs investigation; the image supplies one piece of evidence rather than a complete explanation.

Contents · Previous chapter · Next chapter

On paper, draw pages 18, 19 and 20. Add branch A with 21A and 22A. Add branch B with 21B and 22B. Put fictional request T only inside 21A.

Label the first observation “A selected” and the second “B selected.” Write how T’s inclusion status differs between them. Then add T to 23B as a separate hypothetical event, explicitly noting that this later inclusion is not guaranteed.

Now keep the same drawing but change one branch’s rulebook. Explain why that introduces a different question from choosing between candidates under common rules.

No real chain, wallet or account is involved. The exercise’s value comes from distinguishing divergence, selection, state and rule compatibility.

If your explanation can name the common ancestor, affected suffix and observation context, you have the basic tools for reading a reorganisation claim without assuming either total permanence or total instability.

Contents · Previous chapter · Next chapter

A blockchain history is interpreted through a particular network’s validity, selection and settlement rules. Recent competing branches, a reorganisation and an incompatible rule change are related ideas, but they are not identical events.

Carry two questions into every fork claim: which history is selected, and which rules define valid behaviour? Add a third: what settlement evidence applies to the records under discussion?

The fictional notebook helps explain why the answers can change at different stages. A candidate can be valid without becoming selected. A selected record can be provisional. A planned upgrade can change rules without leaving two enduring networks.

These distinctions support a more careful explanation of immutability. The relevant guarantee is not that no screen can ever change. It is a defined property of the system under stated conditions. Understanding those conditions makes the promise clearer, more useful and less misleading.

Contents · Previous chapter · Worked situations