Ethereum Prague Upgrade Analysis: A Compromise Solution of Continuous Adjustments

Author: Shijiu Jun

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

The major version hard forks of Ethereum, occurring every 1-2 years, gradually radiate from itself to various Ethereum series L2s, and then expand to the development of multiple L1s. Each hard fork contains EIPs that represent the essence of the Ethereum core community, balancing benefits and costs.

So let Shijiu 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 precise timing of the upgrade is expected to be released on the Sepolia testnet on the 3.5 and on the Ethereum mainnet on the 4.8.

The Ethereum official code repository released the first line of the version 4 days ago (2025.2.26) stating: "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 widespread outage).

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

From my personal perspective, this upgrade is also the most influential one for Ethereum since the merge from PoW to PoS, 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 compatibility at the moment of the mainnet switch, and as users, we can also experience it through wallets.

But the real core question is—can this upgrade, apart from the technical implementations by developers, 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?

Panoramic Scan

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

Clearly, we can see three major characteristics:

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

2. 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 (the three added are optimizations for the L2 layer promoted by Vitalik). In the past, a major version would typically start from a core point with a few optimizations, but now it is almost a multi-faceted approach, and the AA (hard fork version) that was difficult to reach consensus on for many years has also been included. From this, we can feel some radical states under the explosion of multi-chain, with EVM systems facing SVM systems (like Solana) and Move systems (like Aptos), as well as the BTC systems (various BTC L2s) all thriving.

3. Ethereum is increasingly leveraging ecological joint advantages, leaning towards optimizing user experience. 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 (which would reduce user costs and price volatility, considered user experience optimization) was in 2018. The last time, by introducing blobs, significantly reduced L2 user transaction costs, and this time, the three points in time 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 it has changed.

Experience Optimization

The most significant change is EIP-7702, which introduces the account abstraction mechanism from the chain layer.

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, only driving and using CA logic when needed, thus lowering holding costs.

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

Users can easily perform multiple transactions in parallel using EOA, such as combining authorization and execution of deductions, which inherently lowers the transaction costs for users.

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

So, although it changes 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 vendors 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, 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

1. 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).

2. Adds functionalities for BLS signature verification, public key aggregation, and multi-signature verification.

3. Specifies specific precompiled addresses for different BLS operations, allowing contracts to directly call these precompiled addresses without needing to deploy additional code to perform complex mathematical operations related to BLS12--381.

Interpretation

It becomes increasingly convenient for ordinary users to use multi-signature smart contract wallets at low costs. It significantly reduces the complexity of signature verification calculations and Gas costs, and can more efficiently implement and support zero-knowledge proofs (like zk-SNARKs) and homomorphic encryption functions. 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

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

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

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

4. Provides Set and Get operations, where SET is operable by the system address for writing transactions, and 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 L2, as most L2s need to access past L1 block hashes to verify the consistency of on-chain data and historical information.

Additionally, oracle-type on-chain verification services need to verify historical blocks and track data to prevent errors in off-chain reported data.

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 delve into it 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)

This will implement staking operation processing 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 execution layer block structure, so the consensus layer no longer needs to rely on the staking data (eth1data) voting mechanism.

EIP-7002 (Execution layer triggerable withdrawals)

This proposal allows the Ethereum execution layer to provide a mechanism for triggering validator exits and partial withdrawals, enabling validators using the "0x01" withdrawal credential 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 back 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 a continued requirement for large holders to participate, representing a compromise with aggregation protocols and avoiding frequent operations by 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 with the same vote, different committees would generate different signing roots, necessitating separate verification for each vote. Therefore, the motivation behind EIP-7549 is to achieve aggregation of the same votes by removing the committee index from the signature, reducing the number of pairing operations required for verification.

Thus, it is important to note that Ethereum is continuously optimizing the staking experience, fundamentally to consolidate the community 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, it allows larger-scale node operators to merge multiple validator accounts while also providing more flexibility for smaller validators, such as accumulating 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 need to reach 32 ETH again 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, in the current situation where the yields of ETH market DeFi projects are weak, 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 affect the EVM layer, raising the gas cost of calldata in transactions directly from 4/16 gas per byte to 10/40 gas. The two values distinguish between the costs of 0-byte and non-0-byte, both representing a 2.5-fold increase.

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

EIP-7691: Blob throughput increase

Increases 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, indicating the target number of blobs per block and the maximum number of blobs per block. Cancun was 3 and 6, and now after Prague, the parameters have become 6 and 9, essentially expanding capacity.

In fact, Ethereum is just adding 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 that can adjust the responsiveness of blob gas pricing.

Interpretation

After all, these are EIP proposals, so they sound 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 the expectations of L2), is not in the same competitive position as Ethereum's L2.

Because either chains like BTC, which have limitations, find it difficult to achieve data rollback and meaningful security sharing as L2.

Other SVM and Move systems are essentially still developing their own L1s and are only shallowly exploring 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, and of course, there are many issues, such as liquidity dispersion and cross-chain complexity. But 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 attempted 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 fees for calldata is to incentivize L2 to use blobs more.

Do not use Ethereum's permanently retained calldata to store L2's state data.

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

Thus, through this development direction, it further confirms the determinacy of the L2 direction, which also means the determinacy of market demand for solving L2 shortcomings.

In Conclusion

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 apart from the unique optimizations for staking and L2, other aspects like BLS, AA, etc., have already been widely piloted by other L1s.

However, in terms of overall significance, this upgrade, although not sparking widespread market discussions 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, improvements in the staking mechanism will further consolidate the security and stability of Ethereum's PoS network, and enhancements in data availability and throughput will provide broader space for the increasingly prosperous second-layer 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 run, Ethereum's development roadmap is clear and firm (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 anti-censorship, low centralization risk (The Scourge).

The Osaka hard fork at the end of 2025 (which is expected to be delayed to 2026) and the Amsterdam hard fork in 2026 are anticipated to make Ethereum more mature and robust with richer functionalities with each upgrade.