In-depth interpretation of this year's most anticipated Ethereum Prague upgrade

Author: Shisi Jun

Introduction

If the history of blockchain is the history of Bitcoin's scaling, then Ethereum's periodic upgrades are the core indicators of scaling direction.

Every major version hard fork upgrade of Ethereum, occurring every 1-2 years, gradually radiates from itself to various Ethereum series L2s, and then expands to the development of multiple L1s. Each hard fork's included EIPs represent the essence of the Ethereum core community, balancing benefits and costs.

So let Shisi Jun take you from a technical perspective to review the 11 EIPs of the Prague-Electra upgrade one by one: what they are, what they do, and why they matter.

Background

The exact timing of the upgrade is expected to be released on the Sepolia testnet on March 5 and on the Ethereum mainnet on April 8.

The official Ethereum code repository released its first line of the version 4 days ago (February 26, 2025): "Oh look, another hotfix release!" Yes, there was a problem. The version code activated on the Holesky testnet caused a fork in the testnet (which can be understood as a large-scale outage).

Although we do not need to focus on the code bugs of the fork, we can see the complexity of the content this time.

From my personal perspective, this upgrade is also the most influential one for Ethereum since the transition from PoW to PoS with the merge, which will completely change the operational model on-chain and bring a brand new experience.

The complete list of EIPs is as follows:

