Today, Ethereum's Fusaka upgrade is scheduled to go live. The Fusaka upgrade is characterized by consensus layer updates related to blob scalability, including PeerDAS and BPO forks, as well as execution layer updates that raise gas fees and block size limits.
Fusaka upgrade will pave the way for L2 rollups to scale while leveraging Ethereum's native security instead of external data availability solutions, laying the foundation for the rollup ecosystem to be more tightly bound to Ethereum.
Coordinating and applying 12 EIPs within seven months in a decentralized network where thousands of nodes must reach consensus is by no means slow. This gradual and deliberate approach to evolution is precisely how Ethereum maintains the largest ecosystem among countless "killer" chains.
Source: Ethereum
Today(December 3, 2025), Ethereum is set to activate Fusaka, its 17th major upgrade, on mainnet. The name Fusaka combines Osaka, the execution layer upgrade designation, with Fulu (a star in the Cassiopeia constellation named in Chinese astronomy), the consensus layer upgrade designation, following Ethereum's traditional naming convention.
Coming approximately seven months after the Pectra upgrade applied in May 2025, this upgrade is part of Ethereum's accelerated development schedule aiming for two hard forks per year. While Fusaka does not include the dramatic user experience innovations or staking modifications seen in Pectra, it targets the most significant network scalability improvement since The Merge in 2022.
The key EIPs included in the Fusaka upgrade are as follows:
[Consensus Layer]
EIP-7594: Reduces node download burden through blob data sampling and expands rollup data processing capacity
EIP-7892: A minimal hard fork mechanism for blob capacity adjustment, enabling gradual expansion without network upgrades
EIP-7918: Stabilizes the fee market by setting a minimum price for blob gas costs
[Execution Layer]
EIP-7642: Improves node synchronization speed and storage savings through chain history expiration and receipt simplification
EIP-7823: Optimizes cryptographic operations by adjusting costs and limits for modular exponentiation
EIP-7825: Prevents network overload by setting a gas cap for single transactions
EIP-7883: Rebalances gas costs for the modular exponentiation precompile (ModExp)
EIP-7910: Improves communication between consensus and execution layers
EIP-7917: Enhances on-chain predictability of the proposer schedule
EIP-7934: Ensures stability through block size limits
EIP-7935: Increases L1 throughput by raising the per-block gas limit from 36M to 60M
EIP-7939: Reduces math and bit operation costs by adding a new EVM opcode for leading zero count operations
Of course, these brief descriptions alone make it difficult to fully grasp the significance of each update. Therefore, in the following sections, we will revisit the key EIPs included in the Fusaka upgrade, explaining what problems they were proposed to solve and what future they could open for general users, developers, and the entire Ethereum ecosystem.
2.1 PeerDAS: A World Where You Don't Have to Download Everything
What if Netflix could only provide its service by downloading all movies and dramas entirely to your phone? Your phone's storage would fill up instantly, and your monthly data costs would skyrocket.
Ethereum's rollups faced a similar situation. Rollups bundle numerous transactions and post data to the Ethereum mainnet in the form of "blobs." The problem was that, until Fusaka, all full nodes had to download and store this entire blob data. As rollup usage increased, bandwidth and storage requirements for node operators grew exponentially, threatening the core principle of decentralization: that ordinary people should be able to run nodes.
Source: Jarrod Watts
PeerDAS (Peer Data Availability Sampling), introduced through EIP-7594, fundamentally solves this problem. The core idea of PeerDAS is Data Availability Sampling (DAS), a technology that allows nodes to verify that data actually exists and is available without downloading the entire blob data.
Imagine inspecting books at a library. When a box containing 100 books arrives, instead of taking out and checking every single book, you randomly select and inspect only 10. If someone tried to send an empty box, there would be a very high probability of finding empty spaces through random sampling. The more samples you take, the harder it becomes to deceive. PeerDAS implements this principle cryptographically, allowing mathematical certainty that all data exists by checking only a portion of it.
DAS is not an entirely new technology. Although there are some technical differences, external data availability layers like Celestia and Avail already use this technology, and some rollups have chosen these external solutions instead of Ethereum for cheaper data costs. The significance of PeerDAS lies in embedding this proven technology into the Ethereum protocol itself. Rollups can now achieve scalability while directly inheriting Ethereum's security, without relying on external chains for data availability.
With the introduction of PeerDAS, each node can verify the data availability of the entire network while storing only about 1/8 of the total data. This significantly reduces the burden on node operators while laying the groundwork for expanding blob throughput. Future parameter adjustments could lower the per-node storage ratio to 1/16 or 1/32, leaving room for additional expansion.
The practical impact will be felt in L2 users' wallets. As blob throughput increases, the data posting costs that L2 rollups must pay will decrease, which translates directly into lower L2 transaction fees. Some predict that the combination of Fusaka and the BPO fork described in Section 2.2 will reduce L2 data fees by an average of 15-40%, and up to 60% during periods of peak blob demand.
When a smartphone app needs new features, updates are distributed through the app store, and users install the latest version with a single click. But in decentralized blockchains like Ethereum, it's not that simple. Thousands of independent nodes must agree on the same rules, so even a small change requires a hard fork where all nodes must upgrade their software before a predetermined time.
The problem is that if such upgrades include many changes and require extensive testing, coordination among nodes and final network implementation takes considerable time. If Ethereum must wait for the next major fork to increase blob capacity while L2 rollups' data demand is growing rapidly, this demand cannot be met, inevitably degrading the service level of rollups.
The Blob Parameter Only (BPO) fork, introduced through EIP-7892, solves this dilemma. BPO forks are lightweight upgrades that modify only blob capacity-related settings. While traditional hard forks require extensive protocol changes and thousands of lines of code implementation, BPO forks allow blob capacity adjustments through client configuration changes alone.
The BPO schedule planned after Fusaka is as follows:
First BPO: December 9, 2025, blob target per block from 6 → 10, maximum from 9 → 15
Second BPO: January 7, 2026, blob target per block from 10 → 14, maximum from 15 → 21
BPO forks provide predictability for L2 projects. A structured BPO framework can give rollups the confidence to trust Ethereum's scaling plans and commit to Ethereum instead of external data availability solutions.
The core of Ethereum's blob market is that blob fees automatically adjust based on supply and demand. When blocks are filled with blobs, fees rise; when usage is low, they fall. Like regular gas fees, it is designed to efficiently regulate blob usage through market mechanisms.
However, in actual operation, the blob fee market behaved differently than expected. Theoretically, when blob prices rise, rollups should reduce usage, which would then bring prices back down in a feedback loop. But in reality, even when blob prices rose significantly, rollups did not noticeably reduce their usage.
The reason was that when blob prices fell below a certain level, the execution costs of blob transactions became much larger than the blob fees themselves. For example, Ethereum's base transaction cost remains at a few cents even when demand is low, while the base cost of blobs could be nearly zero. In this situation, even if blob usage reached saturation for over an hour, the perceived increase in total cost was not significant.
EIP-7918 is a proposal to address this issue by modifying the calculation formula so that blob fees cannot fall below 1/16 of Ethereum's base transaction fee, effectively creating a reserve price.
Source: Ranker
A road with more lanes isn't always better. If large trucks or long cargo vehicles are allowed to use multiple lanes, a road with more lanes might actually become more congested. Factors determining a road's throughput include not just the number of lanes but also vehicle size restrictions and entry rules.
Ethereum's gas limit works the same way. The gas limit determines how much computation can be processed per block. A higher gas limit means more transactions, but it also increases risks that could threaten network security and stability.
Fusaka introduces three changes together to balance this:
Increased Throughput: EIP-7935 raises Ethereum's default gas limit to 60M. This is a continuation of the gradual increase from 30M since The Merge in 2022. The development team verified the safety of 60M through stress tests that filled blocks with synthetic transactions.
Single Transaction Limit: EIP-7825 sets a cap on gas usage per transaction at approximately 16.78 million gas. Previously, a single transaction could consume the entire block's gas, which increased the risk of network attacks and interfered with the processing of other transactions. The new cap is sufficient for most normal transactions while preventing any single transaction from monopolizing a block.
Block Size Limit: EIP-7934 sets a 10MiB cap on the physical size of blocks. Gas measures computational load but does not directly limit data size. Blocks that are too large are difficult to propagate through the network and can cause issues where some nodes see them while others miss them. This limit ensures all nodes can consistently process blocks.
The combination of these three changes allows Ethereum to increase throughput while maintaining network stability. The 60M gas limit enables more transactions and complex smart contract executions on L1, while the transaction and block limits ensure the network operates normally even in malicious use cases or extreme situations.
In the long term, these changes lay the groundwork for Ethereum's transition to parallel execution. The per-transaction gas cap will become even more important in parallel execution environments where multiple transactions are processed simultaneously.
Modern smartphones have built-in security chips such as Apple's Secure Enclave and Android's Keystore. These chips are used for security features like Face ID, fingerprint recognition, and Passkeys, and they use the industry-standard secp256r1 cryptographic curve.
However, Ethereum signs using the secp256k1 curve, which is incompatible with these chips. The background is that in the early days of Bitcoin, Satoshi Nakamoto chose secp256k1, which was barely used at the time, due to concerns that curves standardized by NIST might contain NSA backdoors. Ethereum followed suit.
Currently, some solutions like Trust Wallet's Barz and Safe's passkey module use passkeys or Face ID. These are smart contract wallets utilizing Account Abstraction, implementing secp256r1 signature verification logic within the contract. However, performing this verification on Ethereum L1 consumes 200,000 to 330,000 gas, which is more than 10 times the base cost of a regular transaction (21,000 gas). Some L2s have introduced the RIP-7212 precompile to reduce this cost to 3,450 gas, but Ethereum L1 lacked such optimization.
EIP-7951 introduces a precompile for secp256r1 verification on Ethereum L1. Precompiles are features that embed frequently used operations into the network to execute them much more cheaply. This precompile reduces the verification cost on L1 to 6,900 gas, representing approximately a 50-fold cost reduction. As a result, after the Fusaka upgrade, passkey-based wallets are expected to become an economically practical option on L1 as well.
Source: Tenor
When you send a transaction on Ethereum, you must wait approximately 12 seconds (slot time) for the transaction to be included in a block and finalized. From a user experience perspective, this 12 seconds feels very long.
What if a validator could promise in advance, "I will definitely include your transaction in the next block"? Users could experience their transaction as "instantly confirmed" in their wallet or app even before the block is actually created. This is the concept of "preconfirmation."
For preconfirmation to work, one prerequisite is necessary: knowing in advance who will be the next block's proposer. The problem is that before Fusaka, the beacon chain's proposer schedule was not fully deterministic.
Block proposers are determined based on two factors: a seed value called RANDAO and validators' staking balances. However, staking balances can change frequently due to rewards, penalties, and additional deposits, making the proposer schedule difficult to predict completely. In particular, with the Pectra upgrade increasing the maximum staking limit per validator from 32 ETH to 2,048 ETH, the range of balance fluctuations grew, making predictions even harder.
EIP-7917 requires calculating the list of block proposers for the next several epochs at the start of each epoch and storing it on the beacon chain. This makes it impossible for changes in validators' staking balances to alter the next epoch's proposer schedule.
More importantly, this EIP makes the next epoch's proposer schedule accessible at the application layer through the beacon root and simple Merkle proofs. This will greatly simplify the implementation of on-chain preconfirmation protocols, and Based Rollups like Taiko, where preconfirmation is a core function, are expected to be direct beneficiaries.
3.4.1 MODEXP Optimization and Security Enhancement
Ethereum has a precompile (built-in function) called MODEXP. MODEXP is a function that calculates the modular value (remainder when divided by an integer) of an exponentiation result, primarily used for large-scale mathematical operations in RSA signature verification or proof systems. The problem was that MODEXP allowed unlimited input argument lengths, which could cause bugs if abnormally large argument values were entered. EIP-7823 is a proposal to address this by setting an upper limit of 1,024 bytes for MODEXP precompile inputs. Additionally, to address the issue of gas fees being set excessively low in certain cases, minimum fees were raised and gas fees for edge cases were adjusted upward.
3.4.2 History Expiration and Network Optimization
Since 2015, all transaction records have accumulated on Ethereum, and operating a single node now requires over 1TB of storage space. New nodes joining the network must download all this data, which can present a time and hardware burden for general home node operators rather than professional node operators with sufficient performance capabilities.
EIP-7642(eth/69) supports "partial history expiration", allowing nodes to delete old block data from before The Merge in September 2022. This saves 300-500GB of storage per node, enabling comfortable Ethereum node operation with approximately 2TB of storage. Access to historical data will be supported through torrents and archive nodes from institutional providers.
Additionally, eth/69 significantly improves synchronization efficiency by removing Bloom filters from receipts. Previously, no client actually stored Bloom filters, yet the network protocol specification required them to be transmitted. This resulted in approximately 530GB (about 95GB when compressed) of unnecessary data being transferred every time a new node synchronized. By completely removing this field from the protocol, eth/69 reduces both CPU load on serving nodes and network bandwidth simultaneously.
Finally, the new BlockRangeUpdate message enables real-time sharing of block availability status between peers. Each node notifies surrounding peers when its available block range changes, with transmissions limited to at most once per 32 blocks (1 epoch) to reduce traffic. This allows clients seeking synchronization to identify in advance which peers have the blocks they need, enabling efficient data retrieval without unnecessary request attempts.
In the blockchain industry, the term "Ethereum killer" often appears. It's the narrative that faster, cheaper, and newer chains will replace Ethereum. However, Ethereum has witnessed the rise and fall of multiple killers while remaining the smart contract platform with the most developers, the most TVL, and the most real-world use cases.
The secret is perhaps in its gradual yet meaningful evolution. Ethereum doesn't try to change everything at once. The process of changing the consensus mechanism with The Merge, introducing blobs with Dencun, adding account abstraction with Pectra, and expanding data availability with Fusaka may seem slow, but each has left a clear impact on the ecosystem.
In a decentralized network like Ethereum where thousands of nodes must synchronize, coordinating 12 updates and applying them to mainnet within seven months is by no means easy. This slow and deliberate process may sometimes seem frustrating, but it is precisely this process that makes Ethereum what it is.
Dive into 'Narratives' that will be important in the next year
Ethereum
Gradient
