3 posts tagged with "execution-clients"

An exact hash lookup has one embarrassingly simple invariant: if it returns a block, the hash field should be the hash you asked for. On Platåberget this week, Erigon broke that invariant in all 124 non-null replies; the other two calls returned null.

The other clients did not converge on one answer either. Besu, Nethermind, and ethrex could still return most or all of the orphaned blocks. Geth and Reth returned null. Ethrex returned the right block, then gave me the canonical sibling's transaction count when I asked about the same hash.

Every 12 seconds, your execution client gets a new block and has to tell the consensus layer: valid or not. The call is engine_newPayload, and how long it takes determines how fast your validator can attest to the new head.

That window matters. A faster EL client means earlier head votes, better attestation accuracy, and more flexibility in how you run your validator. The timing game, MEV extraction, and late block handling all happen inside this gap.

So which execution client is fastest? The data is messier than the win-rate leaderboards suggest.

Correction — 17 July 2026: I misread Xatu's derived UNSUPPORTED collector label as a response from the execution client. The snooper applies that label to a null or non-array result, while V2 permits null for missing or pruned blobs, syncing, and other inability to serve the complete request. The client-support, version-upgrade and performance conclusions below are not supported by these rows. I also attributed V2 to Pectra; it is specified in the Osaka execution fork paired with Fulu. The full correction reproduces the same calls across both capture paths.

One month after Pectra went live, roughly 44% of all Nethermind validator nodes are rejecting a blob retrieval call that was introduced in that very fork. Every other major execution client has mostly fixed this. Nethermind hasn't moved.

This is the data on what's happening, why it matters, and where the fault line sits.