Pectra Overview

The Pectra network upgrade is scheduled to activate on Ethereum testnets!

It will go live on Holesky at epoch 115968 (Feb. 24, 21:55 UTC) and then on Sepolia at epoch 222464 (Mar. 5, 7:29 UTC). The Pectra testnet client releases are listed below. Once both testnets have successfully upgraded, a mainnet activation epoch will be chosen.

Pectra follows last year's Dencun upgrade. It introduces features to augment Ethereum accounts, improve the validator experience, support L2 scaling, and more!

This post explores these three major improvements in detail. For a more comprehensive overview, see ethereum.org's guide to the upgrade.

From EOAs to Smart Accounts

EIP-7702 represents a major step toward widespread account abstraction, enabling users to enhance their Externally Owned Accounts (EOAs) with smart contract functionality.

This hybrid approach combines the simplicity of EOAs with the programmability of contract-based accounts. In practice, it enables:

• Transaction batching, where multiple operations execute atomically within a single transaction. No more separate transactions for "approve" and "swap"!

• Gas sponsorship, which allows others to pay for transaction fees. This is especially useful when wanting to transact from an account that doesn't have ETH in it.

• Alternative authentication, which means many hardware security modules (HSMs) in phones today can be used to authorize operations for the account via technologies like passkeys.

• Spending controls, which can limit how many tokens a specific application can spend, or cap daily outflows from a wallet, improving security.

• Recovery mechanisms, which provide different options for users to safeguard their assets, without migrating to a new account.

To use EIP-7702, an EOA signs an authorization pointing to a specific delegation address whose code it wants to execute. Once set, the account gains the new code’s capabilities (e.g., batching, sponsorship, authentication logic, etc.). Because choosing a delegation target hands over a great deal of control, EIP-7702 enforces several safety checks:

• Chain-specific delegations: by default, a delegation is only valid on a specific chain ID, preventing the same authorization from being used on different networks.

• Nonce-bound delegations: authorizations can be tied to the account's current nonce, automatically invalidating them once the nonce increases.

• Revocability: the owner of the EOA can always create another EIP-7702 authorization that revokes or replaces the existing delegation code, preventing a permanent lock-in if something goes wrong.

For a deeper dive into how this all works, see @lightclient's Devcon talk on the topic.

Validator UX Improvements

Three new EIPs within Pectra improve the validator experience: 7251, 7002 and 6110.

The first, EIP-7251, raises the maximum balance a validator can receive rewards on from 32 ETH to 2048 ETH, through an opt-in update of withdrawal credential type.

For smaller stakers, this enables automatic reward compounding. Previously, any rewards earned beyond a validator's 32 ETH deposit would not count towards their active stake. Stakers who wanted to stake more than 32 ETH could only do so in fixed 32 ETH increments, relying on staking pools for anything in between. With EIP-7251, both existing and new validators can be configured to earn rewards on the entirety of their stake, up to 2048 ETH per validator.

This EIP also allows larger operators to consolidate multiple validators, by merging those with shared withdrawal credentials. This reduces the bandwidth requirement for the network as a whole. To understand the mechanics in detail, watch this talk from Teku's Paul Harris.

EIP-7002 also extends validators' abilities, this time by introducing execution layer triggerable withdrawals. Prior to this EIP, only a validator's active signing key could trigger an exit. Now, if an Ethereum address is set as a withdrawal credential, that too can force an exit. This reduces trust assumptions in delegation settings, as the owner of the funds -- be they a human in control of an EOA or a DAO-managed smart contract -- can always trustlessly initiate an exit.

Lastly, EIP-6110 removes a lingering vestige of pre-merge Ethereum: the delay between validator deposits and their addition to the deposit queue. Pre-merge, the Beacon Chain had to wait 2048 blocks before processing validator deposits to account for potential proof-of-work re-orgs. This is no longer necessary!

With EIP-6110, deposit processing delays now drop from around 9 hours to roughly 13 minutes. Teku engineers Lucas Saldanha and Stefan Bratanov covered the details of EIP-7002 and EIP-6110 in their joint Devcon SEA talk.

Blob Scaling .oO

The final major change in Pectra is EIP-7691, increasing Ethereum’s blob capacity by 50%!

Blobs, introduced in the Dencun upgrade, are ephemeral data storage that L2s can use to submit compressed transaction data and proofs to Ethereum L1. Since going live, they've reduced L1 fees for L2s by 10-100x, resulting in far cheaper L2 user transactions.

The Ethereum mainnet currently supports an average of 3 blobs per block, with a maximum of 6 to accommodate periods of high demand. With EIP-7691, these numbers will increase to an average of 6 and maximum of 9.

