Pectra upgrade is the next important milestone for the Ethereum network, 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.

By dwong

Pectra upgrade is the next important milestone for the Ethereum network, 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 prominent main goal, but instead focuses on multiple technical improvements and optimizations. This contrasts with the Dencun upgrade (significant reduction in L2 fees) or the Shapella upgrade (allowing ETH staking withdrawals, completing the final step of 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 of pectra-devnet-3 (see below).
2. 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).
3. The Verkle Trees-related content originally planned to be implemented in Osaka will be further delayed and may be realized in the subsequent Amsterdam upgrade.

This phased approach aims to ensure that the scale and complexity of each upgrade remain within manageable limits, while also allowing sufficient time for comprehensive testing and refinement of each technology.

Pectra Upgrade-related EIPs

Confirmed Included EIPs

1. EIP-2537[1]: Precompile for BLS12-381 curve operations
2. EIP-2935[2]: Store historical block hashes in state
3. EIP-6110[3]: On-chain validator deposits
4. EIP-7002[4]: Triggerable execution layer exits
5. EIP-7251[5]: Increase maximum effective balance
6. EIP-7549[6]: Remove committee index from proofs
7. EIP-7685[7]: General execution layer requests
8. EIP-7702[8]: Set EOA account code for a transaction

Considered EIPs

• EIP-7212: Precompile support for secp256r1 curve
• EIP-7547[9]: Includes list
• EIP-7623[10]: Increase calldata cost
• EIP-7742[11]: Decouple blob count relationship between consensus and execution layers

Key EIP Summaries

EIP-2537: Precompile for BLS12-381 curve operations

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

EIP-2935: Store historical block hashes in state

This proposal suggests storing the hashes of the most recent 8192 blocks in a system contract, primarily to support stateless client execution. This approach makes it easier for stateless clients to access necessary historical information while maintaining compatibility with the existing BLOCKHASH opcode. It simplifies the storage mechanism for block hash history and provides a new pathway for accessing historical data.

EIP-6110: On-chain validator deposits

This proposal integrates the process of validator deposits directly into the Ethereum execution layer's block structure. This change shifts the responsibility for including and validating deposits from the consensus layer to the execution layer, eliminating the need for the consensus layer to vote on deposits (or eth1data). By analyzing the contract log events of deposit transactions to generate a deposit list, 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 system complexity.

EIP-7002: Triggerable execution layer exits

This proposal introduces a new mechanism that allows validators to trigger withdrawal and exit operations through the execution layer (0x01) by revoking credentials. The specific implementation involves attaching withdrawal messages to execution layer blocks, which are then processed by the consensus layer. This method 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 of Ethereum validators (MAXEFFECTIVEBALANCE) while maintaining the minimum staking balance at 32 ETH. This change has several benefits:

1. Allows large node operators to consolidate into fewer validators, improving operational efficiency.
2. Provides small stakers with the opportunity to earn compound rewards, increasing the attractiveness of staking.
3. Offers more flexible staking options to attract more participants.
4. Reduces redundant validators in the network, decreasing the number of P2P messages.
5. Reduces the memory footprint of BeaconState, improving system efficiency.
6. Coordinates with enhanced partial withdrawal mechanisms in the execution layer to further optimize the liquidity of the entire Ethereum network.

EIP-7549: Remove committee index from proofs

This proposal suggests removing the index field of the committee from the signed proof message to achieve 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 for validating consensus rules. While all types of clients can benefit from this improvement, it may bring the most significant performance improvement for ZK circuits that require proof of 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 involves adding a field in the execution header and body to store request information, exposing these requests to the consensus layer for processing. This mechanism is designed to address the increasing demands of smart contract-controlled validators and 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 optimize Ethereum's account abstraction. This proposal introduces a new transaction type that allows externally owned accounts (EOA) to set account code through an authorization mechanism. This improvement supports several new features:

1. Batch operations: Allows EOAs to execute multiple operations in the same transaction, improving efficiency.
2. Delegated transactions: Provides convenience for third-party payment of transaction fees.
3. Permission downgrading: Enhances account security and flexibility.

By adopting the 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 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: EIP-2537

[2]EIP-2935: EIP-2935

[3]EIP-6110: EIP-6110

[4]EIP-7002: EIP-7002

[5]EIP-7251: EIP-7251

[6]EIP-7549: EIP-7549

[7]EIP-7685: EIP-7685

[8]EIP-7702: EIP-7702

[9]EIP-7547: EIP-7547

[10]EIP-7623: EIP-7623

[11]EIP-7742: EIP-7742

[12]EIP-7600: Pectra Hard Fork Metadata: EIP-7600

[13]Ethereum Core Developers Consensus Layer Meeting #197: Ethereum All Core Developers Execution Call 197

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。