introduction

If the history of blockchain is the expansion history of Bitcoin, then the periodic upgrade of Ethereum is the core pointer to the direction of expansion.

Every 1-2 years, the upgrade of the big version of Ethereum hard fork will gradually radiate from itself to the L2 of the various Ethereum series, and then expand to the development of multiple L1, and the Eip contained in each hard fork represents the high essence of the core community of Ethereum, which is the result of the balance of benefits and costs.

So we still have 14 King take you through each of the 11 Eips that Bragg-Electra upgraded from a technical point of view, what is it, what does it do, and why him?

backdrop

The exact timing of the current update is expected to be released on the Sepolia testnet on the 3.5th and on the Ethereum mainnet on the 4.8th.

The official Ethereum codebase released the version 4 days ago (2025.2.26) with the first sentence: "Oh look, another hotfix release!" "Yes, there is a problem, the version of the code currently active in the Holesky test net is causing a fork in the test net (which can be interpreted as a large area of downtime)."

While we don't need to focus on the bugs in the fork code, we can see the complexity of this one.

And from the author's personal point of view, this upgrade is alsoEthereum's most influential since the Pow to Pos mergeIt will completely change the mode of operation on the chain and bring a new experience.

The complete list of eip is as follows:

Although the introduction proposal has been slightly changed, it has attracted the attention of Okx, Metamask, WalletConnect, Biconomy, BaseWallet, Uniswap, Rhinestone, ZeroDev, TrustWallet, Safe and many other wallet teams. Basically all in ensuring that the moment of the main network switch can be adapted, as users, we can also use the wallet to experience.

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

Does the change go far enough, or is it just a routine patch by the Ethereum Foundation in the L2 era?

Panoramic scanning

Let's start with a chart to get a sense of the overall rhythm

Obviously, we can see three characteristics:

1. After the development of Ethereum enters the deep water zone, new proposals can basically be includedThey're all members of the Ethereum Foundation. Vitalik was the first to make the important changes. It is almost impossible to see the creative integration of other characters into the official upgrade, which may also be a proof of the market voice of Ethereum more and more "single-minded", and gradually become an increasingly centralized decision-making system.

2. ethereumThe pace of the market is acceleratingThis upgrade from November last year, the basic consensus has been completed 8, and now the actual implementation includes 11 (the increase is vitalik to promote the l2 level of 3 optimization), once a big version, basically only from a core to do a few optimization, but now almost all are multi-party. AA (hard fork version), which had been difficult to agree on for many years, was also included. It can be felt that under the multi-chain outbreak today, evm systems are facing some radical states under the vigorous development of svm systems (solana, etc.), move systems (aptos, etc.) and even btc systems (all types of btcL2).

3. Ethereum is taking advantage of ecological integration and is increasingly inclined to optimize the user experienceMaybe you will think that optimizing the user experience should not be? Nooooo.In fact, many large version mergers of Ethereum have nothing to do with ordinary user experience. The last time to adjust the block size (expansion will reduce user costs, reduce price volatility is user experience optimization) was 18 years ago. Last time, through the introduction of blob, the user fee cost of L2 was greatly reduced, and this time, the three time points can be seen to pay attention to the optimization of user cost.

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

So let's talk about the details and let's talk about the details and let's understand, what did he change?

Experience optimization

The first and most important change, when 7702, is the introduction of the account abstraction mechanism from the chain layer update, which we have previously had a systematic article interpretation, this time not to repeat:From 4337 to 7702: An in-depth look at the past and future of the Ethereum Account abstract circuit"

unscramble

Objectively speaking, 7702 breaks the impossible unspoken rules on multiple chains, and also breaks the application logic of most DApps.

For the user, he himself is still an EOA address, only when needed to drive and use CA logic, so the holding cost is low.

No need to convert the CA identity out of the chain before 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 executive withholding, so that the transaction cost of users is low.

For Dapps, especially for project parties that need to do enterprise-level management on the chain, such as exchanges, it is subversive optimization, and once the original ecology is realized, the basic exchange cost can be reduced by more than half instantly, and ultimately can benefit users.

So, although he's changed a lot,However, occupying this dimension of cost is worth all DApps to study and adaptBecause this time, users must be on the side of the EIP7702.

But there is an implicit risk: account abstraction, while reducing the cost of interaction, also increases the complexity of user rights management.

