How Blockchain Works | Proof of Stake and Validator Duties

A fictional club appoints record keepers under a rule that assigns different duties at different times. One may propose the next notebook page; others check and report their protocol view.

The club story introduces roles, not a complete proof-of-stake system. Real protocols define participation, selection, messages and consequences precisely.

Proof of stake uses stake within its consensus and security design. It is not simply any group vote, and it is not a rule that every wealthy person can write any accepted record.

We will focus on validator duties, using Ethereum as the named technical example.

No reader needs to buy tokens, deposit assets or operate a validator for this lesson.

The useful starting questions are what a validator is required to do, what evidence it produces and which conditions make that evidence acceptable.

Contents · Next chapter

The ordinary word stake can mean having something at risk. In a proof-of-stake protocol, the term belongs to defined participation and consequence rules.

It does not certify that a participant is honest, knowledgeable or good at every decision.

Our fictional club uses a bond card only as an analogy for a rule-linked commitment. The card does not implement Ethereum’s economics or security.

A clear explanation identifies how the actual protocol uses stake: for example, within selection, voting weight and rewards or penalties according to its specification.

Do not replace that description with “people with money are trusted.” The system checks messages and behaviour under rules; it does not read intentions.

This distinction keeps the discussion focused on mechanism. The existence of a financial consequence can create an incentive, but an incentive is different from an unconditional guarantee that every participant will behave as intended.

Contents · Previous chapter · Next chapter

A proposer supplies a candidate block at a protocol-assigned opportunity. An attesting validator produces a defined signed message about its view under the consensus rules.

These are different duties. Not every validator proposes every block, and an attestation is not merely a casual comment that the website looks correct.

The exact selection and message structure belong to the protocol.

In our fictional notebook exercise, one keeper drafts a page while another submits the required checking card. The cards have different purposes.

This helps prevent a common vocabulary blur: validator does not mean one universal action repeated identically by every participant at every instant.

A useful explanation follows the assigned duty. What was this validator expected to do at this time? Which message or proposal is evidence of doing it? The answer must fit the relevant role rather than a generic picture of everybody signing everything.

Contents · Previous chapter · Next chapter

The fictional proposer submits a page containing an unauthorised loan. The club’s validity rules reject it even though the proposer was eligible to make a proposal.

Ethereum nodes validate the relevant block and execution data under protocol rules. Assignment of a proposal opportunity is not permission to invent accepted balances or ignore invalid transactions.

This is the same distinction made in the proof-of-work guide. A consensus role and content validity are different checks.

The rest of the network does not need to accept an invalid candidate merely because it came from an expected participant.

Our paper model writes proposer eligibility and record validity in separate boxes.

That separation makes the security claim clearer. The protocol can recognise who was assigned to propose while independently checking whether the proposed object is valid. Neither result should silently substitute for the other.

Contents · Previous chapter · Next chapter

A signed attestation has a protocol-defined meaning. It is not a promise about every fact in the world or a general endorsement of an application’s usefulness.

For Ethereum, attestations connect to the validator’s relevant consensus view, including chain-head and checkpoint context according to the applicable rules.

Our fictional checking card says which page and decision stage it concerns. A signature without its message context would not explain much.

The beginner should ask what was signed, by which recognised validator and under which duty.

This connects to the digital-signatures guide. Cryptographic verification supports a defined statement; the surrounding protocol determines how that statement contributes to agreement.

An observer who sees a signature-shaped value should not immediately infer finality, application safety or real-world truth. Those conclusions require the relevant context and additional evidence.

Contents · Previous chapter · Next chapter

A fictional keeper has not yet received a competing page. Its current view differs from another keeper’s view.

Communication timing can affect what participants know. The network-delays guide explains why different local views are not automatically proof of malicious behaviour.

A validator must still follow its protocol’s rules for deciding what to sign and when. The actual rules determine which messages are permitted.

This chapter introduces context, not an excuse that makes every inconsistent message harmless.

A careful investigation distinguishes an incomplete view from evidence of a prohibited signing pattern. It also distinguishes a missing message from a contradictory one.

For the paper exercise, show the information each keeper had before evaluating the claims made about its action. The relevant finding should come from the protocol and evidence, not from an assumption that disagreement always reveals dishonesty.

Contents · Previous chapter · Next chapter

