8 posts tagged with "clients"

Grandine and Lodestar did not validate a Gloas payload in zero milliseconds. The telemetry just made it look that way.

Plataberget's Gloas fork looked like an epoch boundary until the head metrics stopped moving. Lodestar and Nimbus reported a post-fork head in 21 seconds median. Prysm and Teku did not get there for roughly 93 minutes.

The fork was not just a version switch. It walked 16,306 pending deposits to build Gloas's new payload-builder registry, and the way clients handled that queue decided who crossed quickly.

engine_newPayload just gained another three and a half months of history. That is useful, but the new line has a seam in it: on March 27, the regular-node sample jumps from six observers and two execution clients to as many as fifteen observers and four clients.

If you plot "fastest client" straight through that seam, Nethermind appears to improve from 47.5% of observed slots to 94.9% in two days. It did not suddenly get twice as fast. Nine more runners walked onto the track.

I expected finalized_checkpoint to be boring.

It has four useful fields: block, state, epoch, and execution_optimistic. The obvious read is that block is the finalized checkpoint block root and state is the finalized checkpoint state root.

For six clients, that is exactly what shows up.

For Lodestar and Grandine, it is not.

Correction — 17 July 2026: UNSUPPORTED was a derived RPC-snooper label for a null or non-array V2 result, not proof that an execution client lacked the method. The client/version support interpretation below is wrong. The complete successful-return counts still hold because V2 is all-or-nothing. The correction matches the same requests across the consensus and snooper captures.

The blob data is there.

The Engine API path to fetch it is not equally there.

Ethereum has five execution clients and six consensus clients. Everyone has opinions about which is fastest — but almost nobody talks about what they do to your disk.

The short answer: your choice of client stack determines whether your SSD lasts four years or forty.

Every 6.4 minutes, Ethereum's consensus clients have a problem. At the boundary between epochs, they need to do expensive work — update validator balances, compute committee assignments, tick the justification/finalization machinery. While they're doing it, the network doesn't stop. Blocks keep arriving. Attesters keep committing to what they see.

What happens to validators whose client is still mid-computation when the attestation window opens? They vote for the wrong head.

Ethereum had 660 chain reorganizations in the last 30 days. That's a 0.31% reorg rate across roughly 216,000 slots — normal background noise for a live PoS network.

But here's something nobody talks about: if you ask Lighthouse how deep those reorgs were, you'll get a completely different answer than if you ask Prysm. Same event. Same block hashes. Different depth. Every single time.