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, let the Fourteen Lords take you to take a look at the 11 Eips upgraded by Prague-Electra one by one from a technical perspective. What are the uses and why is it him?

Background

The current accurate time for the 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) was: "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 (which can be understood as a large-scale downtime)

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

And from the author's personal opinion, this upgrade is also the most influential time 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 slightly changed, it has caused Okx, Metamask, WalletConnect, Biconomy, BaseWallet, Uniswap, Rhinestone, ZeroDev, TrustWallet, Safe and other wallet teams are following. 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 its change deep enough, or is it just a routine patch for the Ethereum Foundation in the L2 era?

Panorama scan

Let us first use a table to feel the overall rhythm

Obviously, we can see three major characteristics:

After the development of Ethereum 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.

Ethereum's market pace is accelerating. This upgrade has been completed in November last year. Now, 11 are included in the actual implementation (the added three 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 taking part. 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).

Ethereum is increasingly inclined to optimize user experience with the advantages of ecological jointness. Maybe you think it is not appropriate to optimize user experience? No, in fact, many large-scale 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 the introduction of blobs greatly reduced the cost of L2's user handling fee. This time, it can be seen at 3 time points that focus on the optimization of user costs.

But the problem is, Does Ethereum really “put 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?

Experimental 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 parallelism, such as authorized deduction and execution deduction, which will reduce the transaction cost of users itself.

For Dapp, especially project parties that need to do 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.

So, although it has changed a lot, it is worth all Dapps to study and adapt, 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 can lose at most single-chain assets, but now it may lose the entire chain, or even a timely explosion.

Obviously, this is an upgrade that phishing hackers like very much. Users should be more careful about on-chain transactions

Application-side optimization

EIP-2537 (Precompile for BLS12-381 Curve Operations)

The function of

Introduces the precompilation operation of the BLS12-381 elliptic curve, which can optimize complex additions such as BLS signature verification.Secret operation provides higher security (120+ bit security) and computing efficiency (Gas optimization)

New BLS signature verification, public key aggregation and multi-signature verification in actual functions.

Specify specific precompiled addresses 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)

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

This design allows clients to access 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.

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.

Provides Set and get operations. 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 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 class, which requires verification and data tracking of historical blocks to prevent data errors from being 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 closer look and think about the economic logic here). I will summarize each proposal in one sentence and then comment together.

EIP-6110 (Supply validator deposits on chain)

will implement pledge operation processing through the in-chain protocol mechanism, 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 withdrawals, allowing validators using "0x01" withdrawal credentials to independently control their pledged ETH from the execution layer.

EIP-7251 (Increase the MAX_EFFECTIVE_BALANCE)

EIP-align: left;">EIP-7251 (Increase the MAX_EFFECTIVE_

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 in one breath, 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. 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 prone to high-frequency operations that affect the stability of the consensus layer.

EIP-7549 has increased the flexibility of withdrawal operations, which is convenient for stakers, and node operators have increased 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 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.

So, 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.

After multiple eips are supported, 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 was reached, if you generate 10 new ETH income, you will not continue to use ETH pledge, 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 weak revenue of defi projects in the ETH market, it will continue to siphon, and the flow of ETH will decrease. This may be the motivation for the foundation to implement this series of motivation.

L2 ecology optimization

EIP-7623: Increase calldata cost

This is something that will affect the evm layer, and the gas fee of the calldata in the transaction will be directly from 4/16 gas per byte Increase to 10/40 gas, the two values here are the 2.5 times increase between 0 byte charges and non-0 byte charges.

In fact, reducing the block pressure to the flag, forcing L2 not to use calldata, but to use more blobs.

EIP-7691: Blob throughput increase

Increase the capacity of blobs in the block, thereby supporting 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 blobs of each block and the maximum blob of each block Quantity. Cancun is 3 and 6. Now after Prague, the parameters become 6 and 9, which is an expansion.

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

EIP-7840: Add blob schedule to EL config files

Increased a configuration file to allow clients to dynamically adjust the blob number settings of EIP-7691.

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

SolutionReading

is an EIP proposal after all, so it sounds very technical, but the core concept is easy to grasp.

Ethereum's core selling point has transformed from Defi Summer's contract system to an L2 ecological community. Any other chain system, even the hottest 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 because of chain restrictions, and L2 in the practical sense of security sharing.

The other svm systems and move systems are essentially still developing their own L1 and exploring the L2 on it. Of course, the high performance of these chains is relatively less dependent on doing 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, which 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 at the end

The Prague upgrade is a key stop on the road to continuous evolution of Ethereum, but as far as I feel is, 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 beenIt has been widely piloted by other L1s.

However, in terms of overall sense, although this upgrade does not cause 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 flexible. 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 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 "Millions of Tradings per Second" and censorship resistance and low centralized risk (The Scourge).

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