OAK — OnChain Attack Knowledge

Worked example · 2023-05

Ethereum Beacon Chain finality loss event — Ethereum — 2023-05-11 to 2023-05-12

Loss
no direct financial extraction. The Beacon Chain lost finality twice: on 2023-05-11 (about 25 minutes) and on 2023-05-12 (about 64 minutes), per the Thiery analysis [thierycascade]. During each window the chain kept proposing blocks but could not finalise epochs. No double-spend or validator-slashing event is recorded in the cited sources; the primary impact was operational: reduced participation and attestation rewards, and a demonstration that a consensus-client resource-exhaustion problem — not a slashing condition or an adversarial attack — could stall finality on live Ethereum mainnet.
Corrected 2026-10-11
dates, durations and epoch ranges now follow the cited sources (first incident 2023-05-11 about 25 min, second 2023-05-12 about 64 min, not 25 + 8 min); the root cause is Prysm/Teku mishandling "valid-but-old" attestations under CPU/cache load, not rejection of Lighthouse attestations.
OAK Techniques observed
OAK-T14.003 (Restaking / Shared-Security Cascading Risk — broadly construed as consensus-layer liveness-failure surface; the event was produced by Prysm and Teku clients being overloaded while processing valid-but-old attestations, which pushed attestation participation below the two-thirds finality threshold). The event was not a restaking incident in the narrow sense (no AVS, no restaked ETH was involved), but it exercises the same consensus-layer liveness-failure sub-surface that T14.003 captures: client load-handling problems in widely used clients were sufficient to cause a chain-wide liveness failure even though no individual validator double-signed, no slashing condition was triggered, and no adversarial manipulation of the consensus protocol occurred. The incident is the T14.003 anchor for the consensus-client-bug-induced liveness failure sub-pattern: finality stalls produced by resource exhaustion in widely used consensus clients, distinct from the T14.001 slashing-condition surface and the T14.002 MEV-Boost relay-attack surface.
Attribution
unattributed The finality loss was caused by client load handling in Prysm and Teku, not by an attacker. The Ethereum Foundation described it as high load on some consensus-layer clients caused by an exceptional scenario [cointelegraphfinality]. No adversarial attribution applies; the incident is a protocol-layer operational event.
Key teaching point
A consensus-client resource-exhaustion problem in widely used clients is a chain-liveness threat surface that is structurally distinct from the slashing-condition surface (T14.001) and the MEV-Boost relay-attack surface (T14.002). The consensus protocol functioned correctly given the inputs it received, but clients overloaded by valid-but-old attestations could not keep participation above the finality threshold. PoS finality depends on client implementations staying healthy under load, not just on honest-majority assumptions or slashing enforcement.

Summary

The Ethereum Beacon Chain lost finality twice in May 2023. According to the Thiery analysis, the first incident covered epochs 200552–200555 on 2023-05-11 (20:13–20:38 UTC, about 25 minutes, lowest participation 40.9%), and the second covered epochs 200750–200759 on 2023-05-12 (17:20–18:24 UTC, about 64 minutes, lowest participation 30.7%) [thierycascade]. Epoch ranges include a one-epoch buffer each side. In both cases blocks kept being proposed but participation fell below the 66% needed to finalise.

The root cause, per the same analysis, was how some consensus clients — Prysm and Teku — handled "valid-but-old" attestations: they had to recompute beacon states to verify them, which depleted CPU and cache resources. The author also notes that state growth and deposit processing may have reached a tipping point that triggered cascading effects across nodes [thierycascade]. The Ethereum Foundation said the issue appeared to be caused by high load on some consensus-layer clients, and that users could keep transacting because not all client implementations were affected [cointelegraphfinality].

Core developers released patches for Prysm and Teku and finality resumed [cointelegraphfinality]. Because the attestations were valid under the specification, the event is a client-implementation resource-exhaustion failure rather than a protocol or slashing failure; client diversity limited the damage, since clients not affected kept the chain live.

Timeline

When Event OAK ref
2023-05-11 20:13–20:38 UTC First finality loss (about 25 minutes); participation low of 40.9% [thierycascade] T14.003 liveness failure
2023-05-12 17:20–18:24 UTC Second finality loss (about 64 minutes); participation low of 30.7% [thierycascade] (repeat occurrence)
2023-05-12–13 Patches for Prysm and Teku released [cointelegraphfinality] (incident response)
2023-05 to 2023-06 Community discussion of client diversity and client resource handling (community hardening)

What defenders observed

  • Finality-stall was visible at the protocol level in real time. The Beacon Chain's finality-checkpoint progression — which is a publicly observable metric — flatlined. Any observer running a Beacon Chain node (or using a block explorer that surfaces finality-checkpoint data) could observe the stall. The defender-observable signal is that a flatlining finality checkpoint while blocks continue to be proposed is a consensus-layer liveness-failure indicator, not a network-partition indicator (which would also stop block production).
  • Client-diversity was the mitigation that was present but insufficient. Ethereum had several interoperating consensus clients, and not all were affected [cointelegraphfinality], so the chain kept producing blocks. But diversity alone did not prevent the liveness failure because the affected clients (Prysm and Teku) carried enough validator weight to push participation below the finality threshold. The defender lesson is that client-diversity for safety (no chain split) and client-diversity for liveness (no single client or client family can block finality) are different targets, and the latter requires that no single client's failure can pull participation below the finality threshold, not merely that multiple clients exist.
  • No slashing condition triggered — the consensus protocol functioned correctly. The affected validators were not reported as slashed; the problem was resource exhaustion in processing valid-but-old attestations [thierycascade]. This distinguishes the event from T14.001 (slashing-condition exploit, where a validator enters a slashable state) and from T14.002 (MEV-Boost relay attack, where the relay withholds or manipulates blocks). The T14.003 surface — consensus-client implementation divergence causing liveness failure — is a third, structurally distinct risk category.
  • Recovery required client patches, not protocol intervention. Prysm and Teku released updates [cointelegraphfinality]; no hard fork or state rollback is reported in the cited sources. This is a positive operational property of the Gasper finality protocol: temporary liveness failures self-resolve once the condition causing the participation deficit is removed, without requiring an out-of-band recovery procedure.

What this example tells contributors writing future Technique pages

  • T14.003 (Restaking / Shared-Security Cascading Risk) captures a consensus-layer liveness-failure surface that is broader than the literal "restaking AVS slashing" case. The May 2023 finality loss is not a restaking incident — no AVS, no EigenLayer, no restaked ETH — but it exercises the same underlying consensus-layer property that the T14.003 sub-surface is about: a failure mode that propagates through the consensus protocol's participation and finality mechanics without requiring a slashing condition to trigger. Future T14.003 page expansions should include both the restaking-specific cascading-risk cases (AVS slashing propagation through restaked ETH) and the consensus-client-bug-induced liveness-failure cases (like this one), because both exercise the same structural property of the consensus protocol.
  • Client-diversity as a mitigation has a liveness dimension and a safety dimension. The conventional framing of Ethereum client diversity is safety-focused: if one client has a bug that produces an invalid block, validators running other clients will reject it, preventing a chain split. The May 2023 event demonstrated the liveness dimension: if enough validators run clients that share a load-handling weakness, those clients can collectively fall behind on valid messages, causing a finality stall even though no invalid block was produced and no slashing condition triggered. Both dimensions should be surfaced in the T14 mitigation taxonomy.

Public references

Techniques demonstrated (1)