Pith. sign in

REVIEW 5 major objections 4 minor 20 references

EtherBee: A Global Dataset of Ethereum Node Performance Measurements Coupled with Honeypot Interactions and Full Network Sessions

T0 review · 5 major / 4 minor · reviewed 2026-08-07 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read EtherBee, a new global dataset of Ethereum node performance, network sessions, and honeypot interactions, supports the claim that latency-based peer pruning unintentionally drives geographic centralization.

desk verdict EtherBee is a genuinely useful new multimodal dataset worth refereeing; the centralization case study overreaches, but the data artifact is real and should be published with fixes. read the letter →

arxiv 2505.18290 v1 pith:XP5Y43XJ submitted 2025-05-23 cs.NI cs.CR

Scott Seidenberger , Anindya Maiti This is my paper · ORCID
classification cs.NIcs.CR
keywords Ethereumpeer-to-peernetworknodeperformancehoneypotlogsgeographiccentralizationlatency-basedpeerpruningmeasurementdataset
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

EtherBee aims to give researchers the first multimodal record of Ethereum's peer-to-peer layer: three months of node-performance metrics, network session metadata, and honeypot attack logs, collected simultaneously at ten cloud vantage points across five regions. The paper's case study uses this record to argue that latency-based peer pruning, a client optimization meant to speed up block propagation, unintentionally pulls the network's peers closer together geographically. Four of five vantage points showed statistically significant daily decreases in byte-weighted peer distance, with the North American node shrinking by 6.17 km per day. If the trend is real, a performance tweak is quietly eroding the geographic decentralization that underpins Ethereum's resilience and censorship resistance.

What carries the argument

The carrier of the argument is a weighted geographic focal-point computation applied to daily peer-to-peer sessions. Each peer's IP address is mapped to latitude and longitude, converted to Cartesian coordinates on the unit sphere, averaged with weights equal to bytes exchanged, and projected back to a latitude and longitude centroid; the daily byte-weighted average distance from the vantage point to this focal point is then regressed on time. This construction lets the authors turn raw connection logs into a single number per day per vantage point that tracks whether a node's meaningful peer relationships are drifting geographically, and the negative slopes are interpreted as the footprint of latency-based peer pruning.

What would settle it

Recompute the daily byte-weighted distances from round-trip times instead of IP geolocation, or restrict the analysis to peers that stayed connected continuously; if the negative slopes vanish under either check, the centralization claim is an artifact of geolocation error or peer churn rather than latency pruning.

Watch

Extended reading notes

Core claim

The central claim is that client-side latency scoring systematically prunes distant peers and thereby drives geographic centralization of the Ethereum peer-to-peer network. Over 107 days, the byte-weighted average distance from each vantage point to its peers fell for four of five regions, most sharply for the Asia-Pacific node (at a rate of 12.55 km per day) and the North American node (6.17 km per day, with p = 0.002); the South American node showed no local trend (p = 0.797), but when re-centered as if located in North America it exhibited a strong clustering trend of 4.16 km per day, indicating dependence on distant North American peers. The daily weighted focal points converged along North Atlantic submarine cable routes, so the paper concludes that latency pruning concentrates connectivity on a small set of physical links and makes large parts of the network dependent on those routes.

Load-bearing premise

The case study assumes that the daily byte-weighted average peer distance, computed from IP geolocation, is a faithful measure of pruning-driven geographic centralization, with no other factor such as client updates, peer churn, routing changes, or geolocation error producing the downward trends.

Editorial extensions

