Article Ethereum Evolved: Dencun Upgrade Part 2, EIP-7044 & EIP-7045


October 26, 2023


TJ Keel, Andrew Breslin

Ethereum Evolved: Dencun Upgrade Part 2, EIP-7044 & EIP-7045

In part two of the Ethereum Evolved: Dencun Upgrade series, we turn our attention to two staking and validator focused upgrades: EIP-7044 and EIP-7045.

dencun upgrade pt 2 cover image

Reading time

3 mins

Following our first edition of this series, wherein we explored the opcode-focused EIPs (EIP-5656 and EIP-6780), we now turn our attention to two staking and validator focused upgrades: EIP-7044 and EIP-7045. While Part 1 focused on minor code changes and technical improvements to Ethereum’s execution layer, Part 2 of the series (this post) explores changes to Ethereum’s consensus layer scheduled for activation in the Cancun-Deneb fork. 

These changes are fairly described as improvements to validator operations that only became possible—and in some cases, necessary—with hindsight in the months following the Merge. Though they won’t necessarily change Ethereum’s overall trajectory, they will allow for more secure implementations of Ethereum staking, as well as increase the security and robustness of the consensus process.

EIP-7044: Perpetually valid signed voluntary exits

EIP-7044 will allow signed voluntary exits to remain valid indefinitely, instead of being valid only for two upgrades—or the current and previous consensus layer (CL) fork versions—as is the case now. This change aims to simplify and improve the staking user experience, particularly for users of delegated staking solutions. 

Delegated ETH staking in a nutshell

Generally, delegated staking arrangements involve two parties: the ETH staker, who owns 32 ETH (or some multiple of 32 ETH) that they’d like to stake, and the validator operator, who manages the technical and operational complexities of running an Ethereum validator on behalf of the ETH staker. The infographic below describes the relationship between an ETH staker and validator operator on Ethereum:

dencun upgrade pt2, image 1

While some delegated staking arrangements involve the validator operator taking custody of the user’s 32 ETH, requiring the user to trust the validator operator not to misuse or steal their funds, it’s also possible to offer delegated staking non-custodially. For example, ConsenSys Staking offers users their services as a validator operator in an entirely non-custodial manner, so that users retain ownership of their funds throughout the entire ETH staking process. 

Non-custodial, delegated staking offerings like ConsenSys Staking’s are possible because every Ethereum validator has two types of keys: signing keys and withdrawal keys. A validator’s signing key is what’s used to perform the on-chain duties expected of every Ethereum validator (i.e. attesting and proposing blocks). Since validators must sign an on-chain attestation every few minutes, a validator’s signing keys are held in a hot wallet—for convenient access—and must be controlled by the validator operator. 

The validator’s withdrawal key dictates where the original 32 ETH deposit and all accrued staking rewards are sent when a validator exits the Beacon Chain. Since withdrawal keys tend to be used to perform on-chain actions very infrequently, a validator’s withdrawal keys can be held in cold (offline) storage, exclusively by the ETH staker. This ensures that ETH stakers retain sole ownership of their validator’s withdrawal key—and ultimately, their staked funds—even after delegating ownership of their validator’s signing key to the validator operator. 

Validator exits in a delegated staking setup

In the delegated staking setup outlined above, a complication arises when the ETH staker decides they would like to exit their validator and withdraw their original 32 ETH deposit and accrued staking rewards. For context, exiting an Ethereum validator requires that a so-called “voluntary exit message” (VEM) or “voluntary exit operation” is signed with the validator’s signing key and submitted for processing on the Beacon Chain by a consensus layer (CL) client (eg. Teku). The infographic below provides a more detailed breakdown of the validator exit process:

dencun upgrade pt2, image 2

Recall that, even in a non-custodial delegated staking arrangement, the validator’s signing key is held by the validator operator, rather than the ETH staker. This arrangement puts the ETH staker in the undesirable position of having to trust their validator operator to sign and submit a voluntary exit on their behalf whenever they wish to exit their validator. 

