What Caused the Issues with Ethereum’s Fusaka Upgrade? Insights from Prysm's Post-Mortem

On December 4, Prysm developers released a detailed post-mortem analysis addressing the Fusaka mainnet incident that posed a risk to the stability of the Ethereum network. They identified that the consensus client encountered resource exhaustion due to resource-intensive state recomputation while processing certain attestations, which led to significant operational difficulties for validators.

Key Takeaways

The Prysm consensus client experienced resource exhaustion during the Fusaka upgrade, leading to operational issues for validators.
Validator participation fell from over 95% to 75%, risking the Ethereum network's finality.
The upgrade introduced PeerDAS technology to enhance Layer 2 scaling by significantly increasing blob capacity.
Ethereum’s diverse client architecture helped prevent a complete network failure, enabling consistent validation despite the issues with Prysm.
By December 5, validator participation nearly returned to 99%, allowing normal operations to resume within a day.

What broke Ethereum’s Fusaka upgrade? Prysm post-mortem reveals the cause

The issue was first detected shortly after the Fusaka upgrade was activated at epoch 411392 on December 4, 2025, at 21:49 UTC. Because of this bug, the network lost 41 epochs as validator participation dropped to 75%, resulting in an estimated loss of about 382 Ethereum in proof rewards. To address the problem, Prysm developers implemented emergency runtime flags before rolling out permanent fixes in versions v7.0.1 and v7.1.0.

Understanding the Resource Exhaustion Issue

The technical glitch focused on outdated historical states, which created denial-of-service conditions affecting certain nodes. According to Prysm core developer Terence Tsao, “historical state consumes significant compute memory, leading nodes to be overloaded by numerous state replays occurring simultaneously.”

Validators using the Prysm client, which made up approximately 15% to 22.71% of network validators, experienced severe performance degradation. The drop in participation from the usual levels exceeding 95% down to only 75% put Ethereum perilously close to losing its finality. If the bug had impacted another consensus client, like Lighthouse instead of Prysm, the network risked a total loss of finality. This scenario could have halted Layer 2 rollup operations and blocked validator withdrawals until the issue was resolved.

Fortunately, the Fusaka upgrade had successfully introduced PeerDAS (Peer Data Availability Sampling) technology aimed at increasing the blob capacity for Layer 2 scaling by eight times, and it executed without any downtime before the Prysm-related bug emerged.

How Client Diversity Saved the Ethereum Network

The diverse architecture of Ethereum's clients played a crucial role in averting a catastrophic failure. While validators using Prysm faced problems, other clients—including Lighthouse, Nimbus, and Teku—progressed with block validation uninterrupted. This decentralized structure meant that approximately 75% to 85% of validators operated normally during the crisis, preventing loss of finality and allowing ongoing transaction processing even while Prysm was experiencing difficulties.

In response to the situation, the Ethereum Foundation quickly provided emergency guidance for Prysm operators. Validators implemented a temporary fix while developers worked on long-term solutions. By December 5, validator participation rebounded to nearly 99%, and regular operations resumed within just 24 hours of the incident.