If this is right

  • If latency-based pruning is centralizing the network, Ethereum's resilience to regional outages weakens: a disruption on a small number of transatlantic routes would affect a disproportionate share of peer connectivity.
  • Peer-scoring algorithms that look beyond latency, such as rewarding diversity or penalizing excessive geographic concentration, should slow or reverse the observed distance trends.
  • With 94,659 unique IPs and 30.1 TB of raw data, EtherBee gives the community a way to test client-version effects, node churn, and attack patterns against a common synchronized baseline.
  • The 133.8 million honeypot interactions, 58% of them DDoS-related, can be correlated with node performance and session data to measure how attacks target specific regions or node types.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • The case study correlates distance trends with latency pruning without directly observing pruning decisions; a natural follow-up is to instrument clients to log actual peer evictions and check whether evicted peers are geographically farther than surviving peers.
  • Because the inverse re-centering experiment on the South American node reproduced clustering, the mechanism likely generalizes: any region with sparse local peers will feel latency-based pruning as dependence on distant hub regions, not as local clustering.
  • The published dataset could be used to separate the effect of client-version updates from pruning by comparing distance trends across client releases; if the trend is concentrated in one client version, the root cause is that version's scoring logic.
  • Combining the honeypot and session streams could test whether pruned or poorly scoring peers are more likely to be sources of malicious traffic, which would change the security calculus of aggressive pruning.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

5 major / 4 minor

Summary. EtherBee is presented as a multimodal dataset of Ethereum node measurements collected from ten AWS vantage points in five geographic regions over roughly three months (August–November 2024). The collection combines Arkime network-session metadata, Lighthouse and Nethermind node metrics, and T-Pot honeypot interaction logs, indexed in Elasticsearch and released in compressed form via OSF. The paper's case study computes a daily byte-weighted geographic focal point of each node's peers using MaxMind GeoLite2 coordinates, regresses byte-weighted average peer distance over 107 days, and reports negative slopes for four of five vantage points, e.g., -6.17 km/day for North America (p=0.002). The authors interpret these trends as evidence that latency-based peer pruning unintentionally drives geographic centralization, with implications for resilience and censorship resistance.

Significance. If the dataset is as described, EtherBee is a valuable community resource: it combines three synchronized data modalities, spans geographically diverse vantage points, reports specific software versions, and is publicly released, with a honeypot DDoS share (58%) that cross-checks independent estimates (57% from Cloudflare Radar). This could support many future studies of peer-to-peer behavior, node stability, and network threats. The case study addresses a timely and important question about decentralization in Ethereum. However, the causal claim about pruning-driven geographic centralization is not currently established by the evidence presented, so the paper's significance rests primarily on the dataset and collection methodology rather than on the case study conclusion.

major comments (5)
  1. [III.B] The headline claim that four of five vantage points showed a significant shift is not fully documented. The text reports p-values for North America (p=0.002), South America (p=0.797), and the re-centered South America analysis (p<0.001), but no p-values, standard errors, or confidence intervals are given for Europe, Asia-Pacific, or the Middle East. A full regression table for all five original vantage points, including slopes, standard errors, p-values, and intervals, is needed before the 'four of five significant' statement can be evaluated.
  2. [III.A-B] The causal attribution to latency-based peer pruning is not supported because the paper never directly observes pruning decisions. Section III.A motivates the analysis with client peer-scoring and pruning, and Section III.B concludes that 'pruning based on latency unintentionally drives geographic centralization,' but no data on peer disconnects, peer scores, or pruning events are presented. The aggregate distance trends could instead reflect bootstrap/discovery churn, distant peers disconnecting for unrelated reasons, client software updates during the three-month window (Lighthouse v5.2.1, Nethermind 1.27.1), or byte-weighting artifacts from a small number of high-volume peers. The statement in Section III.B that 'nodes in remote regions were pruned more often' is an unsupported assertion without direct pruning measurements.
  3. [III.A] Geolocation uncertainty is not quantified, and this is load-bearing because the reported slopes are 4-12 km/day, corresponding to cumulative shifts of roughly 400-1300 km over the study period. MaxMind GeoLite2 is known to have city-level errors that can be tens to hundreds of kilometers, especially outside densely mapped regions. The analysis should include a sensitivity check, such as excluding low-confidence geolocations, using coarse-grained country or region centroids, or otherwise bounding the effect of geolocation error. Without this, the observed negative slopes may be within the noise of the geolocation method.
  4. [III.B] The statistical significance of the OLS slopes is questionable because the daily byte-weighted average distances are not independent observations: successive days share overlapping peer sets, and the byte-weighted focal point is strongly autocorrelated. The paper does not report autocorrelation-robust standard errors (e.g., Newey-West or block bootstrap) or model the time-series structure. The reported p-values should therefore be treated as likely anti-conservative, and the claim of significance needs to be re-estimated under an appropriate error model.
  5. [III.B] The re-centered South American analysis is post hoc and does not isolate pruning. Re-centering the South American node as if it were in North America and finding a negative slope only shows that the byte-weighted centroid of South American peers moves closer to North America over time; it does not distinguish peer pruning from other changes in the peer set, such as discovery dynamics or shifts in which peers exchange the most data. A no-pruning control, such as a fixed peer-set baseline or a simulation using observed peer-discovery behavior, would be required to support the pruning interpretation.