While it is expected that any reputable validator operator would respect the ETH staker’s request to exit, this scenario exposes the ETH staker to the risk that a validator operator refuses to exit their validator (sometimes referred to as “griefing”). Fortunately, there is a workaround for this suboptimal staking user experience: pre-signed voluntary exits. 

Pre-signed voluntary exits

At present, validator operators demonstrate their intent to honor exit requests from ETH stakers by pre-signing voluntary exits for the validators they operate, and sending these pre-signed voluntary exits to the ETH staker who funded each validator. Providing the ETH staker with pre-signed voluntary exits empowers them to unilaterally submit the voluntary exit to an Ethereum consensus client at any time, and by doing so, independently exit their validator(s). 

Today, these pre-signed validator exits are valid only for the current and previous consensus layer (CL) fork versions. In other words, once the Deneb fork occurs, voluntary exits that were pre-signed prior to the Capella fork will no longer be valid. 

This design choice—to limit the validity of pre-signed voluntary exits—was originally made due to a consideration from Core Devs around the case of a very long, contentious fork. In this case, a pre-signed voluntary exit submitted on fork version A would be replayable on fork version B. This will remain a risk once pre-signed voluntary exits are made perpetually valid via the Deneb upgrade, however the consensus amongst Core Devs is that the advantages and improved staking UX that this change enables outweigh this risk. The EIP’s author contends that “this possibility is not sufficient to justify the UX degradation exposed above, as no funds are at risk and the staker can re-stake on one or both of the chains.”

Future benefits of perpetually valid signed voluntary exits

To reiterate, EIP-7044 will make voluntary exits perpetually valid, rather than being valid only for the current and previous consensus layer (CL) fork versions. 

Beyond improving the staking user experience in the ways described above, this EIP opens up a new design space around automated validator exits. For example, a perpetually valid pre-signed voluntary exit could be stored in some contract, or automated mechanism, that submits the voluntary exit to Ethereum’s consensus layer if and when a specific condition is met (e.g. if your validator is inactive for a set number of epochs). This would provide stakers additional protection against inactivity penalties in the event that their validator setup is lost, or otherwise goes offline. 

For those who are more technically savvy, this change will be implemented by making a single change to the state transition function:

  • Modify process_voluntary_exit to compute the signing domain and root fixed on CAPELLA_FORK_VERSION.

Additionally, the voluntary_exit gossip conditions are implicitly modified to support this change. To make the change backwards compatible the signature domain is locked on the Capella fork.

EIP-7045: Increase max attestation inclusion slot

From one perspective, the Ethereum blockchain is primarily made up of blocks (represented below as squares) and attestations (represented below as circles). Each attestation can be thought of as a vote on a given block to signal its ‘correctness.’ 

dencun upgrade pt2, image 3

Attestations for a specific slot must be included in a block within a predefined time window to be considered valid by Ethereum’s consensus mechanism. For the uninitiated, time in Ethereum is divided into epochs, with each epoch containing 32 slots; a slot is a period of 12 seconds in which blocks can be proposed and validated.

EIP-7045 will extend the maximum inclusion slot for attestations from 1 rolling epoch to 2 non-rolling epochs. In other words, a validator used to have 32 slots to broadcast their attestation for inclusion on a given slot. Under this upgrade, validators will now be able to attest to the slot in the current epoch, plus the complete subsequent epoch—meaning validators now have up to, but not necessarily, 64 slots to include attestations (and receive rewards for doing so). (The nuance here being that a validator is unlikely to have the complete first epoch to attest in, unless the slot they’re attesting to is the first slot in that epoch).

This X+1 attestation window was considered during the Beacon Chain’s initial launch but has only received more attention (and priority) now because it will allow faster confirmation times for each block. In order to understand this change better, we must first clarify a key concept in Ethereum’s consensus known as “fork choice”.