Unlike CALLDATA, which nodes store indefinitely, blobs are pruned from the network after 4096 epochs (~18 days). This bounds the amount of disk space they can use. The binding constraint for blobs is instead bandwidth, as blobs need to be gossiped over Ethereum's peer-to-peer layer. To offset the bandwidth increase caused by EIP-7691, Pectra also introduces EIP-7623, which caps the worst-case size of a block.

To continue scaling Ethereum’s data throughput without a corresponding rise in bandwidth requirements, we must shift from a world where every node stores every blob to one where nodes store only a subset and sample the network to verify the remaining blob data. Good news: work to support this is already underway! Francesco from the Ethereum Foundation research team outlined this scaling roadmap in his devcon keynote.

Pectra Specifications

The list of changes introduced in Pectra can be found in EIP-7600. For reference, they are:

• EIP-2537: Precompile for BLS12-381 curve operations

• EIP-2935: Save historical block hashes in state

• EIP-6110: Supply validator deposits on chain

• EIP-7002: Execution layer triggerable exits

• EIP-7251: Increase the MAX_EFFECTIVE_BALANCE

• EIP-7549: Move committee index outside Attestation

• EIP-7623: Increase calldata cost

• EIP-7685: General purpose execution layer requests

• EIP-7691: Blob throughput increase

• EIP-7702: Set EOA account code

• EIP-7840: Add blob schedule to EL config files

Additionally, full python specification for the changes to the execution and consensus layer specifications can be found in the following releases:

• Execution layer: v1.17.0rc6.dev1

• Consensus layer: Oricorio (v1.5.0-beta.2)

Lastly, Pectra also introduces changes to the Engine API used for communication between the consensus and execution layer nodes. These are specified in the prague.md file of the repository.

Pectra Activation

The Pectra network upgrade will activate on Holesky and Sepolia as follows:

Additionally, Pectra has already been activated on Ephemery, a staking testnet which resets every 28 days. Read more about it here.

Client Releases

The following client releases are suitable for the Pectra upgrade on both Holesky and Sepolia. Further versions will activate support on mainnet. Once these are released, another announcement will be made on this blog.

Consensus Layer Sepolia & Holesky Releases

When running a validator, both the Consensus Layer Beacon Node and Validator Client must be updated.

Note: the Grandine client was open-sourced in April 2024. Since then, it has been included in all Pectra testing efforts alongside other clients.

Execution Layer Sepolia & Holesky Releases

FAQ

How do Ethereum network upgrades work?

Ethereum network upgrades require explicit opt-in from node operators on the network. While client developers come to consensus on what EIPs are included in an upgrade, they are not the ultimate deciders of its adoption.

For the upgrade to go live, validators and non-staking nodes must manually update their software to support the protocol changes being introduced.

If they use an Ethereum client that is not updated to the latest version (listed above), at the fork block, it will disconnect from upgraded peers, leading to a fork on the network. In this scenario, each subset of the network nodes will only stay connected with those who share their (un)upgraded status.

While most Ethereum upgrades are non-contentious and cases leading to forks have been rare, the option for node operators to coordinate on whether to support an upgrade or not is a key feature of Ethereum's governance.

For a more exhaustive overview of Ethereum's governance process, see this talk by Tim Beiko.

As an Ethereum mainnet user or $ETH holder, is there anything I need to do?

In short, no.

This announcement only pertains to Ethereum testnets: Holesky and Sepolia. A further announcement will be made for Pectra's activation on the Ethereum mainnet, but even then, Ethereum mainnet users and $ETH holders are not expected to have to take action.

If you'd like to watch the upgrade go live on Holesky, EthStaker is hosting an online viewing party!

As a non-staking Sepolia or Holesky node operator, what do I need to do?

To be compatible with the upgrade on either testnet, update your node's execution and consensus layer clients to the versions listed in the table above.

As a Sepolia or Holesky staker, what do I need to do?

To be compatible with the upgrade on either testnet, update your node's execution and consensus layer clients to the versions listed in the table above. Make sure both your beacon node and validator client are updated.

As a non-Sepolia or Holesky node operator or staker, what do I need to do?

Nothing for now. Further announcements will be made for Pectra's activation on mainnet.

As an application or tooling developer, what should I do?

Review the EIPs included in Pectra to determine if and how they affect your project --- there are many new exciting features being introduced across both the execution and consensus layers!

As a security researcher, what should I do?

Keep an eye out for a post about the Pectra bug bounty competition coming soon 👀

Why "Pectra"?

Upgrades to the execution layer follow Devcon city names, and those to the consensus layer use star names. "Pectra" is the combination of Prague, the location of Devcon IV, and Electra, a blue-white giant star in the constellation of Taurus.

Original cover image by Julia Solonina, with modifications by Tomo Saito.