Which EIPs have been confirmed to be included in the Pectra upgrade? Will it increase ETH inflation?

Original title: "Which EIPs have been confirmed to be included in the Pectra upgrade? Will it increase ETH inflation?"

Original author: 0XNATALIE, ChainFeeds

Ethereum's next upgrade, Pectra, is named after the combination of Prague and Electra.

Prague represents the upgrade of the execution layer, named after Prague, the host city of the Ethereum Developer Conference (Devcon 4), while Electra symbolizes the upgrade of the consensus layer and is named after stars in alphabetical order. The star name Electra chosen this time corresponds to the letter "E".

As a hard fork that may involve the most Ethereum Improvement Proposals (EIPs) in Ethereum's history, the Pectra upgrade not only includes a series of proposals for validator operations and mainnet performance improvements, but also introduces proposals to optimize L2. Pectra Devnet 4 testnet has just been launched, and 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: increasing the flexibility of accounts by adding code execution capabilities to EOA, enabling them to perform more complex operations; increasing the staking limit may increase the demand for ETH; at the same time, optimizing the validator process improves security and efficiency, and increases the speed and throughput of Ethereum.

1. EIP-2537 (support for BLS signatures): By introducing a series of precompiled contracts (precompiles), support for BLS12-381 curve operations is added to Ethereum, which can realize BLS signature verification and allow multiple signatures to be aggregated into one signature, thereby reducing the complexity of verification. BLS signature is a cryptographic algorithm that can generate smaller signatures and support signature aggregation. This will help L2, which requires a large number of signature verification and data verification operations, to run better.

2. EIP-2935 (Save historical block hashes in the state): By storing the latest 8192 block hashes in the system contract, it supports the stateless client model and provides a more flexible historical block hash query function. These hash values can be queried directly through the contract and bundled as witnesses and provided to stateless clients. The client does not need to maintain the complete blockchain history or store a large amount of data by itself. It only needs to rely on the block hashes and related proofs stored in the state to verify the legitimacy of blocks and transactions.

3.EIP-6110 (providing validator deposits on-chain):Transfer the processing of validator deposits from the consensus layer to the execution layer, and process and verify them on-chain, instead of relying on an additional voting mechanism in the consensus layer to confirm the validity of the deposit information. Enhances the security of the deposit process, reduces processing delays, and simplifies the design of the consensus layer and the client.

4.EIP-7002 (executable exit at the execution layer):Allows the owner of the withdrawal voucher to independently initiate an exit without relying on the validator's active key (BLS key), increasing user autonomy. Currently, only the validator's active key can trigger an exit, 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 voucher (the actual owner of the funds) cannot autonomously control the staked ETH. This proposal triggers the exit and withdrawal of ETH through the execution layer, and holders can initiate an exit through the withdrawal voucher without relying on the active key.

5.EIP-7251 (Increase the upper limit of staking):Increase the maximum effective balance of the validator, allowing each validator to hold more than 32 ETH of staking, while the minimum staking threshold remains at 32 ETH. It aims 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 the committee index out of the proof):Achieve more efficient consensus voting aggregation by moving the committee index field out of the Attestation message. Currently in Ethereum's consensus mechanism, each validator's vote includes: LMD GHOST vote (including the block root and time slot of the vote), Casper-FFG vote (including source and target information), and committee index (the committee number to which the validator belongs). Because the committee index is included in the signature message, when multiple validators vote on the same block, even if their votes are the same, the generated signature roots are different, making it impossible to easily aggregate these votes. Move the committee index field out of the signature message itself to achieve more efficient vote aggregation, reduce verification costs and network load.

7. EIP-7685 (Generic Execution Layer Request): Define a common framework for the Execution Layer (EL) for storing and processing requests triggered by smart contracts. This framework supports more execution layer triggering behaviors and enables different types of requests to be processed uniformly, simplifying the process of adding new request types without modifying the execution block structure.

