Consensus is the answer to a simple question: if thousands of computers all hold a copy of the same ledger, and nobody is in charge, how do they agree on what happened? The answer is a set of rules for proposing new entries, checking them, and voting on them, plus a penalty for cheating. When enough independent participants follow the same rules and vote the same way, the network converges on one history. Everything else in blockchain infrastructure, nodes, RPC endpoints, indexers, explorers, exists to serve or read that agreed history.
The problem consensus solves is older than crypto. Any shared record needs a way to stop the same asset being spent twice, and a way to decide the order of events when two valid-looking versions arrive at once. A central database solves this with an administrator. A blockchain solves it by making agreement expensive to fake and cheap to verify: participants put something at risk, follow public rules, and the rest of the network can check their work without trusting them.
Proof of work and proof of stake, in one paragraph each
In proof of work, participants called miners compete to solve a computational puzzle, and the first to solve it proposes the next block. The puzzle costs real energy, so rewriting history means redoing all that work, which is what makes the chain expensive to attack. In proof of stake, participants called validators lock up assets as stake instead of burning energy. Validators are selected to propose blocks and to vote on blocks others propose, and misbehaviour can cost them part of their stake through slashing. Both designs buy the same thing, agreement that is costly to fake, with different resources.
Proof of stake is the design most new chains use, and it is worth understanding in concrete terms, because it is also the design most node operators run. Ethereum switched its consensus mechanism to proof of stake in 2022, and its documentation is the clearest public reference for how the moving parts fit together. The rest of this post uses Ethereum as the worked example, but the pattern, propose, check, vote, finalise, shows up across proof-of-stake chains with different names for the same jobs.
The Ethereum example: slots, proposers, and attestations
Time on proof-of-stake Ethereum is divided into slots of 12 seconds, grouped into epochs of 32 slots. In every slot, one validator is randomly selected to propose a block. That proposer bundles transactions, wraps them in a block, and broadcasts it. In the same slot, a committee of other validators is randomly chosen to check the block: they re-execute its transactions, verify its signature, and then publish a vote called an attestation in favour of the block if it is valid and builds on the chain they consider correct. Every active validator attests in every epoch, though not in every slot, because committees divide the work.
Attestations are the raw material of agreement. Each one records the validator's view of the chain head and of two checkpoints, the source and the target, which mark progress toward finality. Nodes collect attestations, weigh them by the stake behind them, and follow the chain with the greatest weight of attestations under the fork-choice rule. When two blocks compete for the same slot, this weight is what breaks the tie: the network does not vote once and stop, it keeps voting, and the heavier chain wins.
Finality: when a block stops being reversible
A block that has just been proposed is not yet final. It could still lose a fork-choice contest if a heavier competing chain appears. Finality is the point where reversing a block would require destroying an enormous amount of staked value, so the network treats it as permanent. On Ethereum, checkpoints at the start of each epoch are voted on in pairs, and when a pair attracts votes representing at least two-thirds of total staked ETH, the newer checkpoint becomes justified, and an already-justified checkpoint behind it becomes finalised. In plain terms: finality needs a supermajority, not a simple majority, and that supermajority is measured in stake, not in node count.
This is why applications treat confirmations differently depending on what is at stake. A wallet showing a recent transaction is showing an unfinalised but likely-correct entry. An exchange crediting a large deposit usually waits longer, because the cost of being wrong grows with the amount. Operators should learn the finality rule of every chain they run, because it decides how long to wait before acting on chain data, how to handle reorgs in an indexer or explorer, and what to tell users who ask why a transaction is confirmed in one place and pending in another.
What consensus means for node operators
First, consensus only works if your node agrees with the network, which means staying synced and running a supported client version. A node that falls behind does not just miss data, it votes on a stale view of the chain, and a validator that attests late or incorrectly loses rewards and risks penalties. Sync health, peer count, and client version are therefore consensus health metrics, not cosmetic dashboard numbers. The monitoring setup in our Grafana monitoring guide covers the four numbers that matter most.
Second, client diversity matters. If most validators run the same client software and that client has a bug, the network can stall or split even though nobody acted maliciously. Operators who run a minority client, or who can switch clients during an incident, reduce that shared risk. Third, upgrades need the same care as any consensus change: test on testnet first, snapshot before upgrading, and know the rollback plan, as covered in our validator upgrade guide. A bad upgrade at the wrong time is a self-inflicted consensus failure.
Common misunderstandings, corrected
Consensus does not mean every node agrees instantly. It means the network converges on agreement over time, through repeated votes. Consensus does not mean validators check each other's honesty by reputation. They check it by re-executing blocks and verifying signatures, which is why a validator cannot make an invalid transfer valid just by including it in a block. And consensus does not mean a chain is safe because it has many nodes. Safety comes from stake that is widely distributed and from validators that are actually online and voting, which is why uptime, key safety, and failover design are consensus work, not side quests.
If you are planning a launch, the consensus layer is also where your infrastructure budget starts. You need nodes that stay synced through traffic spikes, RPC endpoints that serve the agreed chain rather than a lagging copy, and monitoring that pages a human when your view of the chain drifts from the network's. That is the work DevOpsBy does for teams: node setup, managed node operations, and a free infra audit to find the gaps before launch week finds them for you.
Disclaimer: This post is educational only, not financial advice. Figures are listing or project data as of 2026-11-05 and may change - always confirm version numbers, requirements, and dates in the official docs before acting on them.