{"id":"7816282f-5422-4b8f-b37e-33fe19a48525","arxiv_id":"2505.18290","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"EtherBee is a new public dataset of Ethereum P2P network activity from ten vantage points over three months, and its case study reports that latency-based peer pruning is associated with growing geographic concentration.","lead":"Researchers built EtherBee, a public dataset of Ethereum peer-to-peer network activity from ten servers on five continents, spanning three months of node metrics, traffic logs, and 133 million recorded attacks. A case study in the paper finds that Ethereum client software's latency-based peer pruning may be pulling connections toward a few geographic hubs, raising resilience concerns.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Causal attribution to latency-based pruning is not supported without direct pruning measurements; aggregate distance trends could reflect peer churn, discovery dynamics, or geolocation artifacts.","rationale":"The reader's weakest assumption correctly identifies that the case study infers pruning from aggregate distance trends without directly measuring pruning decisions or controlling for confounders. My stress-test sharpens this into a falsifiable mechanism: the time trend may be an artifact of peer churn, discovery, or byte-weighting rather than active client behavior. A stable-peer recomputation is a concrete way to distinguish these explanations using the released data. Because the dataset itself is well-described and the requested revisions already include quantifying geolocation uncertainty, correcting for autocorrelation, and providing open access, the conditional verdict remains appropriate; no verdict adjustment is needed.","tokens_in":4455,"tokens_out":3086,"duration_ms":30711,"concrete_test":"Recompute the Section III.B linear regressions using only peers that appear in at least 7 consecutive days of the node's session logs, and compare against the full-peer-set slopes. If the negative slopes disappear for stable peers, the trend is driven by transient peers or bootstrap dynamics rather than pruning of established connections; if the slopes persist, pruning remains a plausible contributor but still requires direct log-based evidence of score-based disconnections to support the causal claim.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The centralization conclusion depends on interpreting a temporal decline in byte-weighted average peer distance as evidence that Ethereum clients prune distant peers based on latency. However, Section III.A-B never directly observes peer scoring, disconnection decisions, or pruning events; it only reports aggregate daily distances computed from MaxMind GeoLite2 geolocation. Multiple mechanisms can produce the same negative slopes without pruning: peers discovered during bootstrap may become geographically closer over time as the node stabilizes; distant peers may disconnect for reasons unrelated to client scoring; client software updates during the three-month window (Lighthouse v5.2.1, Nethermind 1.27.1) may alter peer-selection behavior; and byte-weighting means a small number of high-volume peers, possibly including DDoS or scanning traffic, can dominate the daily centroid and shift it for reasons unrelated to node policy. The re-centered South American analysis is post hoc and does not isolate pruning because it does not compare against a no-pruning control. If the negative slopes are driven by churn or discovery rather than active pruning, the paper's headline claim about client-driven geographic centralization fails, even though the EtherBee dataset itself remains valuable and credible.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","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.","tokens_in":4732,"tokens_out":4019,"duration_ms":36811,"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":[{"comment":"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.","section":"III.B"},{"comment":"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.","section":"III.A-B"},{"comment":"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.","section":"III.A"},{"comment":"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.","section":"III.B"},{"comment":"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.","section":"III.B"}],"minor_comments":[{"comment":"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.","section":"III.A"},{"comment":"Figure 1's legend lists slopes without units; adding 'km/day' to the legend would avoid ambiguity.","section":"III.B / Figure 1"},{"comment":"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.","section":"II"},{"comment":"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.","section":"IV"}],"recommendation":"major_revision","confidential_remarks":"The dataset contribution appears genuine and potentially valuable, and the collection methodology is described with enough specificity to be reproducible. The case study, however, is currently too weak to carry the paper's central claim about pruning-induced centralization. The main gaps—missing p-values for three of five slopes, no geolocation error analysis, no direct pruning measurements, and no autocorrelation-robust inference—are addressable in a revision, but they require substantial additional analysis rather than simple rewording. I would encourage the editor to ask for a revised version that either provides the missing statistical support or substantially narrows the causal claims."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"EtherBee is the real deal as a dataset artifact; the case study riding on top of it is a plausible illustration, not a proven result. If you work on Ethereum P2P or blockchain network measurement, this is worth your time.\n\nWhat's new: nobody has combined full P2P sessions, node telemetry, and honeypot logs from ten geographically spread vantage points over months, time-synchronized and released. The collection methodology is concrete: Arkime for traffic, Lighthouse/Nethermind instrumentation, T-Pot honeypots, Elasticsearch, WireGuard. The sanity check that 58% of honeypot attacks are DDoS against Cloudflare's 57% is a nice touch. The dataset size (30.1 TB primary, 33.7B docs) is substantial, and the OSF DOI is at least a start.\n\nThe soft spot is the case study. They claim latency-based pruning drives geographic centralization because daily byte-weighted average peer distance declines at four of five vantage points. That's a reasonable observation, but the causal step is not supported. They never observe pruning or peer scoring; they infer it from aggregate distance trends. There are obvious confounders: client updates during the window, peer churn, discovery dynamics, and MaxMind GeoLite2 error, which they never quantify. Also, they only report p-values for two of the five slopes (NA and SA), call the other three significant, and don't correct for autocorrelation. The re-centered SA analysis is post hoc, but even that only shows a pattern, not a mechanism. The prose goes beyond the evidence when it says the results 'support the hypothesis'—they're consistent with it, but that's weaker.\n\nThat said, the flaws are in the secondary analysis, not the core artifact. The dataset itself is described in enough detail to be credible, and releasing it lets others test the pruning question directly. The main thing I'd push on is access: 'available upon request' plus an OSF link isn't the same as a direct download with checksums. I'd also want analysis code and geolocation uncertainty.\n\nBottom line: this paper deserves a real referee. I'd take it conditionally: require direct data access, code, p-values for all vantage points, autocorrelation correction, and soften the causal language. The dataset is the contribution; the case study is a teaser.","headline":"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.","tokens_in":5167,"tokens_out":2355,"would_cite":true,"duration_ms":20135,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"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.","keywords":["Ethereum","peer-to-peer network","node performance","honeypot logs","geographic centralization","latency-based peer pruning","network measurement dataset"],"falsifier":"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.","tokens_in":4197,"feed_emoji":"🌐","tokens_out":6535,"duration_ms":47654,"temperature":0.7,"pith_summary":"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.","feed_headline":"Latency-based peer pruning is quietly centralizing Ethereum","feed_subtitle":"A three-month, ten-vantage-point dataset shows peers clustering toward North America and Europe, threatening resilience.","key_machinery":"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.","core_discovery":"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.","pith_inferences":["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."],"forward_implications":["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."],"supporting_citations":[{"why":"Supplies the latency-based peer-scoring design whose pruning behavior the case study tests.","marker":"[20]"},{"why":"Prior measurement of Bitcoin and Ethereum decentralization that motivates the concern.","marker":"[9]"},{"why":"Method for mapping IP addresses to coordinates, used to compute peer distances.","marker":"[19]"},{"why":"Empirical link between round-trip time and geographic distance that underpins the latency-distance reasoning.","marker":"[18]"},{"why":"Dashboard count of persistent beacon nodes that contextualizes the 94,659 observed IPs.","marker":"[15]"},{"why":"Instrumented consensus-layer client that yields the node metrics and peer sessions.","marker":"[12]"},{"why":"Instrumented execution-layer client that yields the node metrics and peer sessions.","marker":"[13]"},{"why":"External estimate of DDoS share used to sanity-check the honeypot attack distribution.","marker":"[17]"}],"fun_headline_variants":["Latency pruning is pulling Ethereum peers toward the Atlantic","Ethereum's latency filter is shrinking its network map","New dataset shows Ethereum clustering along North Atlantic cables","Client latency scoring is redrawing Ethereum's geography","Why Ethereum peers are bunching up on Atlantic routes"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"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.","fun_headline_variants_meta":{"raw":{"variants":["Latency pruning is pulling Ethereum peers toward the Atlantic","Ethereum's latency filter is shrinking its network map","New dataset shows Ethereum clustering along North Atlantic cables","Client latency scoring is redrawing Ethereum's geography","Why Ethereum peers are bunching up on Atlantic routes"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000388,"raw_usage":{"total_tokens":1983,"prompt_tokens":820,"completion_tokens":1163,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":436,"completion_tokens_details":{"reasoning_tokens":1088}},"tokens_in":436,"tokens_out":1163,"duration_ms":6699,"temperature":1.0,"reasoning_tokens":1088,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-07T14:33:05.185754+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"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.","supporting_citations":[{"cited_title":"Perigee: Efficient peer-to-peer network design for blockchains,","cited_arxiv_id":null,"evidence_quote":"Supplies the latency-based peer-scoring design whose pruning behavior the case study tests."},{"cited_title":"Decentralization in bitcoin and ethereum networks,","cited_arxiv_id":null,"evidence_quote":"Prior measurement of Bitcoin and Ethereum decentralization that motivates the concern."},{"cited_title":"Towards geolocation of millions of ip addresses,","cited_arxiv_id":null,"evidence_quote":"Method for mapping IP addresses to coordinates, used to compute peer distances."},{"cited_title":"Rtt measurement and its dependence on the real geographical distance,","cited_arxiv_id":null,"evidence_quote":"Empirical link between round-trip time and geographic distance that underpins the latency-distance reasoning."},{"cited_title":"Ethereum cl layer public dashboard,","cited_arxiv_id":null,"evidence_quote":"Dashboard count of persistent beacon nodes that contextualizes the 94,659 observed IPs."},{"cited_title":"Lighthouse: An ethereum 2.0 client,","cited_arxiv_id":null,"evidence_quote":"Instrumented consensus-layer client that yields the node metrics and peer sessions."},{"cited_title":"Nethermind: The ethereum execution client,","cited_arxiv_id":null,"evidence_quote":"Instrumented execution-layer client that yields the node metrics and peer sessions."},{"cited_title":"Cloudflare radar,","cited_arxiv_id":null,"evidence_quote":"External estimate of DDoS share used to sanity-check the honeypot attack distribution."}],"review_version":1}