Measuring IPNS Performance on the Public Amino DHT

Introduction and Motivation

IPNS is a core component of the IPFS stack, providing mutable references to immutable content. Despite its fundamental role, IPNS has repeatedly been identified by the community as a performance bottleneck, particularly in terms of retrieval latency and user experience.

The objective of this study is to evaluate the current operational behaviour of IPNS on the public DHT. The analysis focuses on three main aspects:

• Reliability of record retrieval over time.
• Retrieval performance and user experience with respect to lookup latency.
• Robustness against network dynamics, especially node churn.

Methodology

The study was conducted on the Amino DHT between 22-08-2025 and 28-08-2025, following the methodology described below:

• The IPNS records used for the study were manually generated and published, configured with a large TTL of one week, so they didn’t need to be re-published.
• The retrieval of the IPNS records, and therefore the data for the study, used the new extension of Akai (https://github.com/probe-lab/akai/) to support IPNS names in the Amino DHT.
• Akai was configured to replicate the IPNS operational quorum of 16 responses, requiring responses from distinct peers before finalising a lookup operation.

Analysis

Record retrievability

The following graph shows the measured retrievability of the IPNS records from the total number of operations. We can see that all retrieval operations completed successfully during the measurement period. Akai’s extension consistently resolved IPNS records and retrieved the correct CID. The quorum of 16 responses ensured correctness and protection against outdated content and network dynamics like node churn.

This confirms that IPNS is functionally reliable in terms of data integrity and retrievability.

Retrieval latency distribution

However, when looking at the retrieval operations, the performance measurements revealed significant latency overhead. The cumulative distribution function of retrieval times shows that:

• The median retrieval time was approximately 11 seconds.
• A substantial fraction of lookups required longer durations, in some cases extending to 37–60 seconds.

These results align with the recurring community complaints regarding IPNS latency. While retrievals were successful, the performance observed is non-optimal for interactive use cases and for the current internet latency standards.

Retrieval latency evolution

To capture temporal effects and avoid hiding transient network behaviour, the following graph displays the retrieval times analysed in a rolling six-hour window.

• The median retrieval time (p50) remained within 7–11 seconds, with occasional increases up to 15–20 seconds.
• The lower bound (p10) improved gradually, reaching as low as 5–6 seconds.
• The upper bound percentiles were the most unstable, exhibiting significant oscillations during the observed period.

This indicates that while the average case is relatively stable, extreme delays, for Internet standards, remain problematic.

Record version stability under churn

To assess resilience to node churn, we examined the resolution of republished records with incremented sequence numbers after three days. As displayed in the graph below, the distribution of retrieved sequence numbers was achieved for the mean of the operations when the records were updated.

Despite churn affecting which peers retained the records, the quorum mechanism ensured that updated sequence numbers could still be retrieved, validating IPNS's robustness in the presence of network dynamics.

Conclusions

The study leads to the following conclusions:

• Correctness and reliability: With a quorum of 16, IPNS consistently returned the correct record values, even under network churn and long TTL intervals.
• Performance limitations: With median retrieval latencies of ~11 seconds and outliers above the 30-second mark, the user experience is generally bad.
• Network resilience: New versions of the IPNS records are successfully propagatedeven after days of the original publication. This highlights robustness despite the dynamics of the Amino DHT.

Recommendations and Future Work

The findings suggest that while IPNS achieves successful retrievals, its current configuration is not optimised for performance. If we wanted to make this more user-friendly, we propose extending the presented study to cover the following items:

• Explore and study alternative quorum sizes to reduce resolution times while maintaining sufficient reliability (i.e., always returning the correct/up-to-date value).
• Analyse the impact of configuration parameters such as TTL and republishing intervals.

IPNS fulfils its design goals in terms of correctness and availability, but the latency observed indicates an urgent need for configuration tuning and protocol optimisation to better serve user requirements.