Scenario
Round-trip latencies for chained requests eth_getBlockByNumber(latest, false) and eth_getLogs(hash) without throttling.
Also, block number consistency with block availability and block age. The block propagation comparison is conservative and latency-agnostic.
Of the possible 31 regions, 2 were selected for data collection: Columbus, OH and Frankfurt.
Each location probe breaks its processing loop if / when the endpoint response is too-many-requests, a.k.a. HTTP code 429 etc. Also, codes 401 and 403.
At the time of the report generation: 4 of 4 datasets were available from 2 selected regions x 2 endpoints.
Additional info about RPC Inspector Pro technology is in the FAQ and documentation
Findings
| Endpoint | Lagging | Unique | Lowest | Arrival Tms | Arrival Region | Highest | Arrival Tms | Arrival Region |
|---|---|---|---|---|---|---|---|---|
| A. mainnet.ethereum.ValidationCloud.io | 0 | 4 | 25,198,192 | 1,780,023,647,330 | Columbus, OH / AWS | 25,198,195 | 1,780,023,672,885 | Columbus, OH / AWS |
| B. svc.Blockdaemon.com | 420 | 3 | 25,198,192 | 1,780,023,647,373 | Columbus, OH / AWS | 25,198,195 | 1,780,023,673,631 | Frankfurt / AWS |
We detected 420 lagging block-number responses whose sendTms, arrivalTms and number prove the endpoint was behind in the respective region.
E.g. on arrivalTms=1,780,023,649,074 in Columbus, OH / AWS, we received number 25,198,193 from A. mainnet.ethereum.ValidationCloud.io. Afterwards, on sendTms=1,780,023,649,128 we dispatched a request to B. svc.Blockdaemon.com, which returned lower number 25,198,192 at arrivalTms=1,780,023,649,308. Therefore, B. svc.Blockdaemon.com was lagging because it was returning lower number 25,198,192 well after A. mainnet.ethereum.ValidationCloud.io advanced to 25,198,193.
Details
Latencies exclude one warmup request per endpoint in each region. Additional columns are visible when you scroll to the right.