Learn about Ethereum Pectra upgrade in one article: full analysis of various EIPs

Original text: Pectra: Ethereum's Next Major Upgrade

Author : Tanay Ved, Coin Metrics

Compiled by : GaryMa, Wu said blockchain

In addition to compiling the original text, this article also provides a complete introduction to other Pectra EIPs not mentioned in the original text.

Key Points

Pectra is the next major upgrade of Ethereum, involving changes to the execution layer (Prague) and consensus layer (Electra). After experiencing the twists and turns of the test network Pectra upgrade, it was finally determined to activate the Pectra main network upgrade near UTC on May 7 at 10:05.

This upgrade will make critical improvements to staking, Layer 2 scalability, and User Experience (UX) and lay the foundation for future changes.

Key changes include: increasing the staking cap for validators, flexible staking withdrawals, enhanced account abstraction, and increasing blob throughput to improve network efficiency and security.

introduction

It has been 31 months since the Merge, 24 months after the "Shapella" upgrade, and 13 months after the "Dencun" upgrade, Ethereum is about to usher in its next major upgrade - Pectra hard fork.

The test network upgrade before the Pectra main network upgrade was a twists and turns.

The Pectra upgrade of Holesky Test Network was activated at 21:55 UTC on February 24, but the chain fork was interrupted due to a misconfiguration of client software (the wrong deposit contract address of Geth, Nethermind and Besu). The developers discussed plans to restore the network through massive penalties events, aiming to speed up the exit of error validators and achieve network finality until March 11.

The Pectra upgrade of Sepolia test network was upgraded as planned on March 5. Due to the custom deposit contract configuration problem, some execution layer (EL) clients encountered abnormalities when including transactions in the block. However, the problem was quickly fixed and the network was finalized.

On March 19, in order to exit test validators, a new test network Hoodi was launched, and the Pectra network upgrade was successfully activated on March 26.

The upgrade of the Ethereum Pectra test network has gone through two months of twists and turns, paving the way for the main network deployment, and it was finally determined to activate the Pectra main network upgrade near UTC on May 7 at 10:05.

Similar to previous Ethereum upgrades, Pectra involves both the execution layer (EL) and the consensus layer (CL). Its name reflects this double focus: Prague represents the executive layer upgrade to commemorate the Devcon 4 venue; Electra (Electra Star) symbolizes the consensus layer upgrade.

Pectra is one of the hard forks that involve the largest number of EIPs (Ethereum Improvement Proposals) in Ethereum (11 EIPs). It is further optimized based on last year's Dencun upgrade, aiming to improve user experience (UX), optimize validator operations, and drive Layer 2 expansion, which is expected to have a profound impact on the Ethereum ecosystem.

In this article, we will classify and divide each EIP according to the field to which each EIP belongs, and deeply analyze each EIP.

Improvements to validator and staking mechanisms

Pectra optimizes the validator operation experience in Ethereum PoS systems with three major EIPs:

EIP-7251: Increase the maximum effective balance (MaxEB)

Currently, Ethereum’s staking mechanism limits the maximum valid staking of a single verifier to 32 ETH, which means that independent stakingers must stake in units of 32 ETH, and rewards exceeding this limit will not be counted as valid staking.

EIP-7251 proposes to increase the maximum effective balance (MaxEB) to 2048 ETH, allowing the staking range of a single validator to be extended to 32 to 2048 ETH, with the impacts including:

· Improve pledge flexibility : The pledger can reinvest all profits into the effective pledge balance without being limited to multiples of 32 ETH. For example, a validator holding 33 ETH can now receive staking rewards for all 33 ETH, which improves funding efficiency and flexibility.

· Reduce the number of validators : Ethereum currently has 1.05 million active validators, and the EIP allows large operators to merge their validators, thereby reducing the total number and reducing the burden on the network.

· Reduce network load : Although more validators help decentralize, they also increase bandwidth and computing burden. Improving MaxEB can optimize the validator set and reduce the overhead of point-to-point communication.

EIP-7002: The execution layer can trigger withdrawals

EIP-7002 further enhances the validator function, allowing it to send out and partial withdrawals directly through the execution layer (0x01) withdrawal voucher.

Currently, the verifier has two keys:

1. Activity key , used to perform verification duties;

2. Withdrawal key , used to access and manage pledged funds.

Previously, only the active key could trigger the exit, while the withdrawal key could not be operated independently. EIP-7002 allows withdrawal keys to trigger withdrawals, which brings:

· Greater control of funds : Verifiers can manage funds directly without relying on node operators.

· Supports fully trustless staking pools to improve security and decentralization.

