consensus client

The consensus client — often called the beacon node — is the half of an Ethereum proof-of-stake node responsible for the consensus layer: agreeing on which block is the canonical head and which checkpoints are final. After Ethereum's Merge in 2022, a full node is no longer one program but a pair, and the consensus client is the one that runs the proof-of-stake brain: it tracks the beacon chain, collects validators' attestations, runs the fork-choice rule to pick the head, and applies Casper FFG to finalize checkpoints.

Its counterpart is the execution client, and the division of labor is precise. The consensus client decides the ordering and which block wins; the execution client takes the ordered transactions and actually runs them on the EVM to compute the resulting state. They communicate over the authenticated Engine API: when the consensus client learns of a new head, it tells the execution client to execute that payload (engine_newPayload) and to update its view of the head (engine_forkchoiceUpdated); when one of its validators is due to propose, it asks the execution client to build a payload. Neither is a full node alone — you must run both.

Concretely, the consensus client implements the beacon chain's slot-and-epoch clock (12-second slots, 32 slots per epoch), gossips and aggregates the attestations validators broadcast, weighs the fork choice using LMD-GHOST, and processes the justification-and-finalization logic that makes checkpoints irreversible. It exposes a Beacon API that a validator client connects to in order to learn its duties and submit signed messages. The consensus client itself holds no signing keys; it is the situational-awareness engine, while signing is delegated to the validator client.

There are several independent consensus-client implementations — Prysm, Lighthouse, Teku, Nimbus, Lodestar, and Grandine — and which one you run is a consensus-critical choice, not a cosmetic one. If a single implementation runs more than roughly two-thirds of validators and contains a bug, it could wrongly finalize an invalid chain that the rest of the network cannot revert; below one-third, a buggy client can only fail to finalize, which is recoverable. This is the heart of why client diversity is treated as a security property of the whole network, not a preference of individual operators.