The Pectra upgrade is the next major milestone for the Ethereum network and is expected to be implemented in the first quarter of 2025. This upgrade consists of two main parts: the Prague execution layer upgrade and the Electra protocol layer upgrade.
Written by: dwong
The Pectra upgrade is the next major milestone for the Ethereum network and is expected to be implemented in the first quarter of 2025. This upgrade consists of two main parts: the Prague execution layer upgrade and the Electra protocol layer upgrade.
Unlike previous major upgrades, Pectra does not have a single prominent primary goal, but rather focuses on multiple technical improvements and optimizations. This is in contrast to the Dencun upgrade (which significantly reduced L2 fees) or Shapella upgrade (which allowed withdrawals of staked ETH, completing the final step in Ethereum's transition to Proof of Stake (PoS)).
Latest Developments
Recently, Ethereum Core Developers (ACD) discussed the possibility of splitting the Pectra upgrade into two phases in a conference call. According to this proposal:
Pectra upgrades will include the EIPs for pectra-devnet-3 (see below for details).
The originally planned EOF (EVM Object Format) and PeerDAS (Peer Data Availability Sampling) content will be postponed to the next upgrade, tentatively named Fusaka (Fulu + Osaka).
The Verkle Trees content originally planned for Osaka will be further delayed and may be implemented in a subsequent Amsterdam update.
This phased approach is designed to ensure that the scale and complexity of each upgrade remains manageable, while also allowing sufficient time for each technology to be fully tested and refined.
Pectra upgrade related EIPs
Confirmed EIPs included
EIP-2537[1]: Precompilation of BLS12-381 curve operations
EIP-2935[2]: Save historical block hashes in the state
EIP-6110[3]: Providing validator deposits on-chain
EIP-7002[4]: Triggerable Execution Layer Exit
EIP-7251[5]: Increase the maximum effective balance
EIP-7549[6]: Moving committee index out of proof
EIP-7685[7]: Generic Execution Layer Request
EIP-7702[8]: Setting the EOA account code for a transaction
EIPs under consideration
EIP-7212: Support precompile of secp256r1 curve
EIP-7547[9]: Inclusion List
EIP-7623[10]: Increase calldata cost
EIP-7742[11]: Remove the blob count relationship between the consensus layer and the execution layer
Introduction to Key EIPs
EIP-2537: Precompilation of BLS12-381 curve operations
The proposal introduces precompile operations on the BLS12-381 curve, which greatly improves the efficiency of operations such as BLS signature verification. Compared with the existing BN254 precompile, BLS12-381 provides higher security (over 120 bits, while BN254 is only 80 bits). This improvement not only includes basic curve operations, but also integrates multi-exponential operations, laying the foundation for efficient aggregation of public keys and signatures.
EIP-2935: Save historical block hashes in the state
The proposal proposes to store the hashes of the most recent 8192 blocks in the system contract. This change is mainly to support the execution of stateless clients. In this way, stateless clients can more easily obtain necessary historical information while maintaining compatibility with existing BLOCKHASH opcodes. This not only simplifies the storage mechanism of block hash history, but also provides a new way to access historical data.
EIP-6110: Providing validator deposits on-chain
The proposal integrates the process of validator deposits directly into the block structure of the Ethereum execution layer. This change shifts the responsibility for deposit inclusion and verification from the consensus layer to the execution layer, eliminating the need for the consensus layer to vote on deposits (or eth1data). This approach not only improves the security and efficiency of deposit processing by analyzing contract log events of deposit transactions, but also improves the user experience. In addition, it simplifies the design of client software and reduces the complexity of the overall system.
EIP-7002: Triggerable Execution Layer Exits
The proposal introduces a new mechanism that allows validators to trigger withdrawal and exit operations by withdrawing credentials through the execution layer (0x01). The specific implementation is to attach the withdrawal message to the execution layer block, which is then processed by the consensus layer. This approach provides validators with more flexible exit options while maintaining the security and consistency of the system.
EIP-7251: Increase the maximum valid balance
The proposal aims to increase the maximum effective balance (MAX_EFFECTIVE_BALANCE) of Ethereum validators while keeping the minimum staked balance at 32 ETH. This change has multiple benefits:
Allows large node operators to consolidate into fewer validators, improving operational efficiency.
Providing small stakers with the opportunity to earn compound interest rewards, increasing the attractiveness of staking.
Provide more flexible staking options to attract more participants.
Reduce redundant validators in the network and reduce the number of P2P messages.
Reduce the memory usage of BeaconState and improve system efficiency.
Cooperate with the partial withdrawal mechanism of the enhanced execution layer to further optimize the liquidity of the entire Ethereum network.
EIP-7549: Moving committee index out of proof
The proposal proposes to remove the committee's index field from signed attestation messages to enable aggregation of identical consensus votes. The main goal of this change is to improve the efficiency of the Casper FFG client by reducing the average number of pairs required to verify consensus rules. While all types of clients can benefit from this improvement, this change will likely result in the most significant performance improvements for ZK circuits that need to prove Casper FFG consensus.
EIP-7685: Generic Execution Layer Request
The proposal defines a general framework for storing and processing requests triggered by smart contracts. The specific implementation is to add a field in the execution header and body to store request information, thereby exposing these requests to the consensus layer, allowing it to process each request. This mechanism is designed mainly to cope with the increasing demand for validators controlled by smart contracts and to provide a foundation for more complex on-chain interactions in the future.
EIP-7702: Set EOA account code for a transaction
EIP-7702, proposed by Vitalik Buterin and others, aims to improve Ethereum's account abstraction. The proposal introduces a new transaction type that allows externally owned accounts (EOA) to set account codes through an authorization mechanism. This improvement supports several new features:
Batch operations: Allow EOA to perform multiple operations in the same transaction, improving efficiency.
Payment on behalf of others: Provides convenience for third parties to pay transaction fees.
Privilege downgrade: Enhance account security and flexibility.
By adopting a new transaction structure, the proposal not only improves the functionality and usability of EOA, but also provides good compatibility and scalability for future account abstraction technologies.
Conclusion
Although the Pectra upgrade does not have a prominent main goal, it will further enhance the functionality, security, and efficiency of the Ethereum network through a series of technical improvements and optimizations. As the upgrade plan progresses, we may see more EIPs being incorporated or adjusted.
References
EIP-7600: Pectra Hard Fork Metadata[12]
Ethereum Core Developers Consensus Layer Meeting #197[13]
[1]EIP-2537: https://eips.ethereum.org/EIPS/eip-2537
[2]EIP-2935: https://eips.ethereum.org/EIPS/eip-2935
[3]EIP-6110: https://eips.ethereum.org/EIPS/eip-6110
[4]EIP-7002: https://eips.ethereum.org/EIPS/eip-7002
[5]EIP-7251: https://eips.ethereum.org/EIPS/eip-7251
[6]EIP-7549: https://eips.ethereum.org/EIPS/eip-7549
[7]EIP-7685: https://eips.ethereum.org/EIPS/eip-7685
[8]EIP-7702: https://eips.ethereum.org/EIPS/eip-7702
[9]EIP-7547: https://eips.ethereum.org/EIPS/eip-7547
[10]EIP-7623: https://eips.ethereum.org/EIPS/eip-7623
[11]EIP-7742: https://eips.ethereum.org/EIPS/eip-7742
[12] EIP-7600: Pectra Hard Fork Metadata: https://eips.ethereum.org/EIPS/eip-7600
[13] Ethereum Core Developers Consensus Call #197: https://www.galaxy.com/insights/research/ethereum-all-core-developers-execution-call-197/
