Which EIPs have been confirmed for inclusion in the Pectra upgrade? Will it exacerbate ETH inflation?

The confirmed EIPs will enhance account programmability, Ethereum's verification efficiency, and staking optimization, while the unconfirmed EIPs focus on improving L2 scalability.

Written by: 0XNATALIE

The next Ethereum upgrade, Pectra, derives its name from a combination of Prague and Electra.

Prague represents the upgrade of the execution layer, named after the city that hosted the Ethereum developer conference (Devcon 4), while Electra symbolizes the consensus layer upgrade, with star names assigned alphabetically. The chosen star name Electra corresponds to the letter "E".

The Pectra upgrade is likely to be the hard fork in Ethereum's history involving the most Ethereum Improvement Proposals (EIPs). It not only includes a series of proposals aimed at improving validator operations and mainnet performance but also introduces proposals to optimize L2. The Pectra Devnet 4 testnet has just launched, and currently, 8 EIPs have been confirmed to be included in the Pectra upgrade.

Confirmed EIPs and Their Impact

The impact of these 8 EIPs on users is reflected in: enhancing account flexibility by adding code execution capabilities to EOAs, enabling them to perform more complex operations; increasing the staking cap may boost demand for ETH; meanwhile, optimizing validator processes improves security and efficiency, increasing Ethereum's speed and throughput.

