2 posts tagged with "consensus client"

We ran Optimum's mump2p gateway, version 1.1.1 at commit 66e391d, on 36 mainnet full nodes in a single datacenter for 11.5 days at the end of August, one gateway on every node, across the full six-by-six matrix of consensus against execution clients. Blocks arrived earlier on three of the six consensus clients. On a fourth about half the move is real, on a fifth the metric cannot say either way, and on the sixth the treated nodes got slower rather than faster. None of the numbers is statistically significant, and the reason is built into the design rather than into the data.

The apparent effect, before we looked hard, was 40 to 110 ms. We then spent a second pass attacking our own control group, because the treated nodes are bare metal in Vienna and the controls are GCP in Frankfurt, and a difference-in-differences absorbs a constant offset between two datacenters but never a drift. What survived that pass is smaller, is carried by fewer clients, and rests on a different kind of evidence than the control group provides. This post is about which parts held.

Over three days in August, Lodestar timed 21,530 newPayload calls to its Ethrex peer and reported a mean of 372.6 ms; Ethrex timed the same calls from its own end of the same socket and reported 164.8 ms. Both figures are right as far as the client reporting them is concerned, since the two stopwatches start and stop at different points, but the 208 ms between them is larger than most of the differences this series has spent six editions measuring between execution clients.

For six editions we compared execution clients through whichever consensus client happened to be watching them, and it took until the sixth to work out how much of what we were reading belonged to the watcher rather than the watched. Six consensus clients run against the same fleet here, no two of them measure a slot the same way, and one of them cannot produce a mean for the engine call at all.