Which EIPs are confirmed to be included in Pectra Upgrade Will it intensify ETH inflation

CoinWorld reports:
Author: 0xNatalie Source: chainfeeds
The next upgrade of Ethereum, Pectra, is named after a combination of Prague and Electra.
Prague represents the upgrade of the execution layer, named after the city where the Ethereum developer conference (Devcon 4) was held, while Electra symbolizes the upgrade of the consensus layer, named after stars in alphabetical order. The chosen star name Electra corresponds to the letter “E”.
As the largest hard fork in Ethereum history that may involve the most Ethereum Improvement Proposals (EIPs), the Pectra upgrade includes a series of proposals to improve validator operations and mainnet performance, as well as introduce optimizations for Layer 2. The Pectra Devnet 4 testnet has just been launched, and there are currently 8 EIPs confirmed to be included in the Pectra upgrade.


Confirmed EIPs and their impact
These 8 EIPs have the following impact on users: they enhance the flexibility of accounts by adding code execution capabilities to Externally Owned Accounts (EOA), enabling them to perform more complex operations; they increase the staking limit, potentially increasing the demand for ETH; and they optimize the validator process, improving security, efficiency, speed, and throughput of Ethereum.
EIP-2537 (BLS Signature Support): By introducing a set of precompiled contracts, this EIP adds support for BLS12-381 curve operations to Ethereum, enabling BLS signature verification and allowing multiple signatures to be aggregated into one, reducing complexity in verification. BLS signatures are cryptographic algorithms that can generate smaller signatures and support signature aggregation, which will benefit L2 operations that require a large number of signature and data verifications.
EIP-2935 (Storing Historical Block Hashes in State): By storing the recent 8192 block hashes in a system contract, this EIP supports the Stateless Clients model and provides flexible historical block hash querying capabilities. These hash values can be directly queried through contracts and bundled as witnesses, providing to stateless clients. Clients no longer need to maintain the complete blockchain history or store large amounts of data, but can rely on the block hashes and related proofs stored in the state to verify the legitimacy of blocks and transactions.
EIP-6110 (On-Chain Deposits for Validators): This EIP moves the processing of validator deposits from the consensus layer to the execution layer, allowing for on-chain processing and validation without depending on additional voting mechanisms in the consensus layer to verify deposit information. It enhances the security of the deposit process, reduces processing delays, and simplifies the design of the consensus layer and clients.
EIP-7002 (Executables Exits): This EIP allows owners of withdrawal credentials to initiate exits independently, without relying on the active key (BLS key) of the validator, increasing user autonomy. Currently, only the active key of the validator can trigger exits, which means that if the active key is lost or the validator delegates the verification task to a third party (such as a staking service provider), the owner of the withdrawal credentials (the actual owner of the funds) cannot control the staked ETH independently. This proposal enables the execution layer to trigger ETH exits and withdrawals, allowing holders to initiate exits through withdrawal credentials without relying on the active key.
EIP-7251 (Increasing Staking Limit): This EIP increases the maximum effective balance of validators, allowing each validator to hold more than 32 ETH in staking, while the minimum staking threshold remains at 32 ETH. It aims to reduce the number of validators in the network by allowing large node operators to merge multiple validators, thereby reducing P2P messaging, signature aggregation, and storage burdens.
EIP-7549 (Removing Committee Index from Attestations): By removing the committee index field from Attestation messages, this EIP achieves more efficient consensus voting aggregation. In the current consensus mechanism of Ethereum, each validator’s vote includes the LMD GHOST vote (including the block root and slot), Casper-FFG vote (including source and target information), and committee index (the committee number to which the validator belongs). Since the committee index is included in the signature message, even if multiple validators vote for the same block with the same content, the generated signature roots are different, making it difficult to easily aggregate these votes. By removing the committee index field from the signature message, more efficient voting aggregation can be achieved, reducing verification costs and network load.
EIP-7685 (General Execution Layer Requests): This EIP defines a general framework for the execution layer (EL) to store and process requests triggered by smart contracts. This framework supports more execution layer trigger behaviors and allows different types of requests to be uniformly processed, simplifying the process of adding new request types without modifying the execution block structure.
EIP-7702 (Adding Code Execution Capability to EOA): This EIP adds code execution capabilities to Externally Owned Accounts (EOA), enhancing the flexibility and programmability of accounts. EOAs can specify a smart contract as a proxy to execute certain operations, such as batch transactions or permission control, without the need to transform into smart contract accounts.
Key Considerations for EIPs
The following are some EIPs actively being considered, mainly optimizing blob to improve fee stability for L2 data publishing, enhancing L2 transaction processing capacity, and effectively reducing L2 costs. In addition, adjustments to calldata costs may affect the amount of ETH burned, increasing inflationary pressure on ETH.
EIP-7742 (Decoupling Blob Count Dependency between Consensus and Execution Layers): This EIP decouples the number of blobs between the consensus and execution layers, simplifying the blob verification process, reducing unnecessary complexity, and improving the protocol’s scalability and flexibility. Currently, both the execution layer and the consensus layer have hardcoded the maximum value of blobs, resulting in redundant verification. This proposal removes the execution layer’s validation of the maximum blob value and dynamically provides the blob target value to the execution layer from the consensus layer. This allows for more flexible adjustment of the blob target parameter to meet future scalability needs.
EIP-7742 is the least controversial proposal in the list of EIPs being considered for inclusion in the upgrade. According to the latest consensus layer meeting, developers agreed to start implementing EIP-7742 in Pectra Devnet 5, but whether it will be officially included still depends on the feedback from the execution layer in the All Core Developers Execution Layer Meeting (ACDE).
EIP-7762 (Minimum Base Fee for Blobs): This EIP increases the MIN_BASE_FEE_PER_BLOB_GAS to reduce the time required to adjust the blob price to a reasonable level. Currently, the minimum base fee for blobs is set at 1 wei. When the demand for blobs exceeds the supply, the price discovery process (i.e., determining a reasonable blob gas price) is too slow and takes a long time to reach an appropriate fee level. By increasing the minimum base fee for blobs, the time required for price adjustments can be shortened, allowing for faster market equilibrium and ensuring network stability during peak demand.
EIP-7623 (Increasing Calldata Cost): This EIP increases the cost of calldata in transactions to reduce the maximum block size and its variability, ensuring that the network can handle transactions more smoothly. The current maximum block size is approximately 1.79 MB, but with the large amount of data published by applications such as rollups, the average block size keeps increasing. By increasing the cost of calldata mainly used for Data Availability (DA) transactions, the maximum block size can be reduced to approximately 0.72 MB, leaving room for future increases in block gas limits or more blobs. This change primarily affects transaction types that rely on Ethereum for large-scale data storage, while the transaction costs for regular users remain unchanged. However, the increased cost of calldata may decrease Ethereum’s competitiveness in data storage. Additionally, the increased calldata cost may lead to a decrease in the number of transactions, resulting in a reduction in ETH burned through the EIP-1559 mechanism and thereby increasing inflationary pressure on ETH.
EIP-7782 (Shortening Slot Time): This EIP shortens the Ethereum slot time from 12 seconds to 8 seconds, generating blocks more frequently to process more transactions. It serves as an alternative solution to increasing the number of blobs to improve transaction throughput. However, it may disrupt certain smart contracts that have hardcoded the 12-second slot time and accelerate Ethereum’s state bloat problem, increasing storage and computational burdens.
EIP-7783 (Gradually Increasing Block Gas Limit): This EIP, as a more moderate alternative to EIP-7782, gradually increases the gas limit of each block to gradually increase the number of transactions that can be accommodated, thereby improving the network’s processing capacity. Compared to directly shortening the slot time, gradually adjusting the gas limit allows for smoother network scalability. This proposal does not require a hard fork but may have an impact on the state data.
Due to the inclusion of a large number of EIPs in the Pectra upgrade, in order to reduce the complexity of a single upgrade and speed up the deployment of some EIPs, the Ethereum Foundation’s engineering team, EthPandaOps, proposed splitting Pectra into two parts in May. However, it was not seriously considered at the time due to concerns about delaying the upgrade. In September, Ethereum researcher Alex Stokes once again proposed the split, which was accepted by developers. This split will help complete the first part of the upgrade within six months:
Part 1: This includes the EIPs that have been running on the Pectra Devnet testnet (i.e., the 8 confirmed EIPs), which are relatively easier to implement and have undergone extensive testing.
Part 2: The more complex EIPs (such as PeerDAS and EOF-related proposals) and other proposals that require more time for testing will be included in the second phase. These proposals require further development, auditing, and testing, especially those involving coordination between the consensus and execution layers.