EIP-6110: On-chain storage verifier deposits

Currently, when a new validator deposits at the execution layer, he needs to wait for the consensus layer to recognize and process, resulting in activation delay.

EIP-6110 allows the execution layer to pass deposit information directly to the consensus layer, reducing additional verification steps and reducing the activation time of the verifier from about 9 hours to about 13 minutes.

Improve Layer 2 scaling capabilities: Increase Blob throughput

EIP-7691: Increase Blob Throughput

Last year, the Dencun upgrade introduced Blobs as an efficient way for Layer 2 rollups to store data. Currently, about 21,000 blobs are submitted on Ethereum every day, but the capacity is close to the upper limit, causing fees to rise and limiting throughput.

Currently, the number of target blobs per block of Ethereum is 3, with a maximum of 6. EIP-7691 proposes to increase its target value to 6 and maximum value to 9 to increase data storage capacity, improve throughput and scalability. This will reduce data storage costs, thereby reducing L2 transaction fees.

EIP-7623: Increase calldata cost

Prior to the introduction of the Blob mechanism, L2 used calldata to store data and was still in use in some cases because it could be more cost-effective.

EIP-7623 increases calldata fees to incentivize L2 to mainly use blobs to store data, thereby improving rollup transaction efficiency.

User Experience (UX) Enhancement

EIP-7702: Set up EOA Account Code

Core idea: temporary empowerment of EOA smart contract capabilities

EIP-7702 introduces a completely new transaction type (identified as 0x04) that allows externally owned accounts (EOA) to temporarily obtain smart contracts during execution of a transaction. That is to say, although traditionally EOA has no code and can only be used to sign transactions, through this proposal, EOA can "load" a piece of code in a transaction, thus performing complex operations like a smart contract wallet.

Key Advantages

1. Batch operation: Users can complete multiple operations within a transaction (such as approve + deposit combination), avoiding the inefficiency problem of requiring multiple transactions.

· Gas Sponsorship: This mechanism can also support third-party sponsorship transaction fees, improve user experience, and allow users to operate without pre-holding ETH.

· Improved security and flexibility: Users can perform fine-grained permission control on transactions, such as allowing only sub-accounts to operate under limited conditions, which enhances account security.

Possible challenges

· Ecocompatibility issues: Since EOA is traditionally considered to have no code, some existing smart contracts or security checks (such as require(tx.origin == msg.sender)) may need to be adjusted to accommodate this mechanism of temporary code-giving.

· Increased transaction structure complexity: The introduction of new transaction types will require major changes to the wallet and client, ensuring that there are 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, thus supporting batch transactions, transaction sponsorship, and more flexible permission management. This mechanism can greatly improve user experience and expand dApp functions, but it will also break some traditional assumptions and require adaptation and updates from all parties in the ecosystem. Overall, this is an important proposal to pave the way for account abstraction, with the goal of making future Ethereum accounts both safe and flexible.

Other EIPs

EIP-7685: General Execution Layer Request

Background and purpose

Currently, there are three main requests that need to be processed between Eth1 (execution layer) and beacon chain (consensus layer):

1. Deposit : User-initiated deposit events initially appear in the Eth1 block, but ultimately need to be processed on the beacon chain.

2. Withdrawal : Withdrawal requests issued from the beacon chain (usually through the command line tool) need to be processed on Eth1.

3. Verifier merge : Similarly, this request 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 two layers, which can easily cause confusion. The unified processing framework proposed by EIP-7685 aims to:

· Handle all these requests in a standard way to make the process clearer and more efficient;

· Relying on Eth1 alone to trigger these operations, this will separate the verifier's operating environment and staking management, thereby improving security.

Main content

1. Request type identification : A specific identification is defined for each operation, such as existing deposit and withdrawal request types, and now the merge request type needs to be added.

2. Integrity assurance : Some mechanisms (such as hash verification and Merkelized data) will be used to ensure the integrity and security of the requested data.

3. Process queues and speed limits : Some restrictions are set for pending requests (such as the number of deposits, withdrawals or merge requests waiting at the same time) to prevent system overload.

The ultimate meaning

For ordinary users and developers, this means that in the future, whether it is initiating deposits, withdrawals or verifier mergers, it can be completed faster and safer through a unified and standardized process. This not only improves the efficiency of the system, but also helps reduce overall risks.

EIP-2537: Precompilation of BLS12–381 Curve Operation

Core purpose

This proposal adds built-in functionality (called precompiled contracts) to Ethereum, specifically used to handle math operations on the BLS12–381 curve.

