Pith. sign in

REVIEW 4 major objections 5 minor 1 cited by

Unveiling Ethereum's P2P Network: The Role of Chain and Client Diversity

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

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

Pith's one-line read 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.

desk verdict 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. read the letter →

arxiv 2501.16236 v1 pith:X36MREQA submitted 2025-01-27 cs.NI

Jiahao Luo This is my paper · ORCID
classification cs.NI
keywords EthereumP2Pnetworkdevp2pnodediscoveryclientdiversitychainmeasurementGeth
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

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.

What carries the argument

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.

What would settle it

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.

Watch

Extended reading notes

Core claim

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.

Load-bearing premise

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.

Editorial extensions

If this is right

  • 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.

Reading between the lines

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

  • 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.
Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

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

Referee Report

4 major / 5 minor

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.

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 (4)
  1. [§4.5, Table 7, Appendix A] 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.
  2. [§4.5, chain diversity comparison] 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.
  3. [§4.4, Figure 5, Table 5] 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.
  4. [§4.3, Table 3] 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.
minor comments (5)
  1. [§4.1 vs. Appendix F] 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.
  2. [Figure 6] 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.
  3. [§4.2] 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.
  4. [Table 2] 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.
  5. [§4.1, measurement window] 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.

Circularity Check

0 steps flagged · score 0.0 of 10

No circularity: the paper reports direct measurements; the main validity concern is representativeness of the modified measurement node, not a derivation that reduces to its own inputs.

full rationale

This is an empirical measurement paper, not a derivation. The headline results—78.05% of peers advertising eth-68, 24.5% with mainnet chain parameters (network ID 1), 13.07% fully compatible peers at 1M dial attempts, and 947 attempts per live peer—are direct observations of Status messages, discovery responses, and dial outcomes, with no free parameter fitted to define the target quantities. The protocol-compatibility classifications are based on stated fields (sub-protocols, network ID, genesis hash, fork ID) and are computed by straightforward decoding of peer messages. The dialing experiment in Table 7 reports measured proportions at increasing attempt counts rather than predicting a quantity from a fitted model. The strongest caveat is external validity: Appendix A describes a heavily modified Geth node with extreme discovery parameters, so the sampled peer population and the 947-attempt average may not represent a stock client's view of the network. That is a measurement-representativeness or confound concern, not circularity. There is no self-citation chain, no imported uniqueness theorem, and no equation in the paper that is equivalent by construction to its inputs. Accordingly, the circularity score is 0.

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

This is an empirical measurement study with no fitted free parameters and no invented theoretical entities. The central claims rest on three domain assumptions about representativeness, comparability, and log fidelity.

assumptions (3)
  • domain assumption The modified measurement node's DHT and peer sample are representative of the network as a whole.
    The paper derives all statistics from this single heavily modified node and assumes they generalize; if the aggressive discovery skews the sample, the percentages and efficiency conclusions change.
  • domain assumption The 2018 Kim et al. measurements are directly comparable to the present post-merge measurements.
    The 2018 study used different measurement techniques; a direct comparison of 54.5% and 13.07% assumes the two methodologies are comparable.
  • domain assumption The logs captured by the instrumented client accurately reflect all devp2p messages and internal state changes.
    The analysis interprets message counts, timeouts, and client states based on the instrumented client's logging; if the logging is incomplete or biased, the conclusions would be affected.

how reviews work

0 comments
Cite this review

Pith. "Pith review of Unveiling Ethereum's P2P Network: The Role of Chain and Client Diversity." pith.science (2026). https://pith.science/paper/X36MREQA

