Understanding Ethereum’s Pectra: The Next Major Upgrade

The Pectra upgrade represents a significant milestone for the Ethereum network, scheduled for implementation in Q1 2025. This upgrade consists of two main components: the Prague execution layer upgrade and the Electra protocol layer upgrade.

Unlike previous major upgrades, Pectra lacks a singular, prominent goal, focusing instead on multiple technical enhancements and optimizations. This differentiates it from the Dencun upgrade, which aimed to drastically reduce Layer 2 fees, and the Shapella upgrade, which facilitated the withdrawal of staked ETH, completing Ethereum’s transition to Proof of Stake (PoS).

Recent Developments

Recently, Ethereum’s All Core Developers (ACD) discussed the possibility of splitting the Pectra upgrade into two phases. According to this proposal:

• The upgrade will incorporate EIPs from pectra-devnet-3.
• Originally planned content related to the EOF (EVM Object Format) and PeerDAS (Peer Data Availability Sampling) will be postponed to the next upgrade, tentatively named Fusaka.
• Aspects related to Verkle Trees, initially scheduled for the Osaka upgrade, will be further delayed and may be included in a future Amsterdam upgrade.

This phased approach aims to keep the scale and complexity of each upgrade manageable, allowing ample time for thorough testing and refinement of each technology.

EIPs Associated with the Pectra Upgrade

Confirmed EIPs

• EIP-2537: Precompiled operations for the BLS12-381 curve
• EIP-2935: Storing historical block hashes in state
• EIP-6110: Providing validator deposits on-chain
• EIP-7002: Triggerable execution layer exit
• EIP-7251: Increasing the maximum effective balance
• EIP-7549: Removing committee index from proofs
• EIP-7685: General execution layer requests
• EIP-7702: Setting EOA account code for a transaction

EIPs Under Consideration

• EIP-7212: Precompiled support for the secp256r1 curve
• EIP-7547: Inclusion lists
• EIP-7623: Increasing calldata costs
• EIP-7742: Decoupling blob count relations between consensus and execution layers

Key EIP Summaries

EIP-2537: Precompiled Operations for the BLS12-381 Curve

This proposal introduces precompiled operations on the BLS12-381 curve, significantly enhancing the efficiency of BLS signature verification. Compared to the existing BN254 precompiles, BLS12-381 offers superior security (over 120 bits versus 80 bits). The proposal includes not just basic curve operations but also multi-exponentiation, laying the groundwork for efficient aggregation of public keys and signatures.

EIP-2935: Storing Historical Block Hashes

This proposal recommends storing the hashes of the last 8,192 blocks in a system contract to support stateless client execution. By doing so, stateless clients can easily access essential historical data while maintaining compatibility with the existing BLOCKHASH opcode.

EIP-6110: On-Chain Validator Deposits

This change integrates the validator deposit process directly into Ethereum’s execution layer block structure, shifting the responsibility for inclusion and verification from the consensus layer to the execution layer. This enhances security and efficiency in handling deposits and simplifies client software design.

EIP-7002: Triggerable Execution Layer Exit

This proposal introduces a new mechanism allowing validators to trigger withdrawal and exit operations through the execution layer. By attaching withdrawal messages to execution layer blocks, this offers validators more flexibility while ensuring system security.

EIP-7251: Increasing Maximum Effective Balance

The aim of this proposal is to raise the maximum effective balance (MAX_EFFECTIVE_BALANCE) for Ethereum validators while maintaining a minimum staking balance of 32 ETH. This change would improve operational efficiency for large node operators and attract more participants by offering flexible staking options.

EIP-7549: Removing Committee Index from Proofs

This proposal suggests removing the committee index field from signature proof messages to enable the aggregation of votes with the same consensus. This change primarily targets efficiency improvements for Casper FFG clients.

EIP-7685: General Execution Layer Requests

This proposal outlines a framework for storing and processing requests triggered by smart contracts, facilitating more complex on-chain interactions.

EIP-7702: Setting EOA Account Code

Proposed by Vitalik Buterin and others, this EIP optimizes Ethereum’s account abstraction by allowing externally owned accounts (EOAs) to set account codes through an authorization mechanism. This change supports batch operations and payment delegation.

Conclusion

While Pectra does not feature a singular major objective, it aims to enhance Ethereum’s functionality, security, and efficiency through a series of technical improvements. As the upgrade progresses, we can expect more EIPs to be included or adjusted, paving the way for a more robust Ethereum network.