Original: Pectra: Ethereum’s Next Major Upgrade
Author: Tanay Ved, Coin Metrics
Translation: GaryMa, Wu Says Blockchain
In addition to the translation of the original text, this article also provides a comprehensive introduction to other EIPs related to Pectra that were not mentioned in the original.
Key Points
Pectra is Ethereum's next major upgrade, involving changes to the execution layer (Prague) and the consensus layer (Electra). After a series of ups and downs during the testnet Pectra upgrade, it has been confirmed to activate the Pectra mainnet upgrade around 10:05 UTC on May 7.
This upgrade will bring critical improvements to staking, Layer 2 scalability, and user experience (UX), laying the groundwork for future transformations.
Key changes include: increasing the staking cap for validators, flexible staking withdrawals, enhancements to account abstraction, and increased blob throughput to improve network efficiency and security.
Introduction
It has been 31 months since "The Merge," 24 months since the "Shapella" upgrade, and 13 months since the "Dencun" upgrade. Ethereum is about to welcome its next major upgrade — the Pectra hard fork.
The testnet upgrade before the Pectra mainnet upgrade has been quite eventful.
The Pectra upgrade on the Holesky testnet was activated on February 24 at 21:55 UTC, but was interrupted due to client software configuration errors (incorrect deposit contract addresses for Geth, Nethermind, and Besu), leading to a chain split. Developers discussed plans to restore the network through a large-scale penalty event aimed at accelerating the exit of erroneous validators and achieving network finality, which was not accomplished until March 11.
The Pectra upgrade on the Sepolia testnet was successfully upgraded as scheduled on March 5, although some execution layer (EL) clients encountered exceptions when including transactions in blocks due to custom deposit contract configuration issues. However, the problem was quickly resolved, and the network achieved finality.
On March 19, a new testnet called Hoodi was launched to test validator exits, and the Pectra network upgrade was successfully activated on March 26.
The Ethereum Pectra testnet upgrade has gone through two months of ups and downs, paving the way for the mainnet deployment, which is confirmed to activate the Pectra mainnet upgrade around 10:05 UTC on May 7.
Similar to previous Ethereum upgrades, Pectra involves both the execution layer (EL) and the 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 in Ethereum's history involving the largest number of EIPs (11 EIPs). It further optimizes the Dencun upgrade from last year, aiming to improve user experience (UX), optimize validator operations, and promote Layer 2 expansion, which is expected to have a profound impact on the Ethereum ecosystem.
In this article, we will categorize and analyze each EIP based on its respective domain.
Improvements to Validators and Staking Mechanisms
Pectra optimizes the validator operation experience in Ethereum's PoS system through three main EIPs:
EIP-7251: Increase Maximum Effective Balance (MaxEB)
Currently, Ethereum's staking mechanism limits the effective staking cap for a single validator to 32 ETH, meaning independent stakers must stake in multiples of 32 ETH, and rewards exceeding this limit do not count towards effective staking.
EIP-7251 proposes to increase the maximum effective balance (MaxEB) to 2048 ETH, allowing a single validator's staking range to expand from 32 to 2048 ETH, with the following impacts:
· Enhanced Staking Flexibility: Stakers can reinvest all earnings into the effective staking balance without being limited to multiples of 32 ETH. For example, a validator holding 33 ETH can now earn staking rewards on all 33 ETH, improving capital efficiency and flexibility.
· Reduced Number of Validators: Currently, there are 1.05 million active validators on Ethereum. This EIP allows large operators to consolidate their validators, thereby reducing the total number and alleviating network burden.
· Decreased Network Load: While having more validators helps decentralization, it also increases bandwidth and computational load. Increasing MaxEB can optimize the validator set and reduce the overhead of peer-to-peer communication.
EIP-7002: Execution Layer Triggered Withdrawals
EIP-7002 further enhances validator functionality by allowing them to directly trigger exits and partial withdrawals through execution layer (0x01) withdrawal vouchers.
Currently, validators have two keys:
Active Key: Used to perform validation duties;
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 also trigger withdrawals, resulting in:
· Greater Control Over Funds: Validators can directly manage funds without relying on node operators.
· Support for Fully Trustless Staking Pools, enhancing security and decentralization.
EIP-6110: On-Chain Storage of Validator Deposits
Currently, when new validators deposit on the execution layer, they must wait for the consensus layer to recognize and process it, leading to activation delays.
EIP-6110 allows the execution layer to directly pass deposit information to the consensus layer, reducing additional verification steps and shortening the activation time for validators from about 9 hours to approximately 13 minutes.
Enhancing Layer 2 Scalability: Increasing Blob Throughput
EIP-7691: Increase Blob Throughput
Last year's Dencun upgrade introduced Blobs as an efficient way for Layer 2 rollups to store data. Currently, about 21,000 Blobs are submitted to Ethereum daily, but capacity is nearing its limit, leading to rising fees and limiting throughput.
Currently, the target number of Blobs per Ethereum block is 3, with a maximum of 6. EIP-7691 proposes to increase the target value to 6 and the maximum to 9, thereby increasing data storage capacity and improving throughput and scalability. This will lower data storage costs, thereby reducing L2 transaction fees.
EIP-7623: Increase calldata Costs
Before the introduction of the Blob mechanism, L2 primarily used calldata to store data and still does so in some cases, as it may be more cost-effective.
EIP-7623 increases calldata fees to incentivize L2 to primarily use blob storage, thereby enhancing rollup transaction efficiency.
User Experience (UX) Enhancements
EIP-7702: Set EOA Account Code
Core Idea: Temporarily Grant EOA Smart Contract Capabilities
EIP-7702 introduces a new transaction type (identified as 0x04) that allows externally owned accounts (EOA) to temporarily gain smart contract functionality during the execution of a transaction. In other words, while traditionally EOAs have no code and can only be used to sign transactions, this proposal allows EOAs to "load" a piece of code within a transaction, enabling them to perform complex operations like a smart contract wallet.
Main Advantages
- Batch Operations: Users can complete multiple operations in a single transaction (e.g., approve + deposit combination), avoiding the inefficiency of needing multiple transactions.
· Gas Sponsorship: This mechanism can also support third-party sponsorship of transaction fees, improving user experience by allowing users to operate without needing to hold ETH in advance.
· Enhanced Security and Flexibility: Users can implement fine-grained permission controls for transactions, such as allowing only sub-accounts to operate under certain conditions, enhancing account security.
Potential Challenges
· Ecosystem Compatibility Issues: Since EOAs are traditionally considered to have no code, some existing smart contracts or security checks (e.g., require(tx.origin == msg.sender)) may need adjustments to accommodate this temporarily granted code mechanism.
· Increased Transaction Structure Complexity: The introduction of a new transaction type will require significant changes to wallets and clients to ensure that no security vulnerabilities or additional high costs arise when handling new authorization tuples and temporary code settings.
EIP-7702 allows ordinary EOAs to temporarily gain smart contract functionality within 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 adaptation and updates from all parties in the ecosystem. Overall, this is an important proposal paving the way for account abstraction, aiming to make future Ethereum accounts both secure and more flexible.
Other EIPs
EIP-7685: General Execution Layer Requests
Background and Purpose
Currently, Eth1 (execution layer) and the beacon chain (consensus layer) need to handle three main types of requests:
1. Deposits: User-initiated deposit events initially appear in Eth1 blocks but ultimately need to be processed on the beacon chain.
2. Withdrawals: Withdrawal requests initiated from the beacon chain (usually via command-line tools) need to be processed on Eth1.
3. Validator Merges: Similarly, this type of request also needs to be transmitted 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 lead to confusion. The unified processing framework proposed by EIP-7685 aims to:
· Handle all these requests in a standardized manner, making the process clearer and more efficient;
· Trigger these operations solely relying on Eth1, thereby separating the validator's operating environment from staking management, thus enhancing security.
Main Content
1. Request Type Identification: Specific identifiers are defined for each type of operation, such as existing deposit and withdrawal request types, with the addition of a merge request type.
2. Integrity Assurance: Mechanisms (such as hash checks and Merkle data) will be employed to ensure the integrity and security of request data.
3. Processing Queue and Rate Limiting: Limits will be set for pending requests (such as the number of simultaneous deposit, withdrawal, 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 merges, operations can be completed more quickly and securely through a unified, standardized process. This not only improves system efficiency but also helps reduce overall risk.
EIP-2537: Precompiled Operations for BLS12–381 Curve
Core Purpose
This proposal adds built-in functionality (known as precompiled contracts) in Ethereum specifically for handling mathematical operations on the BLS12–381 curve.
Why This Precompile is Needed
· Efficiency Improvement: Implementing complex elliptic curve operations (such as signature verification and aggregation) directly in smart contracts consumes a significant amount of gas. Precompiled contracts can greatly reduce the cost of these operations.
· Higher Security: Compared to the currently used BN254 curve (which offers about 80 bits of security), the BLS12–381 curve provides approximately 120 bits of security, making cryptographic operations more secure.
Main Uses
· BLS Signature Verification: BLS signatures allow multiple signatures to be aggregated into one, significantly reducing the computational load during verification.
· zkSNARK Proof Verification: In some privacy-preserving and scalability solutions, zkSNARK proofs need to be verified, which also relies on complex elliptic curve computations.
Practical Significance
With this EIP, developers can use cryptographic operations related to the BLS12–381 curve more efficiently and at a lower cost in smart contracts, thereby supporting more innovative applications, such as more efficient consensus mechanisms, cross-chain interactions, and various decentralized applications.
In short, EIP-2537 aims to address the excessive gas consumption issue when performing high-security cryptographic operations on-chain, making these complex computations more efficient and practical through precompiled contracts.
EIP-2935: Storing Historical Block Hashes in State
Current Issue
In the Ethereum Virtual Machine (EVM), the BLOCKHASH opcode can only retrieve the hashes of the most recent 256 blocks (approximately within the last 50 minutes), which is insufficient for certain applications, such as cross-chain applications that need to prove data from earlier blocks or stateless clients (like rollups).
Core of the Proposal
EIP-2935 proposes to additionally store the hashes of 8192 blocks (approximately within the last 27.3 hours) in the blockchain's state, significantly expanding the range of historical block data available for querying.
How to Implement
In addition to maintaining the existing BLOCKHASH opcode's access to only the most recent 256 blocks, the proposal will introduce a dedicated new system contract:
· set() Method: When each block is processed, the new contract will automatically store the current block hash in a circular buffer.
· get() Method: Anyone or any smart contract can query the historical block hashes stored in the circular buffer through this method.
Practical Benefits
This way, cross-chain applications, rollups, or other systems that need access to earlier block data can directly obtain the required historical information on-chain without relying on external data, making their design simpler, safer, and more reliable.
EIP-7840: Adding Blob Scheduling to EL Configuration
Core Purpose
This proposal aims to write key parameters related to blob scheduling (such as the number of blobs allowed per block and the base fee update ratio) into the configuration file of the execution layer (EL).
Specific Actions
· Add settings for "target blob count" and "maximum blob count" in the configuration file.
· Introduce a parameter called baseFeeUpdateFraction to adjust the speed of base fee updates.
· Clients can query these parameters through the node API to understand the current network's specific configuration for blobs.
Why It’s Useful
This information can help developers and node operators more accurately estimate blob gas costs and assist the network in better managing the scheduling and processing of large data in blocks.
Overall, EIP-7840 adds a set of configurable blob scheduling parameters to the Ethereum execution layer, making the network more efficient and transparent when handling large data (blobs).
EIP-7549: Removing Committee Index from Attestation
Core Idea
Currently, the attestation message contains three parts:
· LMD GHOST Vote (including block root and time slot)
· Casper-FFG Vote (including source and target)
· Committee Index (index)
The issue is that the committee index is also signed, which means that even if the voting content is the same, different indices will result in different signature roots. This prevents votes with the same content from being aggregated.
EIP-7549 proposes to solve this by removing the committee index from the signed voting message. This way, only the core content of the vote (LMD GHOST and Casper-FFG votes) will participate in the signature calculation, allowing multiple validators with the same vote to produce the same signature root, thus enabling aggregation.
Main Benefits
· Significantly Reduces Validation Workload: Currently, to achieve 2/3 consensus, it may require validating 1366 votes. After removing the committee index, only about 22 votes need to be validated (saving approximately 62 times the computational load), which greatly enhances efficiency in the validation process, especially for Casper FFG clients based on zero-knowledge proofs.
· Improves On-Chain Data Storage Efficiency: Since voting information can be aggregated more efficiently, more votes can be packed into each block. Currently, a block can only contain votes from 2 time slots; with the improvement, it can accommodate votes from up to 8 time slots, allowing all votes to be included in a block even if only 1/8 of the proposers are online.
By removing the committee index from the attestation message, not only can the number of pairing operations required during vote validation be greatly reduced, but the packing of voting data can also be made more efficient, enhancing the performance of the entire consensus validation process and on-chain storage utilization. This improvement is particularly important for the Casper FFG consensus mechanism and its related zero-knowledge proof validation.
Conclusion
As an upgrade encompassing a record number of EIPs, Pectra will drive Ethereum's development in key areas such as account abstraction, validator mechanism optimization, network efficiency enhancement, and Layer 2 expansion. Moreover, as Vitalik Buterin recently emphasized, while Ethereum adopts a rollup-centric scaling route, it continues to optimize Layer 1, such as the recent increase of the gas limit to 36 million, with potential future enhancements to censorship resistance, throughput, and scalability.
Reference link:
https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7600.md
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
