Scalability and security go hand in hand: A comprehensive analysis of Ethereum Fusaka upgrade and 12 EIPs

Author: @ChromiteMerge

Ethereum is set to undergo a hard fork upgrade called “Fusaka” on December 3, 2025. This upgrade includes 12 Ethereum Improvement Proposals (EIPs). Think of them as 12 precisely engineered parts that will work together to enhance Ethereum’s scalability, security, and operational efficiency. Below, the author will categorize and explain, in plain terms, what problems each of these 12 EIPs addresses—and why they are crucial to Ethereum’s future.

Scaling! Make Ethereum faster and able to handle more

This is the core theme of the Fusaka upgrade. To support a global digital economy, Ethereum must solve the problems of transaction congestion and high fees. The following EIPs are designed to achieve this goal—especially by improving cost and efficiency for Layer 2 scalability.

EIP-7594: PeerDAS - Data Availability Sampling

Pain point: After the Dencun upgrade introduced data “Blobs” to provide low-cost data storage for Layer 2, one key issue emerged: how can we ensure that this massive amount of data is actually available? The current approach requires every validating node to download and verify all blob data included in a block. When a block carries up to 9 Blobs, this method is still workable. But if the number of Blobs increases further in the future (for example, 128 Blobs), downloading and verifying all blobs would create substantial overhead, raising the participation threshold for validating nodes and threatening the network’s decentralization.

Solution: PeerDAS (Peer Data Availability Sampling) turns the traditional “check everything” into “sample checks.” Put simply:

2. The network slices the full blob data.

3. Each validator does not need to download all blobs; it only needs to randomly download and check a few data fragments.

4. Then, by mutually sampling, exchanging verification results, everyone can jointly confirm the completeness and availability of the entire set of blob data.

It’s like a large jigsaw puzzle game: everyone holds only a few pieces, but as long as they verify the key connections with each other, they can determine whether the whole puzzle is intact. It’s worth noting that PeerDAS is not an entirely new invention; the core DAS idea has been successfully implemented in third-party DA projects such as Celestia. Implementing PeerDAS is more like paying down a critical “technical debt” on Ethereum’s long-term scalability roadmap.

Meaning: PeerDAS dramatically reduces the storage burden on validators, removing obstacles that could otherwise weaken decentralization as Ethereum scales to massive data capacity. In the future, each block could potentially include hundreds of Blobs, supporting the Teragas vision’s claim of up to 10 million TPS. At the same time, ordinary people will also be able to run validators easily, keeping the network decentralized.

EIP-7892: BPO Hardfork - Lightweight Parameter Upgrades

Pain point: Demand for Layer 2 data capacity changes overnight. If every time the Blob limit is adjusted, the ecosystem must wait for a large upgrade like Fusaka, that would be too slow and wouldn’t keep pace with the development of the ecosystem.

Solution: This EIP defines a special “Blob parameter-only hardfork” (Blob Parameter Only Hardfork, BPO) mechanism. This kind of upgrade is very lightweight: it only modifies a few parameters related to Blobs (such as the target number of Blobs per block) and does not involve complex code changes. Even node operators don’t need to upgrade client software; they only need to accept the new parameters at the specified time—just like updating a configuration file online.

Meaning: The BPO mechanism gives Ethereum the ability to quickly and securely adjust network capacity. For example, after the Fusaka upgrade, the community plans to execute two consecutive BPO upgrades in a short period, gradually doubling Blob capacity. This allows Ethereum to scale blob space on demand, elastically, and progressively, smoothing improvements to L2 costs and throughput while keeping risks more controllable.

EIP-7918: Stable Blob Fee Market

Pain point: The previous mechanism for adjusting Blob fees was too “market-driven,” which leads to some unintended issues. First, when demand for Blobs is very low, fees drop close to zero—but this doesn’t effectively stimulate new demand; instead, it creates an abnormal “historical lowest price.” Conversely, when demand is strong, blob fees can skyrocket, creating another extreme high price. This kind of intense price “arms race” (fee undercutting) makes Layer 2 fee planning difficult to manage.

