This milestone serves the purpose of setting the methodology plan for the rest of the project. The milestone includes reviewing of the suggested methodology and the code that needs to be implemented in order to get the right results. This is the right time to make amendments to the suggested methodology. For this grant, there are already results collected previously, which can be shared with the team working on this project. The results will cover most of the datasets needed for the work in this grant. Given that there is a suggested methodology, this Milestone does not come with a reward, but should be part of the work.

Methodology Details

Given a dataset, build the right scripts to identify:<ul><li>Changing IP addresses for constant PeerID</li><li>Changing PeerID for a constant IP</li><li>Rotating both IP and PeerID</li></ul> Apply the scripts to a small subset of the dataset and verify that it works as expected.

Initial Scripts to flag IP and PeerID rotation

Valid methodology and results of whether provider records remain orphan due to PeerID churn.

Orphan Provider Records

PeerID Distribution Script &amp; Plot: Representation of the hash space on a 0-1 plot with the PeerIDs laid on top. Script to reproduce the plot given a dataset of a specific schema.

PeerID Distribution

We expect the scripts and any infrastructure processes that have been developed as part of this grant to be re-usable and easy to use with appropriate documentation and comments. We also expect a final report that details the main findings which address the Request for Measurements (RFM), the methodology used,&nbsp;as well as any conclusions made and open issues for future investigation. The conclusions should be accompanied by plots that justify the findings. The report is not expected to be long - think of a relatively detailed blogpost. The Final Report should be posted on the GH repository in the designated folder.

Final Report, Scripts and Stable Results

We want to learn about how stable are the IPFS nodes' location and how much peers generally move between IP addresses (e.g. Laptop moving from home to coffee shop to work). We also want to be able to identify peers that rotate their PeerIDs. PeerID rotation is critical for the performance of the DHT and if done too often leads to orphan content, i.e., content that exists in the network but its provider record cannot be found. PeerID distribution is useful to identify whether malicious nodes generate PeerIDs and concentrate around a given part of the name space, e.g., to eclipse some particular content/CID. For additional context check this&nbsp;<a href="https://pl-strflt.notion.site/Rotating-PeerIDs-22e9ebebae0440ef873dc5143943e762" rel="noopener noreferrer" target="_blank" style="background-color: transparent;">Notion page</a>.

Nodes that change the address with which they connect to the network (either IP address or PeerID) cause dynamicity that needs to be taken into account in underlying protocols. We want to find out how often does this happen.

IP address Churn (Roaming) & PeerID distribution for nodes in the IPFS Network

Jump to section:

IP address Churn (Roaming) & PeerID distribution for nodes in the IPFS Network

Problem Description

Solution Requirements

Milestones

Other Information