GuShiio.com From a technical perspective, take stock of the 11 Eips upgraded in Prague-Electra one by one.
Author: Fourteen Jun
introduction
If the history of blockchain is the history of Bitcoin’s expansion, then Ethereum’s periodic upgrade is the core indicator of the direction of expansion.
The hard fork upgrade of the large version of Ethereum every 1-2 years will gradually radiate from itself to the L2s of each Ethereum series, and then expand to the development of multiple L1s. The Eip included in each hard fork represents the high essence of the Ethereum core community and is the result of a balance between benefits and costs.
So we still have the 14th gentleman lead you to take stock of the 11 Eips upgraded from Prague-Electra from a technical perspective. What are they, what are their uses, and why him?
background
The exact time for the current upgrade is expected to be released on the Sepolia test network on 3.5 and on the Ethereum main network on 4.8.
The official code base of Ethereum was released 4 days ago (2025.2.26). The first sentence of the version read: “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 area of downtime)
Although we don’t need to pay attention to the forked code bugs, we can see the complexity of this time.
And from the author’s personal opinion, this upgrade is also the most influential one for Ethereum after the merge of Pow to Pos. It will completely change the operating model on the chain and bring a new experience.
The complete eip list is as follows:
[Source: ethroadmap.com/#pectra sticky]
Although the introduction proposal has changed slightly, it has attracted the attention of wallet teams such as Okx, Metamask, WalletConnect, Biconomy, BaseWallet, Uniswap, Rhinestone, ZeroDev, TrustWallet, Safe, etc. Basically, it is all about ensuring that the main network can be adapted at the moment when switching. As users, we can also use our wallets to experience it.
But the real core question is-in addition to the technical realization of developers, can this upgrade truly leverage the ecological landscape of Ethereum?
Are its changes deep enough, or are they just a routine tinkering by the Ethereum Foundation in the L2 era?
panoramic scanning
Let’s use a table to feel the overall rhythm first
Obviously, we can see three major characteristics:
After the development of Ethereum entered the deep water area, the new proposals that could be included were basically people of the Ethereum Foundation. Among them, Vitalik was the first person to make important changes. It is almost impossible to see the ideas of other characters integrated into the official upgrade. This may also be the warrant for Ethereum to become more and more “stubborn” market voices and gradually become an increasingly centralized decision-making system.
The market rhythm of Ethereum is accelerating. This upgrade has 8 basic consensus projects completed in November last year, and now it includes 11 projects to actual implementation (the addition is the addition of 3 optimizations at the l2 level promoted by vitalik). It used to be a big version., basically only a few optimizations are made from one core, but now almost all of them are carried out simultaneously. The AA (Hard Fork Version), which has been difficult to reach consensus for many years, has also been included. From this, we can feel that under the current multi-chain explosion, the evm system is facing some radical states under the vigorous development of svm systems (solana etc.), move systems (aptos etc.) and even btc systems (various types of btcL2).
But the question is, does Ethereum really “put user experience first”? Or is it just forced to optimize the user experience?
Let’s discuss the details one by one to understand what he has changed?
experience optimization
First of all, the most important change is 7702, which introduces the account abstraction mechanism from the chain level update. We have previously had a systematic interpretation of this point, but we will not repeat it this time: “From 4337 to 7702: In-depth Interpretation of Ethereum Account Abstract Track’s Past and Future”
interpretation
Objectively speaking, 7702 breaks impossible hidden rules on multiple chains and also breaks the application logic of most Dapps.
For the user, he himself is still an EOA address, and he only drives and uses CA logic when needed, so the cost of holding is low.
There is no need to convert the on-chain CA identity before doing the operation, which means that the user does not need to register.
Users can easily use EOA to achieve multiple transactions in parallel, such as authorization withholding and execution withholding, so that the transaction cost for users is low.
For Dapp, especially projects that need to do enterprise-level management on the chain, such as exchanges, are even more disruptive optimizations. Once batch collection is realized in the original ecology, the cost of the basic exchange can be instantly reduced by more than half, and ultimately it can also Benefit users.
Therefore, although he has changed a lot, it occupies the cost dimension and is worth studying and adapting by all Dapps, because this time, users will inevitably stand on the side of EIP7702.
But there is an hidden risk here: Although account abstraction reduces interaction costs, it also increases the complexity of user rights management.
If the wallet manufacturer fails to adapt correctly, it may bring unexpected security loopholes. In the past, a survey used to lose single-chain assets at most, but now the entire chain may be lost or even exploded in time.
Obviously, this is an upgrade that phishing hackers like very much, and users should be more careful about online transactions
Application-side optimization
EIP-2537 (Precompile for BLS12-381 Curve Operations)
role
The pre-compilation operation of BLS12-381 elliptic curve is introduced to optimize complex encryption operations such as BLS signature verification, providing higher security (120+ bit security) and computational efficiency (Gas optimization)
In fact, new functions include BLS signature verification, public key aggregation and multi-signature verification.
Specific precompilation addresses are specified for different BLS operations, and contracts can be carried out directly by calling these precompilation addresses, without the need to deploy additional code to perform complex mathematical operations related to BLS12-381.
interpretation
It is becoming more and more convenient for ordinary users and can 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 BLS supporting blockchains such as ZCash).
EIP-2935 (Serve Historical Block Hashes from State)
role
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 the client to access the historical block hash during execution without having to store the historical data of the entire chain itself. It is especially important for future optimization schemes such as Verkle trees.
These hash data is stored in the form of a ring buffer and supports rolling updates, that is, the latest hash values of 8192 blocks are kept up to date at all times.
Set and get operations are provided. SET is a system address operable write transaction, while users can use get to query the block hash using the block number.
interpretation
Because 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 storage-free clients and have optimization value for applications requiring verification services on the chain.
It also helps with the cost of RollupL2, as most L2s need to access L1 block hashes from a period of time to verify the consistency and historical information of the data on the chain.
There is also an oracle type on-chain verification service, which requires verification and data tracking of historical blocks to prevent data errors reported offline.
Multiple optimizations of pledge scenarios
Ethereum pledge is a big topic, but it has little impact on ordinary users (but if you participate in pledge, 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 it together.
EIP-6110（Supply validator deposits on chain）
The intra-chain protocol mechanism will be used to realize the processing of pledge operations, eliminate the voting mechanism at the consensus layer, and optimize the security and efficiency of pledge traffic. By adding a list of actions pledged by the verifier to the execution level block, the record and verification of pledge operations are directly placed into the execution level block structure, so that the consensus layer no longer needs to rely on the pledge data (eth1data) voting mechanism.
EIP-7002（ Execution layer triggerable withdrawals）
This proposal is for Ethereum’s Execution Layer to provide a mechanism to trigger verifiers to withdraw and partial withdrawals, allowing verifiers who use “0x01” withdrawal certificates to independently control their pledged ETH from the execution layer.
EIP-7251 (Increase the MAX_EFFECTIVE_BALANCE)
Increase the effective pledge limit for a single verifier (to 2048ETH), while the minimum pledge 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 ZK circuits.
interpretation
It may seem easy to get confused by reading so much in one go, but in fact, we can just control it back to our core needs.
The macro background is that Ethereum’s 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 large pledged assets, which leads to the existence of a large number of “redundant validators.”
Therefore, the maximum limit has been raised through EIP-7251, which can reduce the number of controlled accounts and reduce the complexity of the system for aggregate pledge agreements such as lido. However, this may aggravate decentralization problems and make the ETH pledge market more centralized.
Always maintaining a minimum of 32 pledge amounts means that large households are still required to participate, which is an ecological compromise with the aggregation agreement and also prevents small households from easily producing 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 have improved control over funds. The technical background here is that there are some flaws in the original design. Since the committee index is included in the signature information, even for the same vote, different committees will generate different signing roots, resulting in the need to verify each vote separately. Therefore, the motivation for EIP-7549 is to reduce the number of pairing operations required for verification by removing the committee index within the signature to achieve aggregation of the same votes.
Therefore, it should be noted that Ethereum continues to optimize the pledge experience. The essence is to consolidate the pledge and the group of node operators. This is the lifeblood of the Ethereum merger. Once a large amount of funds no longer surrounds Ethereum, its security itself will be shaken.
After multiple eips are added, this allows larger-scale node operators to merge multiple validator accounts, and also brings more flexibility to small validators, such as accumulating compound interest gains or more flexible pledge increments. Increase revenue.
This is very important. If you generate 10 new ETH earnings after 32ETH is achieved, you will not continue to pledge ETH, because you still need to gather 32 ETH earnings to open a new account.
But after this update, you can directly pledge 42 eth. Then obviously your compound interest can go back to ETH.
So, in my opinion, given the current weak income of defi projects in the ETH market, he will continue to siphon off 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. It directly increases the gas fee of calldata in the transaction from 4/16 gas per byte to 10/40 gas. The two values here distinguish between the fee of 0 bytes and the fee of non-0 bytes, both of which are 2.5 times higher.
In fact, reducing block pressure is a banner that forces L2 not to use calldata, but to use more blobs.
EIP-7691: Blob throughput increase
Increase the capacity of blobs in blocks, thereby supporting larger-scale 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. Cancun is 3 and 6, but now after Prague, the parameters have become 6 and 9. In short, it is expansion.
In fact, Ethereum is only adding “highways” to L2, but how to solve “traffic flow management” and “charging standards for different highways” are the most fundamental issues.
EIP-7840: Add blob schedule to EL config files
A configuration file has been incremented to allow clients to dynamically adjust the blob count setting of EIP-7691.
There is also a parameter baseFeeUpdateFraction that can adjust the gas pricing responsiveness of the blob.
interpretation
After all, it is an EIP proposal, so it sounds technical, but the core concept is easy to grasp.
The core selling point of Ethereum has changed from the contract system in the Summer of Defi to the L2 ecological community. Any other chain system, even the hottest btcL2 system in 24 years (the essence of the inscription is due to L2’s expectations), is completely incompatible with Ethereum’s L2. Not a competitive position.
Because it is either a practical L2 such as btc, where it is difficult to achieve data fallback due to chain restrictions, and security sharing.
Other svm systems and move systems are essentially still developing their own L1 and still exploring the L2 on them. Of course, the high performance of these chains is relatively less dependent on doing L2.
Therefore, Ethereum uses L2 ‘s tps to improve Ethereum itself. Of course, there are also many problems, such as dispersion of liquidity and cross-chain complexity. But this was the only way he could go. After all, once web3 develops to the stage of high-frequency application chains, it will not cross chains frequently, and to solve liquidity and versatility issues, there are tracks such as chain abstraction that are trying, and we will interpret the particle network and other things for analysis later.
Because the transaction costs on L2 will be highly due to the capacity of Ethereum’s blobs, modifying the gas fee of calldata is to encourage L2 to use more blobs and not use the calldata permanently retained by Ethereum to store L2 ‘s status data.
In addition, the capacity of the blob also needs to be considered for further L2 increases in the future 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.
written in the end
The Prague upgrade is a key stop on the road of Ethereum’s continued evolution, but as far as I feel, this upgrade is more like a compromise plan with constant compromises and constant adjustments.
Ethereum is being pushed by the market rather than actively led, because in addition to pledges and Ethereum’s unique optimization on L2, other bls, aa, etc. have actually been widely piloted by other L1s.
However, in terms of overall significance, although this upgrade does not cause widespread market heated discussions like “London” and “Merger”, it is quietly laying a higher foundation for scalability and decentralization 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 secondary ecosystem.
It is foreseeable that with the completion of the Prague/Electra upgrade, Ethereum will become more efficient, friendlier, and more flexible. More importantly, some concepts and technologies brought by the Prague upgrade point out the direction 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 status scheme and the single-slot final confirmation mechanism.
In the long run, Ethereum’s development roadmap is clear and firm (although slightly stubborn), and the cumulative effect of these upgrades will drive Ethereum to achieve grand visions such as “The Surge” and censory-resistant and decentralized risk (The Scourge).
The Osaka hard fork at the end of 2025 (which is expected to be delayed to 26 years as usual) and the Amsterdam hard fork in 2026 expect that every upgrade will make Ethereum more mature, powerful and more functional.