1. EIP-2537 (Support for BLS Signatures): By introducing a series of precompiles, Ethereum adds support for BLS12-381 curve operations, enabling BLS signature verification and allowing multiple signatures to be aggregated into one, thereby reducing complexity during verification. BLS signatures are a cryptographic algorithm that can generate smaller signatures and support signature aggregation. This will help L2s that require a large number of signature and data verification operations to run more efficiently.
2. EIP-2935 (Store Historical Block Hashes in State): By storing the most recent 8192 block hashes in a system contract, this supports the Stateless Clients model and provides more flexible historical block hash query functionality. These hashes can be queried directly via contracts and bundled as witnesses to be provided to stateless clients. Clients do not need to maintain a complete blockchain history or store large amounts of data themselves; they can verify the legitimacy of blocks and transactions by relying on block hashes stored in state and related proofs.
3. EIP-6110 (On-chain Validator Deposits): Moves the processing of validator deposits from the consensus layer to the execution layer, handling and verifying them on-chain, no longer relying on an extra voting mechanism in the consensus layer to confirm the validity of deposit information. This enhances the security of the deposit process, reduces processing delays, and simplifies the design of the consensus layer and clients.
4. EIP-7002 (Execution Layer Triggered Exits): Allows owners of withdrawal credentials to independently initiate exits without relying on the validator's active key (BLS key), increasing user autonomy. Currently, only the validator's active key can trigger an exit, meaning that if the active key is lost or the validator delegates validation tasks to a third party (such as a staking service provider), the owner of the withdrawal credentials (i.e., the actual owner of the funds) cannot independently control the staked ETH. This proposal enables ETH exits and withdrawals to be triggered via the execution layer, allowing holders to initiate exits with withdrawal credentials without relying on the active key.
5. EIP-7251 (Increase Staking Cap): Increases the maximum effective balance for validators, allowing each validator to hold more than 32 ETH in stake, while the minimum staking threshold remains at 32 ETH. The aim is to allow large node operators to reduce the number of validators in the network by merging multiple validators, thereby reducing P2P messages, signature aggregation, and storage burden.
6. EIP-7549 (Move Committee Index Out of Attestation): By moving the committee index field out of the Attestation message, this enables more efficient consensus vote aggregation. Currently, in Ethereum's consensus mechanism, each validator's vote includes: LMD GHOST vote (containing the block root and slot), Casper-FFG vote (containing source and target information), and committee index (the validator's committee number). Since the committee index is included in the signed message, when multiple validators vote for the same block, even if their vote content is identical, the generated signature roots differ, making it difficult to aggregate these votes. Moving the committee index field out of the signed message itself enables more efficient vote aggregation, reducing verification costs and network load.
7. EIP-7685 (Generic Execution Layer Requests): Defines a generic framework for the execution layer (EL) to store and process requests triggered by smart contracts. This framework supports more execution layer-triggered behaviors and allows different types of requests to be handled uniformly, simplifying the process of adding new request types without modifying the execution block structure.
8. EIP-7702 (Add Code Execution Capability to EOAs): Adds code execution functionality to externally owned accounts (EOAs), enhancing account flexibility and programmability. EOAs can authorize a smart contract to proxy certain operations, such as batch transactions or permission control, via authorized signatures. This provides some smart contract features without needing to convert to a smart contract account.

Key EIPs Under Consideration

The following are some actively considered EIPs, mainly optimizing blobs to improve the stability of L2 data publishing fees, enhance L2 transaction processing capabilities, and effectively reduce L2 costs. In addition, adjustments to calldata costs may affect the amount of ETH burned, increasing inflationary pressure on ETH.

• EIP-7742 (Decouple Blob Counting Between Consensus and Execution Layers): Decouples the number of blobs between the consensus and execution layers, simplifies the blob verification process, reduces unnecessary complexity, and improves protocol scalability and flexibility. Currently, both the execution and consensus layers hardcode the maximum number of blobs, resulting in redundant verification. This proposal removes the execution layer's verification of the blob maximum, instead having the consensus layer dynamically provide the blob target value to the execution layer. This allows for more flexible adjustment of blob target parameters to meet future scaling needs. EIP-7742 is the least controversial proposal among those under consideration for inclusion in the upgrade. According to the latest consensus layer meeting, developers agreed to begin implementing EIP-7742 in pectra-devnet 5, but whether it will be officially included still awaits feedback from the execution layer at the ACDE (All Core Developers Execution Layer Meeting).
• EIP-7762 (Minimum Blob Base Fee): Increases MIN_BASE_FEE_PER_BLOB_GAS to reduce the time required for blob prices to adjust to reasonable levels. Currently, the minimum blob base fee is set at 1 wei, and when blob demand exceeds supply, the price discovery process (i.e., determining a reasonable blob gas price) is too slow, taking a long time to reach an appropriate fee level. By increasing the minimum blob base fee, the price adjustment time can be shortened, allowing the market to reach equilibrium more quickly and ensuring network stability during periods of high demand.
• EIP-7623 (Increase Calldata Cost): Increases the cost of calldata in transactions to reduce the maximum block size and its variability, ensuring the network can process transactions more smoothly. The current maximum block size is about 1.79 MB, but due to the large amount of data published by rollups and other applications, the average block size continues to increase. By increasing the cost of calldata, mainly used for data availability (DA) transactions, the maximum block size will be reduced to about 0.72 MB, leaving room for future increases in block gas limits or more blobs. The transaction costs for ordinary users remain unchanged; this change mainly affects transaction types that rely on Ethereum for large-scale data storage. However, the increase in calldata cost may reduce Ethereum's competitiveness in data storage. In addition, as calldata costs rise, the number of transactions may decrease, resulting in less ETH being burned via the EIP-1559 mechanism, thereby increasing inflationary pressure on ETH.
• EIP-7782 (Shorten Slot Time): Reduces Ethereum's slot time from 12 seconds to 8 seconds, generating blocks more frequently to process more transactions, serving as an alternative to increasing the number of blobs to improve transaction throughput. However, this may break some smart contracts that hardcode the 12-second slot time and accelerate Ethereum's state bloat problem, increasing storage and computational burden.
• EIP-7783 (Gradually Increase Block Gas Limit): As a milder alternative to EIP-7782, this proposal dynamically adjusts the block gas limit to gradually increase the number of transactions per block, thereby improving network processing capacity. Compared to directly shortening the slot time, gradually adjusting the gas limit allows for smoother network scaling. This proposal does not require a hard fork but may impact state data.

Since the Pectra upgrade includes a large number of EIPs, to reduce the complexity of a single upgrade and accelerate the rollout of some EIPs, in May, the Ethereum Foundation's engineering team EthPandaOps suggested splitting Pectra into two parts. However, at the time, there were concerns about delaying the upgrade, so the suggestion was not seriously considered. In September, Ethereum researcher Alex Stokes proposed the split again, and this time it was accepted by developers. This split will help complete the first part of the upgrade within six months:

• Part One: Includes the EIPs already running on the Pectra Devnet testnet (i.e., the 8 confirmed EIPs), which are relatively easier to implement and have already undergone extensive testing.
• Part Two: More complex EIPs (such as PeerDAS, EOF-related proposals) and other proposals requiring more time for testing will be placed in the second phase. These proposals require further development, auditing, and testing, especially those involving coordination between the consensus and execution layers.