Which EIPs have been confirmed to be included in the Pectra upgrade?

Author: 0xNatalie Source: chainfeeds

Pectra, the next Ethereum upgrade, is named after 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, named after stars in alphabetical order. The star name Electra chosen this time corresponds to the letter "E".

As the 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.

Determine the included EIPs and the impact they will have

The impact of these 8 EIPs on users is reflected in: By adding code execution capabilities to EOA, the flexibility of accounts is increased, enabling them to perform more complex operations; raising the pledge limit may increase the ETH ; at the same time, optimizing the verifier 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 implement 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 Hash in State): By storing the latest 8192 block hashes in the system contract, to support the stateless client model and provide more flexible historical block hash query functions. These hash values ​​can be queried directly through the contract and bundled as witnesses to stateless clients. Clients do not need to maintain the complete blockchain history or store large amounts of data themselves. They can verify the legitimacy of blocks and transactions by relying on block hashes and related proofs stored in the state. EIP-6110 (providing validator deposits on-chain): Moves the processing of validator deposits from the consensus layer to the execution layer, and processes and verifies them on-chain, without relying on additional voting mechanisms in the consensus layer to confirm the validity of deposit information. Enhances the security of the deposit process, reduces processing delays, and simplifies the design of the consensus layer and clients. EIP-7002 (executable exit at the execution layer): Allows owners of withdrawal vouchers 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, 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 independently control the staked ETH. This proposal triggers the exit and withdrawal of ETH through the execution layer, and the holder can initiate an exit through the withdrawal voucher without relying on the active key.

3. EIP-7251 (Increase the staking limit): Increase the maximum effective balance of the validator, allowing each validator to hold more than 32 ETH staked, 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 burdens.

4. EIP-7549 (Move the committee index out of the attestation): Achieve more efficient consensus vote 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). Since 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, resulting in these votes not being easily aggregated. Move the committee index field out of the signature message itself to achieve more efficient vote aggregation, reduce verification costs and network load. EIP-7685 (Generic Execution Layer Request): Defines 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.

5. 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 (Remove 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 adapt to 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 the feedback of the execution layer at the ACDE (All Core Developers Executive Layer Meeting).

• EIP 7762 (Minimum blob base fee): Increase 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, and 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 the market can be balanced 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 mainly 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 will bring greater inflationary pressure to ETH.

• EIP 7782 (Shortening Slot Time): Reduce 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 the 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 improving the network's processing capacity. Compared with directly shortening the slot time, gradually adjusting the gas limit can make the network expansion smoother. This proposal does not require a hard fork, but it may have an impact on the state data.

Since the Pectra upgrade contains 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 worried that it would delay the upgrade, so it was not seriously considered. 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:

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

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