Research · Ethereum
Execution and consensus layers
Last reviewed 2026-09-21Source: Ethereum execution-apis specification and ethereum.org node documentationArchitecture descriptions only; no client performance figures are claimed.
Why the node is split in two
Before the Merge, Ethereum had one chain and one client. The chain was extended by proof of work, and the same program that executed transactions also decided which block was next. The Merge separated those two responsibilities: the execution layer kept the accounts, the state and the transaction format, and the consensus layer took over the job of agreeing on the order of blocks. A node now runs one client of each kind, and neither is useful on its own.
The separation was not introduced for elegance. It was the mechanism that allowed a running chain with a large state and a live user base to change its consensus mechanism without a migration. The execution layer's state was preserved exactly as it was; only the way blocks are chosen changed. That is why the Merge is described as replacing the engine while the car keeps moving, and it is why the transition did not require users to move funds or contracts to redeploy.
The split also made the two layers independently upgradeable. A change to the consensus rules — a new fork-choice rule, a change to the reward schedule — is a consensus-layer change and does not touch the execution layer's semantics. A change to the gas schedule or a new transaction type is an execution-layer change and does not touch the consensus layer. The two are coordinated through a shared fork schedule, but the code that implements them is separate.
The engine API
| Concern | Execution client | Consensus client |
|---|---|---|
| State | Holds accounts, storage and code; computes the state root | Holds the validator registry and the checkpoint state |
| Transactions | Validates, executes and meters them | Does not see individual transactions |
| Block production | Builds a payload when asked and returns it | Decides who proposes, and asks for a payload at the right slot |
| Validators | Not aware of them | Manages the registry, duties, rewards and penalties |
| Fork choice | Not aware of it | Applies the fork-choice rule to decide the canonical head |
| Peer network | Gossips transactions and serves state | Gossips blocks and attestations |
Last reviewed 2026-09-21Source: Ethereum execution-apis, Engine API specificationThe interface is specified; the responsibility split summarises it.
The two clients communicate over a local authenticated interface called the engine API. The consensus client drives it: when it is time to propose a block, it asks the execution client to build a payload; when it receives a block from a peer, it passes the payload to the execution client to validate and execute. The execution client returns the state root it computed, and the consensus client checks that the root matches the one the block claims. If it does not, the block is invalid and the consensus client rejects it.
The interface is deliberately narrow. The consensus client does not need to understand the EVM, and the execution client does not need to understand attestations. Each side can be implemented, tested and upgraded independently, and the interface between them is small enough to specify precisely. That is what makes client diversity practical: a team can write a new consensus client without reimplementing the EVM, and a team can write a new execution client without reimplementing the consensus protocol.
The split does introduce a coordination requirement that a single client would not have. The two clients must agree on which fork they are following, and a mismatch — an execution client that has not been upgraded for a fork the consensus client expects — leaves the node unable to follow the chain. That is why the operational guidance for node operators pairs each consensus client with a compatible execution client and treats the pair as a single unit for upgrade purposes.
What the separation buys and costs
The clearest benefit is that the consensus mechanism became replaceable. Ethereum has changed its fork-choice rule, its reward schedule and its validator lifecycle since the Merge, and each of those changes was a consensus-layer upgrade that left the execution layer's state and semantics untouched. A monolithic client would have required each of those changes to be made in the same codebase that executes user transactions, with a correspondingly larger blast radius.
The clearest cost is operational complexity. Running a node now means running two programs, keeping them in sync, and upgrading them together at each fork. For a hobbyist that is a real increase in effort; for a staking operator it is a manageable one, because the consensus client was already a separate program from the validator client. The ecosystem's tooling has largely absorbed the complexity, but it has not removed it.
A subtler consequence is that the two layers have different resource profiles. The execution client is the one that stores the state and executes transactions, so it dominates disk and CPU usage. The consensus client stores the beacon chain's history and the validator registry, which is far smaller, and its work is dominated by signature verification and network traffic. An operator sizing hardware is therefore sizing for the execution client, and the consensus client's requirements are comparatively modest.
Sources and references
The client split, the engine API and the responsibility division described above are taken from Ethereum's interface specification and its node documentation.
- The engine API. ethereum/execution-apis, Engine API specification: the interface through which the consensus client drives the execution client.
- Nodes and clients. ethereum.org, Nodes and clients: the execution and consensus client pair, and what each one does.
- The Merge architecture. ethereum.org, The Merge: how the execution layer was joined to the beacon chain and what changed for users.
- The consensus-layer specification. Ethereum Consensus Specs, Consensus Specs: the beacon chain, fork choice and validator specifications that the consensus client implements.
Related reading
- Research HubEvery dataset on the site, with methodology and provenance.
- Altcoin ResearchAltcoins measured against Bitcoin: design intent, consensus, execution, scaling and market structure.
- The ETH-BTC Correlation RecordHow the correlation is measured, how it behaves across windows, and where it breaks down.
- The ETH/BTC RatioWhat the ratio measures, how to read its trend, and why it is not a forecast.
- ETH During Bitcoin Bull PhasesAssociation within a common market factor, and what co-movement cannot establish.
- ETH During Bitcoin Bear PhasesDrawdown depth and duration compared over identical windows, and the limits of the comparison.