If the wallet manufacturer fails to properly adapt, it may bring unexpected security vulnerabilities, which used to be a single-chain asset loss at most, and now may be a full-chain loss or even a timed explosion.

Apparently, this is an upgrade that phishing hackers love, and users need to be more careful about on-chain transactions

Application side optimization

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

effect

1. The BLS12-381 elliptic curve is introducedPrecompiled operationOptimizes complex encryption operations such as BLS signature verification, providing increased security (120+ bit security) and computational efficiency (Gas optimization)

2. Added BLS signature verification, public key aggregation, and multi-signature verification.

3. Specific precompiled addresses are specified for different BLS operations, and contracts can be performed directly by invoking these precompiled addresses without deploying additional code to perform complex mathematical operations associated with BLS12-381.

unscramble

It is becoming more and more convenient for ordinary users to use multi-signature smart contract wallets at low cost. The complexity and Gas cost of signature verification can be significantly reduced, and functions such as zero-knowledge proofs (such as zk-SNARKs) and homomorphic encryption can be implemented and supported more efficiently. Privacy and interoperability (especially with other BLS-enabled blockchains like ZCash) will play a role.

EIP-2935 (Serve Historical Block Hashes from State)

effect

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

2. This design allows the client to access the historical block hash at execution time without having to store the entire chain's historical data itself, which is especially important for future optimization schemes such as Verkle trees.

3. This hash data is stored in a circular buffer, which supports rolling updates, that is, keeping the latest 8192 block hash values at all times.

4. Provide Set and getOperation, SET is the system address operable to write transactions, while the user can use get to query the block hash with the block number.

unscramble

Because the client can access the historical block hash with a simple query without additional storage,So there's no direct impact on the average user, butWill promote the emergence of some storage-free clientsIt has optimization value for on-chain verification service applications.

The cost of RollupL2 also helpsBecause most L2 requires access to the L1 block hash from a past period of time to verify the consistency and historical information of the data on the chain.

There are also on-chain verification services of the oracle class, which need to verify and track data on historical blocks to prevent data errors from being reported under the chain.

Multiple optimizations of pledge scenarios

