Brief Description of akai
Akai is a generic libp2p DHT item sampler to perform data availability sampling and finding peer information. Another recent study using Akai for IPFS CIDs can be found here.
In this experiment, we use Akai to measure two critical network state transition latencies in the IPFS network: (1) the delay between peer disconnection and peer record removal from the peer store, and (2) the delay between peer connection and peer record addition to the peer store. This analysis helps quantify network state consistency delays.
To use Akai, you can clone it from the GitHub repository, build it, and simply run akai find peer-info <cid> to find information of a given peer. Alternatively, you can run an Akai daemon, using akai daemon so that the tool can continue probing a given peer over time.
Experiment Setup
We deployed akai in the AWS us-east-1 region. For the purposes of this experiment, the ProbeLab team deployed three IPFS peers in Germany, the United States, and Japan, respectively.
These are the CIDs for the peers:
-
Germany:
bafzaajaiaejca6umzfl6r3kd4v2exk4crjn4sm2loa2x2wu7sg3cr2t4723tk5hk -
United States:
bafzaajaiaejcaxgb5auonhtu7bd2g72whyjavlgx6bh2jjuj6sdrtshoci42p2qw -
Japan:
bafzaajaiaejcbdgiqxrwawvz5woeaopzokvu6igoesd7jbxb76tti4l63pjkmx52
The find peer-info operation is performed on the above peers once every 2 minutes for the duration of the experiment, which lasted approximately three days, from August 5th to August 8th 2025.
Throughout the duration of the study, the nodes in Japan and the United States were shut off and restarted every few hours over the duration of three days.
Results
First Restart Cycle
The plot above displays a timeline of each peer’s reachability status. A peer is considered unreachable when either a) the find peer-info operation fails to return a list of multi-addresses for the peer, or b) no entry exists for that peer during Akai’s visit.
The first restart cycles for the US and Japan peers was done on the 5th of Aug 2025 at 21:51 UTC to the 6th of Aug 2025 at 5:02 UTC.
Peers are removed from the peer store almost immediately after disconnection. Rediscovery occurs relatively quickly: approximately 5 minutes after restart for the US peer and 3 minutes after restart for the Japan peer.
Second Restart Cycle
The second restart cycle happened on the 6th of August 2025 between 23:29 UTC and 23:35 UTC.
The peer store removes the disconnected peer almost immediately. Rediscovery happens significantly faster, at only a minute after reconnection, compared to the first restart cycle. This is expected behavior as IPFS refreshes the routing table every 10 minutes.
Third Restart Cycle
The third restart cycle was longer than the second but shorter than the first. The motivation was to observe whether the length of time that a peer is not in the network would influence the time it would take to add it back to the peer store. The peers were shut down on the 7th of Aug 2025 at 00:28 UTC and restarted on the 7th of Aug 2025 at 01:37 UTC.
Interestingly, the US peer was re-added almost immediately, becoming reachable during the visit round on August 7, 2025 at 01:38 UTC. In contrast, the Japan peer did not appear in the peer store until the visit round at 01:40 UTC, consistent with results from the previous restart cycle.
Fourth & Fifth Restart Cycles
During the fourth restart cycle, both peers were shut down on August 8, 2025 at 03:24 UTC and restarted just three minutes later at 03:27 UTC. The Japan peer became reachable almost immediately after restart, while the US peer took about four minutes to become reachable. This behavior contrasts with what we observed in the third restart cycle.
During the fifth restart cycle (August 8, 2025 at 4:46 UTC to 4:55 UTC), both peers disconnected and reconnected almost immediately.
The US peer taking longer to become reachable might be a consequence of timing relative to the DHT’s 10-minute refresh cycle.
Conclusion
This short experiment demonstrates that the delay between the peer store’s state and real-world network conditions is relatively brief, typically around 3-4 minutes, i.e., generally not instantaneous.
The eviction of a disconnected peer from the peer store happens quickly, but there is no clear pattern for which peer is added back first. While one might expect the US peer to be quicker due to the Akai daemon’s deployment in us-east-1, results indicate that the Japan peer was also added more swiftly at times.
Based on this study, we can verify and validate the DHT’s 10-minute routing table refresh interval. However, we observed one notable exception where the US peer required approximately 4 minutes to become reachable after reconnection, even though rediscovery typically occurred within 1-3 minutes across most restart cycles,
Get in Touch
Please share feedback in this post, or feel free to reach out to the ProbeLab team through these contact details, if you require more clarifications. If you’re interested in tracking the availability of your content, please get in touch to talk through the details.