Ethereum logo

Consensus Layer Topology

discv5 DHT

Key metrics on network structure, geographic peer distribution, client diversity, and connection patterns across the Ethereum network. All metrics in this section refer to the Consensus Layer discv5 DHT.

Geographic Distribution

Node IP address to country, city, and autonomous system (ASN) mapping, based on data sourced from https://ipregistry.co/.

Peers By City Consensus

Peers By City

This map shows the online peers per city in the last crawl of the latest day. The city and its coordinates come from the IP address mapping of ipregistry.co. Peers without a known city are not on the map. The text below the map shows how many peers are not on the map.

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

Loading ...

Geolocation Over Time Consensus

Geolocation Over Time

Shows the number of online peers per country in each crawl. The six countries with the most peers in the selected time range have their own series. Other holds the rest, including the peers without a known country. The country of a peer comes from the IP address mapping of ipregistry.co. Select an agent type to show only the peers of that type.

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

DHT Server geolocation per agent version over time

Countries Distribution (24h) Consensus

Countries Distribution (24h)

Shows the online peers per country, as the average number per crawl in the 24 hours up to the latest crawl. The bars show the ten countries with the most peers by their two-letter country code. Hover over a bar to see the country name. other holds the rest, including the peers without a known country. The label on each bar is its share of all peers. The country of a peer comes from the IP address mapping of ipregistry.co. Select an agent type to show only the peers of that type.

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

Snapshot of active agents geolocation within the last 24hrs

Cities Over Time Consensus

Cities Over Time

Shows the number of online peers in the ten cities with the most peers over time. The other cities are in "Other". The city of a peer comes from the IP address mapping of ipregistry.co. Peers without a known city are not in this chart. Select an agent type to show only the peers of that type.

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

Online peers in the largest cities

Autonomous Systems Over Time Consensus

Autonomous Systems Over Time

Shows the number of online peers in the ten largest autonomous systems (ASNs) over time. The other ASNs are in "Other". The ASN of a peer comes from the IP address mapping of ipregistry.co. Peers without a known ASN are not in this chart. Select an agent type to show only the peers of that type.

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

Online peers in the largest autonomous systems (ASNs)

ASN Concentration Consensus

ASN Concentration

Shows how concentrated the online peers are in autonomous systems (ASNs). Only peers with a known ASN count. Select a view:

  • Largest ASNs: the share of the peers in the largest ASN and in the ten largest ASNs.
  • ASNs for 50%: the smallest number of ASNs that together host half of the peers. A low number means that a few network operators host much of the network.
  • HHI: the Herfindahl-Hirschman index of the ASN shares, from 0 (spread over many ASNs) to 10,000 (all peers in one ASN).

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

How many autonomous systems host the online peers

Agent Version Distributions

Network structure representation through client and agent distribution.

Client Diversity Trend Consensus

Client Diversity Trend

Shows the number of online peers per agent type (client software) in each crawl. The areas are stacked, so their top is the number of all online peers. The six agent types with the most peers in the selected time range have their own series. Other contains all other agent types.

The Unknown category represents nodes where the agent version could not be retrieved through the libp2p identify protocol. This situation can occur due to various reasons, such as the node terminating the connection before completing the full protocol negotiation.

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

Client participation over time

Active Agents Distribution (24h) Consensus

Active Agents Distribution (24h)

Shows the client software (agent type) of the online peers. One value is the average number of online peers per crawl in the 24 hours up to the latest crawl. The six agent types with the most peers are shown separately. Other contains all other agent types. The percentages are shares of all online peers.

Our Nebula crawler gets the agent version of a peer through the libp2p identify protocol. Unknown contains the peers where this did not work, for example because the peer closed the connection before the protocol negotiation completed.

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

Snapshot of active agents within the last 24hrs

Agent Versions Trend Consensus

Agent Versions Trend

Shows the number of online peers per version of one agent type (client software) in each crawl. The areas are stacked, so their top is the number of online peers of this agent type. Select the agent type in the menu. The menu lists the six agent types with the most peers in the selected time range, and the first one is the default. The six most common versions in the selected time range have their own series. Other contains all other versions and the peers where we cannot read a version from the agent version.

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