minor comments (4)
  1. [III.A] The weighting term is described as 'total bytes exchanged' in the text, but Figure 1's label says 'Byte-Weighted Average Distance.' Please clarify whether the weight is sent bytes, received bytes, or the sum, and whether the same definition is used for all vantage points.
  2. [III.B / Figure 1] Figure 1's legend lists slopes without units; adding 'km/day' to the legend would avoid ambiguity.
  3. [II] The description of the Elasticsearch cluster (227 TB storage, 132 GB heap, 1,419 shards) is detailed, but the paper does not state how many Peer IDs or sessions are included in the publicly released version, or whether the release includes raw packet payloads or only metadata. A short data-schema or variable-description table would help users.
  4. [IV] The sentence about 'other access options are available on OSF' is vague; please specify the exact access modes (e.g., direct download, S3 bucket) and any access restrictions.

Circularity Check

0 steps flagged · score 0.0 of 10

No circular derivation: the case-study trends are measured from released observational data, with no fitted parameter renamed as a prediction and no load-bearing self-citation.

full rationale

The paper's central contribution is a released dataset, and its case study is an observational analysis of that dataset. The load-bearing numbers — daily byte-weighted average peer distances, the 6.17 km/day North American trend, and the p-values — are computed directly from captured P2P sessions and MaxMind GeoLite2 geolocation, not from any parameter fitted to the conclusion. The weighted focal point formula is an explicit descriptive statistic (Section III.A) and is not used to define or derive pruning behavior. The claim that latency-based pruning drives geographic centralization is presented as a hypothesis supported by observed trends and prior work [9], [20]; this is an interpretive causal attribution, which may be methodologically weak without direct pruning measurements, but it is not circular because the data were not constructed to force the trend. The re-centered South American analysis is an exploratory transformation of the same measurements, not a forecast generated from a fitted model, and no self-citations are load-bearing. Concerns about geolocation error, peer churn, client version changes, and confounding network events are validity risks, not instances of the paper's derivation reducing to its own inputs. Accordingly, no circularity is present.

Assumptions & free parameters 0 free parameters · 4 assumptions · 0 invented entities

The paper introduces no new physical or mathematical entities. Its central claims rest on measurement assumptions about geolocation accuracy, representativeness of vantage points, the causal interpretation of temporal trends, and the validity of simple linear regression on autocorrelated daily averages. No free parameters are fitted to force the case study conclusion; the regression slopes are reported estimates rather than hidden tuning parameters.

assumptions (4)
  • domain assumption MaxMind GeoLite2 provides sufficiently accurate IP-to-location mapping for computing peer distances and focal points.
    Used in Section III.A to convert peer IPs to coordinates; geolocation error is not quantified, and errors of tens to hundreds of kilometers are common for IP geolocation, which could affect daily distance trends.
  • domain assumption Ten AWS servers in five regions are representative of global Ethereum P2P connectivity.
    The paper describes the vantage points as 'global' but they are a convenience sample from AWS regions; results may not generalize to non-cloud, home, or differently located nodes.
  • domain assumption Observed daily trends in peer distance are caused by latency-based peer pruning rather than by confounding network changes.
    The case study attributes the trend to client scoring and pruning, but does not measure pruning decisions directly or control for client updates, peer churn, routing changes, or seasonal effects.
  • ad hoc to paper Daily byte-weighted average distances are independent enough that ordinary least squares p-values are valid.
    Time series of daily averages are likely autocorrelated; reported p-values such as p=0.002 may be overstated, and p-values for the EU, AP, and ME slopes are not reported at all.

how reviews work

0 comments
Cite this review

