Concept: Bunker — distributed file storing system with endorsement of peers

Nowadays p2p technologies are becoming more popular in the age of sharing economy. While Bitcoin is replacing traditional currencies such as the dollar, Ethereum is used for signing smart contracts between peers.

What about file and static site hosting? Have you ever thought about anonymously sharing a file to a public for an indefinite amount of time? If so, let’s consider a system capable of doing this. Such system should be:

  • durable even if DNS or traditional storage systems go down
  • scalable to be able to serve users in case of growing demand
  • anonymous to protect peers who publish files
  • lasting to guarantee that file exists at least a required amount of time
  • resilient from any kind of attacks
  • legal to address copyright and law issues


Recently I have met IPFS (InterPlanetary File System), a distributed hypermedia protocol that can qualify for most of the characteristics described above. However, it does not guarantee lasting of the file in the system. Its architecture is similar to BitTorrent. So to maintain a file or a website, you need to keep it on your own machine to guarantee delivery to other peers. As in BitTorrent you can’t simply push a file into a network. Neither BitTorrent nor IFPS allows you to use resources of other peers unless if it is what they want.

So what to do if you have a huge amount of data, but hosting it on your own machine or renting a server is not an option?


The solution is quite simple: endorse IPFS users storing and sharing your data. And here is an easy way to implement this using a smart contract. A smart contract is a distributed Turing machine could be implemented using various cryptocurrency systems such as Ethereum or RSK.

Consider the following scenario:

  1. A publisher pushes a file to his/her own IPFS node.
  2. On the Bunker website, which is a trusted party, a publisher submits a request to store a file. He/she also provides following data: an IPFS file hash, an IPFS address, MTTL (minimal time to live), an endorsement amount, a currency (Ethereum or Bitcoin), and a wallet address.
  3. On the Bunker website, interested peers can accept this request. To participate in the contract, they should provide this: an IPFS address, a wallet address.
  4. Bunker arranges a smart contract in either Ethereum or RSK.
  5. A publisher loads money to a smart contract, which changes its state to active.
  6. Participating peers keep local copies of a file while a contract is active.
  7. When local copies are saved by peers, a publisher can remove a file from its own storage.
  8. From time to time Bunker identifies peers, which are storing a file, and randomly reports one of them to a smart contract. This process is called peer verification.
  9. Anyone (usually it is Bunker) can trigger a smart contract to pay out a small portion of an endorsement amount to a random verified peer provided by Bunker in step 8. If Bunker had confirmed that no such peer exist, a portion of an endorsement amount is returned back to a publisher. This process repeats until MTTL is reached and all endorsement amount is paid off.

In this scenario, Bunker acts as a trusted party, which connects a publisher to peers. It also identifies peers who comply with a contract and decide who of them should receive an endorsement. On the other hand, a smart contract holds an endorsement amount and decides who should receive it and what portion of it. There is no way to full a smart contract.

Peers verification

This is the most critical step in the whole process, which can be done efficiently only by a trusted party. Though the idea behind this is quite simple:

  1. Bunker requests from a publisher hashes of random portions of a file upon signing a smart contract.
  2. From time to time, Bunker requests peers to provide hashes of a particular portion of a file.
  3. A peer who provided a correct hash faster has more chances to be selected by Bunker to receive a portion of an endorsement amount.

This method requires peers to run a service that allows Bunker to connect and communicate to them. Fortunately, IPFS provides Go library for communication between peers.

Changes to a smart contract

There could be cases when changes to a smart contract make sense:

  • A smart contract is not profitable for either peers or a publisher
  • Existing peers are inactive, so new peers are needed
  • Publisher wants to continue a contract
  • Publisher wants to update content
  • Legal issues associated with content

To resolve such issues publisher can initiate a contract change. This will require a publisher to create a new smart contract with a help of Bunker and to discard a previous contract. By discarding an old smart contract a small penalty fee is paid to peers.

Legal issues

In case if any content violates a copyright or other laws, a publisher is notified by Bunker to make changes to a smart contract. If no changes are made within a specific amount of time, Bunker puts a contract on hold and no endorsement is paid out to peers. This will indirectly make peer remove illegal content from their local storage.


Since a smart contract requires a gas (money) for operation, Bunker receives a small fee in order to run smart contracts.

Why people need this?

It allows storing tremendous amount of data in the distributed system. With the help of IPFS, you can automatically manage scalability in case if data gets very popular with no additional cost.

However, there could be cases when you need to make sure your data is safely stored and are accessible all the time. Bunker provides a way to do it. Bunker can be useful for scientists, photographers, video bloggers, website creators, etc.

It is a step into a feature towards sharing economy and real democracy.


Someone is building it: