Consensus Client (CL) & Execution Client (EL)

Consensus Client (CL) & Execution Client (EL) 

✅ The Two-Client Architecture (CRUCIAL TO UNDERSTAND)

Every Ethereum node (full node or validator) runs two clients:

1. Execution Client (EL) – Geth, Nethermind, Erigon

• Verifies transactions (nonce, signature, gas, balance)

• Executes smart contracts (EVM)

• Maintains the world state

• Computes stateRoot

• Verifies execution payloads of blocks

2. Consensus Client (CL) – Prysm, Lighthouse, Teku, Nimbus

• Runs the Beacon Chain

• Handles validators, attestations, committees

• Chooses the head block (LMD-GHOST)

• Finalizes the chain

• Gossips blocks, attestations, sync messages

Communication Between EL & CL:

They talk through a local API called Engine API (JSON-RPC over pipe/HTTP).
This API sends messages like:

• CL → EL: “Here is a new block’s execution payload, verify it.”

• EL → CL: “Execution payload is valid, here is the new stateRoot.”

• EL → CL: “Here is your suggested new block’s payload.” (when producing block)

---

⭐ Now the FULL Flow (Correct, Clean, and Precise)

---

⭐ 1. User sends a transaction → Full Node (Execution Client)

When a transaction hits a full node:

Execution Client (EL):

• Verifies signature

• Verifies nonce

• Verifies balance

• Verifies gas limit

If valid → EL puts it in its mempool, and then:

EL → broadcasts tx

The EL gossips the transaction across the network to other ELs and validators’ ELs.

✔️ Validators do NOT receive transactions through CL.
⛔ Wrong: "validators put txs in CL mempool"
✔️ Correct: Mempool exists only in the Execution Client.

---

⭐ 2. Validator wants to propose a block

When it is your validator’s turn to propose:

Consensus Client (CL):

• Notifies: “It’s our slot; we must produce a block.”

• Requests a payload from EL via engine_getPayloadV3.

Execution Client (EL):

• Picks the best txs from its own mempool

• Executes them in the EVM

• Computes:

  • new stateRoot

  • transactionsRoot

  • receiptsRoot

  • logs bloom

  • gasUsed

• Creates the execution payload

Then EL → CL:

EL → CL: “Here is your execution payload.”

---

⭐ 3. Consensus Client (CL) builds the Beacon Block

The block contains 2 main parts:

1️⃣ Beacon block (built by CL):

• proposer index

• parentRoot

• randao reveal

• attestations

• slashings

• sync aggregates

• execution payload header

2️⃣ Execution Payload (built by EL):

• txs

• stateRoot

• receiptsRoot

• block hash

• gasUsed

• logs bloom

Then CL signs the block with the validator’s private key (BLS signature).

CL → broadcasts block to whole network.

---

⭐ 4. Other Validators Receive the Block

Validators receive the block via consensus gossip protocol (CL network).

When a validator receives a block:

Consensus Client (CL):

• Checks signatures

• Checks slot & proposer

• Checks fork-choice rules

• Extracts the execution payload

• Passes execution payload to EL via:
  engine_newPayloadV3

Execution Client (EL):

• Re-executes every transaction in the EVM

• Recomputes the stateRoot

• Compares it to the payload’s stateRoot

• If correct → Responds VALID

• If wrong → Responds INVALID (block is rejected)

---

⭐ 5. Validators Create Attestations

Once a validator determines the block is valid:

Consensus Client (CL):

• Creates an attestation voting for:

  • head block (LMD-GHOST)

  • source checkpoint

  • target checkpoint

• Signs the attestation (BLS signature)

• Broadcasts the attestation through CL gossip

Execution Client (EL):

Not involved in attestations.

---

⭐ 6. Attestations Are Included in Future Blocks

Proposers collect attestations and put them in future beacon blocks.

Execution layer never processes attestations.

---

🟩 Your Understanding Corrected

Here is your version vs the correct version:

You said:

“Full node verifies tx using EL and sends to validators.”

✔️ Correct (EL broadcasts tx; validators are also full nodes).

---

You said:

“Validators keep txs in CL mempool.”

⛔ Incorrect
✔️ Mempool exists only in Execution Client (EL)
CL has no mempool.

---

You said:

“Validator takes txs, executes with EL, gets stateRoot, builds block.”

✔️ Correct (EL does execution; CL builds beacon block around it)

---

You said:

“Validators re-execute txs with EL to verify block, then attest.”

✔️ Perfectly correct.

---

🟩 Final Clean Summary

Here’s the simplest “one-shot” explanation:

1. Tx enters EL mempool.
   EL verifies tx and gossips it.

2. When proposing, CL tells EL to build execution payload.
   EL takes txs, executes them in EVM, returns payload.

3. CL receives payload, builds beacon block, signs, broadcasts.

4. Other nodes receive block via CL:

   • CL validates signatures

   • CL gives payload to EL

   • EL re-executes txs, verifies stateRoot

   • If valid → CL attests

5. Attestations are gossiped and included in later blocks.

Execution Client = deals with transactions + EVM + state
Consensus Client = deals with validators + slots + blocks + attestations

They communicate through Engine API.