Pith. "Pith review of EtherBee: A Global Dataset of Ethereum Node Performance Measurements Coupled with Honeypot Interactions and Full Network Sessions." pith.science (2026). https://pith.science/paper/XP5Y43XJ

@misc{pith2026250518290,
  author       = {Pith},
  title        = {Pith review of: EtherBee: A Global Dataset of Ethereum Node Performance Measurements Coupled with Honeypot Interactions and Full Network Sessions},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/XP5Y43XJ}},
  note         = {Machine review of arXiv:2505.18290}
}
read the original abstract

We introduce EtherBee, a global dataset integrating detailed Ethereum node metrics, network traffic metadata, and honeypot interaction logs collected from ten geographically diverse vantage points over three months. By correlating node data with granular network sessions and security events, EtherBee provides unique insights into benign and malicious activity, node stability, and network-level threats in the Ethereum peer-to-peer network. A case study shows how client-based optimizations can unintentionally concentrate the network geographically, impacting resilience and censorship resistance. We publicly release EtherBee to promote further investigations into performance, reliability, and security in decentralized networks.

Figures

Figures reproduced from arXiv: 2505.18290 by the authors.

Figure 1
Figure 1. Daily byte-weighted average distance to peers for each [PITH_FULL_IMAGE:figures/full_fig_p002_1.png] view at source ↗
Figure 2
Figure 2. Data-weighted geographic focal points of five Ethereum [PITH_FULL_IMAGE:figures/full_fig_p002_2.png] view at source ↗

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

20 extracted references · 18 canonical work pages

  1. [1]

    Graph analysis of the ethereum blockchain data: A survey of datasets, methods, and future work,

    A. Khan, “Graph analysis of the ethereum blockchain data: A survey of datasets, methods, and future work,” in 2022 IEEE International Conference on Blockchain (Blockchain) , 2022, pp. 250–257

    work page 2022

  2. [2]

    EX-graph: A pioneering dataset bridging ethereum and x,

    Q. Wang, Z. Zhang, Z. Liu, S. Lu, B. Luo, and B. He, “EX-graph: A pioneering dataset bridging ethereum and x,” in The Twelfth International Conference on Learning Representations , 2024. [Online]. Available: https://openreview.net/forum?id=juE0rWGCJW

    work page 2024

  3. [3]

    Dataether: Data exploration framework for ethereum,

    T. Chen, Z. Li, Y . Zhang, X. Luo, A. Chen, K. Yang, B. Hu, T. Zhu, S. Deng, T. Hu et al. , “Dataether: Data exploration framework for ethereum,” in 2019 IEEE 39th International Conference on Distributed Computing Systems (ICDCS) . IEEE, 2019, pp. 1369–1380

    work page 2019

  4. [4]

    Ethereum proof- of-stake consensus layer: Participation and decentralization,

    D. Grandjean, L. Heimbach, and R. Wattenhofer, “Ethereum proof- of-stake consensus layer: Participation and decentralization,” 2023. [Online]. Available: https://arxiv.org/abs/2306.10777

    arXiv 2023

  5. [5]

    Discovering the ethereum2 p2p network,

    M. Cortes-Goicoechea and L. Bautista-Gomez, “Discovering the ethereum2 p2p network,” in 2021 Third International Conference on Blockchain Computing and Applications (BCCA) . IEEE, 2021, pp. 81–88

    work page 2021

  6. [6]

    Unveiling ethereum’s hidden centralization incentives: Does connectivity impact performance?

    M. Cortes-Goicoechea, T. Mohandas-Daryanani, J. L. Mu ˜noz-Tapia, and L. Bautista-Gomez, “Unveiling ethereum’s hidden centralization incentives: Does connectivity impact performance?” in 2023 Fifth International Conference on Blockchain Computing and Applications (BCCA), 2023, pp. 89–96

    work page 2023

  7. [7]

    Measuring ethereum network peers,

    S. K. Kim, Z. Ma, S. Murali, J. Mason, A. Miller, and M. Bailey, “Measuring ethereum network peers,” in Proceedings of the Internet Measurement Conference 2018 , ser. IMC ’18. New York, NY , USA: Association for Computing Machinery, 2018, p. 91–104. [Online]. Available: https://doi.org/10.1145/3278532.3278542

    arXiv 2018

  8. [8]

    Ethna: Analyzing the underlying peer-to-peer network of ethereum blockchain,

    T. Wang, C. Zhao, Q. Yang, S. Zhang, and S. C. Liew, “Ethna: Analyzing the underlying peer-to-peer network of ethereum blockchain,” IEEE Transactions on Network Science and Engineering , vol. 8, no. 3, pp. 2131–2146, 2021

    work page 2021