Agent version participation over time

Agent Version Distribution (24h) Consensus

Agent Version Distribution (24h)

Shows the versions of one agent type (client software) among the online peers. One value is the average number of online peers per crawl in the 24 hours up to the latest crawl. Select the agent type in the menu. The menu lists the six agent types with the most peers, and the first one is the default. The eight most common versions are shown separately. Other contains all other versions and the peers where we cannot read a version from the agent version. The percentages are shares of all peers of the selected agent type.

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

Snapshot of versions active per agent within the last 24hrs

Protocols & Infrastructure

Key metrics on supported protocols per agent version, as well as intrastructure providers.

Quic Support Over Time Consensus

Quic Support Over Time

Shows the number of online peers per crawl by QUIC support. The areas are stacked, so their top is the number of all online peers. A peer supports QUIC if at least one of its known addresses is a QUIC address:

  • QUIC/IPv4 + QUIC/IPv6: QUIC addresses over IPv4 and over IPv6.
  • QUIC/IPv4 only and QUIC/IPv6 only: QUIC addresses over one IP version only.
  • No QUIC support: no QUIC address.

Select an agent type in the menu to see only its peers.

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

Count of nodes that support QUIC per agent version

Cloud Provider Dependency Over Time Consensus

Cloud Provider Dependency Over Time

Shows the number of online peers per cloud provider in each crawl. The areas are stacked, so their top is the number of all online peers. The providers with the most peers in the selected time range have their own series. The other providers are in Other. Non-Cloud contains the peers that do not run in a cloud data center and the peers without IP address data. The cloud flag and the provider of an IP address come from ipregistry.co.

Select an agent type in the menu to see only its peers.

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

Count of nodes deployed per cloud provider and per agent

Supported Protocols Over Time Consensus

Supported Protocols Over Time

Shows the number of online peers per crawl that support a protocol, for the 40 protocols with the most peers in the selected time range. A peer counts once for each protocol that it supports, so the lines do not add up to the number of peers. The protocol list of a peer comes from the libp2p identify exchange. Peers without a known protocol list are not in this chart. Select an agent type in the menu to see only its peers.

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

Number of peers supporting the top 40 protocols in the network.

Attestation Subnet Subscription Distribution (24h) Consensus

Attestation Subnet Subscription Distribution (24h)

Shows how many online nodes subscribe to a given number of attestation subnets, as the nodes announce in their node record (ENR). The data comes from our Nebula crawls of the discv5 DHT, where one node is one IP address and port. We crawl several times in 24 hours, and each bar shows the average number of nodes per crawl over the latest 24 hours of data. The label on a bar shows its share of all nodes. Select an agent type to see only the nodes that run this client. The n/a bar counts the nodes without subnet information.

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

Loading ...

Fork Support

Prevalence of fork support in the Ethereum network.

Fork Digest Over Time Consensus

Fork Digest Over Time

Shows the number of online nodes per fork digest over time, as the nodes announce in their node record (ENR). The fork digest identifies the fork that a node follows, so the chart shows how the nodes move to a new fork, for example from Electra to Fulu. Fulu BPO1 and Fulu BPO2 are the blob-parameter-only forks after Fulu. Only nodes with a known Ethereum mainnet fork digest are counted. The data comes from our Nebula crawls of the discv5 DHT, with one value per crawl, where one node is one IP address and port. Select an agent type to see only the nodes that run this client.

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

Loading ...

Next Fork Version Over Time Consensus

Next Fork Version Over Time

Shows the number of online nodes per next fork version over time, as the nodes announce in their node record (ENR). A node announces the version of the next fork that its software has scheduled. If no fork is scheduled, it announces the version of its current fork. So the chart shows how many nodes run software that is ready for an upcoming fork, for example Gloas. Only nodes with a known Ethereum mainnet fork digest are counted. The data comes from our Nebula crawls of the discv5 DHT, with one value per crawl, where one node is one IP address and port. Select an agent type to see only the nodes that run this client.

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

Loading ...

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) …