The most anticipated upgrade of Ethereum Prague this year

introduction

If the history of blockchain is the history of Bitcoin’s expansion, then the cyclical upgrade of Ethereum is the core pointer of the expansion direction.

The hard fork upgrade of the Ethereum major version 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 high essence of the Ethereum core community and is the result of the balance between benefits and costs.

So we still let the Fourteen Kings take you to take a look at the 11 Eips upgraded by Prague-Electra one by one from a technical perspective. What is it , what is it for? Why is it him?

background

The exact time for the current upgrade is expected to be released on Sepolia test network on 3.5 and on Ethereum main network on 4.8.

The first sentence of the Ethereum official code base released the version 4 days ago (2025.2.26) is: "Oh look, another hotfix release!" Yes, something went wrong. The version code currently activated on the Holesky test network has caused the test network fork (it can be understood as a large-scale downtime)

Although we don't need to pay attention to the forked code bugs, we can see the complexity of this content from it.

And from the author's personal opinion, this upgrade is also the most influential one for Ethereum after Pow to Pos merge , which will completely change the operating 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 changed slightly, it has attracted the attention of wallet teams such as Okx, Metamask, WalletConnect, Biconomy, BaseWallet, Uniswap, Rhinestone, ZeroDev, TrustWallet, Safe, etc. Basically , we ensure that the moment when the main network switches can be adapted. As users, we can also experience it with the help of our wallet.

But the real core question is - in addition to the technology implementation of developers, can this upgrade really leverage the ecological landscape of Ethereum?

Is it a change, deep enough, or is it just a routine patch for the Ethereum Foundation in the L2 era?

Panoramic Scan

Let's first experience the overall rhythm with a table

Obviously, we can see three major features :

1. After Ethereum's development enters the deep waters, the new proposals that can basically be included are all purely people of the Ethereum Foundation . Among them, Vitalik is the first person to recommend important changes. It is almost impossible to see the creative integration of other characters into the official upgrade. This may be the warrant of Ethereum's market voice, which is becoming increasingly "stubborn" and has gradually become an increasingly centralized decision-making system.

2. The market pace of Ethereum is accelerating . This upgrade has been completed in November last year. Now, it includes 11 (the 3 optimizations at the l2 level promoted by Vitalik). Once a large version, it basically only made a few optimizations based on one core, but now almost all parties are working together. The AA (hard fork version) that was difficult to agree on for many years has also been included. From this we can feel that under the explosion of multiple chains, the EVM system faces some radical states under the vigorous development of the SVM system (Solana, etc.), the Move system (aptos, etc.) and the BTC system (various BTCL2).

3. Ethereum is increasingly leveraging its ecological joint advantages to optimize user experience . Maybe you think it is not appropriate to optimize user experience? No, in fact, many major version mergers of Ethereum have nothing to do with ordinary user experience . The last time I adjusted the block size (expansion will reduce user costs, and reducing price fluctuations is considered user experience optimization) was still in 2018. The last time, by introducing blobs, the cost of L2's user handling fee was greatly reduced. This time, it can be seen that we focus on the optimization of user costs at three points in time.

But the question is, is Ethereum really "puts user experience first"? Or is it just forced to optimize the user experience?

Let’s explore the detailed perspectives one by one to understand. What has he 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, they are still EOA addresses, and they only drive and use CA logic when needed, so the holding cost is low.

No need to convert the on-chain CA identity first 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 authorized deduction and execution deduction, which will reduce the transaction cost to users.

For Dapps, especially those that require on-chain enterprise-level management, such as exchanges, are even more disruptive optimization. Once batch collection is realized, the cost of basic exchanges can be reduced by more than half in an instant, and ultimately it can benefit users.

Therefore, although he has changed a lot, it is worth studying and adapting to all Dapps , because this time, the user must be on the side of EIP7702.

But there is an invisible risk here: although account abstraction reduces interaction costs, it also increases the complexity of user permission management.

