Ethereum logo

Security

We approach security from the point of view of the DHT's Keyspace Density.

The following plots examine the peer distribution within the keyspace, aiding in the identification of potential Sybil and eclipse attacks.

Keyspace Density

Every object indexed by discv5 requires a binary identifier. In the discv5 implementation, peers are identified by their NodeID (extracted from their ENR) which is the `keccak256` hash of its uncompressed `secp256k1` public key. This identifier determines the location of an object within the XOR keyspace.

Keyspace Regions Population

Keyspace Regions Population

  • Description: The plot illustrates the number of online peers whose Kademlia identifier matches each prefix for all prefixes of a given size, for a given network crawl. Each bar is one prefix (a keyspace region). We use one crawl of our Nebula crawler every 12 hours and count the online peers that it found in the DHT routing tables. Since the density of keyspace regions follows a Poisson distribution, it is expected to observe some regions that are significantly more populated than others. On Ethereum, the plot includes all nodes in the discv5 DHT, also the nodes of other networks.

  • How to read the plot: The selected depth indicates the prefix size. There are 2^i distinct prefixes at depth i. Select a depth, or select a time to show one of the 32 most recent crawls.

  • What to look out for: The green dashed line represents the expected density per region: the number of peers divided by the number of regions. A bar significantly exceeding the expected density suggests that a region of the keyspace might be under an eclipse attack, especially if the value is above the risk threshold (red dashed line). If the peer IDs are random, the chance that any region is above the risk threshold is less than 0.1%.

Data is provided as is, without warranty. Scraping and automated bulk extraction are not permitted. See our Terms of Use.

The plot shows how many peers are included in a particular region of the keyspace. Too many peers within one region indicate a potential issue.

Keyspace Density Distribution

Keyspace Density Distribution

  • Description: A keyspace region is the set of Kademlia identifiers that share a prefix, and its population is the number of online peers in it. The population of the regions follows a Poisson distribution, which can make identifying outliers challenging. This plot counts the number of regions for each population size (x-axis) and facilitates the identification and analysis of outliers. While it is normal for some regions to have populations above the average, the plot enables us to quantify these deviations. We use one crawl of our Nebula crawler every 12 hours and count the online peers that it found in the DHT routing tables. On Ethereum, the plot includes all nodes in the discv5 DHT, also the nodes of other networks.

  • How to read the plot: The green line represents the expected number of regions for each population size. The depth is the prefix size: there are 2^i regions at depth i. Note that the Poisson distribution is more evident at greater depths (longer prefix size), while analyzing data at lower depths provides limited insights. It is recommended to read the plot for depths between 9 and 13. Select a depth, or select a time to show one of the 32 most recent crawls.

  • What to look out for: If an isolated bar appears on the far right beyond the risk threshold (red dashed) line, it may indicate a potential eclipse attack, warranting further investigation. If the peer IDs are random, the chance that any region is above the risk threshold is less than 0.1%.

Data is provided as is, without warranty. Scraping and automated bulk extraction are not permitted. See our Terms of Use.

The plot shows the distribution of the PeerIDs across the Poisson curve. Too many PeerIDs outside the curve indicate a potential issue.

Stale Node Records

These plots depict the count of node records stored within each node’s routing table and made accessible through the discv5 DHT. These node records serve as a mechanism through which nodes discover new remote nodes in the network.

Stale Records - Mainnet

Stale Records - Mainnet

Ensuring reachability of referenced nodes shared within the network is critical.

Shows the number of node records in the routing tables of all nodes that our Nebula crawler visited, per crawl. Reachable counts the records of nodes that the crawler could reach, Unreachable the records of nodes that it could not reach (stale records). A node is reachable if it answered the discv5 requests of the crawler without an error. Note that nodes running behind a NAT are counted as unreachable even though they may be online. For instance, if a node’s record is present in the routing tables of 100 other nodes and the node is reachable, the plot will reflect an increase of 100 in the Reachable series.

On 2026-01-12 (the vertical line), we changed the deduplication logic when queuing peers to crawl. We crawl the discv5 DHT which indexes Ethereum Node Records. Each record contains a NodeID among other things. Before that date we skipped crawling records whose NodeID we had already seen and crawled before. However, the newly discovered ENR for the same NodeID could in theory contain more up-to-date information about the node's network addresses. Therefore, after that date we started to probe every ENR that we can find even if we had probed the NodeID before during that same network crawl.

Data is provided as is, without warranty. Scraping and automated bulk extraction are not permitted. See our Terms of Use.

Reachable vs Unreachable DHT Records Over Time

Stale Records - all discv5

Stale Records - all discv5

Ensuring reachability of referenced nodes shared within the network is critical.

Shows the number of node records in the routing tables of all nodes that our Nebula crawler visited, per crawl. Reachable counts the records of nodes that the crawler could reach, Unreachable the records of nodes that it could not reach (stale records). A node is reachable if it answered the discv5 requests of the crawler without an error. Note that nodes running behind a NAT are counted as unreachable even though they may be online. For instance, if a node’s record is present in the routing tables of 100 other nodes and the node is reachable, the plot will reflect an increase of 100 in the Reachable series.

This chart counts all nodes in the discv5 DHT, also the nodes of other networks.

On 2026-01-12 (the vertical line), we changed the deduplication logic when queuing peers to crawl. We crawl the discv5 DHT which indexes Ethereum Node Records. Each record contains a NodeID among other things. Before that date we skipped crawling records whose NodeID we had already seen and crawled before. However, the newly discovered ENR for the same NodeID could in theory contain more up-to-date information about the node's network addresses. Therefore, after that date we started to probe every ENR that we can find even if we had probed the NodeID before during that same network crawl.

Data is provided as is, without warranty. Scraping and automated bulk extraction are not permitted. See our Terms of Use.

Reachable vs Unreachable DHT Records Over Time

Related Work

Blog posts, papers and talks by the ProbeLab team about Ethereum.

YouTube thumbnail: 7EnDYwcMGq4
Talk

devp2p, libp2p, ethp2p - Untangling Ethereum’s Networking Stack

Ethereum's execution layer runs devp2p: RLPx transport, capability negotiation, and request-response subprotocols carrying the mempool and sync. Its consensus layer runs libp2p, a modular general-purpose …

YouTube thumbnail: tB2k2axL6DE
Talk

What can Ethereum learn from other networks?

Ethereum's peer-to-peer layer was designed for a protocol that looked very different from the one we run today, and it did its job well. But …

ArXiv Preprint
Paper

Quantifying Ethereum Energy Consumption via Network Mapping

Ethereum’s electricity use fell by about 99.95% after the network moved from proof of work to proof of stake. Service providers still need to report …

From rawpixel.com / Freepik
Blog post

ProbeLab's 2025 Review and 2026 Outlook

What we've achieved in 2025 and what we're targeting in 2026

MIDDLEWARE '25 Conference Paper
Paper

PANDAS: Peer-to-peer, Adaptive Networking Allowing Data Availability Sampling within Ethereum Consensus Timebounds

Layer-2 protocols such as rollups can help address Ethereum's throughput limits. An efficient data availability layer is key for layer-2 support in Ethereum, but broadcast …

SIGMETRICS '26 Conference Paper
Paper

Multiple Sides of 36 Coins: Measuring Peer-to-Peer Infrastructure Across Cryptocurrencies

Blockchain technologies underpin an expanding ecosystem of decentralized applications, financial systems, and infrastructure. However, the fundamental networking layer that sustains these systems, the peer-to-peer (P2P) …