Pectra: What It Means For You

The upcoming Ethereum Pectra upgrade is one of the largest ever, both in terms of the number of EIPs to be implemented, and its effect on the staking industry. By enabling the consolidation of existing validators up to 2048 eth in size, this is a unique opportunity for node operators and staking protocols to reduce their validator count and migrate to distributed validators to future-proof their infrastructure.  

Disclaimer: As the scope of Pectra is still being finalised, the information presented in this blog article is subject to change. For the latest, please see Christine Kim’s developer call writeups and the This Week in Ethereum newsletter. 

Pectra: Lots of EIPs

Details about the Pectra upgrade have been in constant flux since developers started planning it as early as November 2023. Discussions about what to include in Pectra showed developers in disagreement about priorities for upgrades to the Ethereum protocol, including the major Verkle transition. With a long shopping list of 20 EIPs to go into the Ethereum protocol, the developers agreed to split the EIPs between Pectra and the upgrade after Pectra, which will be called  Fulu-Osaka, or “Fusaka”. 

Wen Pectra?

As of December 2024, the core developers were still finalizing the scope of Pectra. Assuming the scope of Pectra is finalized in January or February, and developers conduct final testing on private devnets, perhaps in March Pectra will be tested on Ethereum’s public testnets, and be activated on mainnet in April or May. However, given the significance of Pectra for stakers and node operators, now is already a good time to examine its details and implications. 

What is EIP 7251 - Maximum Effective Balance (MAX_EB)

For stakers, the most impactful EIP in Pectra is “EIP-7251: Increase the MAX_EFFECTIVE_BALANCE”. The motivation for EIP 7251 is to reduce the number of validators on the network. With the Ethereum network approaching 1.1 million validators, networking issues are emerging, and Ethereum Foundation engineers simulate real trouble beyond 1.4 million validators. (To buy some time, the previous Ethereum upgrade lowered the limit of new validator activations from 15 to 8 validators per epoch, equal to 1,800 validators per day or 657,000 per year.)

For larger operators with many validators, the EIP introduces a new operation, to consolidate existing validators. If desired, up to 64 validators each containing 32ETH can be consolidated into a single large validator with 2048 ETH. This means that an operator with 1000 validators can consolidate them into 16 large validators. The hope is that operators will consolidate their validators into fewer ones, lowering the number of validators on the network, and reducing the network’s computational load.

Getting slashed alone is less scary

MAX_EB also makes the initial slashing penalty very, very cheap, reducing the initial slashing penalty from 1/32 (3.125%) to 1/4096 (0.024%) of the effective balance. As shown in the table below, two fully consolidated 2048 validators being slashed would only result in 1 ETH of losses, representing a 128x reduction compared to pre-Pectra.

Other penalties including offline penalty, correlated slashing penalty, and inactivity leak will also be redesigned in accordance with EB instead of validator count. 

Getting slashed together is still scary

With initial slashing penalties reduced so significantly, you may be thinking, what is left to worry about? One answer, correlated slashing. Correlated slashing can take away the entire effective balance of a validator, and it is still as much of a concern after Pectra activates. Get slashed along with a significant portion of other validators, and everyone gets punished. As shown in the graphic, If between 1% and 33% of validators are slashed at the same time, they will lose between 0.1% and 100% of their validator’s balance. 

Though correlated slashing penalties have never been triggered to date, the entire community needs to work together to prevent a black swan event. Recent bugs in clients like Nethermind and Geth motivated the community to push for improved client diversity, and shows that the Ethereum network is still not as strong as it should be. 

Other types of correlated penalties are also being discussed, with Vitalik outlining earlier this year what a correlation penalty on missed attestations could look like.

Auto-compounding makes upgrading worth it

After Pectra, it’s possible for validators to have an effective balance of anywhere between 32 ETH and 2048 ETH. This means that the calculation for validator rewards and penalties needed to depend on the effective balance. Happily, this makes it possible for a validator to compound its staking rewards. Once a 32 ETH validator produces 1.25 ETH of rewards, it begins to earn more rewards, with an effective balance of 33 ETH, instead of having to wait for another 32 ETH to be earned for a 2nd validator to be spun up. This is a gamechanger for solo stakers with 32 ETH who would otherwise need to wait to earn another 32 ETH to spin up a second validator.

But auto-compounding isn’t just for solo stakers: A large-scale operator responsible for running 8,000 keys currently produces another 32ETH of rewards every 1.5 days. If that ETH isn’t being withdrawn and used to activate new validators, the overall staking yield isn’t optimally efficient. Post-Pectra, the operator could consolidate its 8,000 validators to 128 validators, each with 2000 ETH. This allows the ETH earned from rewards to immediately compound and earn more staking rewards, reducing the need to constantly spin up additional validators. 

