How Blockchain Works | Consensus and Agreement

North Club says a telescope booking changed before the handover. Central says the handover came first. Their local records show different sequences.

For a shared digital service, that difference matters. The same instructions in a different order can produce a different current state.

Consensus mechanisms address agreement within a specified system. Participants need rules for recognising the history they should accept, even when messages arrive at different times.

The telescope clubs are fictional. Their dilemma illustrates a coordination problem rather than proving they need a blockchain.

A conventional service might solve the booking question through one trusted operator. A shared-ledger design introduces particular mechanisms for handling it across participants.

Begin with the need: which sequence will the relevant participants use when applying the rules?

Without a common answer, the clubs can make incompatible decisions about the same equipment.

The solution must be more precise than asking everyone to “agree somehow”.

Contents · Next chapter

The word “agreement” can cover almost anything: a preference, a business decision or a claim about the weather.

Blockchain consensus concerns particular protocol claims, such as an accepted block or history, under specified rules.

That scope matters. Participants can agree that a signed handover acknowledgement belongs in the record without independently inspecting the telescope.

They can also agree on a valid sequence containing a mistaken external statement.

The digital checks establish what the design checks. They do not secretly expand into a universal fact-finding service.

For our learner, write two questions on separate cards. “Which history does the network accept?” goes on one. “Where is the telescope physically?” goes on the other.

Different evidence answers the cards.

A useful system may connect both through an application procedure, but the connection should be explained.

Whenever someone says “consensus proves it”, ask what exact proposition was agreed and which conditions the mechanism actually tested.

The narrower answer is usually much more informative.

Contents · Previous chapter · Next chapter

A proposed instruction can violate a rule. A valid proposal can also be one of several candidates the protocol must distinguish.

Those are separate problems.

Our clubs forbid a reader from acknowledging receipt on behalf of Central. A request from that reader is invalid under the permission rule.

Now imagine two properly authorised booking requests. They may each be valid in some starting context, while their order affects the eventual outcome.

A mechanism must therefore address both rule compliance and the accepted sequence or history.

We should not replace those questions with a popularity contest. A large number of messages cannot make a forbidden action valid merely by favouring it.

In the classroom, first give everyone the written rulebook. Ask them to identify invalid cards before choosing between permitted sequences.

This reveals why checking and selecting are related but different jobs.

Real protocols define these boundaries with greater precision.

The beginner’s habit is to ask which rules reject a candidate and which rules choose among candidates that survive.

Contents · Previous chapter · Next chapter

A thousand people use the booking app. Does that mean each gets one equal vote on the next ledger entry?

Not necessarily. The application’s users, network operators and protocol participants may have different roles.

Some networks restrict relevant duties to identified organisations. Permissionless systems define influence through their own mechanisms. Usernames alone do not explain them.

This distinction is important because one person may create many apparent identities. A design needs a specified way to address that possibility if identity counts would otherwise control the outcome.

For our clubs, the agreement names organisational participants and their roles. Readers do not acquire network authority merely by opening the website.

For a classroom, let one player invent ten names. Ask whether the written rules give those names ten votes. Decide the rule before counting.

The exercise is not a real Sybil-attack defence. It makes the hidden assumption visible.

A good explanation names the unit of influence and the condition for obtaining it.

“Everyone votes” is too vague to support a serious understanding of consensus.

Contents · Previous chapter · Next chapter

North receives a proposed booking change first. Central receives the handover acknowledgement first.

Neither computer has to be dishonest for this to happen. Messages travel through a network and can experience different delays.

A protocol needs a way to handle those views without treating every first impression as a permanent conclusion.

Our paper model can distribute cards in different orders, then apply the agreed ordering rule before updating the official toy state.

The important lesson is that local arrival order and accepted ledger order need not be identical.

That difference also explains why a user’s first screen can be provisional. The application may know that a request was received before knowing its settled position in the accepted history.

Ask what the displayed status means at that stage.

A service should distinguish waiting from failure and provisional inclusion from the result users may safely rely on.

The network’s actual guarantees depend on its design.

The fictional cards illustrate the questions; they do not prescribe a universal consensus sequence.

Contents · Previous chapter · Next chapter

A useful protocol explanation asks what prevents relevant participants from treating incompatible outcomes as settled under its assumptions.

This is one way to introduce the idea of safety.

For the clubs, the unacceptable outcome is two incompatible official assignments of the same telescope for the same booking context.

The design needs precise definitions. What counts as an incompatible result? Which participants are supposed to agree? Under what failures does the guarantee apply?

