Source-linked AI summary
Design and Evaluation of IPFS: A Storage Layer for the Decentralized Web
Dennis Trautwein, Aravindh Raman, Gareth Tyson, Ignacio Castro, Will Scott, Moritz Schubotz, Bela Gipp, Yiannis Psaras
TL;DR
Centralized web infrastructure concentrates control and creates organizational dependencies, motivating decentralized storage and delivery. The paper presents and measures IPFS, an open-source content-addressable peer-to-peer system, finding broad global deployment and generally acceptable publication and retrieval delays. It also identifies operational caveats involving churn, concentration, moderation, and resilience that remain for future work.
Problem
Web operations are increasingly consolidated among large providers, creating single points of organizational failure and motivating decentralized storage and delivery.
Method
The paper presents IPFS design and implementation, using content addressing, peer-to-peer indexing, and measurement methodologies to evaluate deployment and performance.
Results
IPFS spans 152 countries and 2715 ASes; 3/4 of European retrievals are under 2 seconds, while gateway caching serves 76 % under 250 ms.
Takeaways & Limitations
IPFS provides decentralized content storage and delivery with delays acceptable for various use cases, while its datasets, tooling, codebase, and experiences are publicly available.
Takeaways & Limitations
IPFS remains exposed to high churn, AS concentration, moderation challenges, and unevaluated resilience against information attacks.
Abstract
from arXiv · showhide
Recent years have witnessed growing consolidation of web operations. For example, the majority of web traffic now originates from a few organizations, and even micro-websites often choose to host on large pre-existing cloud infrastructures. In response to this, the "Decentralized Web" attempts to distribute ownership and operation of web services more evenly. This paper describes the design and implementation of the largest and most widely used Decentralized Web platform - the InterPlanetary File System (IPFS) - an open-source, content-addressable peer-to-peer network that provides distributed data storage and delivery. IPFS has millions of daily content retrievals and already underpins dozens of third-party applications. This paper evaluates the performance of IPFS by introducing a set of measurement methodologies that allow us to uncover the characteristics of peers in the IPFS network. We reveal presence in more than 2700 Autonomous Systems and 152 countries, the majority of which operate outside large central cloud providers like Amazon or Azure. We further evaluate IPFS performance, showing that both publication and retrieval delays are acceptable for a wide range of use cases. Finally, we share our datasets, experiences and lessons learned.
1 INTRODUCTION
IPFS addresses centralized web infrastructure by providing decentralized, content-addressable storage and retrieval, then evaluates its deployment and performance at scale.
- Motivation: Centralized web services can create single points of organizational failure despite strong technical performance.Common web deployments combine cloud hosting, third-party DNS, content delivery networks, and certificate authorities.
- Motivation: The Decentralized Web distributes traditional web functions through open-source, community-led systems without a single administrative entity.Examples include decentralized name lookup, hosting, and certification.
- Motivation: Decentralizing media storage and serving could let applications build on shared infrastructure without handling decentralization themselves.The paper identifies storage and delivery at scale as core requirements for web platforms.
- IPFS: IPFS is an open-source, community-driven, content-addressable platform for decentralized media-object storage and retrieval.The project spans 176 repositories, 60.4 k commits, and 1185 code contributors, with roadmap decisions led through public voting.
- Contributions: The paper presents IPFS design and implementation, proposes three complementary measurement methodologies, and evaluates deployment and performance.It also makes datasets and tooling publicly available.
- Evaluation: 2715 ASes and 152 countries host IPFS infrastructure, while 7.1 million content retrievals were observed from one vantage point in one day.The deployment spans 464 k IP addresses, with most countries represented in the United States and China.
- Evaluation: 3/4 of European retrievals finish under 2 seconds, and gateway caching serves 76 % of requests under 250 ms.The retrieval includes content-host lookup and fetching a 0.5 MB file; IPFS remains slower than direct HTTP access.
2 IPFS FUNDAMENTALS
IPFS combines content identifiers, peer identifiers, multiaddresses, and a DHT to locate and verify content independently of storage location.
- Content Addressing: Content Identifiers decouple content names from storage locations, allowing objects to be served by any peer.Hash-based CIDs also remove the need for central authorities to allocate addresses.
- Content Addressing: A CID contains self-describing multibase, version, multicodec, and multihash fields.The multihash records the hashing algorithm and digest length, with SHA-256 and 32 bytes as defaults.
- Content Addressing: IPFS chunks imported content into default 256 kB pieces, assigns each chunk a CID, and organizes them into a Merkle DAG.The root node combines descendant CIDs into the final content CID.
- Content Addressing: Merkle DAGs support chunk deduplication and remain independent of where replicas are stored.Deduplication can reduce storage and bandwidth because repeated content need not be stored or transmitted twice.
- Content Addressing: Hash-based CIDs are immutable and self-certifying because altering content changes its CID.This supports self-verification by comparing the CID with the content hash, but complicates dynamically changing objects.
- Peer Addressing: Each peer receives a PeerID derived from its public-key hash, which authenticates the key used for secure communication.A peer keeps the same PeerID unless its operator changes it manually.
- Peer Addressing: Multiaddresses encode layered protocol and endpoint information, including network, transport, and PeerID components.Their extensible syntax supports protocol variation and relaying messages to nodes that cannot be contacted directly.
- Distributed Indexing: A Kademlia-based DHT maps CIDs to provider PeerIDs and Multiaddresses using PUT and GET operations in a shared 256-bit key space.IPFS uses SHA-256 hashes for both CIDs and PeerIDs as indexing keys.
3 IPFS IN ACTION
IPFS publishes content by mapping content identifiers to peers through a distributed hash table, then retrieves content through discovery, routing, and Bitswap exchange. Optional gateways provide browser access and can cache content to reduce latency.
- Content publication: Publication imports content, allocates a CID, and stores a provider record mapping that CID to the publisher’s PeerID on the 20 closest DHT peers.The record is replicated for availability and republished every 12 h by default, with a 24 h expiry interval.
- Content retrieval: Retrieval identifies peers hosting a CID, maps their PeerIDs to Multiaddresses, connects to a provider, and fetches content.The process includes content discovery, peer discovery, peer routing, and content exchange.
- Content retrieval: Before a DHT lookup, requesting peers opportunistically query already connected peers through Bitswap for the desired CID.This can resolve content faster when immediate neighbors already store it.
- Content retrieval: DHT walks use iterative Kademlia lookups, forwarding requests to α=3 peers closest to the requested CID in the requester’s routing table.Peers return the content when available or provide provider-record information for further discovery.
- Content addressing: CIDs are permanent, immutable, and self-certifying, enabling decentralized namespace management and universal caching but complicating dynamic content.IPFS therefore provides an option for publishing mutable content.
- IPFS gateways: Gateways bridge HTTP clients to IPFS, while optional nginx and node-store caching can aggregate demand and persist selected content.There are 107 known gateways, and operating one requires no authorization but does require a public IP address.
4 EVALUATION DATA
The evaluation combines active peer crawling, gateway access logs, and controlled regional performance experiments. These datasets measure IPFS deployment, usage, publication, retrieval, and ethical handling across complementary views of the network.
- Dataset design: Three datasets combine active and passive measurements because IPFS’s decentralized operation and independent node ownership prevent a complete central activity record.The datasets cover peers, gateway requests, and publication and retrieval performance.
- Peer dataset: A crawler running from Germany every 30 minutes recursively gathers DHT peers from six default bootstrap peers.The upgraded crawler also records Multiaddresses, agent versions, supported protocols, and connection, handshake, and crawl durations.
- Peer dataset: The peer measurements comprise over 9500 network crawls and map observed IP addresses to countries, Autonomous Systems, and CAIDA AS Rank.Peer uptime is estimated by revisiting discovered peers with probe intervals adapted to observed accessibility.
- Gateway usage data: A US Protocol Labs gateway dataset records one day of January 2022 traffic, including 7.1 M user requests, 101 k users, and 274 k unique CIDs.The sampled gateway represents a geographic subset because inbound traffic is load-balanced across several anycast gateway instances.
- Performance data: Performance experiments use six AWS virtual machines in six regions, each running go-ipfs v0.10.0 as a DHT server node.Each iteration announces a new 0.5 MB object, has other nodes retrieve it, and disconnects them before the next operation to force DHT lookup and discovery.
- Performance data: The performance dataset has uneven regional operation counts because one instance ended before its latest publication and some control-plane instructions were missed.The authors state this affects statistical significance, not measurement correctness.
- Ethical considerations: The released datasets anonymize IP addresses, avoid identity mapping, and do not inspect CIDs to infer exchanged content.Gateway usage data contains personal information collected during routine operations under IPFS policies.
5 DEPLOYMENT SCALE
IPFS is deployed across a geographically broad and technically diverse network, but peers and infrastructure remain concentrated in particular countries and Autonomous Systems. Most nodes are outside major cloud providers, while peer uptime is generally short and regionally variable.
- Geographical Distribution: 198,964 peers and 464,303 unique IP addresses span 152 countries, with 253,198 addresses reachable at least once and 211,105 always unreachable.The dataset contains 1,998,825 Multiaddresses; 54.5% of addresses were reachable at least once, while 45.5% were always unreachable.
- Geographical Distribution: 28.5% of peers are in the US and 24.2% in China, followed by France at 8.3%, Taiwan at 7.2%, and South Korea at 6.7%.Around 8.8% of peers advertise Multiaddresses mapped to multiple countries, making multihoming commonplace.
- Autonomous System Coverage: 2715 Autonomous Systems contain IPFS peers, but the top 10 hold 64.9% of IP addresses and the top 100 hold 90.6%.More than 50% of observed IP addresses are concentrated in five ASes, including two Chinese ASes containing more than 30%.
- Cloud Coverage: Fewer than 2.3% of IPFS nodes run in cloud infrastructure, suggesting that most deployments use personal or on-premises commodity hardware.The paper contrasts this with Mastodon, where 6% of infrastructure is hosted on Amazon alone.
- Churn: 87.6% of sessions last under 8 hours, while only 2.5% exceed 24 hours; median uptime ranges from 24.2 minutes in Hong Kong to more than twice that in Germany.The observed churn motivates replicating records on k=20 peers.
6 IPFS PERFORMANCE EVALUATION
IPFS provides broadly usable retrieval performance despite higher latency than direct HTTP, while publication is slower because records are distributed across peers. Gateway caching substantially improves retrieval speed, but measurements also expose regional variation and deployment-dependent limits.
- Content Publication Performance: 33.8 s, 112.3 s, and 138.1 s are the 50th, 90th, and 95th percentile publication delays, with DHT walks contributing 87.9 % of overall delay.Publication delay is independent of content size in this experiment because only the provider record is published.
- Content Retrieval Performance: 100 % of controlled retrievals succeeded, although delays were higher and more diverse than typical web access.Retrieval involves interactions with peers outside the experimenters’ control.
- Content Retrieval Performance: 2.90 s, 4.34 s, and 4.74 s are the 50th, 90th, and 95th percentile retrieval delays across regions, including CID lookup.Retrieval is faster than publication and includes mapping CIDs to eligible content locations.
- Scope and Variation: Performance depends on geography and measurement setting: median retrieval is 1.81 s in central Europe versus 3.75 s in South Africa, while last-mile user experience may differ from AWS measurements.Content-exchange results also depend on object size, which was fixed at 0.5 MB in the experiment.
- Content Retrieval Performance: The median retrieval DHT-walk duration is 622 ms, with both provider and peer-record walks completing under 2 s for 50 % of retrievals in every region.Retrieval walks terminate after finding one record-hosting node, unlike publication walks that target 20 peers.
- Gateway Performance: 76 % of gateway requests are delivered in under 250 ms after combining nginx caching with content stored in the local IPFS node.46 % of fetches are nginx cache hits, while 67.1 % of remaining IPFS fetches come from the local node store with delays below 24 ms.
- Comparison with HTTPS: The median IPFS retrieval stretch is 4.3 versus HTTPS, but removing the initial Bitswap timeout yields stretch < 2 for 80 % of retrievals in well-connected areas.The paper identifies the initial 1 s Bitswap timeout as a contributor to the observed cost of decentralization.
7 RELATED WORK
Related work situates IPFS among peer-to-peer overlays, federated services, incentive mechanisms, content-addressing systems, and decentralized data-management projects. IPFS reuses established components while emphasizing broad decentralized storage and distribution.
- P2P Networks: IPFS uses the Kademlia DHT for content indexing rather than introducing an entirely new overlay architecture.Prior work includes many DHT structures and large-scale peer-to-peer content-delivery applications.
- Evaluation of Operational DHTs: Earlier operational DHT studies reported lookup latencies in the tens of seconds, whereas IPFS achieves substantially faster performance in comparable measurements.Prior BitTorrent Kademlia measurements found median lookup latency could exceed a minute.
- The Fediverse: IPFS is complementary to federated services such as Mastodon, Pleroma, Diaspora, and Nextcloud, which use server-based or server-local storage models.The fediverse developed alongside IPFS and provides related but distinct decentralized services.
- Incentives: IPFS does not directly incentivize storage, sharing, or participation; it functions as a best-effort caching, storage, and distribution layer beneath incentive structures.Participation can still be widespread because nodes are not required to store other users’ content.
- Incentives: Pinning services and Filecoin provide stronger availability guarantees than IPFS’s non-incentivized storage layer.Pinning services host user content for a fee, while Filecoin is built on top of IPFS.
- Content Addressing and Data Management: IPFS shares content-based addressing with systems such as BitTorrent, NDN, NetInf, and Secure Scuttlebutt, while related decentralized data projects focus more narrowly on user data control.IPFS instead has a broader focus on decentralized storage systems.
8 CONCLUSIONS
The paper concludes that IPFS combines decentralized operation with broad deployment and acceptable performance, supported partly by hybrid gateways. It also identifies latency, moderation, resilience, and dependence on centralized infrastructure as continuing research concerns.
- Contributions and Uptake: 152 countries and 2715 ASes contain IPFS deployments, demonstrating widespread uptake of the decentralized storage network.The conclusion attributes part of this uptake to the hybrid gateway design and notes that code and datasets are freely available.
- Contributions and Uptake: Hybrid gateways received considerable usage and helped enable IPFS uptake while remaining optional to the overall network.The conclusion presents gateways as part of IPFS’s deployment experience rather than as a required architectural component.
- Future Work: Future work prioritizes minimizing retrieval and publication latency and expanding longitudinal monitoring of IPFS components.The authors specifically propose exploiting Bitswap to preemptively pair peers with similar content interests.
- Future Work: Hydra boosters were not covered because of space constraints and their limited adoption.The authors plan to expand future studies to this component.
- Open Limitations: The paper has not evaluated IPFS resilience to information attacks such as censorship, and moderation remains a challenge in its open, permissionless design.The authors also identify the need to understand reliance on centralized infrastructure such as cloud platforms.