Coin World News Report:
Author: 0xNatalie Source: chainfeeds
The next Ethereum upgrade, Pectra, derives its name from a combination of Prague and Electra.
Prague represents the upgrade of the execution layer, named after the city where the Ethereum developers’ 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 one of the largest hard forks in Ethereum history, the Pectra upgrade includes a series of Ethereum Improvement Proposals (EIPs) that target validator operations, mainnet performance improvements, and the optimization of Layer 2. The Pectra Devnet 4 test network has just been launched and currently includes 8 confirmed EIPs for the Pectra upgrade.
Confirmed EIPs and their impacts
These 8 EIPs have the following impacts on users: they enhance the flexibility of accounts by adding code execution capability to Externally Owned Accounts (EOAs), allowing them to perform more complex operations; increasing the staking limit may increase the demand for ETH; optimizing the validator process improves security and efficiency, enhancing the speed and throughput of Ethereum.
EIP-2537 (BLS Signature Support): By introducing a series of precompiled contracts, Ethereum adds support for BLS12-381 curve operations, enabling BLS signature verification and aggregation of multiple signatures into one, reducing the complexity of verification. BLS signatures are cryptographic algorithms that generate smaller signatures and support signature aggregation. This will benefit Layer 2 operations that require a large number of signature and data verifications.
EIP-2935 (Storing Historical Block Hashes in State): By storing the hash of the most recent 8192 blocks in a system contract, Ethereum supports the Stateless Clients model and provides more flexible historical block hash queries. These hashes can be directly queried through the contract and bundled as proofs (witnesses) for Stateless Clients. Clients no longer need to maintain a complete blockchain history or store large amounts of data, and can verify the legitimacy of blocks and transactions relying on the stored block hashes and related proofs.
EIP-6110 (On-chain Validator Deposits): This proposal transfers the handling of validator deposits from the consensus layer to the execution layer, allowing on-chain processing and verification without relying on additional voting mechanisms in the consensus layer to confirm the validity of deposit information. This enhances the security of the deposit process, reduces processing delays, and simplifies the design of the consensus layer and clients.
EIP-7002 (Execution Layer Triggered Exits): This allows the owner of withdrawal credentials to initiate exits independently without relying on the active key of validators (BLS keys), increasing user autonomy. Currently, only the active key of validators can trigger exits, which means that if the active key is lost or validators delegate verification tasks to third parties such as staking service providers, 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 proposal increases the maximum effective balance for validators, allowing each validator to hold more than 32 ETH for staking, while keeping the minimum staking threshold at 32 ETH. This 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 proposal achieves more efficient consensus voting aggregation. Currently, in Ethereum’s consensus mechanism, each validator’s vote includes LMD GHOST voting (including block root and slot), Casper-FFG voting (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 on the same block with the same content, the generated signature roots will be different, making it difficult to aggregate these votes easily. By removing the committee index field from the signature message itself, more efficient voting aggregation can be achieved, reducing verification costs and network load.
EIP-7685 (General Execution Layer Requests): This defines a general framework for the execution layer (EL) to store and process requests triggered by smart contracts. This framework supports more execution layer-triggered actions and enables unified handling of different types of requests, simplifying the process of adding new request types without modifying the execution block structure.
EIP-7702 (Adding Code Execution Capability to EOA): This proposal adds code execution capability to Externally Owned Accounts (EOAs), enhancing the flexibility and programmability of accounts. EOAs can specify a smart contract to proxy the execution of certain operations, such as batch transactions or permission control, without the need to transform into smart contract accounts while still having certain smart contract functionalities.
Key Considerations for EIPs
The following EIPs are actively being considered, mainly optimizing blob to improve the fee stability of L2 data publication, enhancing L2 transaction processing capabilities, and effectively reducing the cost of L2. 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 Layer): This 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. In the current protocol, both the execution layer and the consensus layer hardcode the maximum value of blobs, leading to redundant verification. This proposal removes the execution layer’s validation of the maximum blob value and allows the consensus layer to dynamically provide the target blob value to the execution layer. This provides more flexibility in adjusting blob target parameters to meet future scalability needs.
EIP-7742 is the least controversial proposal among those being considered for inclusion in the upgrade. According to the latest consensus layer meeting, developers have agreed to start implementing EIP 7742 in pectra-devnet 5, but its official inclusion still depends on feedback from the execution layer in the ACDE (All Core Developers Execution Layer Meeting).
EIP-7762 (Minimum Blob Base Fee): This proposal 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 blob base fee is set at 1 wei, and 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 blob base fee, the adjustment time for prices can be shortened, achieving market equilibrium faster and ensuring network stability during peak demand.
EIP-7623 (Increasing Calldata Cost): This proposal increases the cost of calldata in transactions to reduce the maximum block size and its variation range, ensuring the network can handle transactions more smoothly. The current maximum block size is about 1.79 MB, but due to the large amount of data published by applications such as rollups, the average block size keeps increasing. By increasing the cost of calldata primarily used for Data Availability (DA) transactions, the maximum block size can be reduced to about 0.72 MB, leaving space for future increases in block gas limits or more blobs. This change mainly affects transaction types that rely on Ethereum for large-scale data storage, while the transaction costs for ordinary users remain unchanged. However, the increased calldata cost may reduce Ethereum’s competitiveness in data storage. Additionally, the increase in calldata cost may lead to a decrease in transaction volume, resulting in a corresponding decrease in ETH destroyed through the EIP-1559 mechanism, thereby exerting greater inflationary pressure on ETH.
EIP-7782 (Shortening Slot Time): This proposal shortens the Ethereum slot time from 12 seconds to 8 seconds, generating blocks more frequently to process more transactions. It serves as an alternative to increasing the number of blobs to improve transaction throughput. However, it may disrupt certain smart contracts that hardcode a 12-second slot time and accelerate Ethereum’s state bloat problem, increasing storage and computational burdens.
EIP-7783 (Gradually Increasing Block Gas Limit): This proposal, as a gentler alternative to EIP-7782, gradually increases the gas limit of each block to incrementally accommodate more transactions and improve the network’s processing capacity. Compared to directly shortening the slot time, gradual adjustment of the gas limit allows for smoother network scalability. This proposal does not require a hard fork but may have an impact on state data.
Due to the large number of EIPs included in the Pectra upgrade, in order to reduce the complexity of a single upgrade and speed up the implementation of some EIPs, engineers from the Ethereum Foundation’s EthPandaOps team proposed splitting Pectra into two parts in May. However, at that time, the proposal was not seriously considered due to concerns about delaying the upgrade. In September, Ethereum researcher Alex Stokes once again proposed the split, which was approved by developers. This split will help complete the first part of the upgrade within six months:
Part 1: Includes the EIPs that are already running on the Pectra Devnet test network (i.e., the 8 confirmed EIPs), which are relatively easier to implement and have undergone extensive testing.
Part 2: Puts the more complex EIPs (such as PeerDAS and 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 and execution layers.
