The confirmed EIPs will enhance the programmability of accounts, improve Ethereum's validation efficiency, and optimize staking, while the unconfirmed EIPs focus on how to enhance L2 scalability.

Written by: 0XNATALIE

Ethereum's next upgrade, Pectra, derives its name from a combination of Prague and Electra.

Prague represents the upgrade of the execution layer, named after the city of Prague, where the Ethereum Developer 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."

The Pectra upgrade is likely to involve the most Ethereum Improvement Proposals (EIPs) in Ethereum's history. It not only includes a series of proposals aimed at improving validator operations and mainnet performance but also introduces proposals to optimize L2. The Pectra Devnet 4 testnet has just launched, and 8 EIPs have already 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: enhancing account flexibility by adding code execution capabilities to EOAs, enabling them to perform more complex operations; increasing the staking cap may boost demand for ETH; and optimizing validator processes enhances security and efficiency, improving Ethereum's speed and throughput.

1. EIP-2537 (Support for BLS Signatures): By introducing a series of precompiled contracts, this EIP adds support for BLS12-381 curve operations to Ethereum, enabling BLS signature verification and allowing multiple signatures to be aggregated into one, thereby reducing complexity during verification. BLS signatures are a cryptographic algorithm that can generate smaller signatures and support signature aggregation. This will help L2s that require a large number of signature verifications and data validation operations to operate more effectively.
2. EIP-2935 (Store Historical Block Hashes in State): By storing the hashes of the most recent 8192 blocks in a system contract, this EIP supports the Stateless Clients model and provides more flexible historical block hash querying capabilities. These hashes can be queried directly through contracts and bundled as proofs to be provided to stateless clients. Clients do not need to maintain a complete blockchain history or store large amounts of data; they can verify the legitimacy of blocks and transactions by relying on the block hashes and related proofs stored in the state.
3. EIP-6110 (On-chain Validator Deposit Processing): This EIP moves the processing of validator deposits from the consensus layer to the execution layer, handling and verifying deposits on-chain without relying on additional voting mechanisms in the consensus layer to confirm the validity of deposit information. It enhances the security of the deposit process, reduces processing delays, and simplifies the design of the consensus layer and clients.
4. EIP-7002 (Execution Layer Triggered Exit): This EIP allows holders of withdrawal credentials to independently initiate exits without relying on the active key of the validator (BLS key), increasing user autonomy. Currently, only the active key of the validator can trigger an exit, meaning that if the active key is lost or the validator delegates validation tasks to a third party (such as a staking service provider), the holder of the withdrawal credential (the actual owner of the funds) cannot independently control the staked ETH. This proposal allows for the triggering of ETH exit and withdrawal operations through the execution layer, enabling holders to initiate exits using withdrawal credentials without relying on the active key.
5. EIP-7251 (Increase Staking Cap): This EIP increases the maximum effective balance of validators, allowing each validator to hold more than 32 ETH in stake, while the minimum staking threshold remains at 32 ETH. It aims to reduce the number of validators in the network by allowing large node operators to consolidate multiple validators, thereby reducing P2P messaging, signature aggregation, and storage burdens.
6. EIP-7549 (Remove Committee Index from Proofs): By removing the committee index field from Attestation messages, this EIP achieves more efficient consensus voting aggregation. Currently, in Ethereum's consensus mechanism, each validator's vote includes: LMD GHOST votes (which contain the block root and time slot of the vote), Casper-FFG votes (which contain source and target information), and the committee index (the committee number to which the validator belongs). Since the committee index is included in the signed message, when multiple validators vote on the same block, even if their voting content is the same, the generated signature roots differ, making it difficult to aggregate these votes. Removing the committee index field from the signed message itself allows for more efficient vote aggregation, reducing validation costs and network load.
7. EIP-7685 (General Execution Layer Requests): This EIP 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 allows different types of requests to be uniformly processed, simplifying the process of adding new request types without modifying the execution block structure.
8. EIP-7702 (Add Code Execution Capability to EOAs): This EIP adds code execution capabilities to externally owned accounts (EOAs), enhancing account flexibility and programmability. EOAs can authorize a smart contract to act on their behalf for certain operations, such as batch transactions or permission control, without needing to convert to a smart contract account, thus possessing certain smart contract functionalities.

