<aside> 🔥 Impact: Given how central the role of Hydras has become, it is imperative to have better visibility into their performance and what guarantees can they provide.

</aside>

Material: Github: Hydra-Booster | GitHub: Hydra-Infra | GitHub: Look-Up Measurement | AWS: Console

DRI: @Dennis Trautwein (Nebula/Hydra/Gateway Data) / @Yiannis Psaras / @[email protected] (DHT Lookup Performance Data)

Final Report: https://github.com/protocol/network-measurements/blob/master/RFMs.md#rfm-21--quantify-hydras-performance-contribution

Table of Contents

Motivation

Although not a core component of the IPFS architecture, Hydra peers play a central role in content discovery with several users and applications (see Indexer nodes) depending on them. However, there hasn’t been a thorough (or at least not documented) investigation of the Hydras’ performance with regard to: their effectiveness in providing records (i.e., do they cover the entire hash space in order to be effective?), their performance (i.e., how quick is the process of hitting a Hydra node to get the record back, what percentage of requests do they satisfy?), or their reliability (i.e., do they constantly cover 100% of the hash space, are there more Hydras needed?). Based on these findings, we need to answer questions, such as what space for optimization exists with regard to the Hydra deployment and ultimately, how useful are they to the IPFS network in terms of the performance improvement they bring.

<aside> 🚀 We decided that the tasks below are out of scope for this project, however, still worth pursuing if time permits. The final report is already out and here.

</aside>

Tasks

Hydra-Booster Reliability and Effectiveness Tasks

Workstreams

DHT-Performance

<aside> 📌 Motivation: We want to know how much Hydra-Boosters benefit the network in terms of lookup performance.

</aside>

Methodology

We run the IPFS lookup measurement that we did for the SigCOMM paper again. Once without any modification, so that we have fresh data for the current state of the network and once with slightly modified IPFS instances. Those instances either:

  1. Discard responses from Hydra-Boosters (in the publication and retrieval process) OR
  2. Get fed a list Hydra-Booster head PeerIDs and ignore those peers
    1. This would have the inaccuracy that other parties may run Hydra-Boosters and we wouldn’t discard those. However, likely only PL is running a significant amount

Ideally, we would combine both.

Untitled Database