Why this precompilation is needed

· Efficiency improvement: Direct implementation of complex elliptic curve operations (such as signature verification and aggregation) in smart contracts will consume a lot of gas. Precompiled contracts can significantly reduce the cost of these operations.

· Higher security: The BLS12–381 curve provides about 120 bits of security compared to the currently used BN254 curve (about 80 bits of security), making encryption operations safer.

Main uses

· BLS signature verification: BLS signature allows multiple signatures to be aggregated into one, thereby greatly reducing the amount of computation during verification.

· zkSNARK Proof Verification: In some privacy protection and scalability solutions, zkSNARK Proof is required, and these operations also rely on complex elliptic curve calculations.

Practical significance

Through this EIP, developers can use BLS12–381 curve-related encryption operations more efficiently and at a low 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 is to solve the problem of consuming too much gas when performing high-security encryption operations on the chain, and to make these complex operations more efficient and practical by precompiling contracts.

EIP-2935: Save historical block hash in state

Current Problem

In Ethereum virtual machine (EVM), the BLOCKHASH opcode can only find the hash of the last 256 blocks (within about 50 minutes), which is not enough for some applications, such as cross-chain applications or stateless clients (such as rollups) that need to prove earlier block data.

The core of the proposal

EIP-2935 proposes to save an additional hash of 8192 blocks (about 27.3 hours) in the blockchain state, which greatly expands the range of historical block data available for query.

How to implement it

In addition to keeping the existing BLOCKHASH opcode accessible only to the last 256 blocks, the proposal will also introduce a specialized new system contract:

· set() method: When each block is processed, the new contract will automatically store the current block hash into a ring buffer.

· get() method: Anyone or smart contract can use this method to query the hash of the historical block stored in the ring buffer.

Actual benefits

This allows cross-chain applications, rollups, or other systems that require access to earlier block data to obtain the required historical information directly on the chain without additional dependence on external data, which makes their design simpler, safer and more reliable.

EIP-7840: Add blob schedule to EL configuration file

Core purpose

This proposal aims to write key parameters about blob scheduling, such as the number of blobs allowed per block and the proportion of basic fee updates, into the execution layer (EL) configuration file.

Specific practices

· Add settings for "Target blob count" and "Maximum blob count" in the configuration file.

· Add a parameter called baseFeeUpdateFraction is added to adjust the update speed of the basic handling fee.

· The client can query these parameters through the node API to know the specific configuration of the blob in the current network.

Why is it useful

This information can help developers and node operators estimate blob gas fees more accurately, and also help the network better manage the scheduling and processing of big data in blocks.

In general, EIP-7840 adds a set of configurable blob scheduling parameters to the Ethereum execution layer, making the network more efficient and transparent when processing big data (blobs).

EIP-7549: Move the committee index out of the proof

Core idea

Currently, the Attestation message contains three parts:

· LMD GHOST voting (including block root and time slot)

· Casper-FFG voting (including source and target)

· Committee Index (index)

The problem is that the committee index is also signed, which causes the generated signature roots to be different due to different indexes, even if the vote content is the same. This will prevent votes of the same content from being aggregated.

The solution proposed by EIP-7549 is to remove the committee index from the signed voting message. In this way, only the core content of the voting (LMD GHOST and Casper-FFG voting) will participate in the signature calculation, allowing multiple validators of the same voting to produce the same signature root, which can be aggregated together.

Key benefits

· Sharply reduce verification workload: In current situations, in order to achieve 2/3 of the consensus, 1366 votes may be required to be verified. After removing the committee index, only about 22 votes are verified (a saving about 62 times the amount of calculations) which is a significant improvement in efficiency for verification processes that require a lot of pairing operations, especially for Casper FFG clients based on zero-knowledge proofs.

· Improving on-chain data storage efficiency: Since voting information can be aggregated more efficiently, more votes can be packaged in each block. Now a block can only contain voting with 2 time slots. After improvement, it can reach up to 8 time slots. Even if only 1/8 of the proposers are online, all votes can be included in the block.

By removing the committee index from the Attestation message, not only can the number of pairing operations that need to be processed when verifying the vote, but it can also package the voting data more efficiently, improving the performance and on-chain storage utilization of the entire consensus verification process. This improvement is particularly important for the Casper FFG consensus mechanism and its associated zero-knowledge proof verification.

in conclusion

As an upgrade covering a record number of EIPs, Pectra will promote Ethereum to develop 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 is still continuously optimizing Layer 1. For example, the recent increase of Gas limit to 36 million may further improve censorship resistance, throughput and scalability in the future.

Reference link:

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