After three successful trials on the Holesky, Sepolia, and Hoodi testnets, Ethereum's Fusaka hard fork is scheduled to go live on mainnet on December 3.
This upgrade is highly anticipated, even more so than the previous Pectra hard fork. Fusaka is expected to significantly enhance Ethereum's capabilities, enabling rollups to scale to 1,000 transactions per second (TPS) within a month and potentially reaching 100,000 TPS over time.
The Fusaka upgrade is comprised of two distinct hard forks: the Fulu upgrade for the consensus layer, which governs how validators agree on network activity, and the Osaka upgrade for the execution layer, responsible for processing transactions.
Looking ahead, the consensus layer will be rebuilt as Lean Consensus, formerly known as Beam Chain, which has been renamed due to a trademark dispute. This rebuild aims to enhance security and decentralization with finality achieved in seconds.
As part of the Lean Ethereum roadmap, validators on the execution layer will shift from reexecuting transactions to verifying small zero-knowledge proofs. This transition is designed to allow the L1 to scale to 10,000 TPS.
While this represents a long-term vision expected within five years, the immediate improvements brought by Fusaka in just over two weeks are substantial.
Understanding PeerDAS
Peer data availability sampling (PeerDAS) is an innovative method designed to significantly increase the amount of data Ethereum can handle, thereby facilitating the scaling of L2s and rollups.
The integrity of blockchains relies on every computer in the network performing the same computations and agreeing on the results, which are then immutably recorded. This redundancy, while ensuring truthfulness, is inherently inefficient and limits blockchain speed to the capabilities of the slowest network participants.
Ethereum's commitment to decentralization, which maintains consumer-grade technical specifications for validators and nodes, exacerbates this issue. Although current recommendations are more demanding than early iterations, they remain accessible to a broad global audience.
PeerDAS can be conceptualized as a blockchain equivalent of torrenting. Instead of requiring every network participant to download and upload the entire data file, PeerDAS allows them to process only a small segment. The complete data, referred to as a blob, can be reconstructed later by assembling these individual components, leading to a considerable increase in throughput.
Ethereum Blobs Explained
Layer 2 (L2) solutions process transactions off the main Ethereum chain to alleviate congestion. They then post transaction data back to Ethereum to ensure transparency and enable state resurrection if necessary. As transaction volume increases, L2s must post more data to Ethereum.
Blobs were introduced in the March 2024 Dencun upgrade to store 128 kilobytes of data each. Initially, the system targeted three blobs per block, with a potential to expand to six at higher fees during peak demand. The Pectra upgrade subsequently doubled this target to six blobs, with a maximum of nine.
The available space for these blobs is nearing capacity. Furthermore, the network is facing limitations because every node and validator must download every blob, which is particularly challenging for solo stakers running nodes on personal computers.
Lucas Saldanha, a blockchain protocol engineer with the Teku client, highlights that a fundamental principle of Ethereum's decentralization is its accessibility for anyone to run. However, he notes that increasing storage and network requirements could eventually make it difficult for average users to keep up.
PeerDAS addresses this by dividing blobs into 128 separate columns. This allows validators and nodes to download only a subset of these columns, effectively increasing the data capacity of Ethereum by a factor of eight. This enhancement enables L2s to process eight times more transactions, as they now have a cost-effective means to post the associated data.
Saldanha explains that PeerDAS allows nodes to avoid downloading all blobs, even as the number of blobs increases. This approach ensures data availability and integrity without burdening individual nodes with the entire dataset.
The Evolution of Ethereum Blobs
Historically, all data was stored indefinitely. However, to manage escalating storage demands from L2 scaling, blob data is now retained for only 18 days. With six blobs, validators currently need to store 90GB of data over this period, with minimum specifications recommending a 4TB SSD.
PeerDAS employs erasure encoding, specifically Reed-Solomon encoding, a technique originally developed to ensure data readability on damaged CDs. This method doubles the data size before splitting it into 128 parts.
This redundancy allows the blob to be reconstructed if at least 64 of the parts can be recovered. Saldanha elaborates that the system randomly samples nodes holding specific columns, providing a statistical guarantee of data availability.
The system's design principle is to enable data reconstruction from a partial download of columns, ensuring availability without requiring every node to download the complete dataset.
Blob Parameter Only (BPO) Forks
Ethereum developers are proceeding cautiously with increasing blob capacity. The Fusaka hard fork introduces Blob Parameter Only (BPO) hard forks via EIP-7892, which allow for adjustments to the number of blobs as needed.
The first BPO hard fork is scheduled for December 9, one week after Fusaka, and will increase the blob target by 67% to 10 blobs, with a maximum of 15.
A subsequent BPO fork is planned for January 7, aiming for a blob target of 14 (maximum 21). This represents a 133% increase in data availability and is projected to enable standard L2s to process approximately 800-1,000 TPS. The Lighter appchain is noted as an exception that already achieves significantly higher speeds.
Saldanha anticipates no issues with the initial two BPO forks, deeming the numbers conservative compared to the network's capabilities. Both the Sepolia and Hoodi testnets successfully upgraded to BP02 without reported problems.
The question of whether blobs will reach the anticipated 48-blobs-per-block in 2026, representing an 8x increase, remains open. Saldanha indicates that exceeding 48 blobs has been achieved in controlled devnet environments. However, real-world implementation faces bottlenecks related to block proposing and the mempool, which are complex technical considerations.
Several Ethereum Improvement Proposals (EIPs) are designed to address these challenges. The upcoming 2026 Glamsterdam forks, including the Enshrined Proposer Builder Separation upgrade, are expected to improve block propagation times and facilitate further blob increases.
During a recent all-core-devs call, a new optimization was discussed that could potentially enable 72 blobs per block. A speculative timeline was also presented, suggesting a series of BPO forks every two weeks after late February to reach this target.
Over time, the expectation is for blobs to reach 128+ blobs per block.
Optimizing the Blob Fee Market
Fusaka will also address inefficiencies in the supply and demand dynamics of blob fee pricing.
Ideally, when blob fees are high, L2s should reduce blob submissions, and when fees are low, they should increase submissions. However, the current blob fees are so minimal compared to the gas costs required for posting data on Ethereum that this incentive mechanism is largely ineffective.
Gabriel Trintinalia, a senior blockchain engineer at Consensys working on the execution client Besu, explains that when activity declines, the goal is to stimulate its recovery, a process that currently takes time.
To rectify this, EIP-7918 establishes a minimum blob fee, ensuring it is never less than 1/16th of the Ethereum gas price. This adjustment aims to make fees more responsive to real-time network conditions and accelerate price discovery for blobs.
Trintinalia clarifies that this change prevents blob base fees from falling so low that they become disconnected from execution costs.
Fusaka's Impact on Ethereum L1 Scaling
The Lean Ethereum plan to scale the L1 using ZK-proofs is still in its nascent stages, with significant developments anticipated around the Hegota (Heka-Bogota) hard fork in the latter half of 2026.
However, Fusaka will increase the gas limit—the amount of computation the network can handle—from 45 million to 60 million (EIP-7935), resulting in a 33% increase in network capacity. Trintinalia notes that this will allow for more transactions to be included in each block.
Based on current TPS figures, this change is expected to maintain Ethereum's performance around 30 TPS from December onwards.
At the recent Bankless summit, Tomasz Stanczak, co-executive director of the Ethereum Foundation, projected that the gas limit could rise to 100 million in the first half of 2026 and potentially double or triple thereafter to 200-300 million gas per block. Such an increase would represent a tenfold rise from the 30 million gas limit Ethereum began 2025 with.
Enhancing Perceived Speed with Preconfirmations
EIP-7917 introduces a mechanism for communicating the proposer of the next Ethereum block. This enhancement is designed to improve the functionality of preconfirmations, where a proposer commits to including a transaction in the subsequent block.
From a user's perspective, this allows transactions to be instantly confirmed by wallets or applications within milliseconds, bypassing Ethereum's standard 12-second block time. Rollups that rely on such immediate confirmations, like Taiko, will benefit from this feature.
Passkey Support for Phone-Based Wallets
Fusaka incorporates a new precompile for the secp256r1 elliptical curve cryptography. This curve is utilized by the secure enclave on Apple phones and the Android keystore (EIP-7951).
While account abstraction previously enabled similar functionality, it was prohibitively expensive due to Ethereum's use of the secp256k1 elliptical curve, leading to excessive gas consumption.
By moving this operation to a precompile—an in-client implementation—users can perform the necessary calculations without incurring high EVM gas fees. This development allows Ethereum users to utilize passkeys and phone biometrics for wallet management, replacing the need for traditional seed phrases.
Improving Predictability for Scalability
Fusaka includes several EIPs aimed at standardizing and improving the predictability of network operations, which is crucial for managing increasing protocol scale.
As the L1 scales and generates more transactions, block sizes will naturally increase. To prevent occasional anomalies or deliberate attacks from destabilizing the network, the maximum block size will be capped at 10 megabytes (EIP-7934).
This limit is based on a protocol bandwidth constraint that prevents the propagation of messages exceeding 10 megabytes. Without this cap, a crafted transaction, even if not consuming the entire block's gas, could result in a block that exceeds the 10-megabyte limit and is therefore not propagated across the network.
The maximum gas used by a single transaction will also be capped at 16.7 million, preventing any one transaction from filling an entire block. This measure enhances network stability and mitigates distributed denial-of-service attacks. It also prepares the network for parallel block processing, expected in the Glamsterdam upgrade, and aids in zkEVM proof generation.
Pricing for using the ModEXP precompile will be adjusted to reflect actual computational costs, and input limits will be imposed to prevent bugs and edge-case attacks (EIP-7823 and EIP-7883, respectively).
Trintinalia explains that these changes are intended to make the ModEXP precompile more predictable, noting that excessively long inputs had previously led to numerous consensus bugs.
Additionally, a new opcode (EIP-7939) will automate the counting of leading zeros in data. While seemingly minor, this replaces the current gas-intensive code used for this operation. Trintinalia points out that this can shorten bytecode for ZK-proofs and compilers, potentially reducing ZK-proof generation costs significantly.
EIP-7642 addresses issues arising from the purging of pre-Merge network history by some nodes in May, which had caused node syncing failures.
The Road Ahead: Glamsterdam, Hegota, and Beyond
The Ethereum community is actively debating the inclusion of various features in the upcoming Glamsterdam fork. A key discussion point is whether to incorporate the anti-censorship measure FOCIL (Fork-Choice enforced Inclusion Lists) or if it would unduly complicate operations. FOCIL is currently under consideration but facing pushback.
Block-level access lists and enshrined proposer builder separation are confirmed for Glamsterdam. A more detailed explanation of these features will be provided in an upcoming Ethereum in 2026 special edition.