Table of Contents
Ethereum Historical Upgrades
Core EIPs of Pectra
Functional Improvements Brought by Pectra
3.1 Consensus Mechanism and Validator Optimization
3.2 Network Performance and Scalability Enhancement
3.3 Historical Data Access and State Management
3.4 Account Abstraction
3.5 Cryptography and Precompiled Optimization
3.6 Introduction of Verkle Trees
Impact
References
Ethereum developers publicly announced at the All Core Developers Consensus (ACDC) meeting held in April 2025 that the highly anticipated Pectra upgrade will officially launch on the Ethereum mainnet on May 7, 2025, after successfully running on the Hoodi testnet.
- Ethereum Historical Upgrades
Since the launch of Ethereum, it has undergone multiple upgrades. The earliest upgrades, such as Homestead and Byzantium, primarily aimed to make the network more stable and secure. Later, the DAO fork occurred due to a significant security incident, which made community governance increasingly important. Subsequently, Constantinople and Istanbul introduced several EIPs to optimize smart contract execution efficiency, allowing smart contracts to run smoother and more efficiently. Berlin and London (especially EIP-1559) optimized transaction fees, enhancing user experience and introducing an ETH burning mechanism. The most significant upgrade was The Merge, which transitioned Ethereum from PoW to a more environmentally friendly PoS. The subsequent Shanghai upgrade finally allowed users to withdraw previously staked ETH, further refining the PoS mechanism. The latest Dencun upgrade prepares for scalability by launching "Blob" technology, significantly reducing Layer 2 costs, making it cheaper and faster for users to use Ethereum on Layer 2. Overall, each Ethereum upgrade continuously refines aspects of security, performance, scalability, and user experience.
- Core EIPs of Pectra
The Pectra upgrade is the largest since the Dencun upgrade in March 2024, merging the originally planned Prague and Electra upgrades, encompassing 11 Ethereum Improvement Proposals (EIPs) aimed at enhancing the network's scalability, efficiency, and user experience.
The main EIPs included in the Pectra upgrade are:
EIP-2537: Introduces precompiled contracts for BLS12-381 curve operations to enhance verification efficiency.
EIP-2935: Saves historical block hashes in the state to enhance contracts' access to historical data.
EIP-6110: Provides on-chain validator deposit information to simplify validator management.
EIP-7002: Allows the execution layer to trigger withdrawal operations, increasing withdrawal flexibility.
EIP-7251: Raises the maximum effective balance limit for validators to 2048 ETH, enhancing network security.
EIP-7549: Removes the committee index from proofs to optimize the consensus mechanism.
EIP-7623: Increases the cost of calldata to suppress spam transactions.
EIP-7685: Introduces a general execution layer request mechanism to enhance protocol flexibility.
EIP-7691: Increases the throughput of blobs to enhance data processing capabilities.
EIP-7702: Allows externally owned accounts (EOAs) to set account code, promoting the development of account abstraction.
EIP-7840: Adds blob scheduling to the execution layer configuration, optimizing data storage.
- Functional Improvements Brought by Pectra
The functional improvements brought by this upgrade mainly involve enhancements in performance and scalability, user experience and security, consensus and validator management, and historical data and state management.
3.1 Consensus Mechanism and Validator Optimization
EIP-7251: Increase Maximum Effective Staking Balance
Under Ethereum's current mechanism, stakers need to invest 32 ETH to run a validator node, which is both the minimum threshold and the upper limit for reward calculations; any excess does not yield additional rewards. Therefore, many large stakers must run multiple validator nodes to obtain more returns, leading to operational complexity and high resource consumption. For example, if you have thousands of ETH, you must split it into multiple 32 ETH validators to operate.
The Pectra upgrade introduces EIP-7251, which significantly improves this by raising the effective staking limit for a single validator from 32 ETH to 2048 ETH. This means a validator node can now stake more ETH without needing to split into dozens or even hundreds of nodes. More flexibly, stakers can now earn additional rewards for every 1 ETH staked beyond the base amount; for instance, staking 33 ETH will yield rewards for the entire 33 ETH.
This change not only makes the reward mechanism more reasonable but also greatly reduces the technical complexity of running multiple validators. In the original setup, each validator had to sign once in every round of consensus, which put significant bandwidth pressure on the network. Now, multiple validators can be consolidated into one, alleviating the network burden and opening new space for future Ethereum scalability while still maintaining network security and decentralization. For large stakers, this proposal significantly enhances operational efficiency; for the entire network, it helps Ethereum become more efficient without sacrificing security.
EIP-6110: Supply Validator Deposits On-Chain
Currently, Ethereum validator staking operations rely on the voting mechanism on the beacon chain, where proposers need to verify and process deposits based on data from the execution layer. This process is not only complex but can also lead to errors due to inconsistencies in the APIs used by different nodes, with validator activation typically taking up to 12 hours.
EIP-6110 in the Pectra upgrade simplifies this process by embedding deposit information directly into execution layer blocks. As a result, deposit processing no longer relies on proposer voting, and activation time is significantly reduced to about 13 minutes, while also decreasing the technical complexity for clients, enhancing overall efficiency and security.
EIP-7002: Allow Execution Layer to Trigger Validator Exit
Currently, exiting Ethereum staking and retrieving ETH requires using the validator's "active key" to initiate the operation, while the "withdrawal key" for receiving funds can only receive money and cannot initiate an exit. If the two keys are not held by the same person or if the validator key is lost, it can become very difficult or even impossible to exit and retrieve ETH.
EIP-7002 in the Pectra upgrade addresses this issue. It introduces a system contract that allows stakers to directly use the "withdrawal key" to trigger an exit, eliminating the need for the validator key and access to the beacon chain. This improvement not only makes exiting more convenient but also enhances security and flexibility, laying the groundwork for new models such as third-party staking services and decentralized staking pools, making Ethereum staking simpler and more reliable for users in the future.
EIP-7549: Remove Committee Index from Proofs
In Ethereum's Beacon Chain consensus mechanism, validators vote to determine the latest block and the finalized epoch. Each voting message (referred to as a "proof") contains three elements, two of which are the voting content, and the third is the committee index value.
EIP-7549 proposes to remove the committee index value from the signed proof messages. This improvement simplifies and enhances the efficiency of verifying and aggregating consensus votes, helping to improve the performance of consensus clients and providing significant performance boosts for zero-knowledge proof circuits (used to prove Ethereum consensus).
EIP-7685: Facilitate Communication Between Execution Layer and Consensus Layer
In Ethereum, the execution layer (handling transactions and smart contracts) and the consensus layer (responsible for network security and consensus) need to exchange information, such as staking ETH, withdrawing ETH, and adding validators. However, currently, these operations each have their own processes, which are both complex and inefficient.
EIP-7685 proposes a general solution: the execution layer can add a "request information" line in the block, which will be automatically recognized and processed by the consensus layer. For example, you can issue a request to "stake ETH" through a smart contract without manual intervention, and the system will complete it automatically.
This improvement simplifies the operational process, making various staking-related operations more unified; it also facilitates the future expansion of more new features without major changes to the underlying structure; at the same time, smart contracts can participate in the consensus process more directly and securely, increasing automation and reducing human risk.
3.2 Network Performance and Scalability Enhancement
EIP-7691: Increase Blob Throughput
In the last Dencun upgrade, Ethereum introduced a new data format called "blob" to more efficiently store L2 Rollup data, which has been widely adopted by major Ethereum Layer 2 networks since its launch. However, with the rapid increase in usage, each block can currently only accommodate an average of 3 blobs, with a maximum of 6, and capacity is nearing its limit, leading to increased Rollup fees and limited scalability.
EIP-7691 in the Pectra upgrade raises the target number of blobs per block to 6, supporting a maximum of 9 blobs, thereby providing more available data space for L2. This allows Rollups to package more transactions, enhancing overall scalability, and potentially lowering the fees users pay.
Although this is a moderate throughput improvement, it paves the way for larger-scale scalability. For users, this is another step towards making Ethereum Rollups cheaper and faster.
EIP-7623: Increase Calldata Costs
Before the introduction of blobs in the Dencun upgrade, Ethereum Layer 2 networks (L2) typically used calldata in the EVM to store data. While calldata is a way to permanently store data, it is inefficient and places a greater storage and processing burden on the mainnet. However, until now, using calldata was sometimes still cheaper than blobs, which contradicts Ethereum's intention to promote the use of blobs.
To address this, EIP-7623 in the Pectra upgrade increases the cost of calldata, aiming to encourage developers to use blobs more for storing L2 data. This not only guides the ecosystem towards a more efficient data processing method but also helps balance the increased computational resource consumption when processing blobs. In simple terms, it uses a pricing mechanism to make the more efficient technical path "more cost-effective," promoting the implementation of Ethereum's overall scalability strategy.
EIP-7840: Add Blob Scheduling to EL Configuration
EIP-7840 proposes a simple improvement by adding a new field in the configuration file of the execution layer client. This field is used to set the target and maximum number of blobs per block, as well as to adjust blob fees. By directly defining these settings in the configuration file, clients can avoid the complexity of exchanging this information through the Engine API, making the configuration process more straightforward and efficient.
3.3 Historical Data Access and State Management
EIP-2935: Store Historical Block Hashes in State
Currently, the BLOCKHASH opcode in Ethereum can only query the hashes of the most recent 256 blocks, which is about 51 minutes of history, insufficient for applications that require a longer time window (such as Rollups or cross-chain protocols). EIP-2935 proposes to introduce a system contract that directly stores the hashes of up to 8192 recent blocks (approximately 27 hours) in the on-chain state. This allows developers to access block hashes over a longer time range as easily as querying a regular contract, without relying on external services or off-chain data, thereby improving security and data retrieval efficiency.
3.4 Account Abstraction
EIP-7702: Set EOA Account Code
Most Ethereum wallets we currently use are EOA (Externally Owned Account), which are wallets controlled by private keys, such as MetaMask. These accounts have basic functionality and cannot have various "custom features" like smart contracts. EIP-7702 aims to solve this problem by allowing users to set their address (i.e., externally owned account, EOA) to be represented by existing smart contract code. This EIP introduces a new type of transaction that allows address owners to sign an authorization to set their address to simulate a specified smart contract, thereby achieving more powerful programmability. The introduction of this feature means that users can choose wallets that support transaction bundling, gasless operations, and custom asset access and recovery mechanisms, providing a wallet experience more akin to Web2 products.
3.5 Cryptography and Precompiled Optimization
EIP-2537: BLS12-381 Precompilation
EIP-2537 introduces precompiled contracts for BLS12-381 curve operations in the Pectra upgrade. In simple terms, precompiles are a type of special contract built into the Ethereum Virtual Machine (EVM), designed to execute efficient, standardized computational tasks (such as cryptographic operations). Unlike regular contracts that are deployed on-chain, they are implemented directly by the client, running faster and more securely.
BLS12-381 is an elliptic curve widely adopted by Ethereum's consensus layer for operations such as validator signatures. This upgrade allows developers to easily call dedicated functions in the execution layer to perform such cryptographic operations without needing to write complex, gas-consuming contract code.
This feature is particularly useful for applications that need to handle validator information in the EVM (such as staking pools, restaking protocols, light clients, cross-chain bridges, zero-knowledge proof systems, etc.), enhancing both efficiency and security.
3.6 Introduction of Verkle Trees
An important technical improvement in Pectra is the introduction of support for Verkle trees. Verkle trees are a new data structure that will eventually replace the currently used Merkle Patricia trees for storing account and contract data on-chain. Its greatest benefit is that it allows state proofs to become smaller, meaning nodes need less information to verify data. This is crucial for improving Ethereum's efficiency, reducing node synchronization time, and supporting light clients.
In the upcoming Pectra upgrade, due to the complexity of this technology, Ethereum will not fully enable Verkle trees, but significant preparatory work is already underway. The Pectra upgrade introduces several foundational improvements related to Verkle trees. For example, EIP-2935 directly stores the hashes of the most recent thousands of blocks in the on-chain state, making it easier to query data using Verkle trees in the future; additionally, EIP-2537 introduces support for the BLS12-381 curve, a cryptographic technology used in Verkle trees that can help improve the efficiency and security of proofs. Although these changes may not seem directly related to Verkle trees, they lay the technical groundwork for the future official launch of Verkle trees. The complete implementation of Verkle trees will have to wait for the next larger upgrade, but Pectra has already taken an important step.
In addition to the proposals already included in the Pectra upgrade, some proposals directly related to Verkle trees have been postponed to future upgrades due to complexity or other reasons, such as EIP-6800, which defines the structure and implementation details of Verkle trees and is a core proposal for implementing Verkle trees; and EIP-4762 and EIP-7545, which involve other key aspects of Verkle trees but are still in draft stage and are expected to be adopted in subsequent upgrades.
Overall, Verkle trees will improve Ethereum's data storage and processing methods, making the network faster, more resource-efficient, and easier to scale in the future, while also helping to reduce users' transaction costs. In the long run, this will be an important step for Ethereum to achieve greater scalability and lighter operation. Although Pectra cannot fully implement Verkle trees, it has made a series of necessary preparations, laying the foundation for Ethereum's future towards a faster, lighter, and more resource-efficient future in terms of state structure, cryptographic mechanisms, and protocol communication methods.
- Impact
The Pectra upgrade brings lower fees and higher security to ordinary users. By introducing blobs and optimizing data storage mechanisms, the costs of Rollups are further reduced, making transactions on Layer 2 chains cheaper for users. At the same time, there is no need to convert ETH, account balances remain unchanged, and there is no risk of asset migration, preventing users from falling into scams due to the upgrade.
For developers, Pectra provides more powerful features and tools. For example, it supports precompiles for the BLS12-381 curve, allows reading more historical block hashes, and standardizes cross-layer communication, making the development of staking, zk, cross-chain protocols more efficient and secure. These improvements not only enhance the development experience but also lower the barriers to building complex applications.
For validators and stakers, Pectra significantly increases flexibility and efficiency. The maximum amount a single validator can stake has been raised from 32 ETH to 2048 ETH, reducing technical and management costs; the staking and exit processes are also more streamlined and faster, avoiding a high dependency on private keys.
Overall, the Pectra upgrade brings many practical improvements, making Ethereum faster, cheaper, and easier to use. It lowers Layer 2 fees, makes staking ETH more flexible, simplifies node operation, and enhances the collaboration between the execution layer and the consensus layer. These changes not only improve network performance but also lay the groundwork for more new features in the future, such as cross-chain and zero-knowledge proofs. It is clear that Pectra is an important step for Ethereum towards becoming more powerful, user-friendly, and scalable.
References
All Core Developers Consensus (ACDC) meeting: Consensus Layer Meeting 154 [2025-04-03]
Tim Beiko (@timbeiko), "EIP-7600: Hardfork Meta - Pectra [DRAFT]," Ethereum Improvement Proposals, no. 7600, January 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7600.
Mikhail Kalinin (@mkalinin), Danny Ryan (@djrtwo), Peter Davies (@petertdavies), "EIP-6110: Supply validator deposits on chain [DRAFT]," Ethereum Improvement Proposals, no. 6110, December 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-6110.
Danny Ryan (@djrtwo), Mikhail Kalinin (@mkalinin), Ansgar Dietrichs (@adietrichs), Hsiao-Wei Wang (@hwwhww), lightclient (@lightclient), Felix Lange (@fjl), "EIP-7002: Execution layer triggerable withdrawals [DRAFT]," Ethereum Improvement Proposals, no. 7002, May 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7002.
lightclient (@lightclient), Felix Lange (@fjl), "EIP-7685: General purpose execution layer requests [DRAFT]," Ethereum Improvement Proposals, no. 7685, April 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7685.
dapplion (@dapplion), Mikhail Kalinin (@mkalinin), "EIP-7549: Move committee index outside Attestation [DRAFT]," Ethereum Improvement Proposals, no. 7549, November 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7549.
mike (@michaelneuder), Francesco (@fradamt), dapplion (@dapplion), Mikhail (@mkalinin), Aditya (@adiasg), Justin (@justindrake), lightclient (@lightclient), Felix Lange (@fjl), "EIP-7251: Increase the MAX_EFFECTIVE_BALANCE [DRAFT]," Ethereum Improvement Proposals, no. 7251, June 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7251.
Vitalik Buterin (@vbuterin), Sam Wilson (@SamWilsn), Ansgar Dietrichs (@adietrichs), lightclient (@lightclient), "EIP-7702: Set EOA account code [DRAFT]," Ethereum Improvement Proposals, no. 7702, May 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7702.
Parithosh Jayanthi (@parithosh), Toni Wahrstätter (@nerolation), Sam Calder-Mason (@samcm), Andrew Davis (@savid), Ansgar Dietrichs (@adietrichs), "EIP-7691: Blob throughput increase [DRAFT]," Ethereum Improvement Proposals, no. 7691, April 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7691.
Toni Wahrstätter (@nerolation), Vitalik Buterin (@vbuterin), "EIP-7623: Increase calldata cost [DRAFT]," Ethereum Improvement Proposals, no. 7623, February 2024. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7623.
Alex Vlasov (@shamatar), Kelly Olson (@ineffectualproperty), Alex Stokes (@ralexstokes), Antonio Sanso (@asanso), "EIP-2537: Precompile for BLS12-381 curve operations [DRAFT]," Ethereum Improvement Proposals, no. 2537, February 2020. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-2537.
Vitalik Buterin (@vbuterin), Tomasz Stanczak (@tkstanczak), Guillaume Ballet (@gballet), Gajinder Singh (@g11tech), Tanishq Jasoria (@tanishqjasoria), Ignacio Hagopian (@jsign), Jochem Brouwer (@jochem-brouwer), Sina Mahmoodi (@s1na), "EIP-2935: Serve historical block hashes from state [DRAFT]," Ethereum Improvement Proposals, no. 2935, September 2020. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-2935.
dapplion (@dapplion), Mikhail Kalinin (@mkalinin), "EIP-7549: Move committee index outside Attestation [DRAFT]," Ethereum Improvement Proposals, no. 7549, November 2023. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-7549.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
