Capturing nodes that interact with a Distributed Hash Table (DHT) network as clients has traditionally been challenging, but also not a critical metric for the overall health and operation of the network. With modern-day Data Availability (DA) solutions, such as Celestia, being based on a DHT network and in particular on DHT client nodes, monitoring and metrics for those nodes becomes crucial.
The ProbeLab team has adjusted its network crawling tools to monitor Celestia DHT Server nodes since April 2024, but has recently also developed a specialised tool, called ants-watch, to capture DHT client nodes (aka Light Nodes, or LNs). Our tool collects important data from Celestia Light Nodes which we analyse to develop critical metrics and insights for the DA network’s operation.
In this post, we give a brief overview of ants-watch together with initial results and highlight findings that we were able to uncover by observing the network through our specialised tools.
You can find a more comprehensive description of ProbeLab’s findings regarding Celestia’s network size & stability as well as node geolocation breakdown in this blogpost. All of ProbeLab’s results on Celestia are public and the latest weekly report can be found at: Week 2025-10 | ProbeLab
Monitoring Celestia Light Nodes
DHT Server nodes can be easily captured by standard network crawler functionality, but the case is not the same for DHT Client nodes. This is because each DHT Server node is keeping track of other server nodes in the network by inserting them in their routing table. The routing table of a server node can be queried and will return the addresses of other server nodes in the network. DHT Client nodes, however, are not kept in any other node’s table because they are not expected to be stable, present and participating in the network continuously. This is where extra, specialised functionality is needed to capture DHT Client nodes, and in this case Celestia Light Nodes.
ants-watch is a tool developed by the ProbeLab team specifically for capturing DHT Client nodes. The tool captures client nodes by exploiting some of the DHT’s (in this case libp2p’s kad-dht) internal operational details. More specifically, each DHT Client node needs to keep its routing table up to date and for this reason, it queries the k = 20 closest DHT Server nodes to itself (i.e., to its own PeerID) every so often (every 10 min in Celestia’s case, up from 1 min after recent changes). Therefore, by inserting one controlled DHT Server node for every k = 20 DHT Server nodes, our tool is able to receive routing table update requests from DHT Client nodes (i.e., Celestia Light Nodes). When a request hits one of our ants, we record information about the requesting peer like its agent version, supported protocols, IP addresses, and others.
This is a simplified explanation of how ProbeLab’s ants-watch tool works. For more information, methodology and deployment details head to our dashboards linked further up.
Several metrics can be shown out of the data we gather from our ants deployment, but for now we’re publishing the agent distribution over time (first plot) and the adoption of new releases over time (not shown here, due to forum post restrictions).
Noteworthy Findings
The ants that we have deployed on the Celestia network can capture DHT Client nodes (i.e., Light Nodes), but can also capture DHT Server nodes (i.e., full and bridge nodes). We’ve done a comparison between the numbers we get from our Nebula crawler and those from our ants deployment.
Interestingly, we found that we can see way more DHT Server nodes from the ants deployment, than from the Nebula crawler. In particular, we see almost the double as much server nodes from ants than from Nebula. This finding leads to the conclusion that quite a few DHT Server nodes in the Celestia network are facing connectivity issues, most likely due to NATs. In the latest report we see between 80 and 90 nodes seen by Nebula and more than 150 seen by the ants. Head to the original blogpost for the relevant plots. The issue has been reported to the Celestia team and has been documented in a relevant Github issue.
Summary
Overall, Celestia’s P2P network is in a healthy state with nodes distributed geographically and among different cloud providers. The network is stable with server nodes churning very little. The novel browser-based Light Node implementation (i.e., lumina.rs) allows for easier deployment, but is also more prone to higher churn. However, judging from the population of Light Nodes seen in the network, higher churn does not risk Data Availability.
The ProbeLab team will continue to monitor the Celestia network and report results on our site. Reports are published weekly on Mondays. If there are important metrics that you believe should be part of these weekly reports, or have questions regarding the existing ones, respond to this thread or get in touch with the team.