Loading article...
The consensus layer is the proof-of-stake system that secures Ethereum after The Merge. Learn what it does, how Gasper and the Engine API work, who needs it, trade-offs, and how to run or build on it.
The consensus layer is the part of Ethereum that decides which block is correct and which chain is canonical. Since The Merge on September 15, 2022, Ethereum runs with two linked pieces: an execution layer that runs transactions and an EVM state, and a consensus layer that runs proof-of-stake, selects block proposers, collects validator votes, and finalizes history. Together they form a single Ethereum network. This split replaced proof-of-work mining.
If you run a node, build a dapp, or evaluate validator or protocol work, you interact with the consensus layer even when you only use an execution client.
The consensus layer is the network of consensus clients (sometimes called beacon nodes) that implement proof-of-stake consensus for Ethereum. Before The Merge it ran separately as the Beacon Chain, launched December 1, 2020. After The Merge the Beacon Chain became the consensus engine for Mainnet. The older proof-of-work clients stopped handling block gossip and consensus logic. Today every full node runs two pieces of software that talk over the Engine API with a JWT secret: an execution client (Geth, Nethermind, Besu, Erigon, Reth) and a consensus client (Lighthouse, Prysm, Teku, Nimbus, Lodestar).
The consensus layer does not execute smart contracts or track ETH balances by itself. Its jobs are:
The execution layer still gossips transactions, builds execution payloads, and runs the EVM. A beacon block wraps an execution payload together with consensus data such as the RANDAO reveal, attestations, slashings, deposits, voluntary exits, and sync committee data.
The term consensus layer comes from the 2022 renaming where Eth1 became execution layer and Eth2 became consensus layer. The Ethereum Foundation documented this in The Great Renaming and the Mainnet Merge Announcement. Any reference to Eth2 now means consensus layer.
A consensus mechanism is the full stack of rules and incentives that lets nodes agree on state. Proof-of-stake is only one part of it - the Sybil resistance and block-author selection. Gasper, which combines Casper FFG and LMD-GHOST, is the actual consensus mechanism used on the consensus layer.
latest, safe, and finalized tags. Handling reorgs correctly depends on understanding when a block is justified versus finalized.If you only use a custodial exchange or a hosted RPC and never run infrastructure, you do not need to operate a consensus client. You still benefit from knowing how finality works when you set confirmation policies.
Time is divided into slots of 12 seconds and epochs of 32 slots (6.4 minutes). One validator is pseudo-randomly selected to propose a block in each slot. There is no true randomness across nodes. Ethereum uses RANDAO, where each proposer mixes a hash with a seed that updates each block. The selection is fixed two epochs in advance and is weighted by effective balance. The maximum effective balance is 32 ETH for legacy validators and up to 2048 ETH for compounding validators after the Pectra upgrade in May 2025. Balance above the cap does not increase selection weight.
Only one block per slot should exist. Proposing two different blocks for the same slot is a slashable equivocation.
When it is your slot, your consensus client asks your execution client for an execution payload. That payload contains transactions from the mempool, a state root, and other execution data. The execution client executes the transactions locally to produce the post-state. The consensus client wraps the payload in a beacon block along with randao_reveal, eth1_data, graffiti, proposer slashings, attester slashings, deposits, voluntary exits, and the sync_aggregate. The block is signed and gossiped on the consensus layer network. Peers verify the parent, slot, proposer index, RANDAO reveal, signatures, and then ask their own execution client to re-execute the transactions before accepting.
Every active validator attests once per epoch, not every slot. Each epoch the validator set is shuffled with the RANDAO seed and spread across the 32 slots. Each slot can be split into up to 64 committees. At current validator counts each committee holds several hundred validators.
An attestation carries two votes:
Weight is by staked ETH, not validator count. The threshold that matters is a two-thirds supermajority of total staked ETH.
If two blocks appear at the same height due to latency or equivocation, nodes need a rule to pick one. Ethereum uses LMD-GHOST, short for Latest Message Driven Greedy Heaviest Observed Sub-Tree. Each validator looks at the attestations it has seen and picks the fork with the greatest accumulated weight. If a validator sent multiple votes, only the latest counts. Under normal conditions with one honest proposer per slot, the fork choice does little work. When forks exist, it is the defense that keeps nodes converging.
Only checkpoints can be justified or finalized. The first block of each epoch is a checkpoint. When validators holding at least two-thirds of total stake vote that checkpoint B is the correct descendant of checkpoint A, that forms a supermajority link. The newer checkpoint becomes justified. When the next checkpoint is justified on top of a justified one, the earlier justified checkpoint becomes finalized.
Gasper is the combination of Casper FFG (the justification and finalization gadget) and LMD-GHOST. The flow is:
Under normal operation, finalization takes about two epochs, roughly 13 minutes. A finalized block cannot be reverted unless at least one-third of total staked ETH is destroyed for double voting. Reverting two consecutive finalized blocks would require two-thirds collusion. Slashing removes part or all of the offending stake and ejects the validator. The correlation penalty on day 18 is larger when many validators are slashed at once. The exit for a slashed validator takes 36 days, with an initial penalty of up to 1 ETH on day 1.
Gasper provides plausible liveness: as long as two-thirds of stake follows the protocol, the chain can finalize regardless of other activity. If the chain fails to finalize for more than four epochs, the inactivity leak activates. It slowly drains the stake of validators that are not attesting to the majority chain until the majority regains two-thirds and finality resumes.
Honest validators receive rewards for proposing and attesting correctly, scaled by base rewards derived from total active stake. A proposer receives a fraction of base reward for each valid attestation included, plus a small reward for reporting slashings. Validators that are offline miss rewards and incur small penalties roughly equal to missed rewards.
Slashable behavior includes:
These are penalized harshly because they indicate intentional misbehavior, not accidental downtime.
Execution clients gossip transactions and maintain transaction pools and state tries. Consensus clients gossip blocks and attestations, run fork choice, and track the Beacon state. The two clients communicate over a local authenticated RPC called the Engine API. Both sides are given the same JWT secret. For block proposal, the consensus client requests an execution payload. For block validation, the consensus client unbundles the payload and the execution client re-executes it.
This modular design let The Merge reuse battle-tested execution clients and run five independent consensus clients, which helps client diversity.
Proof-of-stake is subjectively secure: a new node syncing from genesis cannot know which chain is canonical from protocol rules alone. It needs a recent weak subjectivity checkpoint, typically a finalized block within the last few weeks. Checkpoint sync fetches state from such a checkpoint instead of replaying from genesis, with the same trust assumption as using a trusted execution snapshot.
Withdrawals were enabled in the Shanghai/Capella (Shapella) upgrade on April 12, 2023. Two paths exist:
Activation also uses a queue with the same 256 ETH per epoch churn limit. Ethereum limits churn with EIP-7514 to bound validator set growth.
Where it helps
Trade-offs and limits
If you want to understand it deeply 1. Read the core pages on ethereum.org: proof-of-stake, Gasper, block proposal, and node architecture. Then skim the consensus specs on github.com/ethereum/consensus-specs for validator, Beacon block, and Beacon state definitions.
2. Run a full node on a testnet such as Hoodi or Sepolia. Install one execution client and one consensus client, generate a JWT secret, and start with checkpoint sync from a trusted finalized checkpoint. Compare latest, safe, and finalized with curl against both the JSON-RPC (execution) and the Beacon API (consensus).
3. Inspect live data: slots and epochs on a beacon explorer, committee assignments per slot, and Gasper votes. Watch a reorg on a slot with a missed proposer to see LMD-GHOST resolve it, then watch justification and finalization advance every two epochs.
If you want to operate a validator 1. Choose clients: common pairs are Geth plus Lighthouse, Nethermind plus Prysm, Besu plus Teku, Erigon plus Nimbus, or Reth plus Lodestar. Check current client diversity dashboards before deciding. 2. Prepare hardware: a modern CPU, 32 GB RAM, and a fast 2 TB SSD are typical recommendations, with reliable internet and backup power. Keep OS and clients updated and subscribe to client security lists. 3. Create keys with the staking deposit CLI and deposit at least 32 ETH per validator to the deposit contract. Set 0x01 credentials for legacy auto-sweeps or 0x02 for compounding up to 2048 ETH. Providing a withdrawal address once is required before any withdrawals flow. 4. Join the activation queue. Budget for the initialization delay and the churn of 8 validators per epoch. Monitor inclusion, attest correctly every epoch, and avoid running the same keys on two machines. 5. Plan exits in advance. Submit a voluntary exit, account for the exit queue and the 27-hour withdrawability delay, then wait for the sweep. For compounding validators, use execution-layer partial withdrawals for amounts below 2048 ETH.
If you build dapps or data pipelines- Use execution layer eth_getBlockByNumber with tags safe and finalized for confirmations. Treat safe as justified and unlikely to reorg without collusion or severe latency, and finalized as canonical unless one-third of stake was slashed.
Trusted starting points- ethereum.org roadmap for the Beacon Chain, the Merge, and the engine API
No. Proof-of-stake selects who can propose and how weight is counted. The consensus layer is the whole system that uses proof-of-stake plus Gasper, fork choice, gossip, and incentives to agree on the canonical chain.
The execution layer executes transactions and holds accounts and storage. The consensus layer organizes those execution payloads into beacon blocks, collects votes, picks the head with LMD-GHOST, and marks history final with Casper FFG. They gossip on separate p2p networks and sync together via the Engine API.
The name was retired in early 2022. Eth1 is now execution layer, Eth2 is now consensus layer, and Ethereum is execution plus consensus. No roadmap features were removed, only names.
A block is produced every 12 seconds when the proposer is online. It becomes justified after one epoch boundary receives two-thirds of votes and finalized one more justified checkpoint later, typically about 13 minutes after inclusion when the chain is healthy.
Only if at least one-third of total staked ETH double votes and is slashed. The protocol destroys that stake. Social consensus could also coordinate to ignore an attacker fork, but the economic cost remains.
The protocol limits how quickly stake can enter or leave to keep the validator set stable. Entry and exit each cap at 256 ETH per epoch. After exiting, a validator waits about 256 epochs to become withdrawable, then waits for the round-robin sweep that processes up to 16 withdrawals per block.
Legacy 0x01 validators have a 32 ETH effective balance cap. Any excess is auto-swept. Compounding 0x02 validators after Pectra can have up to 2048 ETH effective, so rewards add to weight and auto-sweeps only trigger above 2048 ETH.
Far less than proof-of-work Ethereum. Third-party bottom-up measurements put the full network near 0.0026 TWh per year, on the order of a few thousand US homes, compared with tens of TWh per year before the Merge.
If you run a full node, yes. After the Merge the execution client cannot determine the canonical head alone. If you rely on a provider, the provider runs both. Your app still benefits from using safe and finalized tags for important state reads.
Where does Solana proof-of-history or Cosmos Tendermint fit? Those are different consensus designs for other networks. Solana adds a verifiable delay function to order events before proof-of-stake voting, and Cosmos chains use CometBFT, a BFT protocol with Propose, Prevote, and Precommit steps and proposer selection weighted by voting power. Ethereum does not use proof-of-history. The term consensus layer is specific to Ethereum's post-Merge architecture.
Explore more guides and career playbooks