Solution: The core idea of EIP-7918 is that Blob fees should no longer be allowed to fluctuate without bounds. Instead, a reasonable price range is established—an elastic “minimum consumption” floor. The implementation links the upper and lower bounds (limits) of the blob fee to Layer 2’s execution fee on Layer 1. Whether you update the state root or verify a ZK proof once, these execution fees are relatively stable and have little relationship to the transaction volume within an L2 block. Therefore, tying the blob fee’s upper and lower bounds to this stable “anchor” prevents its price from wildly jumping around.

Meaning: The direct benefit of this improvement is that it prevents the blob fee market from going through an “arms race,” making Layer 2 operators’ cost models more predictable. This helps Layer 2 set more stable and reasonable transaction fees for end users, avoiding the “free today, tomorrow it’s sky-high” roller-coaster experience.

EIP-7935: Increase Mainnet Transaction Capacity

Pain point: The total number of transactions a single Ethereum block can include is determined by the “block Gas limit” (currently about 30 million) and has not been adjusted for many years. The most direct way to increase the network’s throughput is to raise this limit, but it must ensure that validator hardware requirements are not increased and that decentralization is not weakened.

Solution: This proposal suggests increasing the default block Gas limit to a new level (the exact number is still to be determined and could be 45 million or higher). This is not a forced lock-in; it provides a new recommended default value to guide validators in the consensus layer to gradually accept higher Gas limits.

Meaning: This means each Layer 1 block can package more transactions, directly boosting the Ethereum mainnet’s TPS and alleviating congestion and rising Gas fees. Of course, this also places higher hardware requirements on validators, so the community will proceed cautiously with testing and rollout.

Security and Stability! Build a solid line of defense for the network

Alongside scaling, the network’s security and stability must be ensured. In May 2025, the Ethereum Foundation launched the “Trillion Dollar Security” (1TS) plan, aiming to build an Ethereum network that can safely secure assets worth trillions of dollars. Multiple EIPs in Fusaka are part of pushing forward the 1TS plan—like installing more reliable “brakes” and “guardrails” on an Ethereum that’s driving at high speed.

EIP-7934: Set a Maximum Block Physical Size

Pain point: Ethereum’s “block Gas limit” only cares about the total computation amount of all transactions inside the block, but it does not specify the block’s physical size. This creates a loophole: attackers can carefully construct many “low-cost, large-in-size” transactions (for example, sending 0 ETH to a large number of addresses)—with very low computation but very large data size—so they can produce a block whose computation stays well below the limit while its physical volume is unusually huge. Such “data bomb” blocks propagate through the network extremely slowly, which may cause some nodes to not receive the data in time and fall behind, creating a serious DoS (denial-of-service) attack risk.

Solution: Set a hard 10MB size limit for each block. Any block exceeding this size will be rejected by the network.

Meaning: This is like setting the maximum size of trucks on a highway to prevent “over-wide and over-long” vehicles from affecting traffic. It ensures blocks can propagate quickly across the network, reduces latency, and improves the network’s stability and resistance to attacks.

EIP-7825: Set a Gas Limit for Individual Transactions

Pain point: Currently, while there is a block-wide total Gas limit, there is no limit per individual transaction. In theory, someone could construct a single transaction that consumes almost the entire block’s resources, pushing everyone else’s transactions out. That is unfair and also introduces a security risk.

Solution: Set a hard limit of 16,770,000 Gas per transaction. Any complex operations beyond this scale must be split in advance into multiple transactions before they can be submitted.

Meaning: This improves network fairness and predictability, ensuring no single transaction can “buy out the block.” Users’ normal transactions won’t be excessively delayed because of some “super large order.”

EIP-7823 & EIP-7883: ModExp Precompile Security Hardening

Pain point: ModExp is a feature in Ethereum used to handle big-number modular exponentiation, commonly found in some cryptographic applications. However, it has two risks: first, there is no limit on the length of input numbers, so an attacker could craft an excessively large input to “blow up” the system; second, the Gas pricing for ModExp is too low, meaning attackers could call it in large quantities at low cost, consuming node resources.

Solution:

• EIP-7823: Set an 8192-bit upper limit for ModExp input length; this length is far more than enough for real-world application needs.

• EIP-7883: Increase ModExp Gas charges—especially for larger inputs—so the fee rises sharply, ensuring computation cost matches resource consumption.

Meaning: These two improvements tackle the issue from both sides, removing a potential attack vector. They’re like giving a computing service both a “maximum job size” and a “tiered electricity price” so it can’t be abused—thereby improving the overall robustness of the network.

Feature upgrades! Provide developers with more powerful tools

In addition to scaling and security, Fusaka also brings developers some practical new tools and functions, making it more efficient and powerful to build applications on Ethereum.

EIP-7951: Compatibility for Mainstream Hardware Signatures

Pain point: The mobile phones we use every day (such as iPhones), bank U-shields, hardware security modules, and similar devices all typically use an encryption standard called secp256r1 (also known as P-256) for their built-in security chips. But Ethereum defaults to a different standard, secp256k1, which prevents these mainstream devices from interacting securely with Ethereum directly, limiting the large-scale adoption of Web3.

Solution: Add a precompiled contract so Ethereum can natively support and verify signatures from the secp256r1 curve.

Meaning: This is a milestone improvement. It opens the door for Ethereum to interact with billions of hardware devices worldwide. In the future, you’ll be able to sign Ethereum transactions directly using the security chip in your phone, without needing an extra wallet app or complex conversions—resulting in a smoother experience and higher security. This greatly lowers the barrier for the traditional world to access Ethereum, and is a major positive for bridging Web2 and Web3.

EIP-7939: Add CLZ Efficient Computation Instruction

Pain point: In smart contract and cryptography applications, it’s often necessary to compute how many consecutive zero bits appear at the beginning of a 256-bit number (for example, in hash algorithms, compression algorithms, zero-knowledge proof scenarios, and more). Today, the Ethereum EVM has no direct Opcode support for this operation, forcing developers to implement it with complex Solidity code, which is costly and inefficient.

Solution: Add an Opcode named “CLZ” (Count Leading Zeros) to the EVM to perform the calculation in one step.

Meaning: It’s like giving developers a professional tool that saves time and effort. It can significantly reduce the Gas cost of related operations, making applications that rely on complex math computations—especially ZK Rollups—run cheaper and more efficiently.

Network optimization! Invisible improvements for a healthier ecosystem

The last two EIPs may not be strongly felt by users, but they are crucial to the network’s long-term healthy operation and coordination efficiency.

EIP-7642: Reduce New Node Synchronization Burden

Pain point: Over time, Ethereum has accumulated massive amounts of historical data. For a new node to join the network, it needs to download and synchronize all of that data—taking time and effort and raising the threshold. In addition, since Ethereum switched from The Merge to PoS consensus, some fields in old transaction receipt information are no longer needed, creating redundancy.

Solution: Introduce a “history data expiration” strategy so that when new nodes synchronize, they can skip some data that is too old; at the same time, simplify the transaction receipt format and remove redundant fields that are no longer needed. This way, when new nodes synchronize starting from the genesis block, they can avoid downloading large amounts of useless data.

Meaning: This improvement enables nodes to “shed weight.” Each full-node synchronization can reduce about 530GB of data transfer. A lower threshold means more people can run nodes, strengthening the network’s decentralization and robustness.

EIP-7917: Deterministic Block Proposer Order and Preconfirmation

Pain point: To understand the importance of this EIP, we first need to discuss a core pain point of today’s Layer 2 Rollups: centralized sequencers. Right now, most Rollups rely on a single entity to receive and order users’ L2 transactions. This gives it the power to censor transactions and extract MEV, which is at odds with the spirit of decentralization. To address this, the community proposed the concept of Based Rollups—basically giving up the L2’s own sequencer and directly using the Ethereum L1 block Proposer to order L2 transactions, inheriting L1’s decentralization and neutrality.