A word like “secure” cannot substitute for those details.

The classroom can declare a toy rule: the official record may not mark TEL-01 as assigned to both Central and South for the same active booking.

Then introduce competing proposals and check whether the processing arrangement preserves that rule.

The exercise does not prove a real distributed protocol safe. It helps learners state the property being sought.

An accurate explanation includes assumptions about participants, communication and failures.

The guarantee should be assessed together with those assumptions, rather than presented as an unconditional promise that nothing can ever go wrong.

Contents · Previous chapter · Next chapter

A system might avoid incompatible settled outcomes by refusing to process anything. That would not serve the clubs for long.

Liveness concerns the ability to make progress under specified conditions.

Again, the conditions matter. A network cannot promise arbitrary progress through every possible communication failure while preserving every desired property.

Our equipment service needs an operational explanation of when requests can settle and when they may wait.

Imagine a toy rule requiring support from designated participants. If too many are unavailable, the system might pause.

That pause can be consistent with the safety goal. It still creates practical problems for people holding the telescope.

The clubs need a procedure for the physical task during the pause and for later reconciliation.

For learners, separate “no incompatible result accepted” from “new requests successfully completed”. These are different achievements.

Ask what failure conditions each claim covers.

A responsible explanation discusses both the protocol’s behaviour and the service’s recovery arrangements.

Progress is useful when the result remains within the rules people agreed to rely on.

Contents · Previous chapter · Next chapter

A network partition prevents some participants from communicating with others for a period.

North and Central may exchange messages while South cannot reach them. The precise effect depends on the protocol and the importance of South’s role.

The participants may have different information. Some actions may wait. Some designs can continue under particular conditions.

We should not tell a beginner that every partition produces the same outcome on every blockchain.

Instead, ask what support the protocol requires, what each participant can observe and when it may treat a result as settled.

In the classroom, place one learner behind a communication barrier. Continue distributing cards to the others under your written toy rules. Then reconnect the learner.

The reconnection raises another question: how do they learn and check the accepted history?

Consensus and synchronisation are related, but the catch-up procedure also matters.

The activity makes honest disagreement visible.

It helps readers understand why a temporary difference between screens does not, by itself, establish either fraud or a permanent protocol failure.

Contents · Previous chapter · Next chapter

Proof-of-work systems use a specified computational mechanism as part of their block-production and history-selection arrangements.

For a beginner, the important distinction is that ordinary usernames are not simply counted as equal ballots.

The actual design specifies valid blocks, the relevant work and the way participants choose an accepted branch. Invalid data does not become valid merely because a branch contains computational effort.

Our article does not ask learners to mine, buy equipment or calculate a production network’s security. Its role is to prevent a vague classroom-vote explanation from becoming a false universal model.

A useful analogy is a competition with an entry condition and separate validity rules. Winning a race would not authorise breaking the game’s rules.

That analogy is limited; real proof-of-work protocols have precise mathematics and network assumptions.

When reading a claim, ask which network, which selection rule and which failure model it describes.

Do not infer properties of all blockchains from one familiar cryptocurrency.

The mechanism is part of a complete protocol, not a stand-alone certificate that every external claim is true.

Contents · Previous chapter · Next chapter

Proof-of-stake systems use stake and specified participant duties within their consensus designs.

The detailed voting, proposal, penalty and finality mechanisms vary. “People who own coins vote” is too loose to explain all of them.

For our beginner, the useful point is that the protocol defines what counts as relevant support. That unit is not automatically one ordinary account or one person.

We should also distinguish the technical mechanism from an investment argument. Learning how participation is structured does not establish that an asset is a sensible purchase.

Our equipment clubs use fictional identified organisations, so their classroom model should not be advertised as a proof-of-stake simulation.

The technical comparison belongs in the structured Master Blockchain lessons.

Here, ask what a participant is authorised to do, which evidence records that action and how the design responds to specified faults.

A label such as “stake-based” starts the explanation.

It does not finish the questions about validity, accepted history, finality or the service’s dependence on actual operators.

Contents · Previous chapter · Next chapter

A permissioned network specifies participation through an admission and authority arrangement.

For our fictional clubs, North, Central and South appoint relevant operators. That makes certain organisational responsibilities visible.

It does not eliminate trust or coordination work. Who admits a new club? Who removes a compromised operator? Who changes the protocol configuration?

These decisions can affect the system’s behaviour.

An identified participant can still make mistakes, become unavailable or act improperly. The protocol and governance arrangement should explain how those cases are handled.