Show all 20 references
  1. [9]

    Decentralization in bitcoin and ethereum networks,

    A. E. Gencer, S. Basu, I. Eyal, R. Van Renesse, and E. G. Sirer, “Decentralization in bitcoin and ethereum networks,” in Financial Cryp- tography and Data Security: 22nd International Conference, FC 2018, Nieuwpoort, Curac ¸ao, February 26–March 2, 2018, Revised Selected Paper...

    2018

  2. [10]

    Cyber threat intelligence from honeypot data using elas- ticsearch,

    H. Almohannadi, I. Awan, J. Al Hamar, A. Cullen, J. P. Disso, and L. Armitage, “Cyber threat intelligence from honeypot data using elas- ticsearch,” in 2018 IEEE 32nd International Conference on Advanced Information Networking and Applications (AINA) . IEEE, 2018, pp. 900–906

    2018

  3. [11]

    Evolving techniques in cyber threat hunting: A systematic review,

    A. Mahboubi, K. Luong, H. Aboutorab, H. T. Bui, G. Jarrad, M. Bahutair, S. Camtepe, G. Pogrebna, E. Ahmed, B. Barry et al. , “Evolving techniques in cyber threat hunting: A systematic review,” Journal of Network and Computer Applications , p. 104004, 2024

    2024

  4. [12]

    Lighthouse: An ethereum 2.0 client,

    Sigma Prime, “Lighthouse: An ethereum 2.0 client,” https://github.com/ sigp/lighthouse, 2024, version v5.2.1-9e12c21

    2024

  5. [13]

    Nethermind: The ethereum execution client,

    Nethermind Project, “Nethermind: The ethereum execution client,” https://github.com/NethermindEth/nethermind, 2024, version 1.27.1+d2d5d4ae

    2024

  6. [14]

    Arkime: Open source full packet capture and analysis tool,

    A. Project, “Arkime: Open source full packet capture and analysis tool,” 2024, accessed: 2024-12-22. [Online]. Available: https://github. com/arkime/arkime

    2024

  7. [15]

    Ethereum cl layer public dashboard,

    MigaLabs, “Ethereum cl layer public dashboard,” https://monitoreth. io/nodes, 2024, accessed: 16 December 2024. Data retrieved from Armiarma by MigaLabs

    2024

  8. [16]

    T-pot: The all in one honeypot platform,

    T-Pot Project, “T-pot: The all in one honeypot platform,” https://github. com/telekom-security/tpotce, 2024, version 24.04.0

    2024

  9. [17]

    Cloudflare radar,

    Cloudflare, “Cloudflare radar,” https://radar.cloudflare.com/, 2024, ac- cessed: 16 December 2024

    2024

  10. [18]

    Rtt measurement and its dependence on the real geographical distance,

    O. Krajsa and L. Fojtova, “Rtt measurement and its dependence on the real geographical distance,” in 2011 34th International Conference on Telecommunications and Signal Processing (TSP) . IEEE, 2011, pp. 231–234

    2011

  11. [19]

    Towards geolocation of millions of ip addresses,

    Z. Hu, J. Heidemann, and Y . Pradkin, “Towards geolocation of millions of ip addresses,” in Proceedings of the 2012 Internet Measurement Conference, 2012, pp. 123–130

    2012

  12. [20]

    Perigee: Efficient peer-to-peer network design for blockchains,

    Y . Mao, S. Deb, S. B. Venkatakrishnan, S. Kannan, and K. Srinivasan, “Perigee: Efficient peer-to-peer network design for blockchains,” in Pro- ceedings of the 39th Symposium on Principles of Distributed Computing, 2020, pp. 428–437

    2020

Pith tools

Reviewed August 7, 2026 · model on record in the stance chip above.