In short, the consensus layer (CL) client governs consensus and the execution layer (EL) client. The EL client creates blocks with transactions and executes smart contracts.
The interaction between the consensus layer and execution layer is specified by the Engine API: https://github.com/ethereum/execution-apis/tree/main/src/engine
From an explanation in
Are transactions duplicated in both beacon chain and execution layer? you can see that the CL is like the brain, it tells the EL to prepare a payload, get a payload, execute the payload, and tells the EL what the head of the chain is.
Engine API test vectors for The
Merge based
on a discussion of the Engine
API
is helpful to see how the layers interact. The CL calls
engine_forkchoiceUpdatedV1
so that the EL prepares a payload. The CL
calls engine_getPayloadV1
to get a payload. The CL then tells the EL
to execute the payload by calling engine_newPayloadV1
. Assuming that
the payload is valid, the CL then tells the EL that the payload is the
head of the chain by calling engine_forkchoiceUpdatedV1
.
The EL is receiving transactions, and both are syncing different parts of the Ethereum state.
As explained in Which client holds the state of the chain?, both hold the state. For example, consensus layer rewards accrue in the validator's balance on the beacon chain, while transaction tips accrue in the fee recipient address on the execution layer.
Related references:
Run Execution Client without Consensus Client
What is the incentive for people running execution clients in eth2?