Introduction
If the history of blockchain is the history of Bitcoin expansion, then Ethereum's periodic upgrade is the core indicator of the expansion direction.
The major Ethereum hard fork upgrades every 1-2 years will gradually radiate from itself to the L2 of each Ethereum series, and then expand to the development of multiple L1s. The Eip contained in each hard fork represents the essence of the Ethereum core community and is the result of a balance between benefits and costs.
So let Shisijun take you through the technical aspects one by one, what are the 11 Eips of the Prague-Electra upgrade,
background
the current upgrade is expected to be released on the Sepolia test network on March 5 and on the Ethereum main network on April 8.
The first sentence of the version released by the Ethereum official code base 4 days ago (2025.2.26) is: "Oh look, another hotfix release!" Yes, there is a problem. The version code currently activated in the Holesky test network has caused a fork in the test network (which can be understood as a large-scale downtime)
Although we don’t need to pay attention to the bugs in the forked code, we can see the complexity of this content.
And from the author’s personal point of view, this upgrade is alsoEthereum’s most influential one after the merge of Pow to Pos, which will completely change the operation mode on the chain and bring a new experience.
The complete EIP list is as follows:

[Source: https://ethroadmap.com/#pectra sticky]
Although the introduced proposal has been slightly changed, it has already caused Okx,Basically all of them are ensuring that they can be adapted at the moment of the mainnet switch. As users, we can also experience it with the help of wallets.
But the real core question is - in addition to the technical implementation of developers, can this upgrade really leverage the ecological landscape of Ethereum?
Are its changes deep enough, or is it just a routine patch by the Ethereum Foundation in the L2 era?
Panoramic Scan
Let's use a table to feel the overall rhythm first

Obviously, we can see three major characteristics:
After Ethereum's development entered the deep water zone, the new proposal proposers who could basically be included
Ethereum is increasingly inclined to optimize the user experience with the help of the ecological joint advantage. Maybe you think that optimizing the user experience is not right? No, In fact, many major version mergers of Ethereum have nothing to do with ordinary user experience. The last time the block size was adjusted (capacity expansion will reduce user costs, and reducing price fluctuations is considered user experience optimization) was in 2018. Last time, the introduction of blob significantly reduced the user fee cost of L2. And this time, the three time points show that the focus is on optimizing user costs.
But the question is, does Ethereum really "put user experience first"? Or is it just forced to optimize user experience?
Let's explore the details one by one to understand what has changed?
Experience optimization
Interpretation
Objectively speaking, 7702 breaks the impossible unspoken rules on multiple chains, and also breaks the application logic of most Dapps.
For users, it is still an EOA address, and only drives and uses CA logic when needed, so the holding cost is low.
No need to convert the on-chain CA identity before performing operations, which means that users do not need to register.
Users can easily use EOA to do multiple transactions in parallel, such as the combination of authorized deduction and execution deduction, which reduces the transaction cost for users.
For Dapp, especially for projects that need to do enterprise-level management on the chain, such as exchanges, it is a subversive optimization. Once the original ecology of batch collection is realized, the basic exchange cost can be reduced by more than half in an instant, and it can also benefit users in the end.
Therefore, although he has changed a lot, but occupying the dimension of cost is worth all Dapps to study and adapt , because this time, users must stand on the side of EIP7702.
But there is an invisible risk here: although account abstraction reduces the cost of interaction, it also increases the complexity of user permission management.
If wallet manufacturers fail to adapt correctly, it may bring unexpected security vulnerabilities. In the past, a survey would at most lose a single chain of assets, but now it is possible to lose the entire chain, or even explode at a fixed time.
Obviously, this is an upgrade that phishing hackers like very much, and users should be more careful about on-chain transactions
Application side optimization
EIP-2537 (Precompile for BLS12-381 Curve Operations)
Function
Introduction of BLS12-381 elliptic curve
Precompiled operations can optimize complex cryptographic operations such as BLS signature verification, providing higher security (120+ bit security) and computational efficiency (Gas optimization)
BLS signature verification, public key aggregation and multi-signature verification have been added to the actual functions.
Specific precompiled addresses are specified for different BLS operations, and contracts can be directly performed by calling these precompiled addresses without deploying additional code to perform complex mathematical operations related to BLS12-381.
Interpretation
It is becoming more and more convenient for ordinary users to use multi-signature smart contract wallets at low cost. It can significantly reduce the complexity and Gas cost of signature verification calculations, and can also more efficiently implement and support functions such as zero-knowledge proofs (such as zk-SNARKs) and homomorphic encryption. It will play a role in privacy and interoperability (especially with other blockchains that support BLS such as ZCash).
EIP-2935 (Serve Historical Block Hashes from State)
Function
Store the last 8192 block hashes in the storage of a system contract to provide stateless clients with the most recent block hash data.
This design allows clients to access historical block hashes during execution without having to store the entire chain's historical data themselves, which is especially important for future optimization schemes such as Verkle trees.
These hash data are stored in the form of a ring buffer, which supports rolling updates, that is, always keeping the latest 8192 block hash values.
Set and getoperations are provided. SET is a system address that can be operated to write transactions, and users can use get to query block hashes using block numbers.
Interpretation
Because the client can access the historical block hash through a simple query without additional storage,so although it has no direct impact on ordinary users,it will promote the emergence of some storage-free clients, which has optimization value for applications that need to verify services on the chain.
It also helps with the cost of RollupL2, because most L2s need to access the L1 block hashes of the past period of time to verify the consistency and historical information of the data on the chain.
There are also on-chain verification services such as oracles, which require verification and data tracking of historical blocks to prevent data errors reported off-chain.
Multiple optimizations of 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 deeper look and think about the economic logic here). I will summarize each proposal in one sentence and then comment on it together. EIP-6110 (Supply va
l
EIP-6110 (Supply va
ll
l
EIP-6110
EIP-7002 (Execution layer triggerable withdrawals)
This proposal allows Ethereum's execution layer to provide a mechanism to trigger validator exit and partial withdrawals, enabling validators using "0x01" withdrawal vouchers to independently control their staked ETH from the execution layer.
EIP-7251 (Increase the MAX_EFFECTIVE_BALANCE)
Increase the effective staking limit for a single validator (to 2048ETH), while the minimum staking limit remains at 32 ETH.
EIP-7549 Move committee index outside Attestation
Move the committee index field of the "Attestation" message in the consensus layer to the outside of the message to simplify verification and improve efficiency. Ultimately, the performance of the Casper FFG client is improved, especially when running in a ZK circuit.
Interpretation
It may seem easy to get confused when reading so much at once, but in fact, we can just control it back to the core needs.
The macro background is that Ethereum's validator cluster is growing rapidly, with more than 830,000 validators as of October 2023. Because MAX_EFFECTIVE_BALANCE is limited to 32 ETH, node operators need to create multiple validator accounts to manage larger staked assets,which leads to the existence of a large number of "redundant validators".
Therefore, by increasing the maximum limit through EIP-7251, the number of controlled accounts and the complexity of the system can be reduced for aggregated staking protocols such as lido, butthis may aggravate the decentralization problem and make the ETH staking market more centralized.
Always maintaining a minimum of 32 staking amounts means that large households are still required to participate, which is an ecological compromise with the aggregation protocol and also prevents small households from easily generating high-frequency operations that affect the stability of the consensus layer.
Through EIP-7549, the flexibility of withdrawal operations is increased, which is convenient for pledgers and node operators to increase their control over funds. The technical background here is because the original design has some flaws. Since the committee index is included in the signature information, even for the same vote, different signing roots will be generated due to different committees, resulting in the need to verify each vote separately. Therefore, the motivation of EIP-7549 is to achieve aggregation of the same vote by removing the committee index in the signature and reducing the number of pairing operations required for verification.
Therefore, it is important to note that Ethereum is constantly optimizing the staking experience,in essence to consolidate the group of staking and node operators, which is the lifeblood of Ethereum after the merger. Once a large amount of funds are no longer around Ethereum, its security itself will be shaken.
After multiple EIPs are added, this will allow larger node operators to merge multiple validator accounts, while also providing more flexibility for small validators, such as increasing income through compound interest accumulation or more flexible staking increments.
This is very important. Originally, after 32 ETH was reached, if you generated 10 ETH of income, you would not continue to stake ETH, because you still need to get 32 to open a new account.
But after this update, you can directly stake 42 ETH. Then obviously your compound interest income can return to ETH again.
so, in my opinion,under the current situation of weak returns of DeFi projects in the ETH market, it will continue to siphon, and the liquidity of ETH will decrease. This may be the motivation for the foundation to promote this series.
Optimization of L2 ecology
EIP-7623: Increase calldata cost
This is something that will affect the evm layer. The gas fee of calldata in the transaction is directly increased from 4/16 gas per byte to 10/40 gas. The two values here are to distinguish the fees of 0 bytes and non-0 bytes, both of which are 2.5 times the increase.
In fact, reducing block pressure is the banner,forcing L2 not to use calldata, but to use more Blobs.
EIP-7691: Blob throughput increase
Increase the capacity of the blob in the block to support a larger L2 storage space. In the previous Cancun upgrade, there were two core parameters representing blobs, target and max, which were used to represent the target number of blobs per block and the maximum number of blobs per block. In Cancun, they were 3 and 6, and now after Prague, the parameters have become 6 and 9, which means capacity expansion. In fact, Ethereum is just adding "highways" to L2, but how to solve "traffic management" and "charge standards for different highways" is the most fundamental problem.
EIP-7840: Add blob schedule to EL config files
Increased a configuration file to allow the client to dynamically adjust the blob quantity settings of EIP-7691.
There is also a parameter baseFeeUpdateFraction that can adjust the responsiveness of the blob's gas pricing.
Interpretation
After all, it is an EIP proposal, so it sounds very technical, but the core concept is easy to grasp.
The core selling point of Ethereum has changed from the contract system of Defi Summer to the L2 ecological community. Any other chain system, even the hottest btcL2 system in 24 years (the essence of the inscription is still because of the expectation of L2), is completely not in a competitive position with Ethereum's L2.
Because either it is like btc, because of chain restrictions, it is difficult to achieve data fallback and security sharing in the actual sense of L2.
Other svm and move chains are essentially still developing their own L1 and shallowly exploring the L2 on top of it. Of course, the high performance of these chains is relatively less dependent on L2.
So Ethereum uses L2's tps to improve Ethereum itself. Of course, there are many problems, such as dispersed liquidity and cross-chain complexity. But this is the only way he can go. After all, once web3 develops to the stage of high-frequency application chains, it will not frequently cross chains. In addition, there are attempts to solve liquidity and versatility problems, such as chain abstraction. We will analyze particle networks later.
Because the transaction cost on L2 will be highly dependent on the capacity of Ethereum's Blob, the purpose of modifying the gas fee of calldata is to encourage L2 to use more blobs. Don't use Ethereum's permanently retained calldata to store L2's state data.
In addition, the capacity of blob also needs to take into account the subsequent further increase of L2, and needs to be dynamically configurable.
Therefore, through this development direction, the certainty of the L2 direction can be further determined,which also means the certainty of the market demand for solving the shortcomings of L2.
Written at the end
The Prague upgrade is a key stop on the road of Ethereum's continuous evolution, but as far as the author feels,this upgrade is more like a compromise plan that is constantly compromised and adjusted.
Ethereum is being pushed by the market, rather than taking the initiative to lead, because in addition to the unique optimization of Ethereum on pledge and L2, other bls, aa, etc. have actually been widely piloted by other L1.
However, in terms of the overall significance,although this upgrade has not caused widespread market discussion like "London" and "Merger", it has quietly laid a higher scalability and decentralized foundation for the Ethereum network.
The advancement of account abstraction will reduce the threshold for users to use encrypted applications, the improvement of the pledge mechanism will further consolidate the security and stability of the Ethereum PoS network, and the improvement of data availability and throughput will provide a broader space for the increasingly prosperous second-layer ecology.
It can be foreseen that with the completion of the Prague/Electra upgrade, Ethereum will become more efficient, more friendly, and more flexible . More importantly, some of the concepts and technologies brought about by the Prague upgrade point the way for future improvements.
In the next planned hard fork "Osaka" upgrade, the community may introduce more revolutionary improvements, such as the long-awaited Verkle tree state solution and the single-slot final confirmation mechanism .
In the long run, Ethereum's development roadmap is clear and firm (although a little stubborn), and the cumulative effect of these upgrades will drive Ethereum to achieve its grand visions of "millions of transactions per second" (The Surge) and anti-censorship, low centralization risk (The Scourge).
The Osaka hard fork at the end of 2025 (estimated to be delayed to 26 years as usual) and the Amsterdam hard fork in 2026, we expect that each upgrade will make Ethereum more mature and robust, with richer functions.