_Author: _Shijiu Jun
If the history of blockchain is the history of Bitcoin's scaling, then Ethereum's periodic upgrades are the core indicators of scaling direction.
The major hard fork upgrades of Ethereum, occurring every 1-2 years, gradually radiate from itself to various Ethereum series L2s, and then expand to the development of multiple L1s. Each hard fork includes EIPs that represent the essence of the Ethereum core community, balancing benefits and costs.
So let Shijiu Jun take you through the 11 EIPs of the Prague-Electra upgrade from a technical perspective, discussing what they are, their uses, and why they matter.
Background
The expected upgrade timeline is September 3.5 for the Sepolia testnet and April 8 for the Ethereum mainnet.
The Ethereum official code repository released its first line of the version 4 days ago (February 26, 2025): "Oh look, another hotfix release!" Yes, there was a problem. The version code activated on the Holesky testnet caused a fork (which can be understood as a large-scale outage).
While we don't need to focus on the code bugs causing the fork, we can see the complexity of this content.
From my personal perspective, this upgrade is the most influential one for Ethereum since the transition from PoW to PoS with the merge, fundamentally changing the operational model on-chain and bringing a brand new experience.
The complete list of EIPs is as follows:
[Source: https://ethroadmap.com/#pectra sticky]
Although the introduction of proposals has slightly changed, it has already attracted the attention of wallet teams such as Okx, Metamask, WalletConnect, Biconomy, BaseWallet, Uniswap, Rhinestone, ZeroDev, TrustWallet, Safe, etc. Almost all are ensuring compatibility at the moment of the mainnet switch, allowing us as users to experience it through wallets.
But the real core question is—can this upgrade, aside from the technical implementation by developers, truly reshape the ecological landscape of Ethereum?
Is its change deep enough, or is it merely a routine patch by the Ethereum Foundation in the L2 era?
Panoramic Scan
Let's first use a table to feel the overall rhythm.
Clearly, we can see three major characteristics:
After Ethereum's development has entered deep waters, the new proposal submitters that can be included are basically all insiders of the Ethereum Foundation. Vitalik is the primary advocate for significant changes. It is rare to see other roles contributing creative ideas to official upgrades, which may also serve as evidence of Ethereum's increasingly "stubborn" market voice, gradually becoming a more centralized decision-making system.
The market rhythm of Ethereum is accelerating. This upgrade has 8 proposals that reached basic consensus last November, and now it includes 11 in actual execution (the three added are optimizations for L2 driven by Vitalik). In the past, a major version would typically start from a core point with a few optimizations, but now it almost involves multiple parties. The AA (hard fork version) that was difficult to reach consensus on for years has also been included. From this, we can sense the aggressive state under the explosion of multi-chain development, with the EVM system thriving alongside the SVM system (like Solana), Move system (like Aptos), and even the BTC system (various BTC L2s).
Ethereum is increasingly leveraging ecological synergies, leaning towards optimizing user experience. You might think that optimizing user experience is a given, but many of Ethereum's major version merges have little to do with ordinary user experience. The last adjustment to block size (scaling reduces user costs and price volatility, which can be seen as optimizing user experience) was in 2018. The last time it introduced blobs, significantly reducing L2 user transaction costs, and this time, the three time points indicate a focus on optimizing user costs.
But the question is, does Ethereum really prioritize "user experience"? Or is it merely being forced to optimize user experience?
Let's explore the details one by one to understand what has changed.
Experience Optimization
The most important change is EIP-7702, which introduces the account abstraction mechanism from the chain layer.
Interpretation
Objectively speaking, EIP-7702 breaks several impossible unspoken rules on-chain and disrupts the application logic of most DApps.
For users, they still have EOA addresses but only drive and use CA logic when needed, thus lowering holding costs.
There is no need to first convert to an on-chain CA identity before performing operations, meaning users do not need to register.
Users can easily perform multiple transactions in parallel using EOA, such as combining authorization and execution of deductions, which inherently lowers transaction costs.
For DApps, especially projects that require on-chain enterprise-level management, such as exchanges, this is a revolutionary optimization. Once batch aggregation is achieved natively, the costs for exchanges can be reduced by more than half, ultimately benefiting users.
So, while it changes a lot, from the cost perspective, it is worth all DApps to study and adapt because this time, users will undoubtedly stand on the side of EIP-7702.
However, there is an invisible risk: while account abstraction lowers interaction costs, it also increases the complexity of user permission management.
If wallet providers fail to adapt correctly, it may lead to unexpected security vulnerabilities. Previously, a survey might result in the loss of assets on a single chain, but now it could lead to losses across the entire chain, or even timed explosions.
Clearly, this is an upgrade that phishing hackers love; users need to be more cautious with on-chain transactions.
Application Side Optimization
EIP-2537 (Precompile for BLS12–381 Curve Operations)
Function
Introduces precompiled operations for the BLS12–381 elliptic curve, optimizing complex cryptographic operations like BLS signature verification, providing higher security (120+ bit security) and computational efficiency (Gas optimization).
Adds functionalities for BLS signature verification, public key aggregation, and multi-signature verification.
Specifies concrete precompiled addresses for different BLS operations, allowing contracts to directly call these precompiled addresses without needing to deploy additional code to execute complex mathematical operations related to BLS12–381.
Interpretation
This makes it increasingly convenient for ordinary users to use low-cost multi-signature smart contract wallets. It significantly reduces the complexity of signature verification calculations and Gas costs, and can more efficiently implement and support zero-knowledge proofs (like zk-SNARKs) and homomorphic encryption functionalities. It will play a role in privacy and interoperability, especially with other BLS-supporting blockchains like ZCash.
EIP-2935 (Serve Historical Block Hashes from State)
Function
Stores the last 8192 block hashes in the storage of a system contract to provide recent block hash data for stateless clients.
This design allows clients to access historical block hashes during execution without needing to store the entire historical data of the chain, which is especially important for future optimizations like Verkle trees.
These hash data are stored in a circular buffer format, supporting rolling updates, thus always keeping the latest 8192 block hash values.
Provides Set and Get operations, where SET is operable by the system address to write transactions, and users can use Get to query block hashes by block number.
Interpretation
Since clients can access historical block hashes through simple queries without additional storage, although it has no direct impact on ordinary users, it will promote the emergence of some stateless clients, providing optimization value for on-chain verification service applications.
It also helps with the costs of Rollup L2, as most L2s need to access past L1 block hashes to verify the consistency of on-chain data and historical information.
Additionally, oracle-type on-chain verification services need to verify historical blocks and track data to prevent errors in off-chain reported data.
Multiple Optimizations in Staking Scenarios
Ethereum staking is a big topic, but it has little impact on ordinary users (but if you participate in staking, you need to take a closer look and think about the economic logic here). I will summarize each proposal in one sentence and then comment on them together.
EIP-6110 (Supply validator deposits on chain)
This will implement staking operations through an on-chain protocol mechanism, eliminating the voting mechanism of the consensus layer, optimizing the security and efficiency of staking traffic. By adding a list of validator staking operations in the blocks of the execution layer, the records and validations of staking operations are directly placed within the execution layer block structure, so the consensus layer no longer needs to rely on the staking data (eth1data) voting mechanism.
EIP-7002 (Execution layer triggerable withdrawals)
This proposal allows the Ethereum execution layer to provide a mechanism for triggering validator exits and partial withdrawals, enabling validators using the "0x01" withdrawal certificate to independently control their staked ETH from the execution layer.
EIP-7251 (Increase the MAXEFFECTIVEBALANCE)
Increases the effective staking limit for a single validator (to 2048 ETH), while the minimum staking limit remains at 32 ETH.
EIP-7549 Move committee index outside Attestation
Moves the committee index field of the "Attestation" message in the consensus layer outside the message to simplify validation and improve efficiency. Ultimately, this enhances the performance of the Casper FFG client, especially when running in ZK circuits.
Interpretation
Looking at so many at once may seem confusing, but we can focus on the core needs.
The macro background is that the cluster of Ethereum validators is growing rapidly, with over 830,000 validators as of October 2023. Since the MAXEFFECTIVEBALANCE is limited to 32 ETH, node operators need to create multiple validator accounts to manage larger staking assets, leading to a large number of "redundant validators."
Therefore, by increasing the maximum limit through EIP-7251, aggregation staking protocols like Lido can reduce the number of controlled accounts, simplifying the system. However, this may exacerbate centralization issues, making the ETH staking market more concentrated.
Maintaining a minimum staking amount of 32 ETH indicates a continued requirement for large holders to participate, representing a compromise with aggregation protocols and avoiding the instability of the consensus layer caused by frequent operations from smaller holders.
EIP-7549 increases the flexibility of withdrawal operations, allowing stakers and node operators to enhance their control over funds. The technical background here is that the original design had some flaws; since the committee index was included in the signature information, even identical votes would generate different signing roots due to different committees, necessitating separate verification for each vote. Therefore, the motivation behind EIP-7549 is to remove the committee index from the signature, allowing for the aggregation of identical votes and reducing the number of pairing operations required for verification.
Thus, it is important to note that Ethereum is continuously optimizing the staking experience, fundamentally to consolidate the community of stakers and node operators. This is the lifeblood of Ethereum post-merge; if a large amount of capital is no longer centered around Ethereum, its security will be undermined.
With multiple EIPs in place, larger-scale node operators can merge multiple validator accounts, while also providing more flexibility for smaller validators, such as accumulating returns through compound interest or more flexible staking increments to increase yields.
This point is crucial. Originally, after reaching 32 ETH, if you generated an additional 10 ETH in returns, you wouldn't continue to stake that ETH because you would need to reach 32 ETH again to open a new account.
However, after this update, you can directly stake 42 ETH. Clearly, your compound returns can then revert back to ETH.
So, in my view, given the current weak yield situation of ETH market DeFi projects, it will continue to siphon off liquidity, reducing the liquidity of ETH. Perhaps this is the motivation behind the foundation's implementation of this series of changes.
Optimization of the L2 Ecosystem
EIP-7623: Increase calldata cost
This is something that will affect the EVM layer, raising the gas cost of calldata in transactions directly from 4/16 gas per byte to 10/40 gas. The two values distinguish between the cost of 0-byte and non-0-byte data, representing a 2.5-fold increase.
In fact, lowering block pressure serves as a banner, forcing L2s to avoid using calldata and instead utilize blobs more.
EIP-7691: Blob throughput increase
Increases the capacity of blobs within blocks, thereby supporting larger-scale L2 storage space. In the previous Cancun upgrade, there were two core parameters representing blobs: target and max, indicating the target number of blobs per block and the maximum number of blobs per block. Cancun had values of 3 and 6, and now after Prague, the parameters have changed to 6 and 9, essentially expanding capacity.
Ethereum is essentially providing L2s with a "highway," but the fundamental issue is how to solve "traffic management" and "different toll standards for various highways."
EIP-7840: Add blob schedule to EL config files
This adds a configuration file that allows clients to dynamically adjust the blob quantity settings of EIP-7691.
There is also a parameter, baseFeeUpdateFraction, which can adjust the responsiveness of blob gas pricing.
Interpretation
After all, these are EIP proposals, so they sound very technical, but the core concept is easy to grasp.
Ethereum's core selling point has shifted from the contract system of DeFi summer to the L2 ecosystem community. Any other chain system, even the hottest btcL2 system in 2024 (which fundamentally relies on L2 expectations), is not in the same competitive position as Ethereum's L2.
Because either chains like BTC, which face limitations in data rollback and shared security, represent practical L2s.
Other SVM and Move systems are essentially still developing their L1s and are only lightly exploring their L2s. Of course, the high performance of these chains is relatively less dependent on developing L2s.
Thus, Ethereum aims to enhance itself through the TPS of L2s. Naturally, there are many issues, such as liquidity dispersion and cross-chain complexity. However, this is the only path it can take. After all, once Web3 develops to the stage of high-frequency application chains, it won't frequently cross chains, and solutions for liquidity and universality are being attempted in areas like chain abstraction, which we will analyze later with Particle Network.
Since the transaction costs on L2 will be highly derived from the capacity of Ethereum's blobs, modifying the gas fees for calldata is intended to incentivize L2s to use blobs more.
Do not use the calldata permanently retained by Ethereum to store L2 state data.
Additionally, the capacity of blobs needs to consider further increases in L2, requiring dynamic configurability.
Thus, through this development direction, we can further confirm the determinacy of the L2 direction, which also signifies the certainty of market demand for addressing L2 shortcomings.
In Conclusion
The Prague upgrade is a key stop on Ethereum's continuous evolution path. However, from my perspective, this upgrade feels more like a compromise and adjustment solution.
Ethereum is being pushed by the market rather than actively leading it, as aside from the unique optimizations in staking and L2, other aspects like BLS and AA have already been widely piloted by other L1s.
However, in terms of overall significance, this upgrade, while not sparking widespread market discussion like "London" or "The Merge," is quietly laying a higher foundation for scalability and decentralization for the Ethereum network.
The advancement of account abstraction will lower the threshold for users to engage with crypto applications, while improvements in the staking mechanism will further solidify the security and stability of Ethereum's PoS network. Enhancements in data availability and throughput will provide broader space for the increasingly prosperous L2 ecosystem.
It is foreseeable that with the completion of the Prague/Electra upgrade, Ethereum will become more efficient, user-friendly, and resilient. More importantly, some concepts and technologies brought by the Prague upgrade will point the way for future improvements.
In the already planned next hard fork, the "Osaka" upgrade (which is expected to be delayed until 2026), the community may introduce more revolutionary improvements, such as the long-anticipated Verkle tree state scheme and single-slot finality mechanism.
In the long run, Ethereum's development roadmap is clear and steadfast (though somewhat stubborn). The cumulative effects of these upgrades will drive Ethereum towards achieving grand visions like "a million transactions per second" (The Surge) and anti-censorship, low centralization risk (The Scourge).
Looking forward to the Osaka hard fork at the end of 2025 (which is expected to be delayed to 2026) and the Amsterdam hard fork in 2026, I hope each upgrade will make Ethereum more mature and robust, with richer functionalities.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
