introduction
If the history of blockchain is the history of Bitcoins expansion, then Ethereums cyclical upgrades are the core indicator of the direction of expansion.
The major hard fork upgrades of Ethereum 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 11 Eips of Prague-Electras upgrade from a technical perspective. What are they, what are they used for, and why is it him?
background
The exact time for the upgrade is expected to be released on the Sepolia test network on 3.5 and on the Ethereum main network on 4.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 on 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 also the most influential one for Ethereum 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 introduction proposal has slightly changed, it has attracted the attention of wallet teams such as Okx, Metamask, WalletConnect, Biconomy, BaseWallet, Uniswap, Rhinestone, ZeroDev, TrustWallet, Safe, etc. Basically, all of them are ensuring that the main network can be adapted at the moment of switching, and 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 structure of Ethereum?
Are its changes deep enough, or is it just a routine patch by the Ethereum Foundation in the L2 era?
Panoramic Scan
Lets use a table to feel the overall rhythm:
Obviously, we can see 3 major features:
After Ethereum’s development entered a deep water zone, the new proposals that were included were basically all from the Ethereum Foundation . Among them, Vitalik was the first to recommend important changes. It was almost impossible to see the creativity of other roles being incorporated into official upgrades. This may also be a proof that Ethereum is increasingly going its own way and gradually becoming an increasingly centralized decision-making system.
The pace of Ethereum market is accelerating . In November last year, 8 basic consensuses were completed for this upgrade, and now 11 are included in the actual implementation (3 optimizations at the L2 level promoted by Vitalik are added). In the past, a major version basically only made a few optimizations from one core, but now it is almost multi-party, and AA (hard fork version) that was difficult to reach consensus for many years has also been included. From this, we can feel the radical state of the EVM system facing the booming development of the SVM system (Solana, etc.), the Move system (Aptos, etc.) and even the BTC system (various BTC L2) under the current multi-chain explosion.
Ethereum is increasingly leaning towards optimizing user experience with the help of its ecosystem advantages . You may think that optimizing user experience is not the right thing to do? No, in fact, many of Ethereums major version mergers 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. The last time the user fee cost of L2 was greatly reduced by introducing blob, 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? Lets explore the details one by one to understand what it has changed.
Experience optimization
First of all, the most important change is 7702, which introduces the account abstraction mechanism from the chain layer update. We have previously had a systematic article interpretation of this point, so I will not repeat it this time: From 4337 to 7702: An in-depth interpretation of the past and future of Ethereum account abstraction track
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 the CA logic is only driven and used when needed, so the holding cost is low.
There is no need to convert the on-chain CA identity before performing any operations, which means that users do not need to register.
Users can easily use EOA to perform multiple transactions in parallel, such as combining authorized deduction and executed deduction into one, which reduces the transaction cost for users.
For Dapp, especially for projects that need to do on-chain enterprise-level management, such as exchanges, it is a disruptive optimization. Once batch collection is realized in the original ecology, the basic exchange cost can be reduced by more than half in an instant, which can ultimately benefit users.
Therefore, although it has changed a lot, the dimension of cost is worthy of research and adaptation by all Dapps , because this time, users will definitely stand on the side of EIP 7702.
But there is a hidden 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 lead to unexpected security vulnerabilities. In the past, a single-chain asset would be lost at most during an investigation, but now the entire chain may be lost, or even exploded at a scheduled time.
Apparently, this is an upgrade that phishing hackers love, and users should be more careful about on-chain transactions.
Application-side optimization
EIP-2537 (Precompile for BLS 12-381 Curve Operations)
effect
Introduced precompilation of the BLS 12-381 elliptic curve, which optimizes complex cryptographic operations such as BLS signature verification, providing higher security (120+ bit security) and computational efficiency (Gas optimization)
In terms of actual functions, BLS signature verification, public key aggregation and multi-signature verification have been added.
Specific precompiled addresses are specified for different BLS operations, and contracts can be directly executed by calling these precompiled addresses without deploying additional code to perform complex mathematical operations related to BLS 12-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 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 BLS-supported blockchains such as ZCash).
EIP-2935 (Serve Historical Block Hashes from State)
effect
Store the last 8192 block hashes in a system contracts storage to provide stateless clients with the most recent block hash data.
This design allows the client to access historical block hashes during execution without having to store the entire chain’s historical data itself, which is especially important for future optimization solutions such as the Verkle tree.
These hash data are stored in the form of a ring buffer and support rolling updates, that is, always keeping the latest 8192 block hash values.
Provides Set and Get operations, SET is a system address that can be used 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 the need for additional storage, although it has no direct impact on ordinary users, it will promote the emergence of some storage-free clients and have optimization value for on-chain service applications that require verification .
It also helps with the cost of Rollup L2 , as most L2s need to access L1 block hashes from the past period of time to verify the consistency and historical information of on-chain data.
There are also on-chain verification services such as oracles, which require verification and data tracking of historical blocks to prevent data errors from being reported off-chain.
Multiple optimizations for 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 validator deposits on chain)
The staking operation will be processed through the in-chain protocol mechanism, eliminating the voting mechanism of the consensus layer and optimizing the security and efficiency of the staking flow. By adding a list of validator staking operations to the execution layer block, the record and verification of the staking operation will be directly placed in the execution layer block structure, so that the consensus layer no longer needs to rely on the staking data (eth 1 data) voting mechanism.
EIP-7002 (Execution layer triggerable withdrawals)
This proposal allows Ethereums execution layer to provide a mechanism to trigger validator exit and partial withdrawal, allowing validators using the 0x 01 withdrawal voucher 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 2048 ETH), while the minimum staking limit remains at 32 ETH.
EIP-7549 Move committee index outside Attestation
Move the committee index field of the consensus layer’s “Attestation” message outside the message to simplify verification and improve efficiency. The result is a performance improvement for Casper FFG clients, especially when running in ZK circuits.
Interpretation
It may seem confusing to see so much at once, but in fact we just need to control ourselves back to the core needs.
The macro background is that Ethereums validator cluster is growing rapidly, with more than 830,000 validators as of October 2023. Since 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 raising 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, but this may aggravate the decentralization problem and make the ETH staking market more centralized.
Maintaining a minimum stake of 32 at all times means that large households are still required to participate, which is an ecological compromise with the aggregation protocol, and also prevents small households from making 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 stakers 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, the essence of which is to consolidate the group of staking and node operators . This 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.
With multiple EIPs added, this will allow larger-scale 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. After the original 32 ETH is reached, if you generate 10 ETH in new income, you will not continue to use ETH for staking, 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 can return to ETH.
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, directly increasing the gas fee of calldata in the transaction from 4/16 gas per byte to 10/40 gas. The two values here are used to distinguish between the fees of 0 bytes and non-0 bytes, both of which are 2.5 times higher.
In fact, reducing block pressure is a banner, forcing L2 not to use calldata, but to use Blob more.
EIP-7691: Blob throughput increase
Increase the capacity of blobs in blocks to support larger L2 storage space. In the previous Cancun upgrade, there were two core parameters representing blobs, target and max, which were used to indicate the target number of blobs per block and the maximum number of blobs per block. In Cancun, the parameters were 3 and 6, and now after Prague, the parameters have become 6 and 9. In short, the capacity has been expanded.
In fact, Ethereum is just adding a highway to L2, but how to solve traffic management and charging standards for different highways are the most fundamental problems.
EIP-7840: Add blob schedule to EL config files
A configuration file has been added 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 blobs 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 the Defi Summer to the L2 ecological community . Any other chain system, even the hottest BTC L2 system in 24 years (the essence of the inscription is still due to the expectations of L2), is completely not in a competitive position with Ethereums L2.
Because it is either like BTC, due to chain limitations, it is difficult to achieve L2 in the actual sense of data fallback and security sharing.
Other svm and move chains are essentially still developing their own L1 and shallowly exploring the L2 above it. Of course, the high performance of these chains is relatively less dependent on L2.
Therefore, Ethereum uses L2s 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 universality problems, such as chain abstraction. We will analyze particle networks and other issues later.
Because the transaction costs on L2 will be highly dependent on the capacity of Ethereums Blob , the purpose of modifying the calldata gas fee is to encourage L2 to use more blobs and not use Ethereums permanent calldata to store L2 state data.
In addition, the capacity of the blob also needs to take into account the subsequent increase in 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 to solve the shortcomings of L2.
Final Thoughts
The Prague upgrade is a key stop on the road of Ethereums continuous evolution, but in my opinion, this upgrade is more like a compromise plan that requires constant compromise and adjustment.
Ethereum is being pushed by the market rather than taking the lead, because apart from Ethereum-specific optimizations on staking and L2, other bls, aa, etc. have actually been widely piloted by other L1s.
However, in terms of overall significance , although this upgrade did not trigger widespread market discussion like London and Merger, it is quietly laying a higher scalability and decentralization foundation for the Ethereum network.
The advancement of account abstraction will lower the threshold for users to use crypto applications. The improvement of the staking mechanism will further consolidate the security and stability of the Ethereum PoS network. The improvement of data availability and throughput will provide a broader space for the increasingly prosperous second-layer ecosystem.
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 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 vision 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.
