Understanding Ethereum proof of stake: consensus mechanism and data structure

TL;DR

Ethereum runs on proof of stake. Validators put up ETH and vote to agree on each new block, a cycle that repeats every 12 seconds.

This guide has two parts. Part 1 walks the proof-of-stake lifecycle, step by step, so you understand how the network agrees on blocks. Part 2 goes one level deeper into how the consensus layer stores all of that as data: the beacon block, the beacon state, and the validator record, all of which hash down to a single 32-byte root.

Proof of stake on Ethereum, in plain terms

A validator is a piece of software backed by staked ETH. Its job is to propose new blocks when it gets picked and to vote on the blocks other validators propose. Honest work earns rewards. Provable cheating destroys the stake. That trade is what keeps the network secure.

Ethereum runs as two layers, and it helps to know which one we are talking about.

• The execution layer handles transactions, smart contracts, and account balances. You read it with JSON-RPC, the request-and-response API that Ethereum apps and wallets already use.
• The consensus layer runs proof of stake: validators, votes, and finality. You read it with the Beacon API.

This whole article is about the consensus layer. Close to a million validators run it today, securing close to 40 million ETH stake.

Ethereum reached this design through several years of network upgrades, the Merge chief among them. That history is its own long story, and this guide skips it to focus on how the system works now.

The proof-of-stake lifecycle, step by step

Everything below happens on a clock. Time is split into 12-second slots, and 32 slots make one epoch, about 6.4 minutes. Each slot has one assigned proposer and produces at most one block — occasionally a slot is left empty if its proposer misses it — and most of the work repeats slot after slot. Here is the full cycle.

Step 1: Staking

To run a validator, you deposit a stake into Ethereum’s deposit contract, the on-chain contract that registers new validators: at least 32 ETH, capped at 2048. That stake is collateral. It buys the right to take part in consensus, and it is the money at risk if you misbehave.

The larger its stake, the more often it gets picked for work. Two numbers describe that stake. The live balance is the validator’s actual balance right now, which moves a little each epoch as rewards and penalties land. The effective balance is that figure rounded down to a whole number of ETH, and it is what the protocol uses for selection and rewards, so a tiny change in the live balance does not change a validator’s duties.

Step 2: Validator selection

Each slot, the network picks one validator to propose the next block. The pick is pseudo-random and weighted by effective balance, so a validator with more stake is chosen more often. The randomness comes from RANDAO: a shared seed that each proposer updates with a value it can’t choose freely, since it’s derived from its signature. That way no single validator controls who gets selected next.

The chosen validator is the proposer for that slot.

Step 3: Block proposal

The proposer builds a block. It gathers pending transactions, adds its own signature and the consensus data the network expects, and broadcasts the block to its peers. Within a few seconds it has spread across the network.

If the proposer is offline or too slow, the slot is left empty and the network moves on to the next one.

Step 4: Attestation

Now the slot’s committees vote on whether the proposer’s block is valid and should become part of the chain. But where do those committees come from? Each epoch the whole active validator set is shuffled with the RANDAO seed from Step 2 and spread across the 32 slots, so every validator attests exactly once per epoch. Each slot is then divided into up to 64 committees — at today’s validator counts, roughly 490 validators each. Every validator in those committees checks the block and issues an attestation, a signed vote that gets included in later blocks. One attestation carries two votes: a vote for the block the validator sees as the head of the chain, and a vote for a checkpoint further back that it considers settled.

The split is exhaustive: the whole active set is shuffled and divided up fresh each epoch, drilling down from the epoch to a single validator’s job.

That exhaustive split is what guarantees each validator attests exactly once per epoch.

Votes are weighted by stake, not by validator count. The threshold that matters throughout consensus is a two-thirds supermajority of all staked ETH. Once that much stake agrees on something, the network treats it as decided.

Step 5: Finalization

At each epoch boundary the network marks a checkpoint. When validators holding two-thirds of the stake vote for a checkpoint, it becomes justified. When the next checkpoint is justified on top of it, the earlier one becomes finalized. Finalizing takes about two epochs, roughly 13 minutes.

The two stages sit one epoch apart, and each needs two-thirds of all staked ETH to vote.

So a checkpoint is finalized one epoch after it is justified: the moment the next checkpoint is justified on top of it, the earlier one is locked in for good.

A finalized block is treated as permanent. Reversing one would require at least a third of all staked ETH to break the rules at once, and the protocol destroys that stake as the penalty. With close to 40 million ETH staked, that is tens of billions of dollars, so finalized history does not get undone.

This combined system, the head-vote rule plus the checkpoint-finality rule, is called Gasper. A block at the head of the chain can still change. A finalized block will not. If you are building anything that moves money, read finalized data, not the latest block. Our companion guide to the Ethereum Beacon API.

Step 6: Rewards and penalties

Validators that propose and attest correctly and on time earn newly issued ETH, plus a share of the priority fees and MEV (extra value a proposer can capture from the order it puts transactions in) in the blocks they propose. Returns run at a few percent a year.

The penalties have three levels:

