The Pectra upgrade is the next significant milestone for the Ethereum network, expected to be implemented in the first quarter of 2025. This upgrade consists of two main components: the Prague (execution layer) upgrade and the Electra (protocol layer) upgrade.

Unlike previous major upgrades, Pectra does not have a singular prominent goal; instead, it focuses on multiple technological improvements and optimizations. This contrasts with the Dencun upgrade (which significantly reduced L2 fees) and the Shapella upgrade (which allowed for the withdrawal of staked ETH, completing Ethereum’s transition to Proof of Stake (PoS)).

Latest developments

Recently, Ethereum core developers (ACD, All Core Developers) discussed the possibility of splitting the Pectra upgrade into two phases during a conference call. According to this proposal:

1. The Pectra upgrade will include the EIPs from pectra-devnet-3 (detailed below).
2. The originally planned EOF (EVM Object Format) and PeerDAS (Peer Data Availability Sampling) components will be postponed to the next upgrade, tentatively named Fusaka (Fulu + Osaka).
3. Content related to Verkle Trees, initially planned for implementation in Osaka, will be further delayed and may be realized in a subsequent upgrade named Amsterdam.

This phased approach aims to keep the scale and complexity of each upgrade manageable while allowing sufficient time for thorough testing and refinement of the various technologies.

Pectra upgrade related EIPs

EIPs identified for inclusion

1. EIP-2537^[1]: Precompiled operations for the BLS12-381 curve
2. EIP-2935^[2]: Saving historical block hashes in state
3. EIP-6110^[3]: Providing validator deposits on-chain
4. EIP-7002^[4]: Triggerable execution layer exit
5. EIP-7251^[5]: Increasing maximum effective balance
6. EIP-7549^[6]: Moving committee index out of proofs
7. EIP-7685^[7]: General execution layer requests
8. EIP-7702^[8]: Setting EOA account code for a transaction

EIPs under consideration

• EIP-7212: Precompiled operations for the secp256r1 curve
• EIP-7547^[9]: Inclusion list
• EIP-7623^[10]: Increasing calldata costs
• EIP-7742^[11]: Decoupling the blob count relationship between the consensus layer and execution layer

Introduction to key EIPs

EIP-2537: Precompiled operations for the BLS12-381 curve

This proposal introduces precompiled operations on the BLS12-381 curve, significantly improving the efficiency of operations like BLS signature verification. Compared to the existing BN254 precompiled operations, BLS12-381 offers higher security (over 120 bits, while BN254 only provides 80 bits). This improvement includes not only basic curve operations but also integrates multi-exponentiation, laying the foundation for efficient aggregation of public keys and signatures.

EIP-2935: Saving historical block hashes in state

This proposal suggests storing the hashes of the most recent 8,192 blocks in a system contract, primarily to support the execution of stateless clients. This way, stateless clients can more easily access the necessary historical information while maintaining compatibility with the existing BLOCKHASH opcode. This change simplifies the storage mechanism for block hash history and provides a new approach for accessing historical data.

EIP-6110: Providing validator deposits on-chain

This proposal directly integrates the process of validator deposits into the block structure of the Ethereum execution layer. This change shifts the responsibility for including and verifying deposits from the consensus layer to the execution layer, eliminating the need for the consensus layer to vote on deposits (or eth1data). By generating a list of deposits through analyzing contract log events from deposit transactions, this method not only enhances the security and efficiency of deposit processing but also improves user experience. Additionally, it simplifies the design of client software and reduces the overall complexity of the system.

EIP-7002: Triggerable execution layer exit

This proposal introduces a new mechanism that allows validators to withdraw their credentials through the execution layer (0x01) to trigger withdrawal and exit operations. Specifically, the withdrawal message is attached to the execution layer block and 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 maximum effective balance

This proposal aims to increase the maximum effective balance (MAX_EFFECTIVE_BALANCE) for Ethereum validators while maintaining the minimum staking balance at 32 ETH. This change offers multiple benefits:

1. It allows large node operators to consolidate into fewer validators, improving operational efficiency.
2. It provides small stakers with the opportunity to earn compound rewards, making staking more attractive.
3. It offers more flexible staking options, attracting a broader range of participants.
4. It reduces redundant validators in the network, decreasing the volume of P2P messages.
5. It decreases the memory footprint of BeaconState, enhancing system efficiency.
6. Coupled with the enhanced withdrawal mechanism for the execution layer, it further optimizes the liquidity of funds across the entire Ethereum network.

EIP-7549: Moving the committee index out of proofs

This proposal suggests removing the index field of the committee from the signed proof messages to enable the aggregation of the same consensus votes. The primary goal of this change is to improve the efficiency of Casper FFG clients by reducing the average number of pairings required to verify consensus rules. While all types of clients can benefit from this improvement, it is expected to provide the most significant performance enhancement for ZK circuits that need to prove Casper FFG consensus.

EIP-7685: General execution layer requests

This proposal defines a general framework for storing and processing requests triggered by smart contracts. The specific implementation adds a field to both the execution header and body to store request information, thereby exposing these requests to the consensus layer and allowing it to handle each request. This mechanism is designed primarily to address the increasing demand for validator control by smart contracts and to provide a foundation for more complex on-chain interactions in the future.

EIP-7702: Setting EOA Account Code for a Transaction

Proposed by Vitalik Buterin and others, EIP-7702 aims to optimize account abstraction on Ethereum. This proposal introduces a new transaction type that allows externally owned accounts (EOAs) to set account code through an authorization mechanism. This improvement supports several new features:

1. Batch operations: Allows EOAs to perform multiple operations within a single transaction, improving efficiency.
2. Fee payment transactions: Facilitates third parties covering transaction fees.
3. Permission degradation: Enhances the security and flexibility of accounts.

By adopting a new transaction structure, this proposal not only enhances the functionality and usability of EOAs 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 plans progress, we may see more EIPs incorporated or adjusted.

References

• EIP-7600: Pectra hard fork metadata^[12]
• Ethereum Core Developer Consensus Layer Meeting #197^[13]

References

[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 Developer Consensus Layer Meeting #197:https://www.galaxy.com/insights/research/ethereum-all-core-developers-execution-call-197/

Statement:

1. This article is reproduced from[dwong], original title “Interpreting Ethereum Pectra: The Next Major Upgrade”, copyright Attribution to original author [dwong], if you have any objection to the reprint, please contact Gate Learn Team, the team will handle it as soon as possible according to relevant procedures.

2. Disclaimer: The views and opinions expressed in this article represent only the author’s personal views and do not constitute any investment advice.

3. Other language versions of the article are translated by the Gate Learn team and are not mentioned in Gate.io, the translated article may not be reproduced, distributed or plagiarized.