[Source: https://ethroadmap.com/#pectra sticky]

Although the introduction of proposals has slightly changed, it has already attracted the attention of wallet teams such as Okx, Metamask, WalletConnect, Biconomy, BaseWallet, Uniswap, Rhinestone, ZeroDev, TrustWallet, Safe, etc. Almost all are ensuring that they can adapt at the moment of the mainnet switch, and as users, we can also experience it through wallets.

But the real core question is—this upgrade, aside from the technical implementation by developers, can it truly leverage the ecological landscape of Ethereum?

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

Panorama Scan

Let's first feel the overall rhythm with a table.

Clearly, we can see three major characteristics:

After Ethereum's development has entered deep waters, the new proposal submitters that can be included are basically all insiders of the Ethereum Foundation. Among them, Vitalik is the primary advocate for significant changes. It is almost impossible to see the creative integration of other roles into official upgrades, which may also serve as a credential for Ethereum's increasingly "stubborn" market voice, gradually becoming a more centralized decision-making system.

The market rhythm of Ethereum is accelerating. This upgrade has 8 proposals since the basic consensus was reached last November, and now it includes 11 in actual execution (the three added are optimizations at the L2 level promoted by Vitalik). In the past, a major version would typically start from a core point and make a few optimizations, but now it is almost a multi-faceted approach, with the AA (hard fork version) that had been difficult to reach consensus on for years also included. From this, we can feel the aggressive state of the EVM ecosystem facing the SVM (Solana, etc.), Move (Aptos, etc.), and even the BTC ecosystem (various BTC L2s) under the explosion of multi-chain development.

Ethereum is increasingly inclined to optimize user experience by leveraging the advantages of ecological collaboration. You might think that optimizing user experience should be a given, but many of Ethereum's major version merges have little to do with ordinary user experience. The last adjustment to block size (scaling would reduce user costs and price volatility, which can be seen as optimizing user experience) was in 2018. The last time through the introduction of blobs significantly reduced L2 user transaction costs, and this time, the three time points show a focus on optimizing user costs.

But the question is, does Ethereum really prioritize "user experience"? Or is it just being forced to optimize user experience?

Let's explore the details and understand what has changed.

Experience Optimization

The most important change is undoubtedly EIP-7702, which introduces the account abstraction mechanism updated from the chain layer. We have previously provided a systematic article on this, so I won't elaborate further: "From 4337 to 7702: An In-depth Interpretation of the Past and Future of Ethereum Account Abstraction."

Interpretation

Objectively speaking, EIP-7702 breaks multiple impossible unspoken rules on-chain and disrupts the application logic of most DApps.

For users, they still have EOA addresses, but they only drive and use CA logic when needed, thus lowering the holding cost.

There is no need to first convert to an on-chain CA identity before performing operations, which means users do not need to register.

Users can easily achieve multiple parallel transactions with EOA, such as combining authorization and execution of deductions, which inherently reduces the transaction costs for users.

For DApps, especially for projects that require on-chain enterprise-level management, such as exchanges, this is a revolutionary optimization. Once batch aggregation is realized in its original form, the costs for exchanges can be reduced by more than half, ultimately benefiting users.

So, although it has changed a lot, from the cost dimension, it is worth all DApps to study and adapt because this time, users will inevitably stand on the side of EIP-7702.

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

If wallet providers fail to adapt correctly, it may lead to unexpected security vulnerabilities. Previously, a survey might result in the loss of assets on a single chain, but now it could lead to losses across the entire chain, or even timed explosions.

Clearly, this is an upgrade that phishing hackers love; users need to be more cautious about on-chain transactions.

Application-side Optimization

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

Function

Introduces precompiled operations for the BLS12-381 elliptic curve, optimizing complex cryptographic operations such as BLS signature verification, providing higher security (120+ bit security) and computational efficiency (Gas optimization).

The actual functionality adds BLS signature verification, public key aggregation, and multi-signature verification.

Specific precompiled addresses are designated for different BLS operations, allowing contracts to directly call these precompiled addresses without needing to deploy additional code to execute complex mathematical operations related to BLS12-381.

Interpretation

It becomes increasingly convenient for ordinary users to use multi-signature smart contract wallets at low cost. It significantly reduces the complexity of signature verification calculations and Gas costs, and can more efficiently implement and support zero-knowledge proofs (such as zk-SNARKs) and homomorphic encryption functionalities. This will play a role in privacy and interoperability, especially with other BLS-supporting blockchains like ZCash.

EIP-2935 (Serve Historical Block Hashes from State)

Function

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

This design allows clients to access historical block hashes during execution without needing to store the entire chain's historical data, which is particularly important for future optimizations like Verkle trees.

These hash data are stored in a circular buffer, supporting rolling updates, thus always maintaining the latest 8192 block hash values.

Provides Set and Get operations, where SET is operable by the system address for writing transactions, while users can use Get to query block hashes by block number.

Interpretation

Since clients can access historical block hashes through simple queries without additional storage, although there is no direct impact on ordinary users, it will promote the emergence of some stateless clients, providing optimization value for on-chain verification service applications.

It also helps with the costs of Rollup L2s, as most L2s need to access past L1 block hashes to verify the consistency of on-chain data and historical information.

Additionally, on-chain verification services like oracles need to verify historical blocks and track data to prevent off-chain reporting errors.

Multiple Optimizations in 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 provide comments.

EIP-6110 (Supply validator deposits on chain)

This will implement staking operations through an on-chain protocol mechanism, eliminating the voting mechanism of the consensus layer, optimizing the security and efficiency of staking traffic. By adding a list of validator staking operations in the blocks of the execution layer, the records and validations of staking operations are directly placed within the block structure of the execution layer, so the consensus layer no longer needs to rely on staking data (eth1data) voting mechanisms.

EIP-7002 (Execution layer triggerable withdrawals)

This proposal allows the Ethereum execution layer to provide a mechanism to trigger validator exits and partial withdrawals, enabling validators using the "0x01" withdrawal certificate to independently control their staked ETH from the execution layer.

EIP-7251 (Increase the MAXEFFECTIVEBALANCE)

Increases 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

Moves the committee index field of the "Attestation" message in the consensus layer outside the message to simplify verification and improve efficiency. Ultimately, this enhances the performance of Casper FFG clients, especially when running in ZK circuits.

Interpretation

Looking at so many at once may seem confusing, but we can focus on the core needs.

The macro background is that the cluster of Ethereum validators is growing rapidly, with over 830,000 validators as of October 2023. Since the MAXEFFECTIVEBALANCE is limited to 32 ETH, node operators need to create multiple validator accounts to manage larger staking assets, leading to a large number of "redundant validators."

Therefore, by increasing the maximum limit through EIP-7251, aggregation staking protocols like Lido can reduce the number of controlled accounts, decreasing system complexity, but this may exacerbate centralization issues, making the ETH staking market more concentrated.

Maintaining a minimum of 32 ETH for staking indicates that large holders are still required to participate, representing a compromise with aggregation protocols and avoiding high-frequency operations from small holders that could affect the stability of the consensus layer.

Through EIP-7549, the flexibility of withdrawal operations is increased, allowing stakers and node operators to enhance their control over funds. The technical background here is that the original design had some flaws; since the committee index was included in the signature information, even identical votes would generate different signing roots due to different committees, requiring separate verification for each vote. Therefore, the motivation behind EIP-7549 is to remove the committee index from the signature, allowing for the aggregation of identical votes and reducing the number of pairing operations needed for verification.

Thus, it is important to note that Ethereum is continuously optimizing the staking experience, fundamentally to consolidate the group of stakers and node operators, which is the lifeblood of Ethereum after the merge. Once a large amount of capital is no longer centered around Ethereum, its security will be undermined.

With multiple EIPs supporting this, larger-scale node operators can merge multiple validator accounts, while also providing more flexibility for smaller validators, such as accumulating through compound interest or more flexible staking increments to increase returns.

This is very important. Originally, after reaching 32 ETH, if you generated 10 ETH in new earnings, you would not continue to stake ETH because you would still need to reach 32 ETH to open a new account.

However, after this update, you can directly stake 42 ETH. Clearly, your compound interest earnings can return to ETH.

So, in my view, given the current weak yield of ETH market DeFi projects, it will continue to siphon off, and the liquidity of ETH will decrease. This may be the motivation behind the foundation promoting this series of changes.

L2 Ecosystem Optimization

EIP-7623: Increase calldata cost

This will impact the EVM layer, directly increasing the gas cost of calldata in transactions from 4/16 gas per byte to 10/40 gas. These two values differentiate between zero-byte costs and non-zero-byte costs, representing a 2.5-fold increase.

In fact, lowering block pressure is the banner, forcing L2s to avoid using calldata and instead use more blobs.

EIP-7691: Blob throughput increase

Increases the capacity of blobs in blocks, thereby supporting larger L2 storage space. In the previous Cancun upgrade, there were two core parameters representing blobs: target and max, indicating the target number of blobs per block and the maximum number of blobs per block. Cancun had values of 3 and 6, and now after Prague, the parameters have changed to 6 and 9, essentially expanding capacity.

Ethereum is essentially providing a "highway" for L2s, but how to solve "traffic management" and "different toll standards for highways" is the fundamental issue.

EIP-7840: Add blob schedule to EL config files

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

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

Interpretation

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

Ethereum's core selling point has shifted from the contract system of the DeFi summer to the L2 ecosystem community. Any other chain system, even the hottest BTC L2 system in 2024 (which fundamentally relies on L2 expectations), is not in the same competitive position as Ethereum's L2.

Because either chains like BTC, which have limitations that make it difficult to achieve data rollback and shared security, represent practical L2s.

Other SVM and Move systems are essentially still developing their own L1s and are only beginning to explore L2s on top of them. Of course, the high performance of these chains is relatively less dependent on doing L2.

Thus, Ethereum is enhancing itself through the TPS of L2, but there are many issues, such as liquidity dispersion and cross-chain complexity. However, this is the path it must take. After all, once Web3 develops to the stage of high-frequency application chains, it will not frequently cross chains, and solutions for liquidity and universality are being explored in tracks like chain abstraction, which we will analyze later with Particle Network.

Since the transaction costs on L2 will be highly derived from the capacity of Ethereum's blobs, modifying the gas fee for calldata is to incentivize L2s to use blobs more and not to use Ethereum's permanently retained calldata to store L2 state data.

Additionally, the capacity of blobs also needs to consider further increases in L2, requiring dynamic configurability.

Therefore, through this development direction, we can further confirm the determinacy of the L2 direction, which also means the determinacy of market demand for solving L2's shortcomings.

Final Thoughts

The Prague upgrade is a key stop on Ethereum's continuous evolution path, but from my perspective, this upgrade feels more like a compromise and adjustment solution.

Ethereum is being pushed by the market rather than actively leading, as aside from the unique optimizations in staking and L2, other aspects like BLS and AA have already been widely piloted by other L1s.

However, in terms of overall significance, this upgrade, while not sparking widespread market discussion like "London" or "the Merge," is quietly laying a higher foundation for scalability and decentralization for the Ethereum network.

The advancement of account abstraction will lower the threshold for users to use crypto applications, the improvements in the staking mechanism will further consolidate the security and stability of Ethereum's PoS network, and the enhancements in data availability and throughput will provide broader space for the increasingly prosperous Layer 2 ecosystem.

It is foreseeable that with the completion of the Prague/Electra upgrade, Ethereum will become more efficient, user-friendly, and resilient. More importantly, some concepts and technologies brought by the Prague upgrade will point the way for future improvements.

In the already planned next hard fork "Osaka" upgrade, the community may introduce more revolutionary improvements, such as the long-anticipated Verkle tree state scheme and single-slot finality mechanism.

In the long term, Ethereum's development roadmap is clear and steadfast (though somewhat stubborn), and the cumulative effects of these upgrades will drive Ethereum to achieve grand visions like "one million transactions per second" (The Surge) and resistance to censorship with low centralization risks (The Scourge).

Looking forward to the Osaka hard fork at the end of 2025 (which is expected to be delayed to 2026) and the Amsterdam hard fork in 2026, I hope each upgrade will make Ethereum more mature and robust, with richer functionalities.
Author: Shisi Jun
This article reflects the views of the PANews column author and does not represent the position of PANews, nor does it bear legal responsibility. The article and views do not constitute investment advice.
Image source: Shisi Jun. If there is any infringement, please contact the author for deletion.