Execution Layer vs Consensus Layer: Ethereum's Split Architecture

Since the Merge, Ethereum runs on a split architecture consisting of two separate but coordinated pieces of software: the execution layer, which processes transactions and smart contracts, and the consensus layer, which handles proof-of-stake block proposal, attestation, and finality — with a full Ethereum node requiring both running together.

Why the Split Exists

Before the Merge, this split already existed conceptually, but it was created deliberately as an engineering strategy: rather than trying to retrofit proof-of-stake logic directly into the existing, battle-tested transaction-processing software, Ethereum's developers built the new proof-of-stake mechanism (the Beacon Chain) as an entirely separate system first, then joined the two together once both were mature. That original engineering decision is why the split persists today, even though the two layers now work together as a single functioning network.

The Execution Layer

The execution layer (sometimes still informally called "Eth1" from before the Merge) is responsible for:

• Processing transactions — transfers, contract calls, token swaps, and everything else users actually do.
• Executing smart contracts, running the Ethereum Virtual Machine (EVM) logic that powers DeFi protocols, NFTs, and every other on-chain application.
• Maintaining account state — balances, contract storage, and nonces.
• Managing the mempool of pending transactions waiting to be included in a block.

Common execution clients include Geth, Nethermind, Besu, and Erigon.

The Consensus Layer

The consensus layer handles Ethereum's proof-of-stake mechanics:

• Validator management — tracking which validators are active, their balances, and their status.
• Block proposal and attestation — coordinating which validator proposes each block and collecting attestations from other validators about the correct chain head.
• Finality — determining when a block can be considered permanently irreversible.
• Slashing detection — identifying and penalizing validators that violate consensus rules, as covered in our explainer on slashing.

Common consensus clients include Prysm, Lighthouse, Teku, and Nimbus.

How the Two Layers Communicate

The execution and consensus clients run as separate processes (often even as entirely separate programs, sometimes on the same machine, sometimes split across different machines) and communicate over a standardized local interface called the Engine API. In simplified terms, the consensus layer tells the execution layer which transactions to bundle into a candidate block and later confirms which block has become the canonical, finalized version of the chain; the execution layer processes those transactions and reports back the resulting state.

This deliberate separation of concerns means the two types of clients can be developed, tested, and upgraded somewhat independently, and — importantly for network resilience — an execution client bug and a consensus client bug are generally isolated problems rather than a single shared failure point.

Why Running a Full Node Needs Both

A node running only an execution client, with no consensus client, has no way to independently determine which block is actually the legitimate next block in the proof-of-stake chain — it would be entirely dependent on trusting an external consensus client's judgment. Similarly, a consensus client alone has no ability to process transactions or execute smart contract logic. Running both together, properly paired and communicating over the Engine API, is what makes a genuinely independent, fully verifying Ethereum node possible. See our practical guide on how to run an Ethereum node for setup details.

Execution Layer vs. Consensus Layer at a Glance

Aspect	Execution Layer	Consensus Layer
Main job	Process transactions, run smart contracts	Coordinate proof-of-stake consensus
Manages	Account state, contract storage, mempool	Validator set, attestations, finality
Example clients	Geth, Nethermind, Besu, Erigon	Prysm, Lighthouse, Teku, Nimbus
Existed before the Merge	Yes (as the entire chain)	Yes, as the standalone Beacon Chain
Communication method	Engine API (to consensus layer)	Engine API (to execution layer)

Why This Matters for Client Diversity

Because the two layers are separate pieces of software, client diversity needs to be considered independently for each — running a minority execution client paired with a majority consensus client (or vice versa) still leaves you exposed to whichever layer has less diversity across the network. Thoughtful validator and node operators consider both layers' current market share when choosing their software stack.

Bottom Line

Ethereum's post-Merge architecture splits transaction processing (the execution layer) from proof-of-stake consensus (the consensus layer), communicating through a standardized Engine API, a design that traces back to how the Beacon Chain was originally built as a separate system before being joined with mainnet. Running a full node requires pairing both layers correctly, and network resilience depends on diversity within each layer independently, not just diversity overall. For deeper background on the history behind this split, see our explainer on the Beacon Chain.