Wat veroorzaakte het falen van Ethereum's Fusaka-upgrade? Prysm post-mortem onthult de oorzaak

Prysm-ontwikkelaars hebben een post-mortemanalyse vrijgegeven waarin het Fusaka mainnet-incident van 4 december wordt uitgelegd dat de stabiliteit van het Ethereum-netwerk bedreigde.

De consensusclient leed aan uitputting van middelen door dure herberekening van de staat bij het verwerken van specifieke attestaties, waardoor validators ernstige operationele problemen ondervonden.

De bug kwam aan het licht onmiddellijk nadat Fusaka werd geactiveerd bij epoch 411392 op 4 december 2025, om 21:49 UTC.

Het netwerk miste 41 epochs terwijl de validatorparticipatie kelderde naar 75%, wat resulteerde in ongeveer 382 Ethereum (ETH) aan verloren bewijsbeloningen. Prysm-ontwikkelaars implementeerden noodruntime-flags voordat ze permanente fixes doorvoerden in versies v7.0.1 en v7.1.0.

Uitputting van middelen dreef netwerk richting finaliteitsverlies

De technische storing draaide om verouderde historische staten die denial-of-service-omstandigheden creëerden op getroffen nodes.

Prysm-kernontwikkelaar Terence Tsao legde uit dat "historische staat rekengeheugen-intensief is, een node kan worden overbelast door een groot aantal staatsherhalingen die parallel plaatsvinden."

Validators die Prysm draaiden, wat ongeveer 15% tot 22,71% van de netwerkvalidators vertegenwoordigde, werden geconfronteerd met verlammende prestatiedegradatie. De daling van de participatie van normale niveaus boven 95% naar 75% bracht Ethereum gevaarlijk dicht bij het verliezen van finaliteit.

Als de bug een andere consensusclient zoals Lighthouse in plaats van Prysm had getroffen, had het netwerk mogelijk volledig finaliteit verloren.

Een dergelijke gebeurtenis zou potentieel Layer 2 rollup-operaties kunnen bevriezen en validatoropnames blokkeren totdat ontwikkelaars het probleem hadden opgelost.

De Fusaka-upgrade zelf introduceerde PeerDAS (Peer Data Availability Sampling) technologie, ontworpen om de blobcapaciteit achtvoudig te vergroten voor Layer 2-schaling.

De upgrade werd succesvol uitgevoerd zonder downtime voordat de Prysm-bug aan het licht kwam.

Tien consensusclients voorkwamen instorting van Ethereum-netwerk

Ethereum's clientdiversiteitsarchitectuur voorkwam catastrofaal falen. Terwijl Prysm-validators worstelden, bleven tien andere consensusclients, waaronder Lighthouse, Nimbus en Teku, blokken valideren zonder onderbreking.

De gedecentraliseerde clientstructuur betekende dat ongeveer 75% tot 85% van de validators normale operaties behield gedurende de crisis. Dit voorkwam finaliteitsverlies en hield het netwerk transacties verwerken ondanks Prysm's gedegradeerde staat.

De Ethereum Foundation gaf snel noodrichtlijnen uit voor Prysm-operators. Validators pasten de tijdelijke fix toe terwijl Prysm-ontwikkelaars permanente oplossingen bouwden.

Op 5 december herstelde de netwerkparticipatie tot bijna 99%, waarmee normale operaties binnen 24 uur na het incident werden hersteld.