Ethereum pledge is a big topic, but it has little impact on the average user (but if you are involved 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 together.

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

The pledge operation will be processed through the in-chain protocol mechanism, eliminating the voting mechanism of the consensus layer, and optimizing the security and efficiency of the pledge traffic. By adding the operation list of the verifier pledge in the block of the execution layer, the record and verification of the pledge operation are directly placed in the block structure of the execution layer.The consensus layer no longer needs to rely on the eth1data voting mechanism.

EIP-7002 (Execution layer triggerable withdrawals)

The proposal is for Ethereum's Execution Layer to provide a mechanism to trigger the verifier's exit and partial withdrawal, so that the verifier using the "0x01" withdrawal certificate can independently control its pledged ETH from the execution layer.

EIP-7251 (Increase the MAX_EFFECTIVE_BALANCE)

Increase the effective pledge limit for a single verifier (to 2,048ETH), while the minimum pledge limit remains at 32 ETH.

EIP-7549 Move committee index outside Attestation

Move the committee index field of the "Attestation" (proof) message in the consensus layer outside the message to simplify validation and improve efficiency. Ultimately, the performance of the Casper FFG client improves, especially when running in ZK circuits.

unscramble

It may seem confusing to read so much at once, but we can 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 larger pledged assets,This leads to the existence of a large number of "redundant validators".

Therefore, the maximum limit is raised through EIP-7251, which can reduce the number of control accounts and reduce the complexity of the system for lido's aggregate pledge agreements, butThis could exacerbate decentralization issues and make the ETH pledge market more centralized.

And always maintain a minimum of 32 pledges, indicating that large households are still required to participate, which is an ecological compromise with the aggregation protocol, but also to avoid small households prone to high-frequency operations affecting the stability of the consensus layer.

With EIP-7549, the flexibility of the withdrawal operation is increased, which is convenient for the pledgee and the node operator to enhance the control of the funds. The technical background here is due to some flaws in the original design, because the committee index is included in the signature information, even for the same vote, because different committees generate different signing roots, resulting in the need to verify each vote individually. 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, thereby enabling aggregation of the same votes.

So, be aware that Ethereum is constantly optimizing the pledge experience,The essence is to consolidate the community of pledge and node operatorsThis is the lifeblood of Ethereum after the merger, and once a lot of money is no longer around Ethereum, its security itself will be shaken.

With multiple eip subscriptions, this allows larger node operators to consolidate multiple validator accounts, while also giving smaller validators more flexibility, such as the ability to increase returns through compound income accumulation or more flexible pledge increments.

This is very important, after the original 32ETH is achieved, if you generate 10 new ETH income, in fact, you will not continue to take the ETH pledge, because you also need to gather 32 to open a new account.

But after this update, you can directly pledge 42 eth.Then obviously your compounding returns go back to ETH.

so, in my opinion,In the current situation of the weak revenue of the defi project in the ETH market, he will continue to siphon, and the flow of ETH will decrease, which may be the motivation of the foundation to promote this series.

The optimization of L2 ecology

EIP-7623: In c rease calldata cost

This is something that will affect the evm layer, raising the gas cost of calldata in the transaction directly from 4/16 gas per byte to 10/40 gas, where the two values are the difference between the 0 byte cost and the non-0 byte cost, both are 2.5 times the increase.

In fact, lowering the block pressure is the flag,Instead of using calldata, use BLObs for L2.

EIP-7691: Blob throughput increase

Increase the capacity of bloBs in blocks to support larger L2 storage. In the previous Cancun upgrade, there were two core parameters that represented the blobtargetandmaxIs used to represent the number of target blobs per block and the maximum number of blobs per block. Cancun was 3 and 6, and now after Prague, the parameters are 6 and 9, so it's expanded.

In factEthereum is only adding "highways" to L2, but how to solve the "traffic management" and "different high-speed charging standards" is the most fundamental problem.

EIP-7840: Add blob schedule to EL config files

Increments a configuration file to allow clients to dynamically adjust the blob number Settings for EIP-7691.

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

unscramble

It's an EIP proposal, after all, so it sounds technical, but the core idea is easy to grasp.

Ethereum's core selling point has changed from the Defi Summer contract system to the L2 ecosystem communityAny other chain system, even the hottest btcL2 system in 24 years (the essence of the inscription is still because of the expectation of L2), is completely and Ethereum L2 is not a competitive bit.

Because either such as btc, because the chain limit is difficult to do data fall back, security sharing such a practical sense of L2.

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

So Ethereum is through L2 tps to achieve Ethereum itself, of course, there are many problems, liquidity dispersion, cross-chain complexity, are problems. But that's the only way he can go. After all, once web3 develops to the stage of high-frequency application chain, in fact, it will not frequently cross the chain, and to solve the problem of mobility and versatility, there are such tracks as chain abstraction in the attempt, and later we will interpret the particle network and so on to analyze.

Because transaction costs on L2 will be highly dependent on the capacity of Ethereum's BlobTherefore, from modifying the gas fee of calldata, it is to encourage L2 to use blob. Do not use Ethereum's permanent calldata to store l2 status data .

In addition, the blob capacity also needs to be considered for further L2 increases and needs to be dynamically configurable.

So, through this development direction, we can further determine the certainty of L2 direction,It also means certainty of market demand to address L2's shortcomings.

Write at the end

The Prague upgrade is a key stop on Ethereum's continued evolution path, but as far as I'm concerned,This upgrade, it is more like a compromise, constantly adjusting the compromise.

Ethereum is being pushed by the market, rather than actively leading, because in addition to the pledge and the unique optimization of Ethereum on L2, other bls, aa, etc., have actually been widely piloted by other L1.

**But, in the overall sense,**Although this upgrade is not like "London", "merger" as a wide market hot discussion, but quietly lay a higher scalability and decentralized foundation for the Ethereum network.

The promotion of account abstraction will reduce the threshold for users to use cryptographic 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 two-layer ecology.

It can be predicted that with the Prague/Electra upgrade completed,Ethereum will become more efficient, friendlier, and more resilientMore importantly, some of the ideas and technologies brought about by the Prague upgrade point the way for future improvements.

In the "Osaka" upgrade, already planned for the next hard fork, the community may introduce even more revolutionary improvements,For example, Verkle tree state scheme and single slot final confirmation mechanism have long been highly expected.

In the long term, Ethereum's development roadmap is clear and firm (though somewhat stubborn), and the cumulative effect of these upgrades will drive Ethereum to fulfillment**"The Surge" and anti-censorship, The Scourge**Such grand visions.

The Osaka hard fork at the end of 2025 (the usual estimated delay to 26 years) and the Amsterdam hard fork in 2026 are expected to make Ethereum more mature, robust and feature-rich with each upgrade.