Ethereum’s proof-of-stake design combines a fork-choice process with a finality mechanism. Selecting the current head and establishing the relevant finality condition are different tasks.

A validator’s messages contribute according to those defined mechanisms.

The fictional club can illustrate this by distinguishing a provisional selected page from a page that has met the exercise’s final-approval condition.

The analogy does not supply Ethereum’s formal rules. It only makes the two questions visible.

When reading a network status report, ask which stage is being discussed. New candidate blocks can be observed while finality behaves differently.

The earlier guides cover settlement and changing histories in more detail. Here the connection is responsibility: a validator’s duty is meaningful within a particular consensus process, and a message should be interpreted through that process rather than as a universal vote that everything is finished.

Contents · Previous chapter · Next chapter

Our fictional club may give each keeper one equal card for a classroom exercise. Ethereum’s relevant consensus weight is not simply a count of human names or website instances.

The actual protocol determines how stake and effective balances contribute to the relevant calculations.

Do not infer control merely by counting visible validator labels. Several validators can have common operational control, and several services can share dependencies.

This is the same distinction between signing identities and people introduced in the multisignature guide.

The lesson is not that counts are useless. It is that a count must match the property being claimed.

A technical report about voting weight, operator distribution or client diversity needs evidence about that specific quantity. Replacing all three with the word decentralised hides different questions about the structure and operation of the system.

Contents · Previous chapter · Next chapter

A fictional keeper misses a deadline. Another keeper signs a prohibited pair of statements. These are different behaviours in the model.

Ethereum distinguishes ordinary missed-duty consequences from slashable behaviour defined by its protocol. Being offline should not automatically be described as the same event as a slashing offence.

The precise penalties and conditions can change with protocol versions, so this beginner guide does not give operational figures.

Its purpose is to teach the distinction.

A useful incident statement says which duty was missed or which prohibited evidence was found. It does not jump from “a participant was unavailable” to “the participant was proven malicious and slashed.”

Words matter because they identify different mechanisms. Lost opportunity, an ordinary penalty, removal and a particular slashing process should not be treated as interchangeable labels for any disappointing validator outcome.

Contents · Previous chapter · Next chapter

A protocol can specify signing patterns that constitute a slashing offence. Ethereum includes conflicting proposal or attestation behaviours within its applicable definitions.

The relevant evidence is not merely that two observers dislike the same participant.

Our fictional exercise defines one prohibited pattern in plain words: a keeper must not approve two incompatible final decisions for the same designated decision context. This is a toy rule, not Ethereum’s complete slashing definition.

The purpose is to connect a consequence to checkable evidence.

A strong explanation identifies the signed messages, their context and the rule they violate. The proof of that violation is a distinct claim from guesses about motivation.

A participant can cause harm through mistakes as well as intent. Protocol consequences are evaluated under defined conditions, not by a fictional machine that knows whether someone meant well.

Contents · Previous chapter · Next chapter

The fictional keeper says it accidentally approved incompatible cards. That explanation may matter to people reviewing the event, but it does not change which signed messages exist.

A protocol’s validity and consequence rules cannot simply accept every claim of good intentions as a replacement for their specified checks.

Conversely, evidence of a protocol offence does not automatically prove every accusation about a person’s motives or unrelated actions.

Keep technical finding and human interpretation separate.

This is another use of the evidence labels observed, established and inferred. The signed messages may establish a defined violation; the reason for it can remain uncertain.

The beginner lesson is neither harshness nor leniency. It is precision about which question a protocol answers. A clear account states what the evidence supports and leaves broader judgements to the appropriate evidence and process.

Contents · Previous chapter · Next chapter

A validator can perform its protocol duties and receive the applicable rewards while an unrelated application contains a faulty rule.

Consensus participation and application quality are different layers.

The fictional keepers may correctly record every accepted equipment request while the lending program mistakenly permits duplicate returns.

The testing-and-mistakes guide explains that problem. The validators are not automatically human auditors of every application’s intended policy.

This distinction prevents a misleading leap from a functioning consensus mechanism to a claim that every program on the network is safe or useful.

The useful question is what the protocol checks. Valid execution of a flawed application rule can remain valid execution.

Our guide is about security responsibilities, not expected investment returns. Rewards are part of the mechanism’s incentives; they are not a universal certificate of the reliability or suitability of every system using the chain.