8. EIP-7702 (Add code execution capabilities to EOA):Add code execution capabilities to externally owned accounts (EOA) to enhance the flexibility and programmability of accounts. EOA specifies a smart contract to perform certain operations on behalf of the account, such as batch transactions or permission control, through authorized signatures. It has certain smart contract functions without the need to convert to a smart contract account.

EIPs under consideration

The following are some EIPs that are being actively considered, mainly by optimizing blobs, improving the cost stability of L2 data publishing, enhancing L2's transaction processing capabilities, and effectively reducing L2 costs. In addition, adjustments to increase calldata costs may affect the amount of ETH destroyed and increase ETH's inflation pressure.

· EIP-7742 (Removing blob count dependency between consensus layer and execution layer):Decouple the number of blobs between the consensus layer and the execution layer, simplify the blob verification process, reduce unnecessary complexity, and improve the scalability and flexibility of the protocol. In the current protocol, both the execution layer and the consensus layer hard-code the maximum value of blobs, resulting in redundant verification. This proposal cancels the verification of the maximum value of blobs by the execution layer, and instead the consensus layer dynamically provides the blob target value to the execution layer. In this way, the blob target parameters can be adjusted more flexibly to meet future expansion 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 needs to wait for 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 it takes for blob prices to adjust to a reasonable level. Currently, the minimum blob base fee is set to 1 wei. When blob demand exceeds supply, the price discovery process (i.e. determining a reasonable blob Gas price) is too slow and takes a long time to reach the right fee level. By increasing the minimum blob base fee, the time it takes for prices to adjust can be shortened, and market equilibrium can be achieved more quickly, ensuring that the network remains stable during peak demand.

· EIP-7623 (Increase calldata cost):Increase the cost of calldata in transactions to reduce the maximum size of blocks and their range of variation, ensuring that the network can process transactions more smoothly. The current maximum block size is about 1.79 MB, but the average block size is increasing due to large data releases from applications such as rollups. By increasing the calldata cost, which is primarily used for data availability (DA) transactions, the maximum block size is reduced to about 0.72 MB, leaving room for future increases in block gas limits or more blobs. The transaction cost for ordinary users remains unchanged, and this change mainly affects the types of transactions that rely on Ethereum for large-scale data storage. However, the increase in calldata costs may reduce Ethereum's competitiveness in data storage. In addition, the increase in calldata costs may reduce the number of transactions, resulting in a corresponding decrease in the number of ETH destroyed through the EIP-1559 mechanism, which in turn brings greater inflationary pressure to ETH.

· EIP 7782 (Shorten Slot Time):Shorten the Ethereum slot time from 12 seconds to 8 seconds, generate blocks more frequently to process more transactions, and use this as an alternative to increasing the number of blobs to increase transaction throughput. However, it may break some smart contracts that have hard-coded 12-second slot times, and accelerate Ethereum's state bloat problem, increasing storage and computational burdens.

· EIP-7783 (Gradually Increase Block Gas Fee Limit):As a milder alternative to EIP-7782, by dynamically adjusting the gas limit of the block, the number of transactions that can be accommodated in each block is gradually increased, thereby increasing the processing capacity of the network. Compared with directly shortening the slot time, gradually adjusting the gas limit can make the network expand more smoothly. This proposal does not require a hard fork, but it may have an impact on the state data.

Since the Pectra upgrade includes a large number of EIPs, in order to reduce the complexity of a single upgrade and speed up the launch of some EIPs, in May, the Ethereum Foundation's engineering team EthPandaOps suggested splitting Pectra into two parts, but at the time, it was not seriously considered due to concerns that it would delay the upgrade. In September, Ethereum researcher Alex Stokes again proposed a split, which was recognized by developers this time. This split will help complete the first part of the upgrade within six months:

· Part I: Includes EIPs that are already running on the Pectra Devnet testnet (i.e., the 8 EIPs that have been identified), which are relatively easier to implement and have passed a lot of tests.

· Part II: Put more complex EIPs (such as PeerDAS, EOF-related proposals) and other proposals that require more time to test in the second phase. These proposals require further development, auditing, and testing, especially those involving coordination between the consensus layer and the execution layer.