However, this approach has a fatal drawback: it’s slow. Layer 2 must wait until the L1 block is finalized and published before it can execute transactions, resulting in significant delay and a poor user experience. The only solution is to introduce a “preconfirmation” mechanism: the L2’s Gateway can obtain a commitment in advance from future L1 proposers—“I guarantee that I will include your submitted transactions on-chain, otherwise I will compensate you”—so that Layer 2 can update state early (such as account balances) and reduce user waiting time. But under the current mechanism that randomly determines the proposer, the gateway has no idea who to negotiate with, so reliable preconfirmation becomes impossible.

Solution: EIP-7917 modifies the consensus protocol so that, for a future period of time, the Proposer order can be computed in advance deterministically and published to the public. It turns “on-the-fly drawing lots” into a publicly checkable, pre-scheduled “block timetable.”

Meaning: This improvement is a key foundation for enabling next-generation decentralized approaches like Based Rollups. With this “timetable,” an L2 gateway can identify the proposer for a future block in advance and negotiate directly with them to obtain a可信的预确认 (preconfirmation) backed by Slash penalties. This allows Based Rollups to enjoy L1-level decentralization and security while also giving users near-instant transaction experiences similar to centralized sequencers. In a sense, EIP-7917 helps the Ethereum ecosystem scale deeper toward “decentralization,” opening a crucial door.

Why is the Fusaka upgrade coming at the right time?

This Fusaka upgrade is not only a technical iteration, but also an important strategic upgrade in the context of the era when traditional finance moves to the blockchain at large scale through RWA and stablecoins. Today, Ethereum—serving as the main battlefield—already supports more than 56% of the stablecoin supply across the entire network, becoming the core settlement layer of the global digital dollar economy. Fusaka’s goal is to prepare for assets and transaction volumes at “Wall Street”-level scale.

• Fuel for institution-grade Layer 2 chains—unlimited scalability

As traditional financial institutions enter the scene, we will see more “application-specific chains” for particular needs (such as KYC compliance) emerging as Layer 2 solutions. These application-specific chains require the Ethereum mainnet to provide massive, low-cost, and secure data storage capacity (i.e., Data Availability).

The proposals in Fusaka—such as EIP-7594, EIP-7892, and EIP-7918—are exactly designed to meet this need. Their core goal is simple: significantly reduce the cost of data publishing for Layer 2, and provide elastic scalability on demand.

Actually, after the Pectra upgrade, Blob fees are already very low—why keep pushing them down? Because Fusaka follows a strategy of “sacrificing short-term fee revenue to enable bigger economies of scale.” The aim is to grow the network’s GDP, turning more transactions into more staking and ETH burning, thereby supporting the network’s overall value.

• Moving toward “trillion-dollar security,” building an unbreakable financial infrastructure

For financial institutions that manage trillion-dollar assets, security is a non-negotiable bottom line. The Ethereum community has also set the ambitious goal of “trillion-dollar security.” The EIPs in Fusaka—EIP-7934, EIP-7825, EIP-7823, and EIP-7883—are meant to strengthen the walls, eliminate potential security hazards, and move toward this goal.

In short, the main thread of the Fusaka upgrade is clear and firm: scaling and security. With both regulatory tailwinds and market momentum driving it, Fusaka is arriving at precisely the right time. It will help Ethereum seize the opportunity from favorable policies, consolidate its dominant position in the stablecoin and asset-on-chain space, and further transform Ethereum from an “investment speculation asset” into a mainstream financial infrastructure.

Conclusion: Change that runs deep like still water

As an important upgrade at the end of 2025, Fusaka quietly injects strong internal momentum into Ethereum without being met by overwhelming market hype. Its 12 included improvements directly address the three major pain points of scalability, security, and efficiency. What it does is broaden Ethereum’s “value highway,” increasing its capacity and reliability, and preparing it for massive future users, assets, and applications.

For ordinary users, these changes might seem “quiet,” but their impact will be far-reaching. A stronger, more efficient, and more secure Ethereum will be able to realize grand visions that were previously only imaginable—whether it’s a global instant settlement network or a “on-chain Wall Street.” Fusaka is a solid step toward that future.

• This article is based on publicly available information and does not constitute investment advice. Investing in cryptocurrencies involves significant risk—please make decisions carefully and DYOR.

• If you like this article, feel free to follow, like, and share to support it!