{"id":"6314b765-a79e-4623-8df7-6928374ee282","arxiv_id":"2501.16236","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":0,"one_line_summary":"An instrumented Ethereum client reveals that only about 13% of discovered peers are fully mainnet-compatible and that client and chain diversity cause most connection failures and discovery timeouts.","lead":"This paper instruments Ethereum's devp2p client to capture billions of peer-to-peer messages and shows that most discovered nodes are incompatible with the Ethereum mainnet, with only 13% of dialed peers fully compatible. It identifies client-specific behaviors, such as Geth timeouts and Nethermind disconnects, that reduce connection efficiency in a network shared by many chains and client implementations.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The headline chain-diversity percentages and the 947-dials-per-live-peer statistic are likely artifacts of the measurement node's extreme DHT parameters in Appendix A (bucket cap 2^20, 10s refresh), with no stock-configuration control run to show representativeness.","rationale":"The reader's weakest_assumption is exactly the load-bearing concern: a single heavily modified measurement node cannot establish representative network-wide percentages. I agree that the central claim about chain diversity and connection inefficiency rests on this assumption, and the paper provides no control run or raw data to validate it. The strongest evidence that this is a real problem, not a hypothetical: Appendix A documents parameters that remove the normal DHT's bounded, recency-biased eviction, and Table 7's results track the expected behavior of dialing a DHT inflated with stale records. The comparison to the 2018 study (54.5% mainnet) is not a controlled comparison because the measurement methodology changed drastically. However, I would not move to REJECT. The tool is open source, several qualitative observations are configuration-independent (e.g., Besu returning 13 Neighbors nodes, Bor returning fewer, Nethermind's disconnect categorization), and the extreme configuration could plausibly be corrected by re-running with a stock node and showing the results persist. The reader's CONDITIONAL verdict is therefore appropriate: acceptance should require a configuration-invariance check and ideally release of the raw data or reproducible pipeline. My concern reinforces the existing verdict rather than changing it.","tokens_in":16821,"tokens_out":5327,"duration_ms":51263,"concrete_test":"Re-run the measurement with a stock, unmodified Geth v1.14.0 node (default 16-node buckets, 3 concurrent lookups, 5-minute DHT refresh, default dial scheduler) over the same measurement window and recompute (a) Table 6 sub-protocol percentages, (b) the Figure 6 mainnet-config percentage, (c) Table 7 Category A/B/C fractions at 1M, 10M, and 100M dial attempts, and (d) the dials-per-live-peer metric. If the stock node yields materially higher mainnet-compatible fractions (e.g., Category C above 50%) or far fewer dials per live peer (e.g., below 100), the headline is an artifact of the modified configuration.","verdict_should_be":"CONDITIONAL","load_bearing_attack":"The central quantitative claims—78.05% eth-68, 24.5% correct mainnet config, 13.07% fully compatible peers, and 947 connection attempts per live peer—depend on the unstated assumption that the peer population seen by the measurement node is representative of the Ethereum mainnet's P2P neighborhood. Appendix A violates this assumption. A stock Geth node keeps 17 buckets of at most 16 entries (roughly 272 live, recently responsive nodes), evicts stale records, runs 3 concurrent lookups, and refreshes the DHT every 5 minutes. The modified node raises the per-bucket cap to 1,048,576, runs 1,000 concurrent discovery tasks, refreshes every 10 seconds, and dials around 100 times per second from 50 lookup sources. This replaces normal recency/liveness filtering with an effectively unbounded store of stale, unreachable, and non-mainnet records—Polygon bor peers, testnets, dead IPs—so Table 7's decline in Category C from 13.07% to 2.47% as dial attempts scale to 500M is the expected signature of dialing an inflated table, not a property of the network. The 947-attempts average is computed over this bloated table. The comparison with Kim et al.'s 2018 54.5% mainnet share is not controlled: different client configuration, discovery rate, and era. Appendix A asserts 'representative data coverage' but provides no evidence; the raw data are not released. The finding would be convincing only if the same percentages emerge from an unmodified client.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper presents a measurement study of Ethereum's devp2p P2P layer after the Merge. The authors modify a Geth v1.14.0 client (large DHT buckets, high concurrency, fast refresh, aggressive dialing) to log discovery and RLPx messages, classify 743,739 discovered peers, and analyze connection outcomes. The main reported findings are: 78.05% of reachable peers advertise eth-68, 24.5% have the correct mainnet chain configuration, 12.6% are on outdated mainnet forks, the fully compatible peer fraction is 13.07% at 1 million dial attempts but falls to 2.47% at 500 million, and an average of 947 dial attempts is needed per unique peer. The paper also documents client-specific behaviors: Besu and Nethermind return fewer than 16 nodes in Neighbors responses, Geth waits for a 1.5-second timeout in these cases, most disconnects are classified as 'Useless peer,' and many Ping messages carry private fallback IPs. It concludes that chain and client diversity cause substantial discovery and connection inefficiency.","tokens_in":17121,"tokens_out":7391,"duration_ms":64012,"significance":"The study's strengths are its scale (over 8 billion messages), its post-Merge focus, the open-source instrumentation tool, and the actionable bug reports to client developers. If the headline numbers are representative, the paper would be a useful reference for the Ethereum P2P community and for protocol designers. However, the central quantitative claims are only as credible as the representativeness of the measurement node; because the measurements come from a single heavily modified client with no stock-configuration control, the percentage estimates and the dialing-efficiency statistics are not yet established as properties of the Ethereum network. With a control measurement and released data, the contribution could meet the bar for a measurement paper; in its current form the evidence does not support the strength of the claims.","major_comments":[{"comment":"The headline chain-diversity percentages and the '947 attempts' statistic are computed from a single measurement node whose discovery parameters are extreme relative to a stock Geth node: bucket capacity raised from 16 to 1,048,576, concurrent discovery tasks from 3 to 1,000, DHT refresh from 5 minutes to 10 seconds, and dialing at about 100 attempts/second from 50 lookup sources. Such a node can retain and dial a very different population of stale, unreachable, and non-mainnet records than a normal node would, so Table 7's decline in Category C from 13.07% to 2.47% as dial attempts scale to 500 million is the expected signature of an inflated DHT, not necessarily a network property. Appendix A's claim of 'representative data coverage' is asserted without supporting evidence, and the raw data are not released. The authors should add a control run with an unmodified client (or an equivalent argument, e.g., a liveness-filtered subset analysis) before the percentages can be taken as network-level facts.","section":"§4.5, Table 7, Appendix A"},{"comment":"The decline from Kim et al.'s 54.5% mainnet share in 2018 to 'just 13.07% today' is not a controlled comparison: it compares a different measurement methodology, different client configuration, different discovery rate, and a different network era. Moreover, 13.07% is only the Category C fraction at 1,000,000 dial attempts in Table 7; at 100,000,000 and 500,000,000 attempts the same fraction is 4.58% and 2.47%. The paper should either define a single comparable metric for both eras and report it with the measurement conditions, or avoid the direct 54.5% vs. 13.07% statement.","section":"§4.5, chain diversity comparison"},{"comment":"The text says 'Approximately 26% of the Neighbors messages resulted in timeouts,' but Figure 5 actually shows that 26.01% of responses contained fewer than 16 nodes. A short Neighbors response does not by itself produce a timeout; whether a timeout occurs depends on the lookup logic and on whether the client is still waiting for a second Neighbors message. The 1.5-second Geth timeout is presented as a consequence of these short replies, but no direct timeout counts are reported. The paper should distinguish observed short responses from observed timeouts, or report the actual timeout statistics, because this distinction is load-bearing for the claimed Geth inefficiency.","section":"§4.4, Figure 5, Table 5"},{"comment":"The disconnect-reason distribution, including the 41.58% 'Useless peer' share and the comparison with Kim et al.'s <1% in 2018, is also confounded by the measurement setup: the aggressive dialer will spend most of its attempts on stale or unreachable table entries, inflating the 'Useless peer' and 'TCP sub-system error' categories regardless of network composition. Reporting the disconnect distribution for a stock client, or restricting the analysis to peers discovered through normal refresh cycles, would be needed to support the claim that chain and client diversity are the main drivers of these disconnects.","section":"§4.3, Table 3"}],"minor_comments":[{"comment":"The paper reports 16.9 million node discovery attempts per hour and 2.64 million connection attempts per hour in §4.1, but Appendix F says 'Only ten messages per minute on average are sent'; these statements are inconsistent and should be reconciled.","section":"§4.1 vs. Appendix F"},{"comment":"The pie-style chart is hard to read because the labels mix truncated hashes with percentages; labeling the named networks (Polygon, Holesky, BNB Smart Chain, Linea) directly would make the chain-diversity result interpretable.","section":"Figure 6"},{"comment":"The claim that the private-IP issue is 'a potential issue in Geth's UPnP-NAT functionality' would be stronger if supported by a code reference or by a direct test on a Geth node behind NAT; the current evidence is circumstantial.","section":"§4.2"},{"comment":"The definitions of Classes A, B, and C should state explicitly whether an RLPx handshake is required for Class B and whether Class C requires a completed Status exchange with matching parameters.","section":"Table 2"},{"comment":"The paper does not state the exact measurement window for the full dataset; Figure 3 shows only one week in May 2024, while Table 1 aggregates much larger message counts. A precise date range and a description of any data collected outside that week should be included.","section":"§4.1, measurement window"}],"recommendation":"major_revision","confidential_remarks":"The representativeness issue is the central concern; I would ask for a control run or a release of raw data before publication. The paper's fit to a networking measurement venue is good, but the current draft overstates the precision of its headline percentages. I also note that the 'first study' claim in the contributions should be checked against recent post-merge measurements."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Jiahao Luo built a real instrumented Geth client and captured an enormous devp2p dataset — 8 billion messages, 743k unique peers, 78M disconnect messages. The open-source tool and detailed appendices mean someone can replicate the setup. The paper's qualitative findings about individual clients are genuinely useful: Besu's odd 13-node Neighbors responses, Nethermind's aggressive breach-of-protocol disconnects on non-mainnet chains, Geth's 1.5-second timeout on short responses — these are concrete, checkable behaviors that client developers should look at. The false-IP finding (7,934 peers advertising 127.0.0.1) traces to a real NAT bug that Besu and Reth have patched. That part of the paper is solid and actionable.\n\nThe soft spot is exactly what the stress-test note says. The headline percentages — 78.05% eth-68, 24.5% correct mainnet config, 13.07% fully compatible, 947 dials per live peer — come from a node with a bucket cap of 1,048,576, 1,000 concurrent discovery tasks, a 10-second DHT refresh, and roughly 100 dials/second. A stock Geth node keeps on the order of 272 live, recently responsive nodes. The modified node is effectively an unbounded hoover for stale, unreachable, and non-mainnet records. So the claim that mainnet peers have collapsed to 13% is probably measuring the measurement setup, not the network. The comparison to Kim et al.'s 54.5% from 2018 is uncontrolled: different client, different discovery rate, different era. There is no stock-configuration control run, no error bars, and the raw data are not released. That is a serious gap because the paper's central argument about chain diversity and connection efficiency rests on those numbers.\n\nI do not think this is a takedown. The client-level observations stand on their own and many are tied to specific versions and PR links in the appendix. But the quantitative headline needs a control run with an unmodified client, or at least a sensitivity analysis showing the percentages stabilize as parameters are relaxed. And the data should be released. As is, I would treat the percentages as upper bounds on the problem, not as measurements of the network.\n\nThis paper deserves a serious referee — the tool and the anomaly findings are worth engaging with — but it needs major revision before the quantitative claims can be trusted. Send it to review with that expectation.","headline":"Real measurement tool and useful client-level anomalies, but the headline chain-diversity percentages are likely artifacts of the measurement node's extreme DHT settings.","tokens_in":17671,"tokens_out":1918,"would_cite":false,"duration_ms":17122,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"This paper claims that Ethereum's node discovery is flooded with non-mainnet and unreachable peers, so that only a small fraction of dialing effort yields a live, compatible connection.","keywords":["Ethereum","P2P network","devp2p","node discovery","client diversity","chain diversity","network measurement","Geth"],"falsifier":"Run the same escalating dial experiment from an unmodified, default-configuration Geth node (ideally several nodes in different regions) and measure the fraction of dialed peers that complete the eth/68 Status handshake with network ID 1, the mainnet genesis hash, and the current fork ID; if that fraction is close to 24.5% the claim holds, but if it is substantially higher the headline percentages are artifacts of the measurement node's extreme discovery parameters.","tokens_in":16588,"feed_emoji":"🌐","tokens_out":8919,"duration_ms":70201,"temperature":0.7,"pith_summary":"The paper sets out to show that Ethereum's peer-to-peer layer is substantially less efficient than its protocol design assumes because of chain diversity and client diversity. It reports that a large majority of nodes discoverable through the devp2p DHT are either unreachable or running different chains or outdated forks, with only 24.5% of discovered peers carrying the correct mainnet chain configuration and the share of fully compatible peers dropping to 13.07% in the author's live dialing test. It also traces concrete connection failures to client implementation differences, notably Geth's 1.5-second timeout on short Neighbors responses and inconsistent disconnect classification across clients. The author's point is that the health and performance of the post-merge Ethereum network cannot be assessed without accounting for this diversity.","feed_headline":"Dial test finds only 13% of Ethereum peers sync with mainnet","feed_subtitle":"Measurement: 24.5% of discovered peers carry the correct mainnet config; 947 dials per live peer.","key_machinery":"The load-bearing instrument is a heavily modified Geth full node (v1.14.0) with discovery parameters pushed far beyond defaults—bucket size raised from 16 to 1,048,576, concurrent discovery tasks raised from 3 to 1,000, DHT refresh reduced from 5 minutes to 10 seconds—plus a message collector and analyzer that decodes every devp2p message and links it to internal dial states. This setup produces the peer classification (Class A: no sub-protocol exchange; Class B: incompatible chain parameters; Class C: fully compatible) and the chain-parameter distribution (network ID, genesis hash, fork ID read from Status messages) on which the headline percentages rest. The escalating dialing experiments are the mechanism that turns DHT composition into a concrete efficiency figure: 947 average attempts per live peer.","core_discovery":"On the paper's own terms, the central discovery is that the Ethereum DHT that feeds node discovery is dominated by peers that cannot synchronize with the mainnet, and the cost of that pollution is paid in dialing effort. By instrumenting a modified Geth node to log every discv4, RLPx, and eth-wire message and the client's internal dial and disconnect events, the author finds that only 78.05% of peers advertise the latest eth/68 wire protocol, only 24.5% carry the correct mainnet network ID, genesis hash, and fork ID, and 12.6% of mainnet peers are stuck on pre-Cancun configurations. When dial attempts are scaled from 1 million to 500 million, the fraction of fully compatible peers falls from 13.07% to 2.47%, with the proportion of unreachable peers rising to 88.96%, and it takes on average 947 attempts to reach a live peer. Client-specific behaviors compound this: Geth waits a full 1.5-second timeout whenever a Neighbors response contains fewer than 16 nodes, which happens in about 26% of responses, and clients classify disconnects so differently that peer scoring cannot be uniformly applied.","pith_inferences":["The 13.07% compatibility figure likely understates what an ordinary, unmodified node experiences, because the measurement node's inflated DHT buckets and 10-second refresh deliberately pull in more stale and non-mainnet records; running the same dial test with default parameters could quantify that gap.","Bor clients returning almost exclusively bor neighbors implies that fork-specific DHT filtering already exists in practice, which suggests a lightweight, protocol-level compatibility tag could formalize and extend that behavior to all chains.","If Geth adopted immediate processing of partial Neighbors responses, the paper's own timeout data imply discovery lookup latency would drop by roughly 1.5 seconds for roughly a quarter of lookups—a prediction testable in a client patch.","The reported rise in unreachable peers from 29.51% to 88.96% as dial attempts scale may conflate ordinary node churn with chain diversity; separating the two would require correlating repeated dials of the same node IDs over time."],"forward_implications":["Default Ethereum nodes are spending most of their discovery and dialing budget on peers that can never become useful, so block and transaction propagation latency is worse than the raw network size suggests.","The fork-identifier handshake is too late: because incompatibility is only detected after TCP, encryption, and wire-protocol handshake, efficiency gains require either DHT-level filtering or a compatibility hint in discovery responses.","Geth's strict expectation of 16 nodes per Neighbors reply should be relaxed, since about 26% of responses carry fewer nodes and each triggers an avoidable 1.5-second timeout.","Disconnect reasons cannot be trusted as a uniform triage signal across clients, because Nethermind and Geth classify the same underlying failures under different labels."],"supporting_citations":[{"why":"Provides the 2018 peer-measurement baseline: the 54.5% mainnet-config share and the disconnect-reason breakdown that the paper compares against.","marker":"[30]"},{"why":"Defines the FindNode/Neighbors response format with the 16-node expectation that drives Geth's timeout behavior.","marker":"[10]"},{"why":"Shows the Geth lookup code that limits concurrent FindNode tasks and feeds the dial scheduler, the mechanism behind discovery delays.","marker":"[14]"},{"why":"Documents the default DHT bucket and refresh parameters that the measurement node modifies.","marker":"[11]"},{"why":"Introduces the fork identifier used for chain-compatibility checks after the RLPx handshake.","marker":"[41]"},{"why":"Updates fork-ID checks to timestamp-based logic, defining what counts as a current mainnet configuration.","marker":"[43]"},{"why":"Earlier study showing that most connected Ethereum peers offer limited protocol-level value, which the paper's discovery results extend.","marker":"[29]"},{"why":"Specifies the Cancun upgrade that sets the boundary between current and outdated mainnet configurations.","marker":"[13]"}],"fun_headline_variants":["13% of Ethereum peers sync to mainnet in dial test","947 dials to reach one live Ethereum peer","Geth timeout stalls 26% of Ethereum discovery","Client diversity breaks Ethereum peer scoring"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The headline percentages assume that a single modified Geth node with enormous DHT buckets, 1,000 concurrent discovery tasks, and a 10-second refresh cycle encounters the same peer population that an ordinary, unmodified Ethereum node would encounter.","fun_headline_variants_meta":{"raw":{"variants":["13% of Ethereum peers sync to mainnet in dial test","947 dials to reach one live Ethereum peer","Geth timeout stalls 26% of Ethereum discovery","Client diversity breaks Ethereum peer scoring"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000683,"raw_usage":{"total_tokens":3110,"prompt_tokens":963,"completion_tokens":2147,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":579,"completion_tokens_details":{"reasoning_tokens":2099}},"tokens_in":579,"tokens_out":2147,"duration_ms":15178,"temperature":1.0,"reasoning_tokens":2099,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T13:35:37.010494+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Run the same escalating dial experiment from an unmodified, default-configuration Geth node (ideally several nodes in different regions) and measure the fraction of dialed peers that complete the eth/68 Status handshake with network ID 1, the mainnet genesis hash, and the current fork ID; if that fraction is close to 24.5% the claim holds, but if it is substantially higher the headline percentages are artifacts of the measurement node's extreme discovery parameters.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Defines the FindNode/Neighbors response format with the 16-node expectation that drives Geth's timeout behavior."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Shows the Geth lookup code that limits concurrent FindNode tasks and feeds the dial scheduler, the mechanism behind discovery delays."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Documents the default DHT bucket and refresh parameters that the measurement node modifies."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Introduces the fork identifier used for chain-compatibility checks after the RLPx handshake."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Updates fork-ID checks to timestamp-based logic, defining what counts as a current mainnet configuration."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Earlier study showing that most connected Ethereum peers offer limited protocol-level value, which the paper's discovery results extend."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Specifies the Cancun upgrade that sets the boundary between current and outdated mainnet configurations."}],"review_version":1}