• A validator that goes offline loses a small amount of its stake over time. This is the inactivity leak, and it lets the chain recover even if a large share of validators drop off at once.
• A validator that provably breaks the rules, such as proposing two blocks for the same slot or making contradictory votes, is slashed: part of its stake is destroyed and it is forced to exit.
• If many validators cheat in the same short window, the penalty scales up and can take their entire stake. That makes a coordinated attack very expensive.

And then the cycle repeats, every 12 seconds.

From the mechanism to the data

That covers the mechanism. The rest of this guide goes one level deeper, into how the consensus layer stores everything you just read.

Consensus data is not organized the way the execution layer is. There are no addresses or transaction hashes here. Data is keyed by validator, slot, epoch, and checkpoint. Three structures hold almost all of it: the beacon block, the beacon state, and the validator record.

The beacon block

A beacon block is what a proposer produces in Step 3. It has a small header and a larger body. The header fields:

• slot: which slot the block is for.
• proposer_index: which validator built it.
• parent_root: the block it builds on.
• state_root: a fingerprint of the network state after this block (more on this below).
• body: everything else.

The body holds the consensus operations: the proposer’s RANDAO contribution, the attestations it collected, any new deposits and exits, evidence of validators that got slashed, and the sync committee’s aggregate signature. (The sync committee is a rotating group of 512 validators that sign every block; their separate signatures are combined into that one aggregate signature.) It also holds the execution_payload, which is the ordinary block of Ethereum transactions. So a beacon block wraps the transactions block together with all the consensus votes around it.

The beacon state

A block records what changed in one slot. The beacon state is the full picture after that change: the complete record of consensus at a given slot, holding every validator, every balance, the current checkpoints, the randomness values, the sync committees, and more.

One design choice is worth calling out, because it explains a lot. Validators are stored in two parallel lists indexed by the same validator number:

• validators: the slow-changing details of each validator (covered next).
• balances: each validator’s current balance, in its own list.

Balances change every epoch. Keeping them in a separate list means the network can update a number without rewriting the rest of a validator’s record. With close to a million validators, the full beacon state is well over 100 MB.

The validator record

Each entry in the validators list describes one validator with a handful of fields:

• pubkey: the validator’s public key, used to verify its signatures.
• withdrawal_credentials: where its ETH goes when withdrawn. Some credential types let a validator compound its rewards, keeping them staked and earning instead of paid out, up to 2048 ETH.
• effective_balance: the rounded stake the protocol uses for selection and rewards.
• slashed: whether this validator has been caught breaking the rules.
• activation_epoch, exit_epoch, withdrawable_epoch: when it became active, when it exits, and when its funds can be withdrawn.

The live balance is not in this record. It sits in the parallel balances list, for the reason just described.

One hash for the whole state: SSZ and the state root

All of this consensus data is encoded with SSZ, short for Simple Serialize. SSZ does two jobs. It turns every structure into bytes in one fixed, predictable way, and it builds a hash tree over those bytes at the same time.

The second job is the useful one. The entire beacon state, all million validators and everything else, hashes down to a single 32-byte value called the state root. That is the state_root committed inside every block header from Step 3. Each block carries a fingerprint of the exact state it produced.

Because the state is a hash tree, you can prove one small fact from it without sending the whole thing. A light client, a small program that follows Ethereum without storing the whole chain, can verify a single validator’s balance with a short proof of about a kilobyte instead of downloading the full 100-plus MB state. That property is what makes light clients practical.

The state is one binary tree: validator fields are the leaves, each parent is the hash of its two children, the top node is the state root. To prove one fact, you send only the nodes along its branch — not the tree.

The whole left half of the tree — most of a million validators — collapses into that single top sibling hash. The branch runs about 40 levels deep (the validator list can hold up to 2^40 entries), so the proof stays near a kilobyte whether the state holds a thousand validators or a million.

Getting consensus-layer data without running a node

Reading any of this, validator records, finality checkpoints, the beacon state, means talking to a consensus-layer node, also called a beacon node. Running one yourself means an execution client and a consensus client side by side, the two programs that run the two layers, a fast multi-terabyte SSD, and an initial sync that can take a day or more before the node is usable. There are several ways to run an Ethereum node, and none of them are instant.

The other option is a provider. When you deploy an Ethereum node on Chainstack, you get both endpoints at once: the execution-layer JSON-RPC URL and the consensus-layer Beacon API URL, already synced. Every consensus endpoint is documented with runnable examples in the Beacon Chain API reference.

Conclusion

You now have the two halves that matter: how Ethereum agrees on blocks, and how it stores that agreement as data. The lifecycle repeats every 12 seconds — stake, propose, attest, finalize. The data is the same story in three structures, all hashing down to one state root.

The natural next step is to read it. With a synced Beacon API endpoint you can fetch validators, checkpoints, and blocks directly — no node to run, no day-long sync. The natural next step is to read it live. Chainstack gives you both endpoints on a single node — JSON-RPC for the execution layer and Beacon API for the consensus layer — so you can query validators, checkpoints, finality status, and beacon blocks without running your own hardware or waiting through a multi-day sync.

FAQ

Additional reading

• Everything you need to know about The Merge
• Top 5 easiest ways to run an Ethereum node in 2026
• Ethereum Beacon API guide: consensus-layer data explained
• Best Ethereum RPC providers for production workloads in 2026