- The bidder is the participant who needs a file pinned. They use the dapp and their local IPFS node to add their file and make a bid for a hoster to pin their file. They don't need to permanently keep their IPFS node up, just long enough for the hoster to get and pin their file.
- The pinner is the participant that will actually be pinning the file. They run a scatter daemon and a permanent IPFS node to pin the bidders' files. For every file, there are two pinners.
Components and Implementations
- Ethereum smart contracts - The heart of the system. All key transactional data goes through these.
- Scatter daemon - This daemon is intended to run on a server and can act as a validator and hoster.
- Scatter dapp - The dapp (decentralized application) is the interface that allows bidders to place bids for their files to be pinned.
Proving files have been pinned
Listing IPFS pins of a remote node requires API access. The IPFS HTTP API was not built with access control and security in mind. Leaving the API open allows anyone to add or remove files, pins, and perform other operations that really shouldn't be public.
To add to the fun, these API calls can be spoofed or falsified pretty easily. A malicious hoster could accept bids, and setup an API that responds showing that pins were made when in fact nothing is actually there. This is a lot of effort to go through just to pretend to be actually hosting files, but would be a successful attack that would lower the qulity of the network. This option has more or less been ruled out, but may be an aditional layer of proof in the future when access control is implemented .
Instead, the primary form of validation is through "Mutually Assured Destruction." If the two file pinners can not come to an agreement, both of their initial stakes that they put up before pinning the file are burned. This agreement requires each participant to hash two pseudo-random (but repeatable) parts of the file, provide half of each to the contract, and each pinner signs one. If the hashes can't be reassembled and the signatures verified by the contract, the "challenge" is considered failed.
This does leave a known hole in the process. A pinner could in theory, keep a file around just to hash and not offer it to the public IPFS network. The bandwidth savings is likely to be trivial compared to storage, so it's not likely to be overly abused. That said, it is a flaw in the proof that needs to be monitored.
For more details, read the protocol white paper . This document is continuously being updated as the protocl is refined.
Since the amount of pinners per file are currently fixed at 2, that leaves a relatively small window for individuals to try and get two of their pinner accounts to stake at the same time by sending out their transactions at the same time. This would allow them full control, acting as both pinners and validating each other. They could either only host/pin one copy of the file, or use completely made up file hashes for the challenge/defense validation protocol.
This can be made somewhat more difficult by preventing stakes from landing on the same block. But it is not a full-proof method of preventing collusion.
It might be best to provide a pinner with the option of using a variable amount of pinners, leaving them to determine their own level of risk. But this adds a lot of complexity and will be left out of v1 of Scatter.
If you'd like to provide feedback or present ideas, please submit a new issue and we can discuss.