When the network adjusts the price per put it needs to have some concept of over/under supply of storage space.
What metric will the network work with? Will each node/vault declare how much storage they are willing to offer? How can this be verified/enforced/not gameable?
The network wants 30% freespace available. So when the Vaults spot it’s falling to 29% they raise the Farming Reward so Farmers make a bit more. If it falls to 28% they’ll raise the FR a bit more again. This could be done in an exponential fashion. So at 30% freespace the network has a FR of 1. At 29% it could be 1.02 and at 28% it could become 1.04. It works the other way around as well. At 31% freespace you might earn 2% less as a Farmer with a FR of 0.98.
These algo’s will be tested with test_Safecoin.
Is there a more detailed proposal around for an algorithm for this exponential increase/decrease in FR with regards to this desired level of 30% available?
Thanks for the reply @polpolrene. What I was actually asking is how does the network know if a vault is legitimately offering x amount of storage space and will actually supply this?
Surely vaults would just announce a minimum amount of storage pledged to the network as this would keep their reward as high as possible while giving them the same chance of storing a chunk (this is dependant on vault identifier, not amount of space pledged).
This is an area that will be crystalised with testing. The RFC is still old and only really a conceptual RFC. Some things have changed enough to mean the RFC needs updating for the amounts.
The vault s/w will announce what you allocate.
But yes it is in the interests of all farmers to allocate a smaller amount rather than massive amounts to their vaults. This will also happen naturally as the farming rate decreases. That is people will stop farming if the rate is too low thus reducing the available amount of space and cause an increase in FR.
Thanks for chipping in @neo!
That seems gameable to me. To optimise, a vault would simply announce 1mb at any time. Every time they store a chunk they would announce another 1mb of free space. This would keep storage available to the network artificially low.
You can only announce what you have though. At some point, there will be no more 1mb to offer. At a global network level, this will still work for accessing currently available space.
To put it another way, the network only needs to know what is actually available, not what is held offline in reserve. If that global number becomes lower than desired, a price increase will tempt more nodes to come online.
There will be no waynto limit nodes or what storage they offer. The algorithm will therefore have to adjust to play the game well too. If everyone says they have little space, clearly relying on this figure will be no good.
There is an old RFC about safecoin and farming rate implementation. Possibly there will be changes but gives clues about its final design.
Everyone will say they have little space. There is incentive to do this.
Perhaps vaults will need to be penalised if they change the declared amount of storage pledged to the network.
Your vault would suffer. It would need to reset and rejoin thus may have to wait to be accepted again. Also the contents it did have is lost. So you have to have it filled from scratch again.
Also you only get paid when you retrieve chunks for others.
Also even if you could do this it would not have much effect. 1 Mbyte compared to peta/exta bytes will have no difference on the FR.
If everyone tried what you suggest and it could work then the free space increase would only drive the FR down.
It has to change since sacrificial space is no longer
Yes in this moment but possibility the basic idea of using extra copies as farming rate control will exist. Even in the actual routing the idea persist:
/// The loss of sacrificial copies indicates the network as a whole is no longer having
/// enough space to accept further put request so have to wait for more nodes to join
@Deadloch I think you are right that there’s an incentive to declare/allocate a small amount of free space, so this will need to be addressed. Any ideas yourself?
Thanks all for the responses.
@happybeing this is only an issue if vaults are able to adjust the amount of storage they pledge to the network.
If they are not able to change this amount (that they state they are willing to supply the network) then FR won’t be gameable.
I’m not even sure if this is how the network is intended to calculate over/under supply of resources, (by relying on what vaults say they are going to supply) hence why I posted.
I’m planning on writing a blog post addressing the economics of Safe (the only success hurdle left in my opinion). It’s important my understanding is correct before doing this.
Vaults can never be trusted to be honest. We have to expect they will be dishonest, in fact. With this in mind you either don’t trust them or you spot test them to confirm they are truthful.
With that in mind, we have to assume that available vault storage cannot be trusted. Any algorithm foe changing the reward amount must therefore be based on areas we don’t need to trust. Specifically, that they a vault stored the data and was able to confirm that was delivering it at a random later date.
If you blitz the network with tiny nodes and little storage in each, building up rank will take a long time and farming rewards will be limited. If you have one big node which gains rank bit then stops delivering the data it said it had, rank will be lost, as will farming rewards.
The farming award just needs to balance these. If a vault always stores data requested and always returns It on request, you can work that into the farming rate algorithm - lots of highly ranked nodes is likely to mean lots of storage availability in the future too, for example.
The important point is that the farming award can be adjusted to suit conditions. There are many ways you can measure these conditions and I am certain many will be explored and tested to destruction before any live safe coin is released.
We have discussed this question before, most recently here:
You are going to have to write without knowing the solution I think. The community often have debates about these kinds of issues, and then MaidSafe come in with their code (sometimes with community influence, but usually better 
) and then that can evolve further during testing, until we get to find out how this network works!
I look forward to reading your article. Good luck.
Thanks for linking that @happybeing, great to see @mav asking the exact same question.
@Traktion, I believe the economics behind safe will be structured around one thing. A magic line in the sand that defines a point (% oversupply of storage) that is optimal. @polpolrene mentioned earlier in this thread that this could be 30%.
The network dynamically adjusts farmer reward in order to hit this target. People have mentioned the farming rate will be ratcheted. (I think this approach is sub optimal and that in reality put cost needs to be the lever - I will address this when I write my blog piece).
Either way, the network needs to rely on the storage amount vaults are ‘pledging’ to the network as being correct. @Traktion I understand we don’t want to involve any element of trust here, and I’ve also come to the conclusion that this arrangement is gameable unless vaults are unable to alter the amount of storage they are ‘pledging’.
Vaults will have to state how much space they are willing to offer the network when they join and not be able to change this amount. (There will also need to be a maximum limit).
Agreed, but what defines this line in the sand is still not fully defined. A number of elements will likely contribute to this. The core desire is to ensure there is sufficient storage at the best price.
I think not allowing adjustments after the initial pledge would be way too restrictive and ultimately detrimental. Although I do see the potential problems you are bringing to light.
I would suggest freezing out any rewards and not receiving any new chunks for some period of time (maybe something like 24 hours) after every change.