Which EIPs have been confirmed for inclusion in the Pectra upgrade? Will it exacerbate ETH inflation?
TechFlow Selected TechFlow Selected
Which EIPs have been confirmed for inclusion in the Pectra upgrade? Will it exacerbate ETH inflation?
The finalized EIPs will enhance account programmability, Ethereum verification efficiency, and staking optimization, while the undecided EIPs focus on improving L2 scalability.
Navigating Web3 tides with focused insightsBy 0XNATALIE
The next Ethereum upgrade, Pectra, is named as a combination of "Prague" and "Electra."
"Prague" refers to the execution layer upgrade, named after Prague—the host city of Devcon 4—while "Electra" represents the consensus layer upgrade, following the tradition of naming stars alphabetically. The chosen star name Electra corresponds to the letter "E."
Pectra marks one of the most extensive hard forks in Ethereum's history, potentially involving the largest number of Ethereum Improvement Proposals (EIPs) to date. It includes proposals aimed at improving validator operations and mainnet performance, as well as enhancements for Layer 2 (L2) scaling. The Pectra Devnet 4 testnet has just launched, with eight EIPs already confirmed for inclusion in the Pectra upgrade.
Confirmed EIPs and Their Impact
The impact of these eight EIPs on users includes: enhancing account flexibility by enabling code execution for externally owned accounts (EOAs), allowing more complex operations; increasing staking limits which may boost ETH demand; and streamlining validator processes to improve security, efficiency, speed, and throughput on Ethereum.
-
EIP-2537 (BLS12-381 Precompiles): Introduces precompiled contracts to support BLS12-381 elliptic curve operations, enabling BLS signature verification and aggregation of multiple signatures into one. BLS signatures are a cryptographic scheme that produces compact signatures and supports aggregation. This reduces verification complexity and benefits L2 systems requiring frequent signature and data validation.
-
EIP-2935 (Store Historical Block Hashes in State): Stores the last 8,192 block hashes in a system contract to support stateless clients and provide flexible historical block hash queries. These hashes can be directly accessed via contracts and bundled as witnesses for stateless clients, eliminating the need for clients to maintain full blockchain history or store large amounts of data. Clients can verify block and transaction validity using only the stored hashes and accompanying proofs.
-
EIP-6110 (Deposit Contract Execution Layer Integration): Moves validator deposit processing from the consensus layer to the execution layer, handling deposits on-chain without relying on additional voting mechanisms in the consensus layer to validate deposit data. This improves deposit security, reduces latency, and simplifies consensus and client design.
-
EIP-7002 (Execution-Layer Triggered Exits): Allows withdrawal credential holders to independently initiate validator exits without needing access to the validator’s active BLS key. Currently, only validators with active keys can trigger exits. If the key is lost or staking is delegated to third parties (e.g., staking providers), the actual fund owner cannot control their stake. This proposal enables withdrawal credential owners to initiate exits through the execution layer, removing dependency on active keys.
-
EIP-7251 (Increase Maximum Effective Balance): Increases the maximum effective balance per validator, allowing validators to stake more than 32 ETH while maintaining the minimum threshold at 32 ETH. This aims to let large operators consolidate multiple validators, reducing the total number of validators, thereby decreasing P2P messages, signature aggregations, and storage overhead.
-
EIP-7549 (Remove Committee Index from Attestation): Removes the committee index field from attestation messages to enable more efficient vote aggregation. In Ethereum’s current consensus mechanism, each attestation includes an LMD GHOST vote (block root and slot), a Casper-FFG vote (source and target), and a committee index. Since the committee index is part of the signed message, even identical votes produce different signature roots, preventing easy aggregation. By moving this field outside the signed portion, attestations become more aggregatable, lowering verification costs and network load.
-
EIP-7685 (Generalized Execution Layer Requests): Defines a unified framework for the execution layer to store and process requests triggered by smart contracts. This supports various types of execution-layer triggers and allows different request types to be handled uniformly, simplifying the addition of new request types without modifying block structure.
-
EIP-7702 (Account Abstraction for EOAs): Enhances externally owned accounts (EOAs) with limited code execution capabilities, increasing account flexibility and programmability. Through a signed authorization, an EOA can delegate a smart contract to perform specific actions such as batch transactions or permission management, gaining some smart contract functionality without becoming a full contract account.
EIPs Under Active Consideration
The following EIPs are under active consideration, primarily focused on optimizing blob usage to improve fee stability for L2 data publication, enhance L2 transaction capacity, and reduce L2 costs. Additionally, adjustments increasing calldata costs could affect ETH burn rates, potentially increasing inflationary pressure on ETH.
-
EIP-7742 (Decouple Blob Count Between Consensus and Execution Layers): Decouples blob count limits between the consensus and execution layers, simplifying blob validation and reducing protocol complexity. Currently, both layers hardcode the maximum blob count, leading to redundant checks. This proposal removes the execution layer’s fixed blob limit check, instead allowing the consensus layer to dynamically pass a blob target value to the execution layer. This enables more flexible parameter adjustments to meet future scalability needs. EIP-7742 faces minimal controversy among proposed upgrades. According to recent consensus layer meetings, developers have agreed to begin implementing EIP-7742 in pectra-devnet-5, though final inclusion depends on feedback from the ACDE (All Core Developers Execution Layer meeting).
-
EIP-7762 (Minimum Blob Base Fee): Increases MIN_BASE_FEE_PER_BLOB_GAS to accelerate price discovery when blob demand exceeds supply. Currently set at 1 wei, the low minimum causes slow adjustment toward equilibrium fees during high demand. Raising the floor shortens convergence time, enabling faster market balance and better network stability during peak usage.
-
EIP-7623 (Increase Calldata Cost): Raises the cost of calldata in transactions to reduce maximum and average block sizes, ensuring smoother transaction processing. Current maximum block size is ~1.79 MB, but growing data publishing from rollups has increased average block size. By raising calldata costs—mainly used in data availability (DA) transactions—the maximum block size would shrink to ~0.72 MB, freeing space for future increases in block gas limits or more blobs. Regular user transaction costs remain unaffected; the change mainly impacts use cases relying on Ethereum for large-scale data storage. However, higher calldata costs may reduce Ethereum’s competitiveness in data storage. Also, reduced transaction volume due to higher costs could lower ETH burned via EIP-1559, increasing inflationary pressure on ETH.
-
EIP-7782 (Reduce Slot Time): Reduces Ethereum’s slot time from 12 seconds to 8 seconds, enabling more frequent block production and higher transaction throughput—a potential alternative to increasing blob counts. However, it risks breaking smart contracts that hardcode 12-second assumptions and could accelerate state bloat, increasing storage and computational demands.
-
EIP-7783 (Gradual Increase of Block Gas Limit): A milder alternative to EIP-7782, this proposal gradually increases the block gas limit through dynamic adjustments, improving network capacity over time. Compared to reducing slot time, this approach allows smoother scaling. It does not require a hard fork but may impact state growth.
Given the large number of EIPs included in Pectra, to reduce complexity and accelerate deployment of certain features, in May, EthPandaOps—an engineering team from the Ethereum Foundation—proposed splitting Pectra into two parts. At the time, concerns about delaying the overall upgrade prevented serious consideration. In September, Ethereum researcher Alex Stokes revived the idea, which gained developer support. Splitting Pectra could allow the first phase to be completed within six months:
-
Phase One: Includes EIPs already running on the Pectra Devnet testnet (the currently confirmed eight EIPs). These are relatively easier to implement and have undergone extensive testing.
-
Phase Two: Delays more complex proposals—such as PeerDAS and EOF-related upgrades—and other items requiring further development, audits, and testing, especially those involving coordination between consensus and execution layers.
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
@ChainFeedsxyz
