For a successful usage of the safe network two main incentives must be properly implemented:
- Incentive for users to put data on the network => cost of put operations must be minimized.
- Incentive for farmers to provide resources to the network => reward for responding to get requests must be maximized.
These incentives are contradictory, not directly because a put operation is not the same as a get operation, but indirectly because put operations add data on the network which allow get operations to be requested on these data. So the system is more complex than a simple supply and demand problem on a common resource.
In the short term farmers will be given new safecoins without impacting the cost of put operations because there are almost 4 billion of them in reserve (there may be an associated inflation problem with them, but let’s ignore it). In the long term there will be fewer of them and the majority of safecoins given to farmers will be recycled ones. An equilibrium between costs of put and get operations will have to be reached. The main problem is the data duplication (each chunk is stored several times):
- In the past I have read that each chunk was stored 20 times (4 online + 16 offline)
- I have also read there is a 20% reserve of storage space free
- More recently three kinds of chunks appeared (normal, sacrificial and backup)
- In any case there is an important percentage of data that is never read again (that will not generate get requests)
I don’t know the multiplier value but I suppose it is an order of magnitude (like 10 MB of storage is needed in the safe network to store a 1MB file). With such a multiplier it seems hard to content both the users and the farmers and I suspect it is the origin of the pessimistic formula given in RFC n° 5:
int cost_per_Mb = 1/(fr^(1/5)); (5th root, integer value)
For example if FR is 100 000 then the cost of one TB is 1000*1000/10 = 100000 safecoins ≈ 2000€ at current price. This is very expensive (for comparison Dropbox is about 100€ per year for one TB) and yet the chosen value for FR is very high (one reward request every 100 000 gets !!!).
These values are a blocking problem, because no useful equilibrium can be reached and both users and farmers will leave the network:
- Professional farmers will have negative ROI
- Casual users won’t store data because it’s too expensive and besides they won’t be able to farm a single safecoin
I think that non-permanent chunks can solve this problem. What I propose is not a fixed time limit but a security measure: deletion of the oldest chunks will be triggered only if the safe network runs out of disk space. Each data chunk has an associated last payment date: for private data the user has to pay to update this metadata and for public data anybody can pay.
This solution comes in addition to sacrificial data. When the network runs out of space first the sacrificial chunks are deleted and then the oldest chunks.The network is currently supposed to work with permanent data that do not need to be deleted. This proposal is only a security measure that would be useful only if this assumption is not true. In this hypothetical case it is better to delete old chunks instead of random chunks (because this is what will happen if people stop their vault when there is not enough space to store the chunks they held).
The advantage of a payment to keep old data is that safecoins are recycled when users pay to update the last payment date. This is where the blocking problem is really solved: this afflux of recycled safecoins will increase the probability to get one at each reward request and so new revenues will be added for farmers for maintaining the safe network.
I don’t know how the formula giving the cost per MB was computed and so I don’t know what it will become under this new condition but I suppose that it will be more user and farmer friendly.
By the way it would useful if Maidsafe open source their simulations so that we understand how the formula is computed.
Edit: Previously deletion of old data replaced deletion of sacrificial data, in the new version it comes after.