Consolidations - an opportunity to migrate infra

Consolidating validators isn’t just about getting access to auto-compounding, it’s an opportunity to move ETH without moving keys. Traditionally, key migrations are risky exercises, but there’s no other way to move active validators to a different machine. So, for an operator with thousands of validator keys active on tens of nodes, carrying out a major infrastructure upgrade meant either accepting extended downtime, or migrating keys and incurring slashing risk.

However, the consolidation mechanism introduced in Pectra changes all this. How do consolidations work? As described in Paritosh’s Pectra FAQ:

“To consolidate validators, send a transaction from your withdrawal address to the consolidation system contract, including the public keys of the source and target validators you wish to consolidate. (Both must be in the “active” state.) During a consolidation, the source validator is completely exited and the balance is then transferred to the target validator. The target validator will have the sum of the balances of the source validator and will continue to perform its beacon chain duties without any change.”

Consolidations are a straightforward process, moving ETH to a new or existing target validator, which could be on a different machine, with different clients, in a different location - a totally different infrastructure stack. Consolidations are therefore a huge opportunity to migrate validators to/from infrastructure stacks and setups.

What type of setup should an operator migrate to, with this opportunity to consolidate?

Future-proof your staking stack with DVs

Distributed validators represent a future-proofed staking setup, and consolidations post-Pectra are the perfect opportunity to migrate stake to DVs. Bring stake to DVs by spinning up a new DV cluster and consolidating stake to it, or by consolidating stake onto existing DVs. 

Key compromise
With now up to 2048 ETH or ~$8m of stake per validator key, individual keys become more important than ever before. The most costly mistakes for node operators in the recent past haven’t been slashing, but key compromise requiring preventative key rotation, which involves exiting an entire set of validators and activating new ones, a process that results in days, weeks, or even months or missed earnings.  

A key feature of Obol distributed validators is distributed key generation (DKG), whereby each node in a cluster generates a key share, preventing the entire validator key from ever existing in one place. This significantly reduces the risk of slashing, but also the risk of key compromise - the compromise of one of the nodes is not an immediate emergency, as a 2/3 majority of keys are required to replicate validator duties and risk slashing. 

Correlated slashing
Distributing a validator across several nodes enables each node to run a different client stack, with its own unique execution, consensus, and validator clients. A bug in any one client would not result in erroneous behavior from the validator, as signatures from >⅔ of nodes are required for the validator client to sign. This should protect DVs from any black swan correlated slashing events that could take place due to a catastrophic client bug.

So, what are you waiting for? Enjoy reduced slashing risk and built-in client diversity, with DVs. Connect with us, or learn more about Obol at obol.org. 

Other EIPs, and their impact for stakers

Here are some other Pectra EIPs which are relevant to node operators and stakers, but less impactful than MAX_EB:

EIP 7549, Move committee index outside attestation (efficiency gains): 
This EIP is expected to reduce CPU load on validator nodes, by refactoring validator attestation messages, making CL client software more efficient and able to aggregate signatures further.

EIP 6110, Supply validator deposits on chain (UX improvement)
By shifting the responsibility of validating new staked ETH deposits from the CL to the EL, this EIP significantly improves the UX of activating a new validator. Gone is the delay of 1,024 blocks (~16 hours) between the deposit of 32 ETH on the EL and the activation of a validator on the CL. The time from deposit to activation will now be as short as 13 minutes, when the activation queue is empty. Read more in this article. 

EIP 7685, General purpose execution layer requests
This code change introduces a framework for the protocol to store smart contract triggered requests for easy processing by the CL. Smart contract-based staking pools, for example, will be able directly trigger validator withdrawals (EIP 7002) and consolidations (EIP 7251) on the CL.

EIP 7002, Execution layer triggerable withdrawals
Operators no longer need to pre-sign exit messages and provide them to delegators, to avoid the possibility of an operator holding delegated ETH hostage. EIP 7002 allows smart contracts to trigger validator exits without the validator operator. This enables staking applications to remove trust assumptions about the honest behavior of their validator node operators, and for the arbitrary withdrawal of staked ether amounts above 32 eth.

EIP-7691, Blob throughput increase
A recent proposal is to increase the target number of blobs per block from 3 to 6, and the maximum number of blobs per block from 6 to 9. Increasing blob throughput is beneficial for layer-2s, but may increase the computational requirements of operating a validator. Developers conducted data-driven research on the health of solo staking operations and decided the blob capacity increase will not significantly raise hardware requirements for Ethereum validating nodes.