What EIPs have been determined to be included in the Pectra upgrade?

Author: 0xNatalie Source: chainfeeds

Ethereum’s next upgrade to Pectra, its name comes from the combination of Prague and Electra.

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

As a hard fork that may involve the most Ethereum Improvement Proposals (EIP) 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.The Pectra Devnet 4 test network has just been launched, and 8 EIPs have been confirmed to be included in the Pectra upgrade.

Identify the included EIP and its impact

The impact of these 8 EIPs on users is reflected in: by adding code execution capabilities to EOA, improving account flexibility, enabling them to perform more complex operations; increasing the staking ceiling may increase the demand for ETH; and at the same time, optimizing the validator’sProcesses improve security and efficiency, and increase Ethereum’s speed and throughput.

1. EIP-2537 (supports BLS signature): By introducing a series of precompiled contracts (precompiled contracts), it can add support for BLS12-381 curve operations to Ethereum.Implement BLS signature verification, and allows multiple signatures to aggregate into one signature, thereby reducing the complexity during verification.BLS signature is a cryptographic algorithm that generates smaller signatures and supports signature aggregation.This willHelps L2, which requires a lot of signature verification and data verification operations, run better.

2. EIP-2935 (save historical block hash in state): by storing the most recent 8192 block hashs in the system contract,To support Stateless Clients models, and provides more flexible historical block hash query function.These hashes can be directly queried through the contract and bundled as witnesses and provided to stateless clients.Clients do not need to maintain a complete blockchain history or store large amounts of data by themselves, you can verify the legitimacy of blocks and transactions by relying on block hash and related proofs stored in the state.

3. EIP-6110 (providing verifier deposits on the chain): transfers the processing of verifier deposits from the consensus layer to the execution layer, and processes and verifys on the chain, without relying on additional voting mechanisms in the consensus layer to confirm deposit informationeffectiveness.Enhances the security of the deposit process, reduces processing delays, and simplifies the design of the consensus layer and client.

4. EIP-7002 (Execution layer triggerable exit): allows the owner of the withdrawal voucher to initiate an exit independently, andNo need to rely on the validator’s active key (BLS key)), increasing user autonomy.Currently, only the verifier’s active key can trigger an exit, which means that if the active key is lost, or the verifier delegates the verification task to a third party (such as a staking service provider), the owner of the withdrawal voucher (i.e., the fundedThe actual owner) cannot control the pledged ETH independently.The proposal triggers the exit and withdrawal operations of ETH through the execution layer, and holders can initiate exits through the withdrawal voucher without relying on the active key.

5. EIP-7251 (Add to Pledge Cap): Increase the maximum valid balance of the verifier, allowing each verifier to hold more than 32 ETH, while the minimum staking threshold remains at 32 ETH.Aim to allow large node operators to merge multiple validatorsReduce the number of validators in the network, thereby reducing P2P messages, signature aggregation, and storage burden.

6. EIP-7549 (Move Committee Index Out of Proof): A 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 voting includes: LMD GHOST voting (including the voting root and time slot), Casper-FFG voting (including source and target information), and committee index (to which the verifier belongs.committee number).Since the committee index is included in the signature message, when multiple validators vote on the same block, the generated signature roots are different even if their votes are the same, resulting in these votes not being easily aggregated.Move the committee index field out of the signature message itself, thusAchieve more efficient voting aggregation and reduce verification costs and network load.

7. EIP-7685 (General Execution Layer Request): Defines a common framework for the execution layer (EL) to store and process requests triggered by smart contracts.This frameworkSupports more execution layer trigger behavior, and enable different types of requests to be processed uniformly,Simplifies the process of adding new request types, without modifying the execution block structure.

8. EIP-7702 (add code execution capability to EOA):Add code execution to externally owned accounts (EOA) to enhance account flexibility and programmability.EOA specifies a smart contract to perform certain operations, such as batch transactions or permission control, through authorization signatures.It has certain smart contract functions without changing into a smart contract account.

EIPs that are under consideration

The following are some EIPs that are being actively considered. They mainly improve the cost stability of L2 data release, enhance the transaction processing capabilities of L2, and effectively reduce the cost of L2 by optimizing blobs.In addition, the adjustment to increase calldata costs may affect the amount of ETH destroyed and increase the inflationary pressure on ETH.

• EIP-7742 (decoupling the blob count dependency between the consensus layer and the execution layer): decouples the number of blobs between the consensus layer and the execution layer, simplifies the blob verification process, reduces unnecessary complexity, improves the scalability of the protocol andflexibility.In the current protocol, both the execution layer and the consensus layer hardcode the maximum value of the blob, resulting in redundant verification.This proposal cancels the execution layer’s verification of the maximum blob value, and instead provides the consensus layer with 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 on the list of EIPs being considered for inclusion in the upgraded EIP list. According to the latest consensus layer meeting, the developer agreed to start implementing EIP 7742 in pectra-devnet 5, but whether it will be officially included still needs to wait for the execution layer.Feedback on ACDE (All Core Developer Execution Layer Meeting).

• EIP 7762 (minimum blob basic fee): Increase MIN_BASE_FEE_PER_BLOB_GAS with the goal ofReduce the time it takes to adjust the blob price to a reasonable level.Currently, the minimum blob base fee is set to 1 wei, and when the blob demand 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 the appropriate fee level.By increasing the minimum blob base fee, the time for price adjustment can be shortened, market equilibrium can be achieved faster, and the network can remain stable during peak demand.

• EIP-7623 (increase calldata cost): Increase the cost of calldata in transactions to reduce the maximum size of the block and its range of changes, ensuring that 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 released by applications such as rollups, the average block size continues to increase.By increasing the calldata cost primarily for data availability (DA) transactions, reducing the block maximum size to about 0.72 MB, leaving room for future addition of block Gas limits or more blobs.The transaction costs for ordinary users remain the same, and this change mainly affects the types of transactions that rely on Ethereum for large-scale data storage.However, the increase in calldata costs mayReduce Ethereum’s competitiveness in data storage.In addition, calldata costs increase, and the number of transactions may decrease, resulting in a corresponding reduction in ETH destroyed through the EIP-1559 mechanism.In turn, it brings greater inflationary pressure to ETH.

• EIP 7782 (shorten slot time): shortens the Ethereum slot time from 12 seconds to 8 seconds, generate blocks more frequently to process more transactions, using this as an alternative to increasing the number of blobs to improve transaction throughput.But it may destroy some smart contracts that hardcoded 12 seconds slot time and accelerate Ethereum’s state inflation problem, increasing storage and computing burden.

• EIP-7783 (gradually increase the block gas fee limit): As a more moderate alternative to EIP-7782, gradually increase the number of transactions that can be accommodated per block by dynamically adjusting the block gas limit, thereby improving the processing power of the network..Compared to directly shortening slot time, gradually adjusting gas limits can make network expansion more stable.This proposal does not require a hard fork, but may have an impact on 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, EthPandaOps, the Ethereum Foundation’s engineer team, suggested splitting Pectra into two parts, but was worried that it would delay the upgrade at the time., therefore not seriously considered.In September, Ethereum researcher Alex Stokes once again proposed a split proposal, which was recognized by developers this time. This split will help complete the first part of the upgrade within six months:

1. Part One: Including EIPs (i.e., 8 EIPs that have been identified) that have been run on the Pectra Devnet testnet, they are relatively easier to implement and have passed a lot of tests.

2. Part 2: 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 and execution levels.