January 23, 2026
Two months have passed since the Fusaka upgrade.
Let’s take a look at what changed and how the network is performing after the upgrade.
EIP-7594 – PeerDAS
A major problem in the protocol was that, to prove a blob contained a specific piece of information, a node had to download the entire blob.
With the implementation of the new networking protocol PeerDAS, nodes can now perform data availability sampling, ensuring that blob data is fully available while downloading only a subset of the data—around 1/8 of the total.
This is made possible by Reed–Solomon encoding, reducing the load on each node and making L2s cheaper.
EIP-7951 – Enable secp256r1 precompile curve support
EIP-7951 enables Ethereum to verify secp256r1 signatures on-chain.
Previously, Ethereum could not efficiently verify secp256r1 signatures, making it impractical to use keys generated by phone secure elements.
This was a mismatch: security chips implement only standard curves like secp256r1, while Ethereum historically relied on secp256k1.
With EIP-7951, this gap is removed. Secure elements (like Apple’s Secure Enclave) can now be used to sign Ethereum transactions, effectively turning phones into biometric-protected hardware wallets.
EIP-7917 – Deterministic proposer lookahead
Another major change in the protocol comes with EIP-7917.
Before, the block proposer was only known at the start of the slot (12s). Only then could validators do their job, and transaction inclusion was known only after block production.
This model caused increased confirmation latency and often failed to fully utilize block capacity.
EIP-7917 brings near-instant confirmation by allowing the chain to know, before block production starts, who the proposer will be and which transactions are going to be included, with the block being almost ready at the start of the slot.
Importantly, EIP-7917 does not introduce preconfirmations at the L1 level, but provides the necessary infrastructure for protocols that rely on them, such as rollups.
Here you can find a very good deeper explanation:
EIP-7918 – Blob base fee floor
Before Fusaka, the blob base fee was extremely cheap, often dropping to around ~1 wei.
This happened because, when blob demand was low, the pricing mechanism kept decreasing the blob base fee even though L1 execution costs remained significant. As a result, blob prices failed to reflect their real economic cost.
With EIP-7918, a higher base fee floor is introduced, anchoring blob pricing to L1 execution costs. This prevents blob fees from collapsing and makes blob prices more stable and predictable for L2s.
EIP-7892 – Blob-parameter-only hardfork
EIP-7892 introduces a way to change blob capacity through “mini” hardforks that modify only blob configuration.
Ethereum uses blobs as data availability for rollups, and rollups are posting more and more blobs, so we cannot wait for a full hardfork upgrade every time.
This “mini hardfork” can change three parameters:
- Blob target: how many blobs are expected in the next block
- Blob limit (max): the maximum number of blobs per block
- Blob base fee update fraction: determines how blob gas pricing adjusts per block
After Fusaka, two blob-parameter-only forks were scheduled:
- BPO1 (target 10, max 15 blobs) on December 9, 2025
- BPO2 (target 14, max 21 blobs) on January 7, 2026
EIP-7642 – Keep nodes light
Before EIP-7642, during the node handshake, peers did not share which part of the blockchain history they stored (for example, whether they still kept pre-merge blocks).
This became an issue after the decision that, after May 1, 2025, nodes can delete pre-merge history. If a node needed old data, it had to query multiple peers without knowing in advance whether they actually had that data.
With EIP-7642, nodes announce the block range they serve during the handshake, so a node can immediately know which peers are useful and avoid unnecessary requests.
EIP-7935 – Set gas limit to 60M
EIP-7935 sets the block gas limit to 60M, allowing each block to include more transactions.
With more transactions per block, the network can support higher activity, resulting in lower fees and faster inclusion.
The main trade-off is increased resource requirements for nodes.
Since the Merge, no Ethereum upgrade has reshaped the protocol as broadly as Fusaka.
Instead of chasing raw throughput, Fusaka focuses on sustainable scaling: higher capacity, better pricing signals, lighter nodes, and a clearer roadmap for data availability.
These changes quietly redefine what Ethereum can support in practice, especially as L2 usage continues to grow.
The next frontier is privacy. If current research paths materialize, 2026 could be an exciting year for privacy on Ethereum.