Performance Evaluation of IPFS in Private Networks
dl.acm.org
dl.acm.org
The benefits of distributes systems becomes bigger the larger the network. Replicate the same results with 100 nodes and we'll see.
I still think torrents would be even more efficient though, than both FTP and IPFS.
That's true. I would be interested in an experiment to show how many IPFS host would be needed to reach parity to FTP and other protocols.
I'm also wondering if IPFS can't be integrated in CDNs.
You may be interested in BTFS, which is elements of IPFS but using BitTorrent as the protocol.
The structures were cleaned up and given a shave, the trackers removed in favor of just putting everyone on the dht.
So another way to look at it, is that every modern p2p protocol is just eMule :)
The think the core IPFS technology is great. But they really need to settle down with changing the higher level protocols and the go-ipfs implementation is truly a piece of junk.
Also, please re-implement it properly!
People should judge IPFS on this, not p2p file systems or DHTs generally. Bitorrtent for example would do a lot better on those large file tests.
A torrent is basically a filesystem, dumped into a single large bytestring, broken into constant size chunks. Then there is a fairly small swarm of nodes trading those chunks. Most of those nodes are trying to download everything, and want to saturate inbound/outbound pipes.
- IPFS is a single massive DHT for advertising who has what for every single blob in the entire network. Most nodes have a tiny subset of that data.
- IPFS does not use a constant block size.
- IPFS uses a "multihash" instead of hard-coding a specific hash function. This adds parsing time to hashes, and means that hashes are not a consistent size, and they have sizes that don't fit cleanly into words.
Those are just some details that I happen to know off the top of my head, but you start to see the picture. In every architectural trade-off, IPFS goes for the more general thing, instead of the performant thing.
I don't know for sure, but have tried the Go and Node IPFS versions and both are pretty bad. The node version did seem less reliable though.
I don't think this reflects on the language or runtimes - just how they are coded.
> the reading performance of IPFS degrades as the data become more popular in the network.
I'd have expected the opposite.
I guess the question is, what value does IPFS bring that couldn't be done with 30 year old tech to a private network?
Also a suite of utilities for concocting your own p2p applications though standardized APIs. But that's more libp2p.
I wonder how representative of a real-world scenario a three-node IPFS network is. I thought that file fragments are strewn across more nodes typically, with some redundancy. FTP offers nothing like this.
So far this looks a bit too apples-to-oranges to me. Has anyone actually read the paper?
In real world use, this is rarely the case on IPFS. Almost everyone who is trying to make files available via IPFS reliably is pinning the files themselves using a server they operate.
The reason I really like that IPFS exists is bc it's a really convenient, mostly cheap and mostly reliable place to put stuff for quick access, even more than running my own server (ew), or paying for hosting and/or using Supabase, Firebase, etc.
Basically using IPFS as a convenient k/v store. The data is still stored locally, but it's just much less convenient to access.
Is anyone else doing this kind of setup?
I think you're confusing pinning services or something else and it is actually quite a bit more expensive than Google Drive and other sync and storage solutions.
IPFS doesn't store anything. You could just as easily setup Syncthing and it would perform the same functionality it you just want to address your files elsewhere.
I wonder how perkeep would perform in that situation.
OpenSea uses Google Images!
As others have noted no matter what these marketplaces all cache the tried and proven Web2 way with the usual large CDN providers, etc.
But I bet a large breakdown of that is spammier NFTs that use string concatenation and svg rendering such as MLOOT
Also of the HTTPS I bet much of that is Pinata or Cloudflare which are just pinning services for IPFS
In any case I’m actually impressed by these numbers and expect them to further improve away from HTTPS
For what it's worth I've spoken with the creator of this project. They're well aware many of the NFTs hosted on IPFS have an HTTPS URI pointing to a gateway. That's easy to parse and they included these results as IPFS.
There's also Arweave and various other decentralized approaches. Actually Arwave is interesting because if all of the Ethereum NFT assets were added to Arweave it would increase the size of bytes on Arweave by 50%...
Also, many of the IPFS pinning providers host their entire infra on AWS or some other centralized big cloud provider. Makes sense but further points to how hard truly decentralized really is (see Arweave stats).
> They're well aware many of the NFTs hosted on IPFS have an HTTPS URI pointing to a gateway. That's easy to parse and they included these results as IPFS.
Glad to see! Can that info be added to the blog? Yeah I think the paid pinning services should only be a stopgap solution. I think purchasers of NFTs should pin their own and someone should make it easy for them to do that. I bet you could include code for that within the NFT classes, just like how people ram dynamic svg code into them. For collections like PFPs I think projects can incentivize staking+pinning for extra rewards like slowly over time minting an additional nft for people that do it, or separate nft/token for a parallel collection. (Like if mutant ape serum was only claimable by ape holders that helped pin the collection on ipfs)
I need to look at Airweave closer!
But yes this will improve the nft concept very well, and glad to see the path for improvement is happening so fast, money chasers are following the same tutorials.
[1] https://ipfs.io/