HomeEIPsNewsletter

Pectra Upgrade

Enhancements to Ethereum's Performance and User Experience

The Pectra upgrade includes several key EIPs such as EIP-7251, EIP-7702, and EIP-7002. These improvements aim to optimize Ethereum staking management, simplify account interactions, and lay the foundation for more complex operations.

Pectra Upgrade

Pectra Mainnet Fork NFT

Free Non-transferable NFT

Minting is available within three days after the Pectra upgrade goes live.
nft

What is the Pectra Upgrade?

Pectra follows last year's Dencun upgrade. It introduces features to augment Ethereum accounts, improve the validator experience, support L2 scaling, and more. The name "Pectra" is a combination of Prague and Electra. Prague represents the upgrade to the execution layer, named after the city where Ethereum's developer conference (Devcon 4) was held, while Electra symbolizes the upgrade to the consensus layer, named after a star corresponding to the letter "E." The core aspects of the Pectra upgrade include: increasing the individual validator staking limit from 32 ETH to 2048 ETH; allowing externally owned accounts (EOA) to temporarily authorize the execution of smart contract code within a single transaction, supporting features such as batch transactions and gas payment delegation; and enabling direct control of validator exits via execution layer addresses, eliminating the need for pre-signed BLS keys.

Related EIPs for this upgrade

EIP 2537
Precompile for BLS12-381 curve operations
This proposal defines a standard for implementing BLS12-381 curve operations in Ethereum. It specifies a set of precompiled contracts to perform these operations efficiently on the Ethereum Virtual Machine (EVM). This is an important step towards improving the security and efficiency of cryptographic operations on the Ethereum network.
Learn more
EIP 2935
Save historical block hashes in state
EIP-2935 proposes storing the last 8192 block hashes in a system contract to support stateless clients in Ethereum. This enables clients to access recent block hashes without storing them locally. It introduces a ring buffer for efficient retrieval and doesn't change how the BLOCKHASH function works. The goal is to make it easier for stateless clients and rollups to access historical block data.
Learn more
EIP 6110
Supply validator deposits on chain
This proposal adds validator deposits directly to the Execution Layer block, shifting the responsibility for deposit inclusion and validation from the Consensus Layer to the Execution Layer. This removes the need for deposit voting in the Consensus Layer and simplifies the deposit processing, improving validator UX and security. The list of validator deposits in a block is derived from deposit contract log events. The proposal introduces minimal data complexity and does not increase the risk of DoS attacks on the Execution Layer.
Learn more
EIP 7002
Execution layer triggerable exits
EIP-7002 allows validators to trigger withdrawals using their execution layer (0x01) withdrawal credentials, not just the active key. This enables the owner of the withdrawal credentials to independently exit and withdraw staked ETH, even if the active key is lost. The system includes a contract that queues requests, applies dynamic fees to prevent abuse, and processes them in each block.
Learn more
EIP 7251
Increase the MAX_EFFECTIVE_BALANCE
Increase MAX_EFFECTIVE_BALANCE while keeping the 32 ETH minimum staking balance. This change allows larger validators to consolidate into fewer validators and gives smaller validators the ability to stake in more flexible increments. The goal is to reduce the validator set size, improve network efficiency, and allow both small and large validators to benefit from compounding rewards.
Learn more
EIP 7549
Move committee index outside Attestation
EIP-7549 proposes moving the committee index outside of the signed Attestation message to improve efficiency in Casper FFG clients. This change reduces the number of pairings needed to verify consensus rules and lowers the number of attestations required to reach a 2/3 threshold. By separating the committee index, the proposal also allows more efficient packing of attestations into beacon blocks, increasing the total voting capacity.
Learn more
EIP 7623
Increase calldata cost
Increasing the calldata cost for transactions that predominantly post data, aiming to reduce the maximum block size and improve block space efficiency. By raising calldata costs from 4/16 to 10/40 gas per byte for data-heavy transactions, the proposal limits the block size without affecting most users, who typically rely on calldata for EVM operations. This change will reduce the maximum Execution Layer payload size, allowing more blobs in preparation for EIP-4844.
Learn more
EIP 7685
General purpose execution layer requests
This proposal introduces a general-purpose framework to store and share contract-triggered requests between the Execution Layer and Consensus Layer. The approach simplifies the addition of new request types, enhances flexibility, and improves overall system safety by delegating operations to smart contracts.
Learn more
EIP 7691
Blob throughput increase
Increase the number of blobs per block on Ethereum to 6 (with a max of 9) to boost scalability for Layer 2 solutions. This change aims to improve throughput in the short term, based on test results and network monitoring, and adjusts the base fee update to balance the impact.
Learn more
EIP 7702
Set EOA account code
Introducing a new transaction type aimed at enhancing the functionality of Externally Owned Accounts (EOAs) by allowing them to delegate execution of code to other addresses in a more flexible and controlled manner. The transaction type, known as the Set Code Transaction, allows a signing account to specify a list of authorization tuples, each containing a delegation designator pointing to a code address.
Learn more
EIP 7840
Add blob schedule to EL config files
Adds a new configuration object, blobSchedule, to Execution Layer client configuration files. The goal is to dynamically adjust blob parameters and improve the responsiveness of blob gas pricing, without relying on complex interactions over the engine API.
Learn more

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, 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.

Serve Ethereum Builders, Scale the Community.
Resources
GitHub
Community
Supported by
ETHPanda
LXDAO
Plancker