A classroom model can name its participants and write their duties on cards. That makes the authority boundary easier to inspect than an unexplained statement that the network is private.

Compare permission to read a booking with permission to participate in network decisions.

They are not necessarily the same.

The value of a permissioned design should be judged against the clubs’ actual requirements and simpler alternatives.

Knowing the participants is one ingredient in that judgment, rather than proof that every shared record is correct.

Contents · Previous chapter · Next chapter

A request can appear in a candidate history before a reader has the relevant evidence to treat it as settled.

Different networks handle this question differently. Some provide particular finality evidence under their protocol assumptions. Others support confidence through the development of the accepted history.

There is no universal number of blocks that means the same thing everywhere.

Our clubs should specify what their application waits for before displaying “handover acknowledgement completed”.

That operational policy must fit the actual network and the consequence of the action.

A low-stakes demonstration and a valuable equipment release need not use the same decision procedure.

Finality concerns the settled status of a recorded result under the system’s rules. It does not mean the outside world stops changing or that a later authorised correction is impossible.

For the learner, replace “permanent forever” with a better question: what evidence allows the relevant reader to rely on this result for this next action?

The answer should name the network’s guarantee and its assumptions.

Contents · Previous chapter · Next chapter

All three clubs accept a signed record stating that the telescope passed inspection. The lens was never checked.

The accepted history can preserve the claim consistently while the inspection claim remains poorly supported.

Consensus does not become an all-purpose sensor, investigator or fact-checker.

The application needs an evidence procedure for what happens outside the network. It may use authorised reports, inspection methods and dispute resolution.

Those procedures can fail too. Multiple reports may repeat one source’s mistake, and several people may misunderstand the same form.

Our learner should therefore avoid the shortcut “many computers agreed, so it must be true”.

Ask instead what they agreed on and what evidence was available to them.

This is a useful habit in ordinary research as well. Repetition and independent corroboration are not the same.

A robust shared record can help people inspect the history of a claim.

Its usefulness increases when the boundary between protocol agreement and external truth stays visible.

Contents · Previous chapter · Next chapter

The clubs decide to require a new kind of equipment acknowledgement. How does that change become part of the system?

A protocol’s present operation and the process for changing its rules are different questions.

Participants may need to adopt new software, update configuration or agree through a specified governance arrangement.

If some continue with the old rules, compatibility questions arise.

Our classroom can demonstrate this with two printed rulebooks. One requires a single acknowledgement; another requires two. Process the same cards and compare results.

The disagreement is not resolved merely by calling both players honest. Their rules differ.

A real upgrade needs a precise account of the change, the authority to make it and the conditions for adoption.

Readers should ask who can change which rules and how affected participants learn about the change.

A network’s governance can introduce dependencies not apparent in its everyday consensus diagram.

Understanding agreement therefore includes both running the current rules and examining how those rules can be altered.

Contents · Previous chapter · Next chapter

Give three learners the same starting equipment state and a clearly written toy rulebook.

Prepare two conflicting booking requests. Deliver them in different orders to the learners. Let each describe its local view before establishing the official sequence under the toy agreement.

Next, submit an unauthorised request. Everyone should reject it, even if several players prefer the outcome.

Then disconnect one learner. Decide whether the written arrangement permits progress or requires waiting. Reconnect them and practise checking the accepted record.

Finally, replace one rulebook with a revised version. Identify the disagreement about rules before discussing the records.

The cards do not implement a secure consensus protocol. They teach scope, delays, conflicts and assumptions.

Ask the learners what was agreed, who was eligible to support it and which physical facts remained unobserved.

A good explanation accounts for every difference without treating “consensus” as a magical vote.

That understanding is enough to make a real protocol description much easier to read later.

Contents · Previous chapter · Next chapter

When a service advertises blockchain consensus, ask which claims are agreed, which participants matter and how validity differs from history selection.

Then ask what happens during delays, participant failures and rule changes, and what evidence establishes finality.

The child-friendly explanation is that the network follows rules for deciding which record history to use. The rules matter, and agreeing on a record does not prove every story inside it.

For an adult, add safety, progress, participation and authority boundaries.

The Ethereum consensus-mechanism documentation describes one ecosystem’s concepts and actual mechanism. Other networks need their own specifications.

Smart Contracts and Rules continues the series by asking what instructions do once the system processes them.

Return to Nodes and Shared Copies for the computers carrying out the work.

The strongest conclusion stays scoped: these participants accept this history under these rules and assumptions.

That sentence tells us far more than saying a blockchain works because everyone agrees.

Contents · Previous chapter · Continue to worked situations