Skip to content

ProbeLab P2P Network Metrics Proposal

Project Description

In the past weeks, the ProbeLab team has extended Nebula, our flagship network crawler, to support the Monero network. Our initial, one-off study on the Monero network resulted in the following blogpost, where we included a variety of results:

https://probelab.io/blog/peering-into-privacy-a-deep-dive-into-the-monero-network-topology/

This proposed project has two primary targets:

  1. We want to adapt our tooling, set up infrastructure to continuously monitor the health of Monero’s P2P network and extract valuable insights. The results will be published on our website (https://probelab.io), in the form of dashboards, similar to what we do for several other networks.
  2. We will develop the right methodology and corresponding tooling to estimate the number of unreachable nodes.

Why is it Important for the Community?

While platforms like monero.fail and moneronet.info provide excellent real-time data on public nodes and network health, our objective with Nebula is to provide an alternative methodology for the P2P layer allowing us to identify nuances in node behavior and infrastructure concentration that were inaccessible previously.

Monero is, by design, one of the most privacy-preserving financial networks. At the transaction layer, the cryptography is strong and the privacy guarantees are real with techniques like ring signatures or stealth addresses that obscure senders and hide recipients respectively. But a network is more than its transaction protocol and at the P2P layer, Monero looks remarkably similar to other decentralized systems that we at ProbeLab have investigated before. Nodes expose IP addresses, handshakes expose metadata, peer lists get shared openly, and behavioral patterns that, if you know how to read them, can tell you quite a lot.

The gap between Monero’s reputation for opacity and the relative transparency of its networking layer is exactly why we want to adapt our tooling to continuously look deeper into the specifics of the P2P layer.

Furthermore, looking into unreachable nodes is becoming increasingly important. These nodes are more vulnerable to IP-origin tracing of transactions than reachable nodes, due to how Dandelion++ works. Looking into how Dandelion++ works and proposing optimisations to overcome potential node identification/de-anonymisation through the stem-phase transaction will be very valuable for the future of Monero.

Who is the Team?

ProbeLab specialises in developing tools for measurement and monitoring of P2P layer protocols. We've got a wide variety of tools and deployed infrastructure that runs 24/7 and monitors several high profile networks - see: https://probelab.io/networks for details. As a sample of our track-record to date, we monitor more than 10 networks, performing thousands of crawls per week, monitoring more than 50k nodes, for the past 4 years that we’ve been in operation. We offer services in several shapes and forms, from executive reports on the state of the network, to more tailor-made studies on particular metrics and further to 24/7 monitoring of critical blockchain network infrastructure.

The core team consists of three academics, each holding a PhD in computer science with a specialization in computer networking [0, 1, 2].

Milestones

Milestone 1: Core Monero Network Metrics

We will follow the methodology outlined in our recent blogpost and set up infrastructure to continuously crawl the network and present the following metrics in (near) real-time dashboards on our website.

Expected Outcome: Metrics on https://probelab.io: Network Size, Connection Errors, Geographical Distribution of nodes, Cloud Provider Distribution over time, Archival Node Distribution, Network Sync Status, Spy Nodes Count, Ban List Adoption, Connection Error Distribution. Expect a dashboard similar to: https://probelab.io/ipfs/topology/ or https://probelab.io/ethereum/topology/ including most metrics from our recent blog post.

We can rely on existing ETL pipelines and code from other networks but the Spy Node segmentation of the data and ban list dimension require additonal work.

The requested budget will cover infrastructure costs for six months. We will submit a follow-up grant proposal to cover the infrastructure costs for a year.

Effort: 0.75 PM (Person Months)

Milestone 2: Identifying Unreachable Nodes

Identifying unreachable nodes in the Monero network is important because these nodes can be prone to IP-origin tracing of transactions. Here are some notes that we will take into account while investigating the issue, which will very likely influence the study and its outcomes:

  • Some Monero nodes perform subnet deduplication before connecting to outbound nodes.
  • If an unreachable node connected to a spy node sends to the spy node a Dandelion++ stem-phase transaction, then the spy node can infer the true origin node of the transaction.
  • A reachable node's stem-phase transactions could come from the node itself, or from any of its inbound connections. However, the case is not the same for an unreachable node that does not have other inbound connections through which they could receive other nodes' stem-phase transactions. This is a limitation for unreachable nodes.
  • The above affects Monero users who set up their own nodes through the Monero GUI wallet. this is because, these users appear as unreachable because by default, they can’t open the right inbound port(s).
  • Papers worth consulting while looking for a solution:

Expected Outcome: A report about metrics on unreachable nodes in the Monero network published on ProbeLab’s blog. If budget allows we will also collect these metrics continuously and put them alongside the metrics of Milestone 1 on probelab.io.

Effort: 1.5 PM (Person Months)

Budget

This proposal draws on ProbeLab's 4 year track record of network monitoring and our specialized expertise in P2P layer analysis. We are requesting a total of 170 XMR assuming a market rate of 275 EUR/XMR and a rate of 130 EUR/hour.


This proposal expires six months from the date of submission.

Edited by Dennis Trautwein

Merge request reports

Loading