We will now turn our attention to EIP-4788, an arguably more impactful EIP that will lower the trust assumptions inherent to mainnet applications that require information about Ethereum’s consensus state to function correctly, such as liquid staking protocols and restaking applications. This is achieved by exposing the parent (previous) beacon block root in each execution block and storing a small history of these beacon block roots in a new smart contract on Ethereum’s execution layer.
This beacon block root-containing contract will allow any mainnet-deployed smart contract to query and gain information about Ethereum’s consensus state in a trust-minimized manner. A ring buffer is used to ensure that only a limited number of consensus state roots are stored, to avoid the contract’s state growing indefinitely.
Where the first two parts of this series detailed minor technical changes and attunements, EIP-4788 has the potential to more meaningfully impact Ethereum at the user application level.
The layers of Ethereum
As its name suggests, Ethereum’s Merge represented the joining of two, previously distinct, blockchains: pre-Merge Ethereum mainnet (now called Ethereum’s execution layer), and the Beacon chain (now, Ethereum’s consensus layer).
Technically, post-Merge Ethereum is still two tightly coupled blockchains. However the block trees of the execution layer (EL) and consensus layer (CL) have a 1:1 mapping, meaning that every EL block has one, and only one CL block which corresponds to it, and vice versa.
This 1:1 mapping of EL and CL blocks means that we can think of post-Merge Ethereum as a single blockchain consisting of two layers. The EL is where Ethereum transactions are processed and broadcast to the rest of the network, and is the layer where all user accounts and smart contracts exist. The CL runs Ethereum’s PoS consensus algorithm, and handles transaction settlement and finality by ensuring that a supermajority of validators agree upon the head of the Ethereum blockchain.
Communication between Ethereum layers
Historically and still to this day, the ways in which Ethereum’s layers communicate with each other have been limited.
Pre-Merge Information Flows
The first information to flow between Ethereum’s EL and CL were new, 32 ETH deposits made to Ethereum’s deposit contract; the deposit contract is the Ethereum protocol’s entry point for staking. Technically, it is a standard smart contract deployed on Ethereum mainnet (the EL), where anyone can permissionlessly send 32 ETH along with a payload of other data to fund and activate Ethereum validator software.
Part of the “payload of other data” included in each deposit transaction is the deposit data root, which provides a succinct, cryptographic representation of all other data included in the deposit transaction. The deposit contract verifies both the amount of ETH, and the deposit data root of each deposit transaction, and once it completes this verification, emits a receipt, or EVM log event, containing the data relevant to that deposit.
There are two ways that this deposit log event can make its way from Ethereum’s EL to the CL. The first is a process we’ll refer to as Eth1 data voting. This is the process by which beacon block proposers (i.e. validators on Ethereum’s Beacon chain who are selected to propose beacon blocks) come to agreement on the state of Ethereum’s EL, and in particular, the deposit contract. Eth1 data voting is a complicated process requiring a majority vote of beacon block proposers over a repeating cycle of 2048 slots (~6.8 hours), and an 8-hour delay (the ETH1_FOLLOW_DISTANCE). The second way a deposit log event is transferred from the EL to the CL is through a validator directly importing these logs from its own execution client via the standard JSON RPC interface (see the Deposit Processing section of Ben Edgington’s book for more detail).
Both of the mechanisms are legacy processes now that the Merge has occurred, and will be reformed in some future Ethereum hard fork, likely under EIP-6110.
Post-Merge information flows
Since the Merge, communication between execution and consensus clients has been intermediated by a component called the Engine API. As described in Ben Edgington’s book, the Engine API “is one-way in the sense that the consensus client can call methods on the Engine API, but the execution client does not call any methods on the consensus client”.
Ben goes on to explain that, after the Merge, three calls or information flows are “the most interesting methods the engine API provides…”. At a high-level, these information flows achieve the following:
Flow 1 results in the validation of a newly proposed block.
Flow 2 updates the execution client with information about the head of the chain, and results in the execution client building an execution payload.
Flow 3 results in the consensus client retrieving a newly built execution payload, which it includes in a new block proposal.