A Comprehensive Understanding of the Ethereum Pectra Upgrade: Detailed Analysis of Each EIP

Original: Pectra: Ethereum's Next Major Upgrade

Author: Tanay Ved, Coin Metrics

Compiled by: GaryMa, Wu Says Blockchain

In addition to the compilation of the original text, this article also supplements the introduction of 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 upgrade of Pectra, it has been finalized 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 in 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 tumultuous.

The Pectra upgrade on the Holesky testnet was activated on February 24 at 21:55 UTC, but it 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 finality, which was not realized 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 finalized 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 their respective domains.

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 impacts including:

· 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, thus reducing the total number and alleviating network burden.

· Decreased Network Load: While more validators help decentralization, they also increase 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, allowing them to directly trigger exits and partial withdrawals through execution layer (0x01) withdrawal credentials.

Currently, validators have two keys:

1. Active Key: Used to perform 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 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 in 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 validator activation time from about 9 hours to approximately 13 minutes.

Enhancing Layer 2 Scalability: Increasing Blob Throughput

EIP-7691: Increase Blob Throughput

The Dencun upgrade last year introduced Blobs as an efficient way to store data for Layer 2 rollups. Currently, about 21,000 Blobs are submitted to Ethereum daily, but capacity is nearing its limit, leading to increased fees and limiting throughput.

Currently, the target number of Blobs per Ethereum block is 3, with a maximum of 6. EIP-7691 proposes to raise the target value to 6 and the maximum to 9 to increase data storage capacity, 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 for data, 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

1. Batch Operations: Users can complete multiple operations (e.g., approve + deposit combination) in a single transaction, avoiding the inefficiencies 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, there are three main types of requests that need to be processed between Eth1 (execution layer) and the beacon chain (consensus layer):

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 sent 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 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 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, 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: Some limits will be set for pending requests (such as the number of simultaneous waiting 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, they can complete these operations faster and more securely through a unified, standardized process. This not only improves system efficiency but also helps reduce overall risk.

EIP-2537: BLS12-381 Curve Operations Precompile

Core Purpose

This proposal adds built-in functionality (called precompiled contracts) in Ethereum specifically for handling mathematical operations on the BLS12-381 curve.

Why This Precompile is Needed

· Efficiency Improvement: Directly implementing complex elliptic curve operations (such as signature verification and aggregation) in smart contracts consumes a lot of gas. Precompiled contracts can significantly reduce the cost of these operations.

· Higher Security: Compared to the currently used BN254 curve (which has about 80 bits of security), the BLS12-381 curve offers about 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, and these operations also rely on complex elliptic curve computations.

Practical Significance

Through this EIP, developers can use BLS12-381 curve-related cryptographic operations more efficiently and cost-effectively in smart contracts, 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 issue of excessive gas consumption when performing high-security cryptographic operations on-chain, making these complex computations more efficient and practical through precompiled contracts.

EIP-2935: Store 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 state, significantly expanding the range of historical block data available for querying.

How to Implement

In addition to keeping the existing BLOCKHASH opcode limited to 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 to access earlier block data can directly obtain the required historical information on-chain without relying on external data, making their designs simpler, safer, and more reliable.

EIP-7840: Add 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 execution layer (EL) configuration file.

Specific Actions

· Add settings for "target blob count" and "maximum blob count" in the configuration file.

· Also include a parameter called baseFeeUpdateFraction to adjust the speed of base fee updates.

· Clients can query these parameters through the node API to know the current network configuration for blobs.

Why This is 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 Ethereum's execution layer, making the network more efficient and transparent when handling large data (blobs).

EIP-7549: Remove Committee Index from Attestation

Core Idea

Currently, the validator voting (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 lead to 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 Reduce 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 significantly improves efficiency for the validation process that requires a large number of pairing operations, especially for zero-knowledge proof-based Casper FFG clients.

· Improve 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 for validating votes be greatly reduced, but it can also pack voting data more efficiently, 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. At the same time, as Vitalik Buterin recently emphasized, while Ethereum adopts a rollup-centric scaling approach, it continues to optimize Layer 1, such as recently raising the gas limit to 36 million, with further improvements in censorship resistance, throughput, and scalability expected in the future.

Reference Links:

https://github.com/ethereum/EIPs/blob/master/EIPS/eip-7600.md