Translation | GaryMa Wu Blockchain
In addition to translating the original text, this article also provides a comprehensive introduction to other EIPs of Pectra not mentioned in the original text.
Original link:
https://coinmetrics.substack.com/p/state-of-the-network-issue-299
Key Points
Pectra is the next major upgrade of ETH, involving changes to the execution layer (Prague) and consensus layer (Electra). After a turbulent Pectra testnet upgrade, it was finally determined to activate the Pectra mainnet upgrade around 10:05 UTC on May 7th.
This upgrade will make critical improvements to staking, Layer 2 scalability, and user experience (UX), and lay the foundation for future changes.
Major changes include: raising the staking limit for validators, flexible staking withdrawals, enhanced account abstraction, and increased blob throughput to improve network efficiency and security.
Introduction
31 months after "The Merge", 24 months after the "Shapella" upgrade, and 13 months after the "Dencun" upgrade, ETH is about to undergo its next major upgrade - the Pectra hard fork.
The testnet upgrade before the Pectra mainnet upgrade was quite turbulent.
The Pectra upgrade on the Holesky testnet was activated on February 24th at 21:55 UTC, but was interrupted due to client software configuration errors (incorrect deposit contract addresses for Geth, Nethermind, and Besu), causing a chain fork. Developers discussed plans to recover the network through a large-scale penalty event, aiming to accelerate the exit of faulty validators and achieve network finality, which was finally realized on March 11th.
The Pectra upgrade on the Sepolia testnet was upgraded as planned on March 5th. Some execution layer (EL) clients experienced abnormalities when including transactions in blocks due to custom deposit contract configuration issues, but the problem was quickly resolved, and the network achieved finality.
On March 19th, a new testnet called Hoodi was launched to test validator exits, and the Pectra network upgrade was successfully activated on March 26th.
After two months of twists and turns in the ETH Pectra testnet upgrade, paving the way for mainnet deployment, it was finally determined to activate the Pectra mainnet upgrade around 10:05 UTC on May 7th.
Similar to previous ETH upgrades, Pectra involves both the execution layer (EL) and consensus layer (CL). Its name reflects this dual focus: Prague represents the execution layer upgrade, commemorating the location of Devcon 4; Electra symbolizes the consensus layer upgrade.
Pectra is one of the hard forks with the most EIPs (Ethereum Improvement Proposals) in ETH history, with 11 EIPs. Building on last year's Dencun upgrade, it aims to improve user experience (UX), optimize validator operations, and promote Layer 2 expansion, expected to have a profound impact on the ETH ecosystem.
In this article, we will categorize and analyze each EIP based on its domain.
Improvements to Validators and Staking Mechanisms
Pectra optimizes validator operations in the ETH PoS system through three main EIPs:
EIP-7251: Increasing Maximum Effective Balance (MaxEB)
Currently, ETH's staking mechanism limits the effective staking cap for a single validator to 32 ETH, meaning independent stakers must stake in 32 ETH increments, with rewards beyond this limit not counting towards effective staking.
EIP-7251 proposes raising the Maximum Effective Balance (MaxEB) to 2048 ETH, allowing single validators to stake between 32 and 2048 ETH, with impacts including:
· Enhanced Staking Flexibility: Stakers can reinvest all earnings into effective staking balance without being limited to 32 ETH multiples. For example, a validator with 33 ETH can now earn staking rewards on all 33 ETH, improving fund efficiency and flexibility.
· Reduced Validator Count: Currently, ETH has 1.05 million active validators. This EIP allows large operators to merge their validators, thereby reducing the total number and alleviating network burden.
· Decreased Network Load: While more validators contribute to decentralization, they also increase bandwidth and computational burden. Increasing MaxEB can optimize the validator set, reducing peer-to-peer communication overhead.
EIP-7002: Execution Layer-Triggered Withdrawals
EIP-7002 further enhances validator functionality by allowing direct triggering of exits and partial withdrawals through the execution layer (0x01) withdrawal credentials.
Currently, validators have two keys:
1. Active Key, used for performing validation duties;
2. Withdrawal Key, used to access and manage staked funds.
Previously, only the active key could trigger exits, while the withdrawal key could not operate independently. EIP-7002 allows the withdrawal key to trigger withdrawals, bringing:
· Greater Fund Control: Validators can directly manage funds without relying on node operators.
· Support for Fully Trustless Staking Pools, improving security and decentralization.
EIP-6110: On-Chain Storage of Validator Deposits
Currently, when a new validator deposits on the execution layer, they must wait for the consensus layer to identify and process it, causing activation delays.
EIP-6110 allows the execution layer to directly transmit deposit information to the consensus layer, reducing additional verification steps and shortening validator activation time from about 9 hours to about 13 minutes.
Enhancing Layer 2 Scalability: Increasing Blob Throughput
EIP-7691: Increasing Blob Throughput
The Dencun upgrade last year introduced Blobs as an efficient method for Layer 2 rollups to store data. Currently, about 21,000 Blobs are submitted on ETH daily, but capacity is near its limit, causing fee increases and throughput limitations.
Currently, ETH targets 3 Blobs per block, with a maximum of 6. EIP-7691 proposes increasing the target to 6 and the maximum to 9 to increase data storage capacity, improve throughput and scalability. This will reduce data storage costs and consequently lower L2 transaction fees.
EIP-7623: Increasing Calldata Costs
Before the Blob mechanism, L2 primarily used calldata for data storage and may still use it in some cases as it can be more cost-effective.
EIP-7623 increases calldata fees to encourage L2 to primarily use blobs for data storage, thereby improving rollup transaction efficiency.
User Experience (UX) Enhancement
EIP-7702: Setting EOA Account Code
Core Idea: Temporarily Granting Smart Contract Capabilities to EOA
EIP-7702 introduces a new transaction type (identified as 0x04) allowing Externally Owned Accounts (EOA) to temporarily gain smart contract functionality during a single transaction. Traditionally, EOA has no code and can only sign transactions, but this proposal allows EOA to "load" code in a transaction, enabling complex operations like a smart contract wallet.
Main Advantages
1. Batch Operations: Users can complete multiple operations in one transaction (e.g., combining approve + deposit), avoiding the inefficiency of multiple transactions.
· Gas Sponsorship: This mechanism can also support third-party transaction fee sponsorship, improving user experience by allowing users to operate without pre-holding ETH.
· Enhanced Security and Flexibility: Users can implement fine-grained transaction permission controls, such as allowing sub-accounts to operate under specific conditions, enhancing account security.
Potential Challenges
· Ecosystem Compatibility: Since EOA has traditionally been considered codeless, some existing smart contracts or security checks (like require(tx.origin == msg.sender)) may need adjustment to accommodate this temporary code-granting mechanism.
· Increased Transaction Complexity: The introduction of a new transaction type will require significant modifications to wallets and clients to ensure no security vulnerabilities or additional high costs when handling new authorization tuples and temporary code settings.
EIP-7702 allows ordinary EOA to temporarily obtain smart contract functionality in a single transaction, supporting batch transactions, transaction sponsorship, and more flexible permission management. This mechanism can greatly improve user experience and expand dApp functionality, but it will also break some traditional assumptions, requiring ecosystem participants to adapt and update. Overall, this is an important proposal paving the way for account abstraction, with the goal of making future Ethereum accounts both secure and more flexible.
Other EIPs
EIP-7685: Universal Execution Layer Requests
Background and Purpose
Currently, there are three main requests that need to be processed between Eth1 (execution layer) and the beacon chain (consensus layer):
1. Deposits: Deposit events initiated by users initially appear in Eth1 blocks but ultimately need to be processed on the beacon chain.
2. Withdrawals: Withdrawal requests from the beacon chain (usually through command-line tools) need to be processed on Eth1.
3. Validator Merging: Similarly, such requests need to be passed between Eth1 and the beacon chain.
Why This Proposal is Needed
Currently, different types of operations are passed back and forth between the two layers, which can cause confusion. The unified processing framework proposed by EIP-7685 aims to:
· Handle all these requests with a standard method, making the process clearer and more efficient;
· Rely solely on Eth1 to trigger these operations, separating the validator's running environment from staking management, thereby improving security.
Main Content
1. Request Type Identification: Specific identifiers are defined for each operation, such as existing deposit and withdrawal request types, and now adding a merge request type.
2. Integrity Guarantee: Mechanisms (such as hash verification, Merkleized data) will be used to ensure the integrity and security of request data.
3. Processing Queue and Rate Limiting: Restrictions will be set for pending requests (such as the number of simultaneous waiting deposits, withdrawals, or merge requests) to prevent system overload.
Final Significance
For ordinary users and developers, this means that in the future, whether initiating deposits, withdrawals, or validator merging operations, they can complete them faster and more securely through a unified, standardized process. This not only improves system efficiency but also helps reduce overall risk.
(Note: The translation continues in the same manner for the rest of the text, maintaining the specified translation rules.)Pectra, as an upgrade covering a record number of EIPs, will drive Ethereum's development in key directions such as account abstraction, validator mechanism optimization, network efficiency improvement, and Layer 2 expansion. At the same time, as Vitalik Buterin recently emphasized, although Ethereum adopts a Rollup-centric expansion route, it continues to optimize Layer 1, such as recently raising the gas limit to 36 million, and may further enhance its resistance to censorship, throughput, and scalability in the future.
Reference link:
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7600.md
