Ethereum is gearing up for its next significant upgrade: Pectra. This update, combining the Prague execution layer upgrade and the Electra consensus layer upgrade, promises to bring substantial improvements and new capabilities to the Ethereum network. As we look ahead to a potential Q1 2025 implementation, it’s important for stakeholders, and particularly stakers, to understand the implications of these changes.

Pectra is introducing a series of Ethereum Improvement Proposals (EIPs) that will enhance the network’s functionality, scalability, and user experience. In this article, we’ll dive deep into the key components of the Pectra upgrade, exploring what these changes mean for stakers, developers, and the broader Ethereum ecosystem. 

What is the Ethereum Pectra Upgrade?

Pectra is the name of the next upgrade on Ethereum – Prague is the name of the execution layer (EL) upgrade and Electra is the name of the consensus layer (CL) upgrade.

The Ethereum Improvement Proposals (EIPs) that will be included in Prague are (based on devnet-1 inclusion):

• EIP-2537: Precompile for BLS12-381 curve operations
• EIP-2935: Save historical block hashes in state
• EIP-7685: General purpose execution layer requests
• EIP-7702: Set EOA account code for one transaction

The EIPs that will be included in Electra are:

• EIP-6110: Supply validator deposits on chain
• EIP-7002: Execution layer triggerable exits
• EIP-7251: Increase the MAX_EFFECTIVE_BALANCE from 32 to 2,048 ET; for more on this change and its implications see here.
• EIP-7549: Move committee index outside Attestation

When is the Ethereum Pectra Upgrade Happening?

At the time of writing, Pectra is estimated to take place during Q1 2025. There are some elements of the Pectra upgrade such as PeerDAS and EOF that could impact the proposed date (see below); however, it is likely that either of these upgrades could potentially be included in subsequent forks if they were to push out the timing of Pectra too much.

What should stakers know for the Ethereum Pectra Upgrade?

For a good summary of the upcoming Pectra upgrade – Marek Moraczyński’s presentation at ETHCC is highly recommended.

EIP-7251, also referred to as ‘maxEB’, has the most potential impact on stakers. This proposal would increase MAX_EFFECTIVE_BALANCE from 32 ETH to 2,048 ETH, reduce the initial slashing penalty from 1/32 of a validator’s balance to 1/4096 and allow consolidation of active validators.

Importantly, most of the key changes will be at the discretion of the staker. For instance, the decision to consolidate multiple validators is left to the staker. These consolidations will likely be execution layer (EL) triggerable – meaning the staker will likely need to use their externally owned account (EOA) to sign a consolidation instruction.

The decision of whether to consolidate validators is not a trivial one – see this piece for more. One of the key considerations is whether expected rewards and penalties change with consolidation. As a rule, expected rewards should be unchanged by the consolidation decision – the likelihood of being chosen for proposals and sync committee are proportional to a validator’s balance and attestation rewards are paid in proportion to a validator’s balance; meaning two validators with half the balance of a different validator have roughly equal total expected rewards.

On the penalty side, penalties are higher with a higher balance, but like rewards, ex-ante, they are not expected to be greater when comparing a consolidated validator with its unconsolidated constituent validators. The analysis is a bit more nuanced when looking at ex-post penalties, i.e., what is the expected size of the penalty given that one has occurred. For this analysis a consideration of the type of penalty – missed attestation, slashable offense, inactivity leak, etc – needs to be considered along with its nature – what is the typical distribution of such penalties and are they likely to occur in clusters, i.e., affecting multiple validators at once?

One aspect of EIP-7251 that is not voluntary, is that the partial withdrawal sweep is likely no longer to catch validators with balances above 32 ETH, but rather validators with balances above 2,048 ETH will be picked up in the partial withdrawal sweep.

This is where EIP-7002 – EL triggerable withdrawals – comes in. Stakers will be able to trigger withdrawals (and full exits) from their EOA. So if a staker wanted to withdraw any amount above 32 ETH, they would need to trigger this from their EOA.

