The confirmed EIPs will improve the programmability of accounts, Ethereum's verification efficiency and staking optimization, etc. The unconfirmed EIPs focus on how to improve L2 scalability.
Written by: 0XNATALIE
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 the hard fork that may involve the most Ethereum Improvement Proposals (EIPs) in Ethereum history, the Pectra upgrade not only includes a series of proposals for validator operations and mainnet performance improvements, but also introduces proposals for optimizing L2. The Pectra Devnet 4 testnet has just been launched, and 8 EIPs have been confirmed to be included in the Pectra upgrade.
Determine the EIPs to be included and the impact they will have
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.
EIP-2537 (Support for BLS Signatures): By introducing a series of 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.
EIP-2935 (Save historical block hashes in 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 large amounts of data by itself, but only needs to rely on the block hashes and related proofs stored in the state to verify the legitimacy of blocks and transactions.
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, rather than relying on an additional voting mechanism in the consensus layer to confirm the validity of the deposit information. This enhances the security of the deposit process, reduces processing delays, and simplifies the design of the consensus layer and the client.
EIP-7002 (Execution-Layer Triggerable Exits): Allows the owner of a 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 independently 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.
EIP-7251 (Increase the staking limit): Increase the maximum effective balance of the validator, allowing each validator to hold more than 32 ETH 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 burdens.
EIP-7549 (Move Committee Index Out of Attestation): By moving the committee index field out of the Attestation message, more efficient consensus vote aggregation is achieved. Currently in Ethereum's consensus mechanism, each validator includes in the vote: LMD GHOST vote (containing the block root and time slot of the vote), Casper-FFG vote (containing source and target information), 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. Moving the committee index field out of the signature message itself allows for more efficient vote aggregation, reducing verification costs and network load.
EIP-7685 (Generic Execution Layer Request): Defines a common framework for the Execution Layer (EL) to store and process 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.
EIP-7702 (Adding code execution capabilities to EOA): Add code execution capabilities to externally owned accounts (EOA), thereby enhancing the flexibility and programmability of accounts. EOA specifies a smart contract to perform certain operations on behalf of the account through authorized signatures, such as batch transactions or permission control. 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, which mainly improve the stability of L2 data publishing fees, enhance L2's transaction processing capabilities, and effectively reduce L2 costs by optimizing blobs. In addition, the adjustment of increasing 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 feedback from 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, 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 blocks and its 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 cost may make Ethereum less competitive for data storage. In addition, the increase in calldata cost 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 puts more inflationary pressure on ETH.
EIP 7782 (shortening slot time): shortens the Ethereum slot time from 12 seconds to 8 seconds, generates blocks more frequently to process more transactions, and uses 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, accelerate Ethereum's state bloat problem, and increase 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 expand more smoothly. This proposal does not require a hard fork, but 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 1: Includes EIPs that are already running on the Pectra Devnet testnet (i.e., the 8 EIPs that have been confirmed), which are relatively easy to implement and have passed a lot of testing.
Part II: Put more complex EIPs (such as PeerDAS, EOF-related proposals) and other proposals that require more time for testing in Phase II. These proposals require further development, auditing, and testing, especially those involving coordination between the consensus layer and the execution layer.
