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 April 8th implementation (subject to change), 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-6 inclusion):
- EIP-2537: Precompile for BLS12-381 curve operations
- EIP-2935: Save historical block hashes in state
- EIP-7623: Increase calldata cost
- EIP-7685: General purpose execution layer requests
- EIP-7702: Set EOA account code for one transaction
- EIP-7840: Add blob schedule to EL config files
The EIPs that will be included in Electra are:
- EIP-6110: Supply validator deposits on chain
- EIP-7002: Execution layer triggerable exits
- EIP-7251: Give validators the option to increase the MAX_EFFECTIVE_BALANCE from 32 to 2,048 ETH; for more on this change and its implications see here.
- EIP-7549: Move committee index outside Attestation
- EIP-7691: Blob throughput increase
When is the Ethereum Pectra Upgrade Happening?
Pectra is expected to happen on April 8th (*subject to change)..
What should stakers know for the Ethereum Pectra Upgrade?
EIP-7251, also referred to as ‘maxEB’, has the most potential impact on stakers. This proposal would give validators the ability to increase MAX_EFFECTIVE_BALANCE (“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 be execution layer (EL) triggerable – meaning the staker will need to use the withdrawal address key associated with their validator to sign a consolidation instruction.
The decision of whether to consolidate validators or to increase max effective balance from 32 to 2,048 ETH is not a trivial one – see this piece for more. Note that whether we are talking about consolidations or increasing max effective balance, both decisions likely result in higher balance validators. So the analysis between these two decisions is similar. 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?
It should be noted that the decision to change max effective balance will result in validators compounding rewards below effective balances of 2,048 ETH – that is, each additional amount of effective balance will increase expected rewards proportionally. The other side of this coin is that partial withdrawal sweeps will no longer occur automatically for effective balances below 2,048 ETH.
This is where EIP-7002 – EL triggerable withdrawals and exits – 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, assuming they have opted in to increasing their max effective balance to 2,048 ETH.
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
It has been decided that both PeerDAS and EOF will be included in subsequent upgrades to Pectra. The below is for informational purposes.
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 significantly. 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.
For more on PeerDAS see this reference.
EOF (or EVM Object Format) 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.
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.
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.
The information herein is being provided to you for general informational purposes only. It is not intended to be, nor should it be relied upon as, legal, business, tax or investment advice. Figment undertakes no obligation to update the information herein.