After three successful trials on the Holesky, Sepolia and Hoodi testnet, Ethereum’s Fusaka hardfork will go live on mainnet on December 3.
It’s the most eagerly anticipated upgrade to Ethereum since the last one, Pectra — although Fusaka will have a much more significant impact, enabling rollups to scale in the space of a month up to 1,000 transactions per second (TPS) and to 100,000 TPS over time.
It’s actually two separate hard forks: the Fulu upgrade to the consensus layer (the part of a blockchain where validators in the network agree on what happened) and the Osaka upgrade to the execution layer (the part that actually processes transactions).
In the future, the consensus layer will be rebuilt as Lean Consensus (formerly known as Beam Chain but renamed after a trademark dispute) and hardened for security and decentralization with finality in seconds.
As part of the Lean Ethereum roadmap, validators on the execution layer will switch from reexecuting transactions to simply verifying tiny zero-knowledge proofs, enabling the L1 to scale to 10,000 TPS.
But that’s the long-term vision, expected to be completed within five years. Let’s take a look in detail at what improvements will occur in a little over two weeks’ time with Fusaka.
Sure, but what is PeerDAS?
Peer data availability sampling (PeerDAS) is a clever method to enable Ethereum to handle a lot more data, which enables L2s and rollups to scale up throughput.
The reason blockchains are a source of truth is because every computer in the network repeats the work of all the other computers in the network and agrees on the result, which is then recorded immutably.
This is, of course, horribly inefficient and means the blockchain’s speed is limited by the slowest computers, with the worst download speeds, on the network.
Ethereum makes this issue worse as its commitment to decentralization means it keeps the tech specs for validators and nodes at a consumer-grade level. (Current recommendations are closer to a gaming laptop than the Raspberry Pi of legend but are still within reach of a large number of people around the world.)
PeerDAS can be thought of as similar to torrenting for blockchains — instead of making everyone on the network download and upload the whole file, PeerDAS enables them to process just a small part. The whole thing — the blob — can be reconstructed later by assembling the components. This increases throughput considerably.
OK, but what are blobs in Ethereum?
L2s process transactions away from Ethereum to free up capacity on the L1. They then post transaction data in various forms back on Ethereum so everyone can be confident it’s legit and can resurrect the state of the L2 if needed. More transactions mean the L2s need to post more data on Ethereum.
Blobs were introduced in the March 2024 Dencun upgrade to store 128 kilobytes of data each. The system started with a three-blob target (but could stretch to six, with higher fees to discourage use during periods of heavy demand), and that doubled to six (max. nine) in the Pectra upgrade.
That space is already full, and the network is also running up against the limits of what it can handle because every node and validator has to download every blob. That’s particularly tough for solo stakers — validators running on laptops and home desktops.
Lucas Saldanha, blockchain protocol engineer with the Teku client, explains that a core concept underpinning Ethereum’s decentralization is “that anyone can run it.”
“But if we keep increasing storage and network requirements, it gets to a point where the regular person won’t be able to keep up anymore.”
PeerDAS splits the blobs into 128 separate “columns” and allows validators and nodes to download just a few of them. This increases the amount of data Ethereum can handle by a factor of eight, which enables the L2s to process eight times more transactions than they currently do, as they now have somewhere to post that transaction data at an affordable cost.
“The simplest way of thinking about PeerDAS would be making it in a way where even though we have more blobs, each server or each node doesn’t have to download all of them,” says Saldanha. “But you still have the same properties of knowing that the data is available if you need and, second, knowing that the data is the correct data.”
Ethereum blobs are not forever
Back in the old days, everyone stored every bit of data forever, but to avoid endlessly massively increasing storage requirements as the L2s scale up, blob data now only needs to be kept for 18 days. With six blobs, validators need to store 90GB of data over that period, and the minimum specs recommend a 4TB SSD.
Also read: Back to Ethereum — How Synthetix, Ronin and Celo saw the light
Cleverly, PeerDAS is designed in such a way that the whole blob can be reconstructed from just 50% of the slices. Saldanha explains this uses erasure encoding (aka Reed-Solomon encoding), which was invented to stop CDs from becoming unplayable if they get scratched.
The data is encoded in a way that doubles its size before being split up into 128 parts. This redundancy allows the blob to be restored if you can cobble together just 64 of the bits. Saldanha explains the system randomly samples who has which columns “to get a statistical guarantee that the data is available.”
“So, it sounds a little bit like magic, but that’s kind of the design principle behind it. You don’t need to download everything, and you can look at part of those columns. And if you have enough columns, you can reconstruct the whole thing if you need to.”
BPO forks only increase the number of blobs
Ethereum devs are a cautious bunch and don’t intend to crank up the blobs to 48 in one go.
Instead, Fusaka creates Blob Parameter Only (BPO) hard forks with EIP-7892, enabling blobs to be increased (or decreased) as required. The first BPO hard fork will happen one week after Fusaka, on December 9 and increase the blob target by 67% to 10 blobs with a maximum of 15.
Provided nothing breaks, the second BPO fork will be on January 7 with a blob target of 14 (max. 21). That’s a 133% increase on today’s data availability and would enable the standard L2s to process around 800-1,000 TPS. (The Lighter appchain does indeed go many times faster than this already, but it’s the exception that proves the rule.)
Saldanha doesn’t foresee any problems with the first two BPO forks.
“They are very conservative numbers compared to what we can do,” he says. The Sepolia and Hoodi testnets both upgraded to BP02 with no issues reported.
But whether blobs will hit 48-blobs-per-block in 2026 — the 8x everyone has been talking about — is an open question. Saldanha says they have managed to go beyond 48 blobs in a controlled devnet environment, but in the real world, there are some bottlenecks to do with block proposing and the mempool (highly technical but explained well here).
A bunch of EIPs aim to fix those issues, including the 2026 Glamsterdam fork’s Enshrined Proposer Builder Separation upgrade, which will provide more time for block propagation and enable further blob increases.
On the most recent all-core-devs call, a new optimization that could potentially help achieve 72 blobs per block was discussed, along with a very “speculative timeline” that included a series of BPO forks every two weeks sometime after late February to achieve a 72 blob target.
Over time, blobs are expected to hit 128+ blobs per block.
Fixing the broken blob fee market
Fusaka will also fix the broken supply-and-demand economics of blob fee pricing.
When blob fees are high, L2s should submit fewer blobs (and do), and when prices are low, they should submit more blobs (but don’t). The problem is that the blob fees are so minuscule in comparison to the required cost of gas fees to post the data on Ethereum that no one cares about this incentive.
“When activity goes down, you still want to make it go up again,” explains Gabriel Trintinalia, senior blockchain engineer with Consensys, who is working on execution client Besu. “Today it takes a while to get to that level,” he says.
To fix the problem, EIP-7918 ensures the minimum blob fee is never less than 1/16th of the Ethereum gas price, which should make fees more responsive to real-time network conditions and see blobs achieve “price discovery a lot faster than before.”
“This basically means that blob base fee cannot go so low that it is detached from execution cost,” he says.
How Fusaka scales Ethereum’s L1
The Lean Ethereum plan to scale the L1 using ZK-proofs is still in its early days, and we’re unlikely to see major developments on that front until the Hegota (Heka-Bogota) hard fork in the second half of 2026.
But Fusaka does increase the gas limit (the amount of computation the network can handle) from 45 million to 60 million (EIP-7935), increasing network capacity by 33%. “We’re going to be able to include more transactions in the block,” Trintinalia says.
Based on the current TPS, this will see Ethereum chug along around 30 TPS from December.
At this week’s Bankless summit, Ethereum Foundation co-exectutive director Tomasz Stanczak said he expects that gas limit to increase to 100 million in the first half of 2026 and to double or even triple from there to 200 million to 300 million gas per block. If that happens, that would mark a 10x increase on the 30 million gas limit Ethereum started 2025 with.
Making Ethereum feel faster than it is
EIP-7917 implements a way to communicate who the proposer of the next Ethereum block will be in order to make preconfirmations work better. Preconfirmations are when a proposer promises to include a transaction in the next block. From a user’s perspective, the transaction is instantly confirmed by wallets or apps in milliseconds rather than being constrained by Ethereum’s lengthy 12-second block time. Based rollups like Taiko will rely on this functionality.
Support for passkeys to turn phones into Ethereum wallets
Fusaka adds a new precompile (code that auto-executes operations outside of the EVM) for the “secp256r1 elliptical curve” cryptography used for the secure enclave on Apple phones and the Android keystore (EIP-7951).
Account abstraction already made this possible, but it was too expensive; it used a ridiculous amount of gas because Ethereum uses the different secp256k1 elliptical curve.
“We’re moving that to a precompile, which is an in-client implementation. So, now you could actually call this precompile to do all the calculations that you need without having to actually pay for the expensive calculation that will be done in EVM.”
So, instead of writing down seed phrases, Ethereum maxis can just use passkeys and phone biometrics and wallets.
Making a bunch of stuff more predictable to scale up
Fusaka includes a bunch of EIPs that help make everything more uniform and predictable, which will stop things from breaking as the protocol scales faster and faster.
As the L1 scales, it will generate more transactions, and block sizes will increase. To avoid having the occasional rogue block screwing up the network (whether by accident or as a deliberate attack), the maximum block size will now be limited to 10 megabytes (EIP-7934).
“There is a bandwidth constraint in the protocol that will not propagate messages that are bigger than 10 megabytes. So, in a particular attack, for example, someone could craft a transaction that would not use the whole gas of the block, but it would still be large enough that when that transaction is encoded, it would go over the 10 megabytes. And you would have a problem.”
“This transaction, while still valid, would make the block not be propagated in the network.”
The maximum amount of gas used by a transaction will also be capped at 16.7 million, preventing a single transaction from filling the entire block. This will help network stability and prevent distributed denial-of-service attacks. It will also help ready the network for parallel block processing (coming in Glamsterdam), and it aids zkEVM proof generation.
Pricing for using the ModEXP precompile will also be changed to reflect the actual computational cost, and limits will be set on inputs to the precompile to avoid bugs and edge case attacks (EIP-7823 and EIP-7883, respectively).
“That’s to make the ModeXP precompile more predictable,” says Trintinalia, noting that impractically long inputs had caused numerous consensus bugs.
There’s also a new op code (EIP-7939) to automatically count the number of leading zeros in a piece of data. Although this sounds faintly ridiculous, it replaces the current gas-heavy code that devs need to use for this.
“For ZK-proofs and for compilers, it can make the bytecode shorter because you have that in [the] structure, and ZK-proofs can be significantly cheaper because of that as well,” he says.
Another bit of maintenance is contained in EIP-7642, which fixes some of the issues created in May when some nodes purged pre-Merge network history, leading to node syncing failures.
The future: Glamsterdam, Hegota and beyond
The Ethereum community is already passionately arguing about what should and should not be included in the Glamsterdam fork and whether the anti-censorship measure FOCIL (Fork-Choice enforced Inclusion Lists) should be added to the current scope or if it’ll just make everyone’s life too difficult. (It’s looking like it’s getting pushed but is still officially under consideration.)
Currently, block-level access lists and enshrined proposer builder separation are definitely included, but a simple explanation about what they do will have to wait until Magazine’s Ethereum in 2026 special in mid-December.
Andrew Fenton
Crypto carnage — Is Bitcoin’s 4-year cycle over? Trade Secrets