Ethereum Evolved: Dencun Upgrade Part 3, EIP-4788

Part 1 of this series explored the opcode-focused EIP-5656 and EIP-6780. Part 2 of this series detailed the consequences of staking and validator-focused EIP-7044 and EIP-7045. 

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.

After the Shanghai/Capella fork that enabled withdrawals of staked ETH, the methods outlined above in Flows 1, 2, and 3 were upgraded (to their V2 counterparts seen here, here, and here) to include withdrawal information in the calls made by the consensus client to the Engine API.

Putting the beacon block root in the EVM

Unlike the Engine API-intermediated information flows between Ethereum’s execution and consensus layers outlined above, EIP-4788 puts the parent beacon block root (from which the state of Ethereum’s consensus layer can be derived) directly into each execution block. This effectively exposes Ethereum’s consensus state in the EVM for the first time, and can be thought of as introducing an oracle, enshrined at the protocol-level, which relays Ethereum’s consensus state to Ethereum mainnet. 

There are three roots in any given consensus block (note that consensus block and beacon block are interchangeable terms):

Beacon Block Root: This is a hash of the entire header of the previous block. It links each block to its predecessor, forming a chain. We’re focused on this root.

State Root: This is a hash of the root of a Merkle Patricia tree that represents the state of the Ethereum network after the current block's transactions have been processed. It's not derived from the block header but from the state of the Ethereum mainnet.

Body Root: This is a hash of the root of a Merkle Patricia tree that represents all transactions included in the block. Like the State Root, it's not derived from the block header but from the transactions included in the block.

EIP-4788 will force the commitment of a hash tree root of each parent beacon block in the corresponding execution block’s header, and store each of these roots in a smart contract on Ethereum mainnet. It will do this by introducing a new field in the execution block header, parent_beacon_block_root, which contains the hash tree root of the parent beacon block for the given execution block.

The parent beacon block is simply the beacon block that came before the current one. Therefore, EIP-4788 will make use of the beacon block root, but it will be based on the prior block (the parent beacon block root), rather than the current block.

A limited number of these parent beacon block roots will be stored in a smart contract on Ethereum mainnet. This smart contract will implement a ring buffer data structure so that it can only ever hold ~1 day's worth of consensus state. The purpose of this ring buffer is to ensure that the contract’s state does not grow indefinitely. As new block roots are added to the buffer, the oldest ones are overwritten once the buffer reaches its capacity, hence maintaining a fixed size. This allows for efficient and bounded storage while still providing access to recent consensus layer state.

In a sense this data structure is a tradeoff; making the parent_beacon_block_root available for a reasonable amount of time without keeping an overly long, and therefore memory intensive, number of hashes.

Having this beacon block root-containing contract deployed on mainnet will allow any Ethereum contract to pass in an arbitrary execution block height from the last ~24 hours, and gain information about Ethereum’s consensus state at that point in time, in a trust-minimized manner. 

Implications of EIP-4788

EIP-4788 effectively introduces an oracle, enshrined at the protocol-level, which relays Ethereum’s consensus state to Ethereum mainnet (a.k.a. the EL). Once this EIP is merged, smart contracts and protocols deployed on Ethereum mainnet will no longer require a trusted oracle solution to gain information about Ethereum’s consensus state. Importantly, this consensus state information can be “unpacked”, and used to determine the status and balance of all Ethereum validators.

Currently, many staking-related applications rely on oracle systems composed of a relatively small number of oracle node providers who are trusted to independently verify and report information about Ethereum’s consensus state to the applications contracts on mainnet. These applications include some of the most prominent liquid staking pools on Ethereum (Lido, Rocket Pool), and re-staking arrangements like Eigenlayer. 

Liquid staking pools

As their name implies, liquid staking pools combine (or pool) deposits from users into 32 ETH chunks that are used to fund new validators. In exchange for their ETH deposit, users are given a receipt token in an amount proportional to their deposit. These receipt tokens are known as liquid staking tokens or LSTs, and they provide users with two primary benefits: increased capital efficiency, and a simplified UX around tracking their earned staking rewards.

LSTs improve the capital efficiency of ETH staking since LST holders can rehypothecate, or repurpose, their LST as collateral elsewhere in the DeFi ecosystem. Further, they simplify the process of tracking earned staking rewards by periodically updating either the number of LST tokens each user holds (in the case of a rebasing LST like Lido’s stETH), or the value of each LST relative to ETH (in the case of a repricing token like Rocket Pool’s rETH). 

The way this supply or value increase occurs today is via the staking pool’s trusted oracle system. Lido entrusts 5 oracle node operators to report the aggregate value of all Lido validators and distribute each day’s earnings to users by increasing the number of tokens each user holds. Similarly, Rocket Pool entrusts 18 oracle node operators to provide the same information for all Rocket Pool validators, however, oracle node providers are also paid in Rocket Pool’s native governance token $RPL. This position is a paid one to incentivize honest behavior and alignment with the protocol. In both cases, this oracle update occurs every ~24 hours and introduces undesirable trust assumptions and a significant centralization vector for the protocol. 

By exposing the parent, beacon block root in the execution layer, EIP-4788 makes Ethereum’s consensus state available to all contracts and protocols deployed on mainnet in a trust-minimized, cryptographically verifiable manner ultimately eliminating the need for trusted oracle systems. 

Re-staking applications

Practically, when speaking on re-staking applications, we’re referring to Eigenlayer. Conceptually, we’re referring to extending the crypto-economic security provided by Ethereum’s network of validators to services beyond the Ethereum protocol itself.

By embedding beacon block roots into the EVM, and by using the same logic described in relation to staking pools above, EIP-4788 could enhance the security, trustworthiness, and efficiency of EigenLayer's operations. This upgrade should increase the system's integrity and enable more innovative restaking strategies.

Many in the industry consider this an essential upgrade, as re-staking solutions could potentially onboard large amounts of staked ETH, and expose this ETH to additional slashing criteria imposed by the systems that it’s used to secure. By reducing the trust assumptions in re-staking, the Ethereum network may limit the potential downsides and chances of a re-staking slashing event.

Charting the future of Ethereum—one EIP at a time 

Compared to the four previously discussed EIPs, EIP-4788 is arguably more transformative and impactful. Rather than tweaking a consensus rule, or adding a helpful and convenient opcode, EIP-4788 will enhance the ability of Ethereum’s two layers to communicate. While we can reasonably predict some of the implications, there may be others discovered down the road. For instance, how will this upgrade alter MEV on Ethereum?

Our next post in this series, Part 4, will cover EIPs 7514 and 1153.

To continue to part four, Ethereum Evolved: Dencun Upgrade Part 4, EIP-7514 & EIP-1153, please click here.