Independent Ethereum client measurements
Neutral, hardware-backed measurements of Ethereum execution and consensus clients.
Operated by RockLogic GmbH · ISO 27001 certified · Supported by an Ethereum Foundation grant
From the blog
A few hand-picked posts from our blog.
Six execution clients on identical hosts: 5 to 16 GiB RAM, half a CPU core at the tip, and disk writes from 0.9 to 22 MB/s. What each client costs to run, and why one needs a bigger box.
The same six Ethereum consensus clients on identical hardware reported between 0 and 5,791 reorgs over 90 days. Why their counters disagree, and what it means for your alerts.
Every EC connects to different peers, churns at different rates, and sees a different slice of the network. From 25 to 130 peers, with one common cloud misconfig that quietly degrades 70% of connections.
Series
One consensus client at a time: where a 12-second slot goes against the 4-second attestation deadline, and how each client lets you see it.
Half the 4-second budget is gone before your execution client even starts. Under Lighthouse, the EC you pick shifts the would-fail-attestation rate up to 3.7x on identical hardware.
Nimbus publishes a complete block-arrival histogram, and this edition read it as the whole story. The finale corrects that: its engine timing was there all along, under a name we did not search for.
Three consensus clients timed the same engine calls on identical hardware. Only the extremes and Besu's 200 ms forkchoiceUpdated survive all three; the middle of the field permutes with the pairing.
Three metric-name searches missed Grandine's engine timing entirely, because the name is all-caps and the method sits in a label. Besu's slow head update is confirmed on a fourth instrument, and part three's driver ordering turns out to be a two-tier split.
Teku splits a block's journey into eleven named stages, more slot detail than any other client here. Five of its own counters also ranked a node that never committed a block best in the fleet.
The richest instrument of the six decomposes a slot in milliseconds and answers the 4-second question without interpolating. It also reads 200 ms longer than the execution client's own engine timer.
The same engine call timed from both ends of the same socket. Consensus-side stopwatches sit 6 to 208 ms above the execution client's own handler, plus six corrections and a sync-detection recipe per client.
Seven weeks, six instruments, three Ethrex generations and nothing held fixed. Three results turned up every time, one dissolved under a finer cut, and the middle of the field never settled.
Series complete
Six clients, six instruments, seven weeks. The finale calibrates every instrument against the execution client's own timer, and ships that table alongside it as a CSV.
Pick your path
StereumLabs data serves different audiences. Jump to the page that matches your role.
Run institutional staking or RPC infrastructure. Compare resource budgets, validator performance, and upgrade impact across versions.
Pick an EC+CC combo for your hardware. Practical guides on peer counts, sync speed, and what to monitor.
Neutral, hardware-backed measurements with full methodology disclosure. Cite our datasets, reproduce our runs.
See how your EC or CC behaves across 42 pairings, multiple versions, and real workloads.
How we measure
We publish our scenarios, flags, hardware specs, and limitations so others can reproduce or critique our results.
Read the full methodology →Equalized conditions, documented config policy, no vendor allegiance. Every client gets the same scenario and the same resource budget.
Anchored on declared bare-metal in Vienna (Epyc 9654P, ZFS raidz1, dedicated NICs). Cloud profiles are disclosed and pinned.
Every run publishes versions, flags, environment hashes, and sampling metadata. You can rerun what we ran or critique what we measured.
New analysis lands roughly every week. Subscribe via RSS or reach out for custom runs on your fleet.