Fork choice: How Ethereum determines the canonical block

While the blockchain is linear, it only becomes so after the network votes on ‘correctness’ to establish consensus on which block is canonical, and therefore the head block. Before consensus is reached on the canonical block, there may be multiple competing blocks, each receiving some number of attestations, or votes.

dencun upgrade pt2, image 4

In the above diagram, validators will attest to one of the three head blocks as shown by the green, purple, and blue arrows. Until this voting process has completed, with validators attesting to a specific one, the Ethereum network has not decided which block is canonical. 

Evaluating Ethereum’s fork choice with LMD-GHOST

Ethereum uses an algorithm called LMD-GHOST (Latest Message Driven Greedy Heaviest Observed SubTree) to analyze fork weights and choose the canonical block. LMD-GHOST selects the fork with the greatest cumulative weight by recursively traversing block descendents, allowing it to identify the fork most supported by validator attestations. Its primary objective is to prevent the network from disputing which block is canonical, or the most attested to block.

dencun upgrade pt2, image 5

For LMD-GHOST to function securely it needs access to as many attestations as possible. Currently, attestations can only be included within 32 slots of creation. This has limited the attestation dataset available to evaluate fork choice. 

Hence, researchers have deemed it appropriate to increase the attestation window of the Beacon Chain, and therefore increase the number of attestations that may be assigned to a given block. By doing so, LMD-GHOST will be able to more quickly and more efficiently determine the canonical block, enabling consensus nodes to more easily resolve conflicts if two or more competing forks appear.

It is important to note, however, that LMD-GHOST is but one part—albeit an important one—of the mechanism used to secure Ethereum’s Proof of Stake (PoS) consensus. While LMD-GHOST is responsible for confirming the canonical block, another algorithm known as Casper the Friendly Finality Gadget (Casper-FFG) determines finality of the epoch.

Ethereum PoS currently uses a combination of both algorithms (Gasper) to manage validator rewards and penalties, determine block validity, elect a canonical block, and declare finality. To learn more about Gasper, we encourage reading the Ethereum Foundation’s explanatory resource on the Gasper algorithm

Note: Different applications may choose either LMD-GHOST or Casper-FFG as a source of ‘truth’ for Ethereum’s state depending on their security needs. The main tradeoff here is speed vs. fidelity: LMD-GHOST can reasonably declare Ethereum’s canonical state early, while Casper-FFG will take longer to finalize epochs—but once an epoch is finalized, blocks added to the chain during that epoch are immutable (Casper-FFG is said to provide accountable safety for this reason).  

Benefits of increasing the attestation window

By expanding the inclusion window to X + 1 epochs (instead of restricting inclusion of attestations to the current epoch), EIP-7044 enables LMD-GHOST to incorporate more attestations when assessing fork weights. This way, LMD-GHOST will be able to more confidently select the canonical fork endorsed by the majority of Ethereum validators.

The extended window also provides flexibility for validators to influence Ethereum’s consensus. For instance, even if some validators are initially censored, their late attestations can still accumulate weight behind the valid fork. This makes LMD GHOST more robust against temporary censorship or coordination issues.

EIP-7044 is certainly a step in the right direction towards lowering block confirmation times and reducing latency for Ethereum users. However, we must note that this EIP and corresponding research is independent of ongoing research and development to enable Single Slot Finality (SSF) on Ethereum (which will require more significant changes to the consensus layer).

Charting the future of Ethereum—one EIP at a time

The EIPs discussed in this post—EIP-7044 and EIP-7045—are supplementary consensus layer upgrades that will primarily affect Ethereum validators and staking pools. The next post in this series will cover EIP-4788: an upgrade that adds the Beacon block root to the EVM (Ethereum Virtual Machine). A fitting followup as it will allow some of the consensus layer’s state to be accessible by the execution layer. 

To continue to part three, Ethereum Evolved: Dencun Upgrade Part 3, EIP-4788, please click here.