{"id":"8a456081-295d-4024-a69c-3a229b98b1ab","arxiv_id":"2411.14623","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"Ethereum P2P nodes attract measurably more reconnaissance and credential-harvesting traffic than control honeypots, and many live nodes expose management ports.","lead":"The authors deployed honeypot servers with and without Ethereum nodes on five continents and logged two months of inbound attack traffic. Ethereum nodes drew significantly more scans and credential-harvesting attempts, and about a quarter of live Ethereum nodes expose extra management ports.","discovery_kind":"new_application","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The treatment and control groups differ in instance type and likely in AWS IP reputation; the Section 4.1 GLMM group effect may measure IP-pool differences rather than Ethereum-node targeting.","rationale":"The reader's weakest assumption is that the causal attribution of elevated attacks to the Ethereum node rests on control/experimental comparability, specifically the larger instance used for the experimental group. My reading agrees: Table 1 shows a clear confound, and the GLMM in Section 4.1 adjusts only for region, not for instance type or individual VP/IP. This is the most load-bearing concern because the central claim is the elevated attack rate on Ethereum nodes; if the group effect is caused by IP-pool reputation, the headline conclusion collapses. The paper does have independent support: the port scan of 6,184 live nodes provides evidence of exposure, and the URI/SSH analyses suggest targeted behaviors. Those pieces do not, however, establish the elevated attack rate that the GLMM is meant to prove. A single additional control arm with identical hardware would settle the issue. Since the reader already reached CONDITIONAL on essentially this ground, no verdict adjustment is needed; the stress test confirms the condition.","tokens_in":11048,"tokens_out":5290,"duration_ms":59227,"concrete_test":"Redeploy the control honeypots on exactly the same instance type and disk size as the experimental group (r7i.xlarge, 2500GB) in the same five regions, with T-Pot and Arkime but without Ethereum clients. If the control attack counts remain at the original control baseline while the experimental nodes again show elevated counts, the hardware/IP-pool confound is refuted. If the control counts rise to the experimental level, the Section 4.1 group effect is an artifact of the deployment differences rather than the Ethereum node.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The paper's headline result (Section 4.1, Table 2) is a GLMM fixed effect for 'Group (Experimental)' of beta_1 = 1.111, SE = 0.008, z = 147.289, p < 0.001, interpreted as evidence that running an Ethereum P2P node attracts elevated reconnaissance. The load-bearing assumption is that control and experimental groups differ only in the presence of the Ethereum node. Table 1 violates this: controls are m7/6i.large with 128GB disk, while experimental nodes are r7/6i.xlarge with 2500GB disk. The GLMM includes a random intercept for the five AWS regions, but it does not include instance type, AWS IP pool, or a per-VP random intercept. With only one control and one experimental public IP per region, the group coefficient is fully confounded with any systematic difference between the two sets of IPs, such as different /24 allocations or different prior scan history. If the experimental IPs happen to fall in more heavily scanned address blocks, the model would attribute the resulting higher attack count to the Ethereum node even if the node itself contributed nothing. This is not an internal contradiction, but it is a missing counterfactual: the design does not rule out the most plausible alternative explanation for the elevated counts. The independent port-scan result (25.68% of live nodes with open ports) supports exposure, but it does not establish an elevated attack rate. The absence of released data and code prevents an independent check of IP-pool balance or raw count distributions.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper reports a two-month measurement study in which the authors placed T-Pot honeypots on ten AWS EC2 instances across five regions, with five 'control' honeypots and five 'experimental' honeypots that additionally ran Ethereum beacon nodes. The central claim is that Ethereum P2P nodes receive significantly more reconnaissance and attack traffic than matched controls: Section 4.1 reports a GLMM fixed effect for the experimental group of beta = 1.111 (SE = 0.008, z = 147.289, p < 0.001). The paper also reports targeted HTTP URI requests, a more concentrated distribution of SSH login attempts against the experimental group, and an Internet-wide scan of 6,184 Ethereum nodes showing that 25.68% had at least one open non-P2P port. The authors conclude that running a P2P node increases a host's attack surface and recommend network-layer mitigations for decentralized networks.","tokens_in":11365,"tokens_out":3850,"duration_ms":41497,"significance":"If the causal interpretation is warranted, the finding is of practical interest to operators of Ethereum and other P2P nodes: it would show that merely participating in the P2P overlay attracts materially higher reconnaissance traffic and that many existing nodes expose additional administrative ports. The paper also offers a potentially replicable honeypot-plus-node measurement design and contributes a useful descriptive scan of the live Ethereum node population. However, the headline causal claim rests on the comparability of the experimental and control groups, and the manuscript's own Table 1 shows they differed in instance type and disk size. With only one control and one experimental public IP per region, the GLMM group coefficient is inseparable from IP-pool and instance-reputation effects. The independent port-scan evidence documents exposure but does not by itself establish elevated attack rates. The absence of released data and code also prevents independent verification of IP-pool balance and raw count distributions.","major_comments":[{"comment":"The central claim that Ethereum nodes are targeted more than controls is supported by a GLMM whose group fixed effect is fully confounded with differences in instance type and IP-pool reputation. Table 1 shows the experimental group used r7/6i.xlarge instances with 2500 GB disks while the control group used m7/6i.large instances with 128 GB disks. Since there is only one control and one experimental public IP per region, any systematic difference between the two IP allocations—such as different /24 ranges, prior scan history, or cloud reputation—will be absorbed by the 'Group (Experimental)' coefficient. The model adjusts only for region, not for instance type, IP pool, or a per-VP random intercept, so it cannot rule out the most plausible non-Ethereum explanations for the elevated attack counts. This is load-bearing for the paper's headline finding and must be addressed, either with additional data that separate VP-level effects or by reframing the claim as a descriptive association with the specific IPs used.","section":"Section 4.1, Table 1"},{"comment":"The GLMM is reported with 100,000 observations from only 10 VPs over two months, but the manuscript never defines the aggregation unit or the temporal resolution of those observations. With five experimental and five control servers, a z-statistic of 147.289 cannot be taken at face value unless the model properly accounts for repeated measurements within each VP. The paper also uses the random-effects variance (sigma^2 = 0.050, SE = 0.030) to argue that regional variability is small and that the fixed effect explains the variability, but with only five regions this variance estimate is highly uncertain. The authors should report the number of repeated observations per VP, the correlation structure assumed, and sensitivity of the coefficient to excluding individual VPs.","section":"Section 4.1, Table 2"},{"comment":"The 'targeting ratio' used to compare experimental and control groups for URI request categories is descriptive, with no confidence intervals, significance tests, or adjustment for multiple comparisons. The ratio of experimental to control counts can exceed 1 simply because the control honeypots attract a large baseline of generic scanning traffic, so the numerator and denominator are not independent benchmarks of targeted behavior. Given that the earlier GLMM already reports a strong overall group difference, the URI analysis should at least present per-category tests or a clear statement that the figure is illustrative rather than inferential.","section":"Section 4.2, Figure 4"},{"comment":"The port-scan claim that 25.68% of live Ethereum nodes have at least one open port beyond their P2P ports is based on scanning only the top 100 ports from the authors' honeypot data plus default RPC/P2P ports. The manuscript does not list those 100 ports, and it is unclear whether the scan covered all common administrative and monitoring ports or only a subset. The paper also reports 6,185 nodes identified but uses 6,184 as the denominator, a numerical inconsistency that should be corrected. The scan result supports exposure, but its completeness and precision should be clarified before it is used to generalize the threat assessment to the wider P2P network.","section":"Section 4.4"}],"minor_comments":[{"comment":"There are several typos and duplicated words, including 'attributable to to geographic differences' and 'variability can can be attributed' in Section 4.1; these should be corrected during revision.","section":"Throughout"},{"comment":"References [9] and [10] cite the same paper in different formats; this duplicate citation should be consolidated.","section":"References"},{"comment":"The paper says 'we identified 6,185 active beacon nodes' but then reports the denominator as 6,184 in the 25.68% calculation; the correct count should be stated consistently.","section":"Section 4.4"},{"comment":"The figure numbering is confusing: the main text refers to 'Figure 7' for the top-50 ports and then to 'Figure 7 in the Appendix' for the full distribution, and the same figure appears in the supplementary results. The figures should be renumbered and referenced unambiguously.","section":"Appendix C"},{"comment":"The authors state that the AMIs are available as artifacts, but they do not provide a data availability statement for the raw honeypot logs, P2P session data, or scan results. Releasing aggregated count data would substantially strengthen the reproducibility of the main statistical claims.","section":"Data Availability"}],"recommendation":"major_revision","confidential_remarks":"The paper reports a measurement study with a plausible central hypothesis, and the descriptive findings on port exposure are useful. However, the main statistical comparison does not currently control for the most obvious confound—the systematic difference between the experimental and control AWS instances—and with one IP per group per region the group effect is not identifiable as an Ethereum-node effect. I would like to see either additional data collection that addresses VP-level confounding, an explicit sensitivity analysis, or a careful reframing of the contribution as descriptive measurement rather than causal evidence of node-specific targeting. The paper does not appear to have any internal inconsistency that would warrant rejection, and the limitations section is candid about the need for future broader deployments, but the current evidence is not yet sufficient for the strength of the abstract's claims."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"You should know two things about this paper. First, it's the first all-port honeypot study of Ethereum P2P nodes under proof-of-stake, and it includes a useful port scan of 6,185 live nodes. Second, the headline statistical claim—that Ethereum nodes get attacked more than controls—is plausible but not airtight, because the treatment and control groups differ in instance type and disk, and the model can't separate the node effect from IP-pool reputation.\n\nWhat's genuinely new: prior work focused on the RPC port under proof-of-work. This paper runs full honeypots on all ports, deploys beacon nodes across five regions, and shows that RPC and discovery ports are still targeted after the PoS switch. The port scan is the strongest empirical contribution: 25.68% of live nodes have an open port beyond P2P, including SSH on 13.63% and RPC on about 3%. That's a concrete, reproducible finding about the current network. The paper is honest about being an initial study and lists limitations.\n\nThe soft spots are real but not fatal. The GLMM with beta=1.111, z=147, p<0.001 looks impressive, but with only five regions and one experimental IP per region, the group coefficient is confounded with any systematic difference between the two IP sets—instance type, disk size, AWS allocation. The high z-score is partly an artifact of treating repeated daily counts as independent; the effective sample size is small. That doesn't invalidate the finding, but it means the \"elevated attacks\" claim rests on a weak design. The port-scan result stands on its own and supports the broader exposure claim, but it doesn't measure attack rates.\n\nAlso, no data or code released, which prevents anyone from checking the raw counts or IP-pool balance. That's a fixable issue for a revised version.\n\nWho's this for? Network security and blockchain measurement folks. It's a reasonable first pass, not a definitive quantification. I'd send it to peer review—with a request for the authors to address the confounding or soften the claim to match the design.","headline":"A plausible but not airtight measurement study; the port scan is the strongest part, while the GLMM treatment effect is confounded by IP-pool differences.","tokens_in":11910,"tokens_out":1559,"would_cite":true,"duration_ms":15377,"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":"Running an Ethereum P2P node draws significantly more reconnaissance attacks than a comparable honeypot.","keywords":["P2P overlay networks","Ethereum nodes","reconnaissance attacks","honeypots","port scanning","attack surface","proof-of-stake","network measurement"],"falsifier":"Repeat the two-month deployment with identical instance types, disk sizes, and randomized IP assignment for experimental and control servers in the same regions; if the attack-count gap disappears or falls to background noise, the claim that the P2P node drives the elevation would be refuted. An independent random sample of live Ethereum nodes, port-scanned by a second party, could also test the 25.68% open-port rate; a rate close to the ordinary cloud-host baseline would undermine the generalization.","tokens_in":10843,"feed_emoji":"🛡️","tokens_out":13564,"duration_ms":106255,"temperature":0.7,"pith_summary":"This paper tests whether joining a public peer-to-peer (P2P) network makes a host a more attractive target for internet attackers. The authors ran real Ethereum beacon nodes next to full-port honeypots on the same machines, and honeypot-only control machines in five world regions, for two months. The Ethereum nodes received a substantially higher volume of attacks than the controls—about three times higher in the fitted model—and the extra traffic aimed at P2P discovery ports, RPC ports, SSH, and cloud-credential endpoints. A port scan of 6,184 live Ethereum nodes found that 25.68% exposed at least one non-P2P port, so the elevated risk is not confined to the authors' own deployment. If the finding holds, operating P2P infrastructure carries a concrete security cost, and node operators should harden their hosts accordingly.","feed_headline":"Ethereum P2P nodes draw far more attacks than plain honeypots","feed_subtitle":"Two-month honeypot study: Ethereum nodes see roughly triple the scans; a quarter of live nodes expose extra ports.","key_machinery":"The load-bearing mechanism is a paired deployment: each experimental server ran a real Ethereum beacon node (a consensus client paired with an execution client) alongside a full-port honeypot platform, while each control server ran only the honeypot platform, with one pair of servers in each of five geographically distributed cloud regions. This makes the presence of the Ethereum node the intended difference between groups and lets every inbound interaction with the honeypot containers be logged as an attack. The statistical workhorse is a generalized linear mixed model with a log-transformed attack count as the response, experimental-versus-control status as a fixed effect, and geographic region as a random effect; the coefficient $\\hat{\\beta}_1 = 1.111$ is the paper's estimate of the attack increase attributable to running a node. The complement is an external TCP port scan of 6,184 live Ethereum nodes, which extends the exposure finding from the authors' own servers to the wider network.","core_discovery":"The central discovery is that Ethereum P2P nodes are disproportionately targeted by reconnaissance, not merely exposed to background internet noise. In a generalized linear mixed model that adjusts for geographic region, the experimental group's log-transformed attack count was significantly higher than the control group's ($\\hat{\\beta}_1 = 1.111$, $SE = 0.008$, $z = 147.289$, $p < 0.001$), corresponding to roughly three times the attack count. The additional attacks were not generic background traffic: they included HTTP requests for `.env` files and cloud metadata credentials, more concentrated SSH login attempts (Gini 0.43 versus 0.25), and scans of P2P discovery and RPC ports even after Ethereum's shift to proof-of-stake. A TCP scan of 6,184 live beacon nodes showed that 25.68% had at least one open port beyond their P2P ports, most commonly SSH (13.63%) and HTTP/HTTPS (about 12.7% each), with 2.99% exposing the default RPC port (8545). The paper concludes from these results that P2P overlay nodes are treated by attackers as valuable persistent hosts, and that host-level and network-level hardening is warranted.","pith_inferences":["If public visibility in the peer table is what attracts scans, other P2P networks with openly enumerable peer lists—Bitcoin, IPFS, file-sharing overlays—likely carry a similar attack premium; the paper only measured Ethereum, so this is an extrapolation.","The ASN-divergence result suggests a concrete, testable defensive rule: block or rate-limit ASNs with heavy scanning but low peer density, then measure how much attack traffic is removed without reducing peer connectivity.","The 25.68% figure comes from nodes listed by one popular explorer; an independent random sample of the live network would be a stronger test and could reveal whether open RPC ports correlate with client version or node age.","A longitudinal version of this measurement could serve as an early-warning signal for decentralized infrastructure: a sudden rise in nodes with open RPC ports might precede a wave of wallet-draining exploits."],"forward_implications":["Node operators should treat a P2P beacon node as a public-facing service and apply host hardening—key-only SSH, firewalled RPC, credential hygiene—because the node itself attracts reconnaissance.","Because P2P discovery ports are targeted even under proof-of-stake, the node's networking stack is a live attack surface, so client updates and patching matter even when the RPC port is closed.","Because attacks originate disproportionately from networks other than those hosting Ethereum nodes, operators can filter or throttle high-scan ASNs without losing many legitimate peers.","Exposed administrative ports on 25.68% of live nodes mean many existing operators are one vulnerability away from compromise, making the measured attack premium a practical risk rather than a theoretical one.","The observed 20% peer loss during an active attack shows that aggressive scanning alone can disrupt beacon duties, so reconnaissance is itself a denial-of-service vector."],"supporting_citations":[{"why":"Establishes the prior result that attackers target Ethereum nodes through exposed RPC ports, which the present study extends to all ports.","marker":"[9]"},{"why":"Documents real cryptocurrency-stealing attacks against Ethereum RPC endpoints, the threat model that motivates the node-as-target hypothesis.","marker":"[8]"},{"why":"Shows that simple honeypots can profile attackers hitting Ethereum's RPC port; the present study broadens this to full-port honeypots.","marker":"[18]"},{"why":"Provides evidence that cloud IPs receive elevated background traffic, motivating the regional control-group adjustment in the model.","marker":"[28]"},{"why":"Supplies the operational definition of an attack as a logged interaction with a honeypot container.","marker":"[21]"},{"why":"Is the honeypot platform deployed on every experimental and control server, the study's data-collection instrument.","marker":"[36]"},{"why":"Is the consensus client whose P2P session data and attestation simulator produce the node-side measurements.","marker":"[33]"},{"why":"Is the execution client paired with the consensus client in the deployed beacon nodes.","marker":"[26]"}],"fun_headline_variants":["Ethereum P2P nodes draw 3x more scans than controls","P2P honeypots reveal targeted recon, not internet noise","Triple recon attacks hit Ethereum nodes, with open ports","Ethereum peers see 3x recon and extra exposed services","Ethereum nodes hit by triple scans and exposed ports"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The claim that the Ethereum node itself causes the elevated attacks assumes the experimental and control servers are otherwise comparable; the experiment gave the node group larger instances with larger disks, so if instance size or cloud-assigned IP reputation changes inbound scan volume, the measured effect would be overstated.","fun_headline_variants_meta":{"raw":{"variants":["Ethereum P2P nodes draw 3x more scans than controls","P2P honeypots reveal targeted recon, not internet noise","Triple recon attacks hit Ethereum nodes, with open ports","Ethereum peers see 3x recon and extra exposed services","Ethereum nodes hit by triple scans and exposed ports"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000707,"raw_usage":{"total_tokens":3179,"prompt_tokens":930,"completion_tokens":2249,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":546,"completion_tokens_details":{"reasoning_tokens":2160}},"tokens_in":546,"tokens_out":2249,"duration_ms":15487,"temperature":1.0,"reasoning_tokens":2160,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T15:04:58.519597+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Repeat the two-month deployment with identical instance types, disk sizes, and randomized IP assignment for experimental and control servers in the same regions; if the attack-count gap disappears or falls to background noise, the claim that the P2P node drives the elevation would be refuted. An independent random sample of live Ethereum nodes, port-scanned by a second party, could also test the 25.68% open-port rate; a rate close to the ordinary cloud-host baseline would undermine the generalization.","supporting_citations":[{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Establishes the prior result that attackers target Ethereum nodes through exposed RPC ports, which the present study extends to all ports."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Documents real cryptocurrency-stealing attacks against Ethereum RPC endpoints, the threat model that motivates the node-as-target hypothesis."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Shows that simple honeypots can profile attackers hitting Ethereum's RPC port; the present study broadens this to full-port honeypots."},{"cited_title":"2023.{DScope}: A {Cloud-Native} Internet Telescope","cited_arxiv_id":null,"evidence_quote":"Provides evidence that cloud IPs receive elevated background traffic, motivating the regional control-group adjustment in the model."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Supplies the operational definition of an attack as a logged interaction with a honeypot container."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Is the honeypot platform deployed on every experimental and control server, the study's data-collection instrument."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Is the consensus client whose P2P session data and attestation simulator produce the node-side measurements."},{"cited_title":null,"cited_arxiv_id":null,"evidence_quote":"Is the execution client paired with the consensus client in the deployed beacon nodes."}],"review_version":1}