Another important aspect of EIP-7002 is the ability for stakers to exit their validators using their EOA. This is particularly beneficial to stakers that use staking service providers. In the rare circumstance, where institutional staking service providers have not prepared for the extreme and rare scenario where the provider is unable to exit a validator on behalf of a customer, the customer will be able to simply use their EOA to exit the validator themself.

Finally, EIP-6110 – supply validator deposits on-chain- will reduce the time to activate a new validator. Currently, it takes around thirteen hours to deposit 32 ETH and have a validator activated, assuming there isn’t a validator queue. With EIP-6110 that time will drop to around thirteen minutes (again, assuming that there isn’t a validator queue).

The decrease in deposit time results from shifting the responsibility of processing deposits from the CL to the EL. More specifically, two delays have been removed. First, ETH1_FOLLOW_DISTANCE – about 6.8 hours – pre-Merge was a delay to ensure that reorgs were very unlikely and that if there were any issues on the EL, core devs had a window to respond. The other delay – EPOCHS_PER_ETH1_VOTING_PERIOD – an additional 6.8 hours, was meant to collect enough votes from validators on the CL to come to consensus about deposits. Both of these delays are no longer required with EIP-6110. 

For a thorough, in-depth look at this proposal Emmanuel Awosika’s piece is highly recommended.

PeerDAS and EOF

Proto-danksharding (EIP-4844) was included in the Deneb upgrade on March 23rd of this year and created data blobs on Ethereum – a new kind of blockspace tailored to L2s. The current target number of data blobs, three, and the maximum of six per block was chosen to ensure that the increased data demands would not overwhelm validators. In the future, as Etheruem moves toward full danksharding, the number of blobs will increase. Without any changes, at some point many validators would be unable to keep up with the increased data demands. Data availability sampling – having some validator sample a portion, but not all of the data – is a solution to this problem. This is the basis of PeerDAS.

Currently, the goal for devs is to have the PeerDAS changes implemented in the Pectra upgrade, but to have them activated during a separate fork, after Pectra. The thinking here is to not create too many changes at once.

For more on PeerDAS see this reference.

There is a similar development taking place on the execution layer known as EOF (or EVM object format). Although the goals of EOF – among them are to provide structure to EVM bytecode and create versioning – the approach to including it in Pectra is somewhat similar to PeerDAS. As of the last execution layer all core devs call on July 18th, 2024, the participants agreed to continue working on EOF with the aim of including the upgrade in Pectra. Should it become clear that EOF will delay Pectra, it is likely it will be removed.

EOF is actually a set of EIPs, all focused on aspects of EOF. From a high level, this set of EIPs can be viewed as giving developers more expressiveness, reducing the work required of execution layer (EL) clients, performing certain EL operations more efficiently and potentially reducing gas for some operations.

Marius Van Der Wijden, a well-respected member of the core dev community, voiced his concerns regarding the inclusion of EOF in Pectra, citing its complexity and potential security concerns. For a review of both the benefits and drawbacks of EOF, see this piece written by Marius.

Conclusion

As we’ve explored, the changes introduced by EIPs such as 7251, 7002, and 6110 offer new opportunities and flexibilities for stakers, while also addressing some of the current limitations in the Ethereum network.

The potential inclusion of PeerDAS and EOF, although still under consideration, signals Ethereum’s commitment to continuous improvement and scalability. These developments, if implemented, could further enhance the network’s capabilities and efficiency.

Figment is the leading provider of staking infrastructure, providing the complete staking solution for over 500 institutional clients, including asset managers, exchanges, wallets, foundations, custodians, and large token holders, to earn rewards on their digital assets. On Ethereum, Figment is the largest non-custodial staking provider of staked ETH. Institutional staking services from Figment include seamless point-and-click staking, portfolio reward tracking, API integrations, audited infrastructure, and slashing protection. This all leads to Figment’s mission to support the adoption, growth, and long-term success of the digital asset ecosystem.