# The Merge terminology

In general Ethereum client consists of two layers. This separation becomes especially important in the context of the Merge.

- **Consensus-layer.** Responsible for the consensus, i.e. block seal validity, and fork choice rule. The Merge enables PoS consensus driven by the beacon chain hence this layer is represented by modified beacon chain client.
- **Execution-layer.** Responsible for transaction bundling and execution, and state management. This layer is represented by modified pre-merge PoW clients.

If these layers are bundled into a single piece of software, then the UX of running a post-merge client would be very similar to what users are currently running.

On the other hand, there are use cases which could benefit from composite client architecture. Composite client consists of two parts, **consensus client** (a.k.a. beacon chain client) and **execution client** (modified pre-merge PoW client). See [Silkworm](https://github.com/AlexeyAkhunov/papers/blob/master/Turbo-Geth-Silkworm-architecture-plans.pdf) for a good example of composite client design.

Consensus-layer is responsible for maintaining **consensus chain** (beacon chain) and fork choice rule by processing **consensus blocks** (beacon blocks) and attestations received from other peers connected to **attestation sub-network** (a part of beacon chain network).

Each beacon block contains an **execution payload**. Execution payload contains a list of transactions and other data required to execute and validate the payload. There is a validity condition of beacon block with respect to the payload, i.e. if the payload is invalid then the beacon block is considered invalid too.

In order to check this validity condition, consensus-layer sends the payload to the execution-layer which does the following. Assembles an **execution block** (former PoW block with stubbed ethash fields), verifies pre-conditions, executes transactions and verifies post-conditions. Then the result is sent back to the consensus-layer.

After execution, block is inserted into the **execution chain** (execution-layer blockchain, a pre-merge ethereum chain) and the post-block state is stored into **execution state** storage (ethereum state storage as we know it today). Execution chain is used to serve JSON-RPC requests.