If the wallet manufacturer fails to adapt correctly, it may bring unexpected security loopholes. It used to be a survey that lost single-chain assets at most, but now it may lose the entire chain, or even a timely explosion.

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)

effect

1. The precompilation operation of BLS12-381 elliptic curve is introduced , which can optimize complex encryption operations such as BLS signature verification, providing higher security (120+ bit security) and computing efficiency (Gas optimization)

2. In actual functions, BLS signature verification, public key aggregation and multi-signature verification have been added.

3. Specific precompiled addresses are specified for different BLS operations. The contract can be directly carried out by calling these precompiled addresses, and there is no 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. In privacy and interoperability (especially with other BLS-enabled blockchains such as ZCash) will play a role.

EIP-2935 (Serve Historical Block Hashes from State)

effect

1. The last 8192 block hashes are stored in the storage of a system contract to provide the most recent block hash data for stateless clients.

2. This design allows clients to access the historical block hash during execution without storing the historical data of the entire chain by themselves, especially for future optimization solutions such as Verkle trees.

3. These hash data are stored in the form of a ring buffer, supporting rolling updates, and maintaining the latest 8192 block hash values ​​at all times.

4. Set and get operations are provided. SET is a system address that can operate write transactions, and users can use get to query block hash with block numbers.

Interpretation

Because the client can access the historical block hash 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 , which is of optimization value for on-chain verification service applications.

It is also helpful for the cost of RollupL2 , because most L2s need to access the L1 block hash over the past period to verify the consistency and historical information of the data on the chain.

There is also an on-chain verification service of oracle-like, which requires verification and data tracking of historical blocks to prevent data errors from being reported off-chain.

Multiple optimizations for pledge 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 together.

EIP-6110 (Supply va l idator deposits on chain)

The in-chain protocol mechanism will be used to implement pledge operation processing, eliminate the voting mechanism of the consensus layer, and optimize the security and efficiency of pledge traffic. By adding a list of staked operations by verifiers in the blocks of the execution layer, the records and verification of the staked operations are placed directly into the block structure of the execution layer, so that the consensus layer no longer needs to rely on the staked data (eth1data) voting mechanism.

EIP-7002 (Execution layer triggerable withdrawals)

This proposal allows Ethereum's Execution Layer to provide a mechanism to trigger validator exit and partial withdrawal, allowing validators using "0x01" withdrawal credentials to independently control their pledged ETH from the execution layer.

EIP-7251 (Increase the MAX_EFFECTIVE_BALANCE)

Increase the valid staking limit for individual 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 outside 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 seems easy to be confused when you look at so much at one go, but in fact, we can just control 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 larger staking assets, which has led to the existence of a large number of "redundant validators".

Therefore, the maximum ceiling is increased through EIP-7251. For those aggregation staking protocols of lido, the number of control accounts can be reduced and the complexity of the system can be reduced, but this may exacerbate the decentralization problem and make the ETH staking market more centralized.

Always maintaining a minimum of 32 pledges means that large investors are still required to participate, which is an ecological compromise with the aggregation agreement and also avoids small investors 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 stakers, and the node operators have increased 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 if it is the same vote, different signing roots will be generated due to different committees, which requires separate verification of each vote. Therefore, the motivation of EIP-7549 is to achieve aggregation of the same votes by removing the committee index within the signature, reducing the number of pairing operations required for verification.

Therefore, we should pay attention to Ethereum's continuous optimization of the staking experience, which is essentially to consolidate the staking and node operators . This is the lifeblood of the Ethereum merger. Once a large amount of funds are no longer surrounding Ethereum, its security itself will be shaken.

With multiple EIP support, this allows larger node operators to merge multiple validator accounts, while also bringing more flexibility to small validators, such as increasing revenue through compound interest income accumulation or more flexible staking increments.

This is very important. After the 32ETH is reached, if you generate 10 new ETH returns, you will not continue to use ETH stake, because you still need to gather 32 to open a new account.

