Interpreting Ethereum Pectra: The Next Major Upgrade
TechFlow Selected TechFlow Selected
Interpreting Ethereum Pectra: The Next Major Upgrade
The Pectra upgrade is the next major milestone for the Ethereum network, expected to be implemented in the first quarter of 2025.
Navigating Web3 tides with focused insightsAuthor: dwong
The Pectra upgrade is the next major 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 consensus layer upgrade.
Unlike previous major upgrades, Pectra does not have a single prominent primary goal. Instead, it focuses on multiple technical improvements and optimizations—contrasting with upgrades like Dencun (which significantly reduced L2 fees) or Shapella (which enabled withdrawals of staked ETH, completing Ethereum’s transition to proof-of-stake).
Latest Developments
Recently, Ethereum core developers (ACD, All Core Developers) discussed during a call the possibility of splitting the Pectra upgrade into two phases. Under this proposal:
-
The Pectra upgrade will include the EIPs from pectra-devnet-3 (see below).
-
The originally planned EOF (EVM Object Format) and PeerDAS (Peer Data Availability Sampling) components will be postponed to a future upgrade, tentatively named Fusaka (Fulu + Osaka).
-
Verkle Trees-related features initially intended for Osaka may be further delayed and potentially implemented in a subsequent Amsterdam upgrade.
This phased approach aims to keep the scope and complexity of each upgrade manageable while allowing sufficient time for thorough testing and refinement of each technology.
EIPs Associated with the Pectra Upgrade
Confirmed EIPs
-
EIP-2537[1]: Precompiles for BLS12-381 curve operations
-
EIP-2935[2]: Save historical block hashes in state
-
EIP-6110[3]: On-chain voting deposits
-
EIP-7002[4]: Triggerable execution-layer exits
-
EIP-7251[5]: Increase maximum effective balance
-
EIP-7549[6]: Move committee index out of attestation
-
EIP-7685[7]: Generalized execution layer requests
-
EIP-7702[8]: Set EOA account code within a transaction
EIPs Under Consideration
-
EIP-7212: Precompile to support secp256r1 curve
-
EIP-7547[9]: Inclusion lists
-
EIP-7623[10]: Increase calldata costs
-
EIP-7742[11]: Decouple blob count between consensus and execution layers
Overview of Key EIPs
EIP-2537: Precompiles for BLS12-381 Curve Operations
This proposal introduces precompiled operations for the BLS12-381 elliptic curve, significantly improving the efficiency of operations such as BLS signature verification. Compared to the existing BN254 precompile, BLS12-381 offers higher security (over 120 bits vs. 80 bits for BN254). The improvement includes not only basic curve arithmetic but also integrated multi-exponentiation capabilities, laying the foundation for efficient aggregation of public keys and signatures.
EIP-2935: Save Historical Block Hashes in State
This proposal suggests storing the hashes of the most recent 8192 blocks within a system contract. The change primarily supports stateless client execution by enabling such clients to easily access necessary historical data while maintaining backward compatibility with the existing BLOCKHASH opcode. It simplifies the mechanism for storing block hash history and provides new ways to access historical data.
EIP-6110: On-Chain Voting Deposits
This proposal integrates the validator deposit process directly into the Ethereum execution layer's block structure. This shift transfers 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 analyzing deposit transaction logs from a smart contract to generate the deposit list, this method enhances the security and efficiency of deposit processing, improves user experience, simplifies client software design, and reduces overall system complexity.
EIP-7002: Triggerable Execution-Layer Exits
This proposal introduces a new mechanism allowing validators to trigger withdrawal and exit actions via execution-layer (0x01) withdrawal credentials. Specifically, withdrawal messages are attached to execution-layer blocks and then processed by the consensus layer. This approach provides validators with greater flexibility in exiting while preserving system security and consistency.
EIP-7251: Increase Maximum Effective Balance
This proposal aims to increase the maximum effective balance (MAX_EFFECTIVE_BALANCE) for Ethereum validators while keeping the minimum staking requirement at 32 ETH. The change brings several benefits:
-
Enables large staking operators to consolidate into fewer validators, improving operational efficiency.
-
Allows smaller stakers to earn compounding rewards, increasing the appeal of staking.
-
Provides more flexible staking options, attracting broader participation.
-
Reduces redundant validators on the network, decreasing P2P message overhead.
-
Reduces BeaconState memory footprint, enhancing system performance.
-
Works alongside enhanced partial withdrawal mechanisms in the execution layer to further optimize capital liquidity across the Ethereum network.
EIP-7549: Move Committee Index Out of Attestation
This proposal recommends removing the committee index field from signed attestation messages to enable aggregation of identical consensus votes. The main goal is to improve the efficiency of Casper FFG clients by reducing the average number of pairings required to verify consensus rules. While all client types benefit from this improvement, ZK circuits that must prove Casper FFG consensus may see the most significant performance gains.
EIP-7685: Generalized Execution Layer Requests
This proposal defines a general framework for storing and processing requests triggered by smart contracts. The implementation adds one field each in the execution header and body to store request data, exposing these requests to the consensus layer so they can be individually processed. This mechanism is primarily designed to meet the growing demand for smart contract-controlled validators and lays the groundwork for more complex on-chain interactions in the future.
EIP-7702: Set EOA Account Code Within a Transaction
Proposed by Vitalik Buterin et al., EIP-7702 aims to enhance Ethereum's account abstraction. It introduces a new transaction type that allows externally owned accounts (EOAs) to set account code through an authorization mechanism. This improvement enables several new capabilities:
-
Bundled operations: Allows EOAs to execute multiple actions within a single transaction, improving efficiency.
-
Sponsored transactions: Enables third-party fee payment for transactions.
-
Permission downgrading: Enhances account security and flexibility.
By adopting a new transaction structure, this proposal not only improves the functionality and usability of EOAs but also ensures good compatibility and extensibility for future account abstraction technologies.
Conclusion
While the Pectra upgrade lacks a single dominant objective, its collection of technical enhancements and optimizations will further strengthen Ethereum’s functionality, security, and efficiency. As the upgrade plan progresses, we may see additional EIPs added or adjusted accordingly.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@UpchainDAO