Contents · Previous chapter · Next chapter

The fictional club uses several record-keeping devices, but all run the same software and depend on the same power source.

The number of devices does not establish independence from a common software or infrastructure failure.

Real validator systems have operational dependencies. Client implementation, provider and operator concentration are related but distinct properties.

This guide does not claim current market shares or rank particular providers. Those would require current measurements and a defined method.

The conceptual lesson is to draw the dependencies behind the validator labels.

A network can have many recognised signing identities while some failure modes remain correlated. A careful decentralisation explanation names which distribution it has measured.

For beginners, the comparison is enough: ten labels, ten independent operators and ten different software implementations are three different descriptions. Do not treat one as automatic evidence of the others.

Contents · Previous chapter · Next chapter

The fictional club’s record-keeping votes concern the notebook’s protocol decisions. They are not automatically votes on every change to the club’s constitution.

Likewise, a proof-of-stake mechanism should not be casually equated with a universal token-holder election over every network rule.

Governance and software adoption have their own processes, depending on the system.

Ethereum’s validator attestations are not ordinary referendums in which a holder votes to change any protocol policy they prefer.

The governance-and-upgrades guide explores that separate route.

This distinction matters because the same word vote appears in different contexts. A consensus message, an application governance ballot and a community decision can have different participants, authority and consequences.

Name the actual decision before explaining who controls it. Otherwise an accurate statement about one form of weight can become a misleading claim about all forms of authority.

Contents · Previous chapter · Next chapter

The fictional program records a claim that equipment arrived at the workshop. The validator duties are performed correctly and the network settles the record.

That does not establish that a validator personally saw the delivery or that the bond makes the original report accurate.

This is the oracle boundary again. A protocol can secure agreement about accepted digital records while the connection to the outside event remains a separate responsibility.

The distinction is especially important when financial incentives are described as if they could replace every measurement and checking process.

Ask what evidence the application submitted and what the consensus rules actually validated.

Our paper model leaves a separate delivery-observation box outside the committee diagram. The empty box makes the unresolved claim visible rather than allowing the word staked to fill it with assumed truth.

Contents · Previous chapter · Next chapter

Understanding proof of stake does not require participating financially. A reader can learn proposals, attestations and penalties entirely through fictional diagrams and the protocol’s documentation.

This guide does not compare returns, recommend services or provide a setup procedure.

That keeps the learning goal clear: explain the mechanism before anyone considers a consequential action involving it.

The parent-and-child route through the series is especially useful here. Ask the child to describe what a keeper signs and why two different signing patterns might have different consequences.

An adult can then add the protocol context without turning the explanation into an invitation to deposit assets.

Good technical education gives a reader a more accurate model of duties and assumptions. It should not quietly transform vocabulary learning into a product decision the reader never asked to make.

Contents · Previous chapter · Next chapter

Create three fictional role cards: proposer, checking keeper and observer. Give each a clearly written duty in the exercise.

Present one valid page, one unauthorised page, one missed checking deadline and one pair of incompatible approvals under your toy rule.

For each case, ask which evidence exists and which conclusion follows. Keep missing information and prohibited messages separate.

Then add a shared software dependency and ask whether three signing labels establish three independent failure domains.

Mark every card as fictional. None is a real validator message or a simulation of Ethereum’s complete consensus rules.

The exercise is complete when a reader can name the assigned duty, applicable rule and supporting evidence without assuming that every error is slashing or that protocol participation proves every application safe.

Contents · Previous chapter · Next chapter

Proof-of-stake consensus is a system of defined roles, evidence and incentives. Validators do not merely hold a reassuring label; they perform specific protocol duties.

Proposing, validating content, attesting, selecting a head and reaching finality have different places in the explanation.

Missed duties and slashable evidence also need to be distinguished. Exact consequences belong to the applicable specification and version.

Carry four questions into the technical companion: which duty, which message, which rule and which evidence?

Our fictional committee shows why those questions are more useful than a slogan about trusting people with deposits. The mechanism should be explained through what the protocol can check and the assumptions supporting it.

That understanding gives a beginner a route into more technical material without confusing consensus weight with universal governance, incentives with certainty or accepted records with outside truth.

Contents · Previous chapter · Worked situations