Key Considerations for EIPs

Here are some EIPs that are actively being considered, primarily aimed at optimizing blobs to improve the cost stability of L2 data publishing, enhance L2 transaction processing capabilities, and effectively reduce L2 costs. Additionally, adjustments to calldata costs may impact the amount of ETH burned, increasing inflationary pressure on ETH.

• EIP-7742 (Decouple Blob Count Dependency Between Consensus and Execution Layers): This EIP decouples the blob count between the consensus layer and the execution layer, simplifying the blob verification process, reducing unnecessary complexity, and improving the scalability and flexibility of the protocol. In the current protocol, both the execution layer and the consensus layer have hardcoded maximum blob values, leading to redundant validation. This proposal removes the execution layer's validation of the maximum blob value, instead allowing the consensus layer to dynamically provide the target blob value to the execution layer. This way, the target parameters for blobs can be adjusted more flexibly to accommodate future scaling needs. EIP-7742 is among the proposals with the least controversy 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 formally included still awaits feedback from the execution layer in the ACDE (All Core Developers Execution Layer Meeting).
• EIP 7762 (Minimum Blob Base Fee): This EIP aims to increase MINBASEFEEPERBLOB_GAS to reduce the time required for blob price adjustments to reasonable levels. Currently, the minimum blob base fee is set at 1 wei, and when blob demand exceeds supply, the price discovery process (i.e., determining a reasonable blob gas price) is too slow, taking a long time to reach an appropriate fee level. By increasing the minimum blob base fee, the time for price adjustments can be shortened, allowing for quicker market equilibrium and ensuring network stability during peak demand.
• EIP-7623 (Increase Calldata Costs): This EIP proposes to raise the costs of calldata in transactions to reduce the maximum size of blocks and their variability, 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 like rollups, the average block size is continuously increasing. By increasing the calldata costs primarily used for data availability (DA) transactions, the maximum block size can be reduced to about 0.72 MB, leaving room for future increases in block gas limits or more blobs. The transaction costs for ordinary users remain unchanged; this change mainly affects transaction types that rely on Ethereum for large-scale data storage. However, the increase in calldata costs may reduce Ethereum's competitiveness in data storage. Additionally, the increase in calldata costs may lead to a decrease in transaction volume, resulting in a corresponding reduction in the amount of ETH burned through the EIP-1559 mechanism, thereby exerting greater inflationary pressure on ETH.
• EIP 7782 (Shorten Slot Time): This EIP proposes to shorten Ethereum's slot time from 12 seconds to 8 seconds, generating blocks more frequently to handle more transactions, serving as an alternative to increasing the number of blobs to improve transaction throughput. However, this may disrupt certain smart contracts that have hardcoded the 12-second slot time and accelerate Ethereum's state bloat issue, increasing storage and computational burdens.
• EIP-7783 (Gradually Increase Block Gas Fee Limits): As a milder alternative to EIP-7782, this EIP proposes to dynamically adjust the gas limits of blocks, gradually increasing the number of transactions each block can accommodate, thereby enhancing the network's processing capacity. Compared to directly shortening slot times, gradually adjusting gas limits allows for smoother network scaling. This proposal does not require a hard fork but may impact state data.

Due to the large number of EIPs included in the Pectra upgrade, to reduce the complexity of a single upgrade and accelerate the rollout of some EIPs, in May, the Ethereum Foundation's engineering team EthPandaOps suggested splitting Pectra into two parts. However, there were concerns that this would delay the upgrade, so it was not seriously considered at that time. In September, Ethereum researcher Alex Stokes proposed the split again, and this time it received developer consensus. This split will help complete the first part of the upgrade within six months:

• First Part: This includes the EIPs that are already running on the Pectra Devnet testnet (i.e., the confirmed 8 EIPs), which are relatively easier to implement and have undergone extensive testing.
• Second Part: This will include more complex EIPs (such as PeerDAS, EOF-related proposals) and other proposals that require more time for testing. These proposals need further development, auditing, and testing, especially those involving coordination between the consensus layer and the execution layer.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。