The "execution layer" is what was previously known as Ethereum 1.0, which originally kept the consensus rules and the execution of transactions bundled together. With the move to Ethereum 2.0, we moved all the stuff responsible for maintaing [[2. Consensus|consensus]] into the "consensus layer" and built a bunch of different clients responsible for running those rules on what is known as the "beacon chain". We left all the stuff responsible for executing state changes on what was Ethereum 1.0, with the same clients as always doing that, while now fetching information about consensus (i.e. who is in the validator set and what they have attested to) from their beacon chain client compatriots. ### Relevant Background The "Eth1 and Done" post refered to in [[3. Data|Data]], written by cdetrio, provides deeper insight into why Ethereum 1.0 kept consensus and execution coupled. >There is a distinction between two approaches to execution. At root is the fundamental difference between a “data availability consensus game” that is the ordering of blocks (which has a non-deterministic outcome), versus an “interactive verification game” that is the execution of transactions (which has a deterministic outcome, given an ordering). The primary drawback of separating consensus and execution, as argued in that [original whitepaper](https://web.archive.org/web/20190403172018/https://github.com/ethereum/wiki/wiki/White-Paper), is that it make light clients very difficult to create. >The real downside to lack of true light clients is that it becomes difficult to imagine how a cross-chain protocol would work; the usual way to do cross-chain stuff is to imagine a contract on one chain being a light client of another chain (and if two contracts on two different chains can be light clients of each other, then trustless cross-chain atomic swaps become possible). This, among other reasons, motivated building Ethereum as its own chain (with execution coupled to consensus) rather than as a meta-protocol that piggybacks on data attached to bitcoin tx’s. The primary gain of separating consensus from execution is that it gives us scalability if we do it well and apply the lessons we have learned since Vitalik wrote that whitepaper in 2014. We can see in this trade-off - that is, light clients versus scalability - the primary problem we face when working on infrastructure. Increasing throughput and speed to finality inevitably means a higher cost and/or complexity to validate (which is why light clients become a challenge). Viable scaling solutions must try and navigate this without privileging either pole. ## How It Works Now Each beacon chain (that is, each [[2. Consensus|Consensus Layer]]) block contains an **execution payload**. This 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, the consensus layer client sends the payload to an execution layer client, which does the following. It 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, the block is inserted into the **execution chain** (execution layer blockchain, a pre-merge Ethereum chain) and the post-block state is stored in **execution state** storage (Ethereum state storage as we know it today). It is this execution chain that is used to serve JSON-RPC requests. If you'd like to dive really deep, [this spec from the execution layer pespective](https://hackmd.io/@n0ble/ethereum_consensus_upgrade_mainnet_perspective) is a good place to go. ### Clients 1. [Geth](https://geth.ethereum.org/) 2. [Besu](https://besu.hyperledger.org/en/stable/) 3. [Erigon](https://github.com/ledgerwatch/erigon) 4. [Nethermind](https://nethermind.io/) Author: cryptowanderer