@misc{pith2026250116236,
  author       = {Pith},
  title        = {Pith review of: Unveiling Ethereum's P2P Network: The Role of Chain and Client Diversity},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/X36MREQA}},
  note         = {Machine review of arXiv:2501.16236}
}
read the original abstract

The Ethereum network, built on the devp2p protocol stack, was designed to function as a "world computer" by supporting decentralized applications through a shared P2P infrastructure. However, the proliferation of blockchain forks has increased network diversity, complicating node discovery and reducing efficiency. Ethereum mainnet nodes cannot easily distinguish between peers from different blockchains until after establishing an expensive TCP connection, encryption, and protocol handshake. This inefficiency is further worsened by client diversity, where differences in software implementations cause protocol incompatibilities and connection failures. This paper introduces a monitoring tool that tracks devp2p message exchanges and client statuses to analyze connection dynamics and protocol variations. Our findings highlight issues such as inefficiencies in node discovery and client incompatibility, including timeouts in Geth during the discovery process. The study emphasizes the need to consider chain and client diversity when assessing the health and performance of the post-merge Ethereum network.

Figures

Figures reproduced from arXiv: 2501.16236 by the authors.

Figure 1
Figure 1. Overview of the Ethereum network architecture. [PITH_FULL_IMAGE:figures/full_fig_p003_1.png] view at source ↗
Figure 2
Figure 2. The architecture of measurement system design. [PITH_FULL_IMAGE:figures/full_fig_p004_2.png] view at source ↗
Figure 3
Figure 3. Messages and tasks per hour, including a brief shut [PITH_FULL_IMAGE:figures/full_fig_p004_3.png] view at source ↗
Figures from the paper (3 more)
Figure 4
Figure 4. Figure 4: Clients reporting breach of protocol Upon further investigation, we found that the majority of Breach of protocol disconnects were issued by Nethermind clients, specifi￾cally versions 1.25.4 and 1.26.0. As shown in [PITH_FULL_IMAGE:figures/full_fig_p006_4.png]
Figure 5
Figure 5. Figure 5: Node lengths for a FindNode Request An important observation is that, as shown in [PITH_FULL_IMAGE:figures/full_fig_p006_5.png]
Figure 6
Figure 6. Figure 6: Chain parameters distribution. Columns represent [PITH_FULL_IMAGE:figures/full_fig_p007_6.png]

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

  1. Unraveling Ethereum's Mempool: The Impact of Fee Fairness, Transaction Prioritization, and Consensus Efficiency

    cs.CR 2025-06 conditional novelty 4.0 of 10

    Empirical evidence from live Geth and Prysm nodes shows Ethereum's post-EIP-1559 mempool still favors high fees, while high congestion correlates with longer finalization times.

Reference graph

Works this paper leans on

55 extracted references · 48 canonical work pages · cited by 1 Pith paper

  1. [1]

    Ether Alpha. 2024. Improve Ethereum’s resilience by using a minority client. https://clientdiversity.org/. Accessed: 2024-05-11

    work page 2024

  2. [2]

    Mega Apriani and Riri Fitri Sari. 2021. Performance Comparison of Spongent and Photon Hashing Algorithms in Ethereum-based Blockchain System. In 2021 7th International Conference on Electrical, Electronics and Information Engineering (ICEEIE). 564–569. https://doi.org/10.1109/ICEEIE52663.2021.9616831

    work page arXiv 2021

  3. [3]

    ChainList. 2021. Helping users connect to EVM powered networks. https: //chainlist.org/. Accessed: 2024-04-10

    work page 2021

  4. [4]

    Matthias Seitz1 Dan Cline. 2024. Add an ability to change P2P listening address. https://github.com/paradigmxyz/reth/pull/4849. Accessed: 2024-04-10

    work page 2024

  5. [5]

    etclabscore. N/A. GitHub - etclabscore/core-geth: A highly configurable Go implementation of the Ethereum protocol. https://github.com/etclabscore/core- geth GitHub repository

    work page

  6. [6]

    ETCMC DAO. 2024. ETCMC - Decentralise the Ethereum Classic Network. https://etcmc.org/. Accessed on May 6, 2024

    work page 2024

  7. [7]

    Ethereum. 2015. Introduction to Smart Contracts. https://ethereum.org/en/ developers/docs/smart-contracts/. Accessed: 2024-04-10

    work page 2015

  8. [8]

    Ethereum. 2018. Whisper: Ethereum Communication Protocol. https://github. com/ethereum/whisper. Accessed: 2024-04-10

    work page 2018

Show all 55 references
  1. [9]

    Ethereum. 2024. devp2p: Ethereum peer-to-peer networking specifications. https: //github.com/ethereum/devp2p. Accessed: 2024-04-10

    2024

  2. [10]

    Ethereum. 2024. Finnode message in Ethereum Node Discovery Proto- col v4. https://github.com/ethereum/devp2p/blob/master/discv4.md#findnode- packet-0x03. Accessed: 2024-04-30

    2024

  3. [11]

    Ethereum. 2024. go-ethereum: Official Go implementation of the Ethereum protocol. https://github.com/ethereum/go-ethereum. Accessed: 2024-04-10

    2024

  4. [12]

    Ethereum Execution Specs. 2023. Mainnet Upgrade: Paris. https://github. com/ethereum/execution-specs/blob/master/network-upgrades/mainnet- upgrades/paris.md

    2023

  5. [13]

    Ethereum Execution Specs. 2024. Cancun Network Upgrade Specifi- cation. https://github.com/ethereum/execution-specs/blob/master/network- upgrades/mainnet-upgrades/cancun.md

    2024

  6. [14]

    Ethereum Foundation. 2023. go-ethereum: P2P Discovery Lookup Code. https://github.com/ethereum/go-ethereum/blob/ 65e5ca7d8126f7a8c708f8affb64f16c22cc63c0/p2p/discover/lookup.go#L142- L152. Accessed: 2024-10-05

    2023

  7. [15]

    Ethereum Foundation. 2024. Ethereum Execution Client Specifications. https: //github.com/ethereum/execution-specs. Accessed: 2024-04-10

    2024

  8. [16]

    Ethereum Foundation. 2024. Ethereum Snapshot Protocol (SNAP). https://github. com/ethereum/devp2p/blob/master/caps/snap.md. Accessed: 2024-10-05

    2024

  9. [17]

    Ethereum Foundation. 2024. Ethereum Wire Protocol. https://github.com/ ethereum/devp2p/blob/master/caps/eth.md. Accessed: 2024-10-05

    2024

  10. [18]

    Ethernodes. 2024. Ethereum mainnet statistics. https://ethernodes.org/. Accessed: 2024-05-14

    2024

  11. [19]

    Etherscan. 2024. Ethereum node tracker. https://etherscan.io/nodetracker. Ac- cessed: 2024-05-14

    2024

  12. [20]

    Ethereum Foundation. 2022. The Merge. https://ethereum.org/en/roadmap/ merge/

    2022

  13. [21]

    Swarm Foundation. 2019. Swarm: Decentralised Data Storage and Distribution Technology. https://www.ethswarm.org/. Accessed: 2024-04-10

    2019

  14. [22]

    Yue Gao, Jinqiao Shi, Xuebin Wang, Qingfeng Tan, Can Zhao, and Zelin Yin. 2019. Topology measurement and analysis on ethereum p2p network. In 2019 IEEE Symposium on Computers and Communications (ISCC). IEEE, 1–7

    2019

  15. [23]

    Lioba Heimbach, Lucianna Kiffer, Christof Ferreira Torres, and Roger Watten- hofer. 2023. Ethereum’s Proposer-Builder Separation: Promises and Realities. arXiv:2305.19037 [cs]

    2023 arXiv

  16. [24]

    Sebastian Henningsen, Daniel Teunis, Martin Florian, and Björn Scheuer- mann. 2019. Eclipsing ethereum peers with false friends. arXiv preprint arXiv:1908.10141 (2019)

    2019 arXiv

  17. [25]

    Hwanjo Heo and Seungwon Shin. 2021. Behind Block Explorers: Pub- lic Blockchain Measurement and Security Implication. In 2021 IEEE 41st International Conference on Distributed Computing Systems (ICDCS). IEEE, DC, USA, 216–226. https://doi.org/10.1109/ICDCS51616.2021.00029

    2021

  18. [26]

    Hwanjo Heo, Seungwon Woo, Taeung Yoon, Min Suk Kang, and Seungwon Shin

  19. [27]

    Don Johnson, Alfred Menezes, and Scott Vanstone. 2001. The elliptic curve digital signature algorithm (ECDSA). International journal of information security 1 (2001), 36–63

    2001

  20. [28]

    James Kempton. 2024. EIP-7636: Extension of EIP-778 for "client" ENR Entry [DRAFT]. https://eips.ethereum.org/EIPS/eip-7636. [Online serial]

    2024

  21. [29]

    Lucianna Kiffer, Asad Salman, Dave Levin, Alan Mislove, and Cristina Nita- Rotaru. 2021. Under the Hood of the Ethereum Gossip Protocol. In Financial Cryptography and Data Security, Nikita Borisov and Claudia Diaz (Eds.). Vol. 12675. Springer Berlin Heidelberg, Berlin, Heidelb...

    2021 doi

  22. [30]

    Seoung Kyun Kim, Zane Ma, Siddharth Murali, Joshua Mason, Andrew Miller, and Michael Bailey. 2018. Measuring Ethereum Network Peers. In Proceedings of the Internet Measurement Conference 2018. ACM, Boston MA USA, 91–104. https://doi.org/10.1145/3278532.3278542

    2018

  23. [31]

    Kai Li, Yuzhe Tang, Jiaqi Chen, Yibo Wang, and Xianghong Liu. 2021. TopoShot: Uncovering Ethereum’s Network Topology Leveraging Replacement Transac- tions. In Proceedings of the 21st ACM Internet Measurement Conference. ACM, Virtual Event, 302–319. https://doi.org/10.1145/3487...

    2021

  24. [32]

    Kai Li, Yibo Wang, and Yuzhe Tang. 2021. DETER: Denial of Ethereum Txpool sERvices. In Proceedings of the 2021 ACM SIGSAC Conference on Computer and Communications Security (CCS ’21). Association for Computing Machinery, New York, NY, USA, 1645–1667. https://doi.org/10.1145/34...

    2021

  25. [33]

    Soo Hoon Maeng, Meryam Essaid, and Hong Taek Ju. 2020. Analysis of Ethereum Network Properties and Behavior of Influential Nodes. In 2020 21st Asia-Pacific Network Operations and Management Symposium (APNOMS). 203–207. https: //doi.org/10.23919/APNOMS50412.2020.9236965

    2020

  26. [34]

    Masoud, Yousef Jaradat, Ahmad Manasrah, Mohammad Alia, Khaled Suwais, and Sally Almanasra

    Mohammad Z. Masoud, Yousef Jaradat, Ahmad Manasrah, Mohammad Alia, Khaled Suwais, and Sally Almanasra. 2024. A Measurement Study of the Ethereum Underlying P2P Network.Computers, Materials & Continua 78, 1 (2024), 515–532. https://doi.org/10.32604/cmc.2023.044504

    2024

  27. [35]

    Matic Network. 2024. Official repository for the Polygon Blockchain. https: //github.com/maticnetwork/bor. Accessed: 2024-04-10

    2024

  28. [36]

    Petar Maymounkov and David Mazieres. 2002. Kademlia: A peer-to-peer informa- tion system based on the xor metric. In International Workshop on Peer-to-Peer Systems. Springer, 53–65

    2002

  29. [37]

    Matthias Seitz. 2024. Support external address in discv4 handle type. https: //github.com/paradigmxyz/reth/issues/4222. Accessed: 2024-04-10

    2024

  30. [38]

    Matthias Seitz1. 2024. Feature: Track Node Record. https://github.com/ paradigmxyz/reth/pull/4224. Accessed: 2024-04-10

    2024

  31. [39]

    Matthias Seitz2. 2024. Fix: Prevent Node Info Zero Address. https://github.com/ paradigmxyz/reth/pull/4268. Accessed: 2024-04-10

    2024

  32. [40]

    Péter Szilágyi. 2024. Connection Slot Exhaustion with Passive Nodes. https: //github.com/ethereum/go-ethereum/issues/29329#issuecomment-2031290591. Accessed: 2024-05-08

    2024

  33. [41]

    Péter Szilágyi and Felix Lange. 2019. EIP-2124: Fork identifier for chain compati- bility checks. https://eips.ethereum.org/EIPS/eip-2124. [Online serial]

    2019

  34. [42]

    Christof Ferreira Torres, Ramiro Camino, and Radu State. 2021. Frontrun- ner Jones and the Raiders of the Dark Forest: An Empirical Study of Fron- trunning on the Ethereum Blockchain. In 30th USENIX Security Symposium (USENIX Security 21). USENIX Association, 1343–1359. https:...

    2021

  35. [43]

    Marius van der Wijden. 2022. EIP-6122: Forkid checks based on timestamps. https://eips.ethereum.org/EIPS/eip-6122. [Online serial]

    2022

  36. [44]

    Liang Wang and Ivan Pustogarov. 2017. Towards Better Understanding of Bitcoin Unreachable Peers. arXiv:1709.06837 [cs]

    2017 arXiv

  37. [45]

    Yibo Wang, Wanning Ding, Kai Li, and Yuzhe Tang. 2023. Understanding ethereum mempool security under asymmetric dos by symbolic fuzzing. arXiv preprint arXiv:2312.02642 (2023)

    2023 arXiv

  38. [46]

    Ben Weintraub, Christof Ferreira Torres, Cristina Nita-Rotaru, and Radu State

  39. [47]

    Matt Whitehead. 2024. Use From field in a PING packet when creating a peer table entry. https://github.com/hyperledger/besu/pull/6225. Accessed: 2024-05-6

    2024

  40. [48]

    Matt Whitehead1. 2024. Only accept an address from a peer if it is a valid IP address. https://github.com/hyperledger/besu/pull/6439. Accessed: 2024-05-6

    2024

  41. [49]

    Gavin Wood et al. 2024. Ethereum: A Secure Decentralised Generalised Transac- tion Ledger. https://github.com/ethereum/yellowpaper

    2024

  42. [50]

    Wei Xia, Zhenzhen Li, Zhen Li, Gang Xiong, and Gaopeng Gou. 2021. EthSnif- fer: A Global Passive Perspective on Ethereum. In Blockchain and Trustworthy Systems, Hong-Ning Dai, Xuanzhe Liu, Daniel Xiapu Luo, Jiang Xiao, and Xi- angping Chen (Eds.). Vol. 1490. Springer Singapore...

    2021 doi

  43. [51]

    Aviv Yaish, Kaihua Qin, Liyi Zhou, Aviv Zohar, and Arthur Gervais. 2023. Specu- lative Denial-of-Service Attacks in Ethereum. Cryptology ePrint Archive, Paper 2023/956. https://eprint.iacr.org/2023/956 https://eprint.iacr.org/2023/956

    2023

  44. [52]

    Xiao Yi, Yuzhou Fang, Daoyuan Wu, and Lingxiao Jiang. 2022. BlockScope: Detecting and Investigating Propagated Vulnerabilities in Forked Blockchain Projects. arXiv preprint arXiv:2208.00205 (2022)

    2022 arXiv

  45. [53]

    id ": " ce85a9d87

    Chonghe Zhao, Yipeng Zhou, Shengli Zhang, Taotao Wang, Quan Z. Sheng, and Song Guo. 2024. DEthna: Accurate Ethereum Network Topology Discovery with Marked Transactions. arXiv:2402.03881 [cs] Conference acronym ’XX, June 03–05, 2018, Woodstock, NY Trovato et al. A Client Config...

    2024 arXiv

  46. [2022]

    In Proceedings of the 22nd ACM Internet Measurement Conference

    A Flash(Bot) in the Pan: Measuring Maximal Extractable Value in Private Pools. In Proceedings of the 22nd ACM Internet Measurement Conference. ACM, Nice France, 458–471. https://doi.org/10.1145/3517745.3561448

  47. [2023]

    In Proceedings 2023 Network and Distributed System Security Symposium

    Partitioning Ethereum without Eclipsing It. In Proceedings 2023 Network and Distributed System Security Symposium. Internet Society, San Diego, CA, USA. https://doi.org/10.14722/ndss.2023.24465

    2023

Pith tools

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