Interpretation of Ethereum Pectra: The next major upgrade

The Pectra upgrade is the next important milestone for the Ethereum network and is expected to be implemented in the first quarter of 2025.This upgrade includes 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 technological improvements and optimizations.This contrasts with the Dencun upgrade (a substantial reduction in L2 fees) or the Shapella upgrade (available for staking ETH withdrawals, completing the final step in Ethereum’s transition to Proof of Stake (PoS).

Latest progress

Recently, Ethereum Core Developers (ACD, All Core Developers) 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 EIPs of pectra-devnet-3 (see below for details).

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

3. The Verkle Trees related content originally planned to be implemented in Osaka (Osaka) will be further postponed and may be implemented in subsequent Amsterdam (Amsterdam) upgrades.

This phased approach aims to ensure that the scale and complexity of each upgrade remains within a controllable range, while also leaving enough time for the full testing and improvement of various technologies.

Pectra upgrade related EIPs

Confirmed included EIPs

1. EIP-2537^[1]: BLS12-381 Precompilation of curve operation

2. EIP-2935^[2]: Save the historical block hash in the state

3. EIP-6110^[3]: Provide verifier deposits on the chain

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

5. EIP-7251^[5]: Increase the maximum effective balance

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

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

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

EIPs under consideration

• EIP-7212: Supports precompilation of secp256r1 curve

• EIP-7547^[9]: Include list

• EIP-7623^[10]: Increase calldata cost

• EIP-7742^[11]: Decompress the blob count relationship between the consensus layer and the execution layer

Key EIP Introduction

EIP-2537: Precompilation of BLS12-381 Curve Operation

This proposal introduces precompilation operations on the BLS12-381 curve, greatly improving the efficiency of operations such as BLS signature verification.Compared to existing BN254 precompilation, the BLS12-381 provides greater security (over 120 bits, compared to only 80 bits for the BN254).This improvement not only includes basic curve operations, but also integrates multiple exponential operations, laying the foundation for efficient aggregation of public keys and signatures.

EIP-2935: Save historical block hash in state

The proposal proposes to store the hashes of the last 8192 blocks in the system contract, a change that is mainly to support stateless client execution.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 new ways to access historical data.

EIP-6110: Provide verifier deposits on the chain

The proposal integrates the process of validator deposits directly into the block structure of the Ethereum execution layer.This change shifts the inclusion and verification responsibility of deposits from the consensus layer to the execution layer, eliminating the need for the consensus layer to vote on deposits (or eth1data).Generating deposit lists by analyzing contract log events for deposit transactions, this approach not only improves the security and efficiency of deposit processing, 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 exit

The proposal introduces a new mechanism that allows validators to trigger retraction and exit operations through the execution layer (0x01) withdrawal of credentials.The specific implementation is to append the withdrawal message to the execution layer block and then process it by the consensus layer.This approach provides validators with more flexible exit options while maintaining system security and consistency.

EIP-7251: Increase the maximum effective balance

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

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

2. Provide small pledges with the opportunity to receive compound interest rewards and increase the attractiveness of pledges.

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

4. Reduce redundant validators in the network and reduce the number of P2P messages.

5. Reduce BeaconState’s memory usage and improve system efficiency.

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

EIP-7549: Move the committee index out of the proof

The proposal recommends removing the committee’s index field from the signed proof message to achieve aggregation of the same consensus vote.The main goal of this change is to increase the efficiency of the Casper FFG client by reducing the average number of pairs required to validate consensus rules.While all types of clients can benefit from this improvement, this change may lead to the most significant performance improvement for ZK circuits that need to prove the Casper FFG consensus.

EIP-7685: General Execution Layer Request

The proposal defines a common framework for storing and processing requests triggered by smart contracts.The specific implementation is to add a field to each of the execution header and the body to store the request information, thereby exposing these requests to the consensus layer, allowing them to process each request.This mechanism is designed mainly to cope with the increasing demands of smart contract control validators and provide a foundation for more complex on-chain interactions in the future.

EIP-7702: Set up EOA Account Code for a Transaction

EIP-7702 proposed by Vitalik Buterin et al. aims to optimize the account abstraction of Ethereum.The proposal introduces a new type of transaction that allows externally owned accounts (EOA) to set up account codes through an authorization mechanism.This improvement supports several new features:

1. Batch Operations: Allows EOA to perform multiple operations in the same transaction to improve efficiency.

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

3. Permission downgrade: Enhance the security and flexibility of your account.

By adopting a new transaction structure, the proposal not only improves the functionality and availability 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 technological improvements and optimizations.As the upgrade plan advances, we may see more EIPs being incorporated or adjusted.