Decoding Ethereum Pectra: The next major upgrade

The Pectra upgrade is the next major milestone for the Ethereum network and is expected to be implemented in Q1 2025. The upgrade consists of two main parts: Prague execution layer upgrade and Electra protocol layer upgrade.

Unlike previous major upgrades, Pectra does not have a prominent main goal, but 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 of Ethereum's transition to Proof of Stake (PoS)).

Recent Progress

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

1. The Pectra upgrade will include the EIPs of pectra-devnet-3 (see below).

2. The EOF (EVM Object Format) and PeerDAS (Peer Data Availability Sampling) content originally planned will be postponed to the next upgrade, tentatively named Fusaka (Fulu + Osaka).

3. Verkle Trees related content originally planned for Osaka will be further postponed and may be implemented in the subsequent Amsterdam upgrade.

This phased approach is designed to ensure that the size and complexity of each upgrade remains within a manageable range, while also allowing enough time for each technology to be fully tested and improved.

Pectra upgrade related EIPs

Confirmed included EIPs

1. EIP-2537^[1]：Precompile of BLS12-381 curve operation

2. EIP-2935^[2]：Store historical block hashes in the state

3. EIP-6110^[3]：Provide validator deposits on the chain

4. EIP-7002^[4]：Triggerable execution layer exit

5. [5]: Increase maximum valid balance

6. EIP-7549^[6]: Move committee index out of proof

7. EIP-7685^[7]: Generic execution layer request

8. EIP-7702^[8]: Set EOA account code for a transaction

EIPs under consideration

• EIP-7212: Support precompiles for the 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: Precompile of BLS12-381 curve operations

This proposal introduces precompile operations on the BLS12-381 curve, greatly improving the efficiency of operations such as BLS signature verification. Compared to the existing BN254 precompilation, 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 the 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

This proposal integrates the process of validator deposits directly into the block structure of the Ethereum execution layer. This change shifts the responsibility for the inclusion and verification of deposits 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, but also improves the user experience by analyzing the contract log events of deposit transactions. In addition, it simplifies the design of client software and reduces the complexity of the overall system.

EIP-7002: Triggerable Execution Layer Exit

This 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 Maximum Effective Balance

This proposal aims to increase the maximum effective balance (MAX_EFFECTIVE_BALANCE) of Ethereum validators while maintaining the minimum staked balance of 32 ETH. This change has multiple benefits:

1. Allows large node operators to merge into fewer validators, improving operational efficiency.

2. Provides opportunities for small stakers to earn compounding rewards, increasing the attractiveness of staking.

3. Provides more flexible staking options to attract more participants.

4. Reduces redundant validators in the network and reduces the number of P2P messages.

5. Reduce the memory footprint of BeaconState and improve system efficiency.

6. In conjunction with the enhanced execution layer's partial withdrawal mechanism, further optimize the liquidity of the entire Ethereum network.

EIP-7549: Move committee index out of proof

This proposal proposes to remove the committee's index field from the signed proof message to achieve aggregation of votes for the same consensus. The main 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. Although all types of clients can benefit from this improvement, this change may bring the most significant performance improvement for ZK circuits that need to prove Casper FFG consensus.

EIP-7685: Generic Execution Layer Request

This 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 the 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 provide a basis 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 optimize Ethereum's account abstraction. The proposal introduces a new transaction type that allows externally owned accounts (EOAs) to set account codes through an authorization mechanism. This improvement supports several new features:

1. Batch operations: Allow EOA to perform multiple operations in the same transaction, improving efficiency.

2. Payment on behalf of transactions: Provide convenience for third parties to pay transaction fees.

3. Permission downgrade: Enhance the security and flexibility of accounts.

By adopting a new transaction structure, this 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.