But after this update, you can directly pledge 42 eths. Then obviously your compound interest income can return to ETH again.

so, in my opinion, in the current situation of weak returns in the ETH market, he will continue to siphon, and the flow of ETH will decrease. This may be the motivation for the foundation to implement this series .

Optimization of L2 ecosystem

EIP-7623: In c rease calldata cost

This is something that will affect the evm layer. It increases the gas fee of the calldata in the transaction directly from 4/16 gas per byte to 10/40 gas. Here the two values ​​are to distinguish between 0 bytes and non-0 bytes, both of which are 2.5 times the increase.

In fact, reducing the block pressure is a flag, and forcing L2 not to use calldata, but to use Blob more often .

EIP-7691: Blob throughput increase

Increase the capacity of blobs in the block to support larger L2 storage space. In the previous Cancun upgrade, there were two core parameters target and max representing the blob , which were used to represent the target blob number of each block and the maximum blob number of each block. Cancun is 3 and 6. Now after Prague, the parameters become 6 and 9, which is an expansion.

In fact, Ethereum is just adding "highways" to L2, but how to solve "vehicle flow management" and "tolling standards for different highways" is the most fundamental problem.

EIP-7840: Add blob schedule to EL config files

An incremented configuration file is used to allow clients to dynamically adjust the blob number settings of EIP-7691.

There is also a parameter baseFeeUpdateFraction that can adjust the responsiveness of the gas pricing of the blob.

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 summer of Defi to the L2 ecological community . Any other chain system, even the most popular btcL2 system in 24 years (the essence of the inscription is still due to L2 expectations), is completely not a competitive position with Ethereum's L2.

Because it is either like BTC, because it is difficult to achieve data fallback due to chain restrictions, and security sharing is the practical sense of L2.

Other svm systems and move systems are essentially developing their own L1 and exploring the L2 on it. Of course, the high performance of these chains is relatively less dependent on L2.

So Ethereum uses L2 TPS to improve Ethereum itself. Of course, there are many problems, such as liquidity decentralization and cross-chain complexity, which are all problems. But he could only walk this way. After all, once web3 develops to the stage of high-frequency application chains, it will not cross- chain frequently, and solves the problems of liquidity and universality. There are chain abstracts and other tracks to try. Later, we will interpret the partial network and other analysis.

Because the transaction cost on L2 will be highly derived from the capacity of Ethereum's blobs , the gas fee for modifying the calldata is to encourage L2 to use more blobs, and do not use the calldata permanently retained by Ethereum to store the status data of l2 .

In addition, the capacity of the blob also needs to be considered for further 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 for solving the shortcomings of L2.

Written at the end

Prague upgrade is a key stop on the road to Ethereum's continuous evolution, but as far as I feel, this upgrade is more like a compromise plan with constant compromise and adjustment.

Ethereum is being pushed by the market, not actively leading, because in addition to staking 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 arouse widespread market heated discussions like "London" and "merger", it silently lays a higher foundation for the Ethereum network to scale and decentralize.

The advancement of account abstraction will reduce the threshold for users to use encrypted applications, the improvement of the staking 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-tier ecosystem.

It can be foreseen that with the completion of the Prague/Electra upgrade, Ethereum will become more efficient, friendly, and more resilient . More importantly, some of the concepts and technologies brought by the Prague upgrade have pointed out the direction for future improvements.

In the next hard fork "Osaka" upgrade that has been planned, the community may introduce more revolutionary improvements, such as the long-awaited Verkle tree state scheme and single-trough final confirmation mechanism .

In the long run, Ethereum's development roadmap is clear and firm (although slightly stubborn), and these cumulative effects of upgrades will drive Ethereum to achieve grand visions such as "The Surge" and anti-censorship and low-centralized risks .

The Osaka hard fork at the end of 2025 (as expected to be delayed to 26 years as usual) and the Amsterdam hard fork in 2026. We hope that every upgrade will make Ethereum more mature and robust and more functional.