Specifics of the farming algorithm

[mav]

Specifics of the farming algorithm are being implemented in the vault repo (safe-farming is a fairly general repo, whereas vault implements the specific events and amounts for rewards and costs).

This is just my reading of it, I kept my notes and uncertainties so any clarifications or details are more than welcome.

Some useful comments starting here: Nodes participating in the system are rewarded for their work. Elders are responsible for the duties of keeping track of rewards, and issuing payouts form the section account. The points can be anything, but in our StorageReward system, it is the number of bytes of a write operation.
(minor typo ‘form’ > ‘from’ in the comment)

Reward amount varies depending on the amount of data being PUT, small chunks reward less than big chunks.
See commit feat(farming): accumulate reward on data write.

Farming parameters in feat(farming): update metrics on elder churn.
Velocity is hardcoded as 2 as per rfc0057 source.
cost_base starts as zero source.
cost_base changes depending on the estimated total nodes in the network source.
minting_velocity is calculated as 1/farmed_percent source.

store_cost starts as 0 source.
store_cost changes as load on the node multiplied by base_cost source. (I assume load is the node level not the section level? Worth double checking this.)
load is the change in the counter, ie current_counter / previous_counter source.
The counter is updated … not sure when? It looks like it can be deduced from elder_duties/key_section/payment/mod.rs? It’s incremented when process(PaymentDuty) is called.

cost_base is different to store_cost, think of cost_base as part of the calculation for store_cost.

[VaCrunch]

@mav

Elders are responsible for the duties of keeping track of rewards, and issuing payouts

Can they pay themselves?

[mav]

@VaCrunch

Can they pay themselves?

Presumably yes the same way that other nodes are rewarded. The reward must be agreed by a majority of elders. So no single elder can reward, it must be a collective action.

[oetyng]

Nice to see you picking up on this

@mav

any clarifications or details are more than welcome

Absolutely, I’ll happily answer any questions about these things.

@mav

Reward amount varies depending on the amount of data being PUT, small chunks reward less than big chunks.

That’s right, and to that comes a base cost, which is calculated every time there is an Elder change, and it is this thing here:

@mav

cost_base changes depending on the estimated total nodes in the network source.

(Should get it consistent there with cost base / base cost. TBD.)

@mav

store_cost changes as load on the node multiplied by base_cost source . (I assume load is the node level not the section level? Worth double checking this.)

This is on node (Elder) level, true, but will be more or less the same on section level, since they handle the same requests.

@mav

load is the change in the counter, ie current_counter / previous_counter source.
The counter is updated … not sure when?

Every time there is a write (attempt), the counter is incremented.
(This as well should probably get a better name.)

The load is thereby measured as a delta between periods of specific Elder constellations.

@mav

minting_velocity is calculated as 1/farmed_percent source.

A note here: this has been updated to unfarmed_percent / farmed_percent, which allows the velocity to go below 1 when farmed goes above 50%.
Update: This is now set as minting_velocity = ((unfarmed_percent / farmed_percent) + 1)^2, which allows all money to be minted eventually, albeit slower and slower. With this specific one, the earnings are 10 times bigger at 15% minted, vs 50% minted.

Additional note is that these numbers still need tweaking, especially to get sane results when prefix length starts to increase.
Also, I think the buffer supply of the network cannot be very high, since that in effect means (mostly, depending on impl) removing that money from circulation. So, a 50 % buffer means there’s only going to be up to 50 % of total supply in circulation, which somewhat defeats the purpose of the total supply.

[jlpell]

@oetyng

So, a 50 % buffer means there’s only going to be up to 50 % of total supply in circulation, which somewhat defeats the purpose of the total supply

Why not view the 50% buffer as a target, where the dynamics of the system allow for fluctuations about the steady state. To make this plausible you will need to include rate effects.

[oetyng]

@jlpell

Why not view the 50% buffer as a target, where the dynamics of the system allow for fluctuations about the steady state.

Well, this is essentially locking out 50 % of the supply. If 50 % is the target, and made to be a steady state, that’s what we get. This is because fluctuations won’t be large at that point (unless the system is made very unstable).
A better target would be to have almost everything minted, otherwise we’ve basically just said that the new supply is 2.1 billion instead of 4.2. Why set it at 4.2 billion if we’re only going to use 2.1 billion? We could have set it to 2.1 from start then, and allowed almost all to be minted.

[tobbetj]

Why do we have to create new supply? I don’t remember the cause. For every stored data on nodes, those get paid by clients.

It seems Blockhains like Bitcoin have problem that with relative few transactions per block the miners income can’t only come from transaction fees, artificially creating value to miners by giving them new coins as payment. The SAFE-network don’t have that problem. With supply/demand marketplace to buy coins there will never be a shortage.

If it is to pay developers then I think it would be better to create example 50-100 million more and give it to some created SAFE-organisation that supports developers.

Why not make max supply 450 million like today or example 550 million if a suppporting organisation needs funds to survive.

[oetyng]

There is a once set supply, that’s simply the reason. Since that supply has been set, it has to come out into circulation (otherwise, it is as if didn’t exist). Currently there is about 15% in circulation.

How this is done is by allowing upload of data to be cheaper than it really is, and having the network pay the difference to the farmers.
That way all that supply is spread out among the farmers until all is minted. At that point users pay farmers 1:1 and the network tops up with nothing.

This also means that the earlier you are in as a farmer the more you earn. The earnings will be much bigger when the network starts. The network will incentivise farmers to join because of this. It will also be much cheaper (in purchasing power) to store data early on, because of the network paying the farmers a large part. So that should incentivise users to upload their archives and backups etc sooner rather than later.

All of the above should combine to stimulate growth of the network.

[digipl]

@oetyng

How this is done is by allowing upload of data to be cheaper than it really is, and having the network pay the difference to the farmers.

[Traktion]

It’s great to read details about farming and safecoin. It is one of the areas that hooked me on this project years ago, when Bitcoin was still new. I can’t wait to see it in action!

Regarding supply, it needs to slowly increase to not create monstrous deflationary tendencies with the currency (when demand increases and supply doesn’t). It would make it hard to use in a meaningful way.

I do wonder whether a total supply is a good idea in some ways, as it ideally should track/adjust to demand indefinitely (both increasing and decreasing total in circulation). Im conscious of what the white paper defined and what people have bought into. Maybe that is something for a future fork!

What is proposed is still far better than the sort of distribution Bitcoin et al use, which is much more rigid.

[mav]

@oetyng

base cost, which is calculated every time there is an Elder change
…
The load is thereby measured as a delta between periods of specific Elder constellations.

I don’t foresee any issues here but the event is interesting. It may (but hopefully does not) motivate DOS of elders (to remove them and thus trigger the event). For example elders changing rapidly gives a load very close to 1. It’ll be interesting to see in testing how much load varies. I guess this range will be different for a young network vs old network since elder change will be less frequent in an old network, also the counter will change at differing rates depending on network age…?

Seems like a nice challenge to try analysing the dynamics of the load parameter. Load is one of those simple-but-complex parameters.

@oetyng

[variable naming is not] consistent there with cost base / base cost. TBD.

Haha I hadn’t noticed this! Ctrl+f shows 7 of each, so a tough decision ahead!!

@oetyng

@jlpell

Why not view the 50% buffer as a target

this is essentially locking out 50 % of the supply

When reward is on PUT like in rfc0057 it makes sense to target 100% with gradually slower approach over time. The ‘recycling’ and the ‘minting’ are triggered by the same event so operate in lockstep.

But if PUT recycles and GET mints then there needs to be a target less than 100% since there can be periods of mostly recycling or mostly minting. Since the minted coins must never go below 0% or above 100% the economy must push toward some target amount between 0-100%.

The economic design has changed from rfc0012 to rfc0057. rfc0012 is PUT will recycle and GET will mint. rfc0057 is PUT will recycle and mint together.

In rfc0012 total coins in circulation can go up or down.

In rfc0057 total coins in circulation can only go up.

This difference calls for very different control mechanisms.

I’m not sure how much can be learned about one mechanism from the other.

For now rfc0057 mechanics is fine to get a testnet running, but I feel it does not economically ensure permanent data so we will end up with rfc0012 style dynamics.

It’s a can of worms for sure. Would be interested to hear other opinions.

@oetyng

Since that supply has been set, it has to come out into circulation (otherwise, it is as if didn’t exist).

This is only true for rfc0057 style economics.

In rfc0012 where there are boundaries at 0% and 100% with a push-away requirement, those boundaries still have a purpose even though they are never touched (ie ‘never exist’).

If the total coins minted can only go up like in rfc0057 then it makes sense to gradually approach the upper bound and it’s true that if they aren’t minted then it’s as if they didn’t exist.

I feel a lot hinges on this line in rfc0057: “For now, we will use an algorithm which would eventually deplete all farmable coin, but which is simple to implement while we gather further data from testnets.”

My main question from this is, how will data be ensured to be permanent? Rewarding only on PUT as in rfc0057 seems to make this difficult to achieve, although maybe I am merely lacking imagination.

I see this discussion is getting away from the topic of pre-dev-updates so maybe it is time to move to another topic?

[oetyng]

@mav

I feel a lot hinges on this line in rfc0057: “For now, we will use an algorithm which would eventually deplete all farmable coin, but which is simple to implement while we gather further data from testnets.”

My main question from this is, how will data be ensured to be permanent? Rewarding only on PUT as in rfc0057 seems to make this difficult to achieve, although maybe I am merely lacking imagination.

Quick answer: With what is in place now, there is no “depletion of farmable coins”.
Users will always pay for the data, and that payment always goes to farmers. What eventually ends, is the network bonus added on top.

[drehb]

@mav

My main question from this is, how will data be ensured to be permanent? Rewarding only on PUT as in rfc0057 seems to make this difficult to achieve

One option is having farmers post a bond and slashing them when they fail to deliver the data they are responsible for.

[jlpell]

We need both PUT and GET rewards for farmers.

[oetyng]

@drehb

slashing them when they fail to deliver the data they are responsible for.

This should already happen.

So, we have these things that ensure data permanence:

1. Data is always paid for.
2. If you stay around you get part of that money.
3. If you don’t deliver data that you should have, you get kicked out.

So, if you get kicked out, you won’t be staying around, and you get no money.

There’s a misunderstanding that when network stops topping up the data payments, that farmers wouldn’t get paid. It is wrong. They get what users pay then, 1:1.

@jlpell

We need both PUT and GET rewards for farmers.

Not obvious why we need it. The above would seem to do what’s necessary. Maybe you’d like to elaborate, based on the current solution of course, so that it can be seen what it solves and how.

[oetyng]

@mav

It [load] may (but hopefully does not) motivate DOS of elders (to remove them and thus trigger the event). For example elders changing rapidly gives a load very close to 1. It’ll be interesting to see in testing how much load varies. I guess this range will be different for a young network vs old network since elder change will be less frequent in an old network, also the counter will change at differing rates depending on network age…?

The write counter is incremented after payment, so it’s not an unrestricted influence on state.
At some theoretical level of course the cost is not prohibitive.
It’s a simple way of measuring some of the load, which could be useful. I’d rather measure percent filled at nodes, but I don’t have access to such measurements at the moment.

@mav

But if PUT recycles and GET mints then there needs to be a target less than 100% since there can be periods of mostly recycling or mostly minting. Since the minted coins must never go below 0% or above 100% the economy must push toward some target amount between 0-100%.

This is just more complicated I’d say, to no important benefit to farmers or the system.

@mav

rfc0057 is PUT will recycle and mint together

Current implementation merely has similarities with rfc0057, it is a distinct system.

@mav

For now rfc0057 mechanics is fine to get a testnet running, but I feel it does not economically ensure permanent data

I don’t think it does either, but again, current implementation is not rfc0057, and does not share that problem I’d say.

@mav

This is only true for rfc0057 style economics.
In rfc0012 where there are boundaries at 0% and 100% with a push-away requirement, those boundaries still have a purpose even though they are never touched (ie ‘never exist’).

I disagree. If there is an upper boundary that is never or practically never crossed, then the supply above that percent effectively does not exist. The practically available supply is that what will be in circulation. If the phenomenon happens to have a use as a “buffer”, it is simply as to work around the created problem of imbalance in supply due to rewarding on GET.

Anyhow, doesn’t matter much here as we are aiming for getting everything into circulation.
I actually don’t see much point in not getting everything into circulation (eventually). It’s like saying 3.7 bn is better than 4.2 bn. If we had said 3.7 bn, then that would have been the number, would we then mint only 3.3 bn?

@mav

My main question from this is, how will data be ensured to be permanent?
Rewarding only on PUT as in rfc0057 seems to make this difficult to achieve

This system does not reward on PUT though. It does distribution calcs and accumulation at PUT. But it rewards on relocation, and section splits.

Nodes are rewarded for staying around, and they are prevented from staying around if not storing the data as expected. So, there needs to be checks on data, if data is not requested often for example. But that problem is there with various systems.

[tobbetj]

@oetyng

There is a once set supply, that’s simply the reason.

Not satisfied without something deeper more tangible

@oetyng

This also means that the earlier you are in as a farmer the more you earn.

Or that there will be 15% more farmers which will earn the same as without artificial incentive. But what is the purpose, the reason? Are we in very much need of 15% extra farmers? In the beginning it might be wanted to have more farmers but there are probably much better ways, efficient ways giving way higher then 15% boost, for example airdrop to new participants. Once the network get’s traction there is no need for 15 earningsboost that might give 15% more farmers.

It is artificial incentive without significant good reasons to exist, it might cause more harm then it does good.

• For example what will current supply look like on exchanges, does the network know current supply or will exchanges just show current supply = ? If the current supply is unknown then is there a chance that current price being calculated with maximum supply, that would be devestating early on. Coins that suffers 10x inflation within the first year might dig an early grave, too much inflation might affect trust in very negative way.

• Second reason is that a fork which would set a fixed maximum supply might render our project dead on arrival. A fork with a fixed maximum supply would be superior every time. It opens up for unnecessary attacks on the project. As creating 15% new coins until 4.5 billion don’t have a significant purpose then there is no loss for fork setting max supply to something like 550 million.

@Traktion

Regarding supply, it needs to slowly increase to not create monstrous deflationary tendencies

You mean inflationary tendencies, more coins to current supply = inflation, If less coins to current supply = deflation.

[bones]

You would rather airdrop than pay farmers.
Seriously? Thats a joke.

[oetyng]

@tobbetj

Not satisfied without something deeper more tangible

It really isn’t deeper than that.
If David and gang back in the days had said 6.45 bn, or 65 bn or 0.0065 bn, then that would have been the number. If any other number, then that would have been it.

I’m rather more concerned with getting enough “nanos”, or “picos”, as to support enormous networks and the smallest payments that would be considered useful.

If we look at nanos, we have ~4.3E18 units of payment. You could choose to call things gigasafecoin, and then we only have 4.3 gigasafecoins. And if we call safecoins for nanos, and gigasafecoins for safecoins, then we have 4.3 safecoins and 4.3bn nanos. But nothing changes in practice with that. As you can see, it’s not very useful to get hung up on those things.

@tobbetj

But what is the purpose, the reason?

It’s quite simple actually. If you don’t have a net minting, then you are stuck at 15% supply (current supply).
The way you do net minting, is to take from the network unminted, and give to someone, and make sure more is given out than comes in as payment for data.

Seems the most fair thing is to “give” that money to the farmers, for their work, aka Pay them for their work.

So, this could be identified as an incentive, due to the fact that a farmer will get more at some point and less at another point. And payments, money, is an incentive.

If you think that is artificial, then probably the whole network is artificial. And when I come think of it, yes it is
But, how would you propose to get the unminted coins into circulation? In one way or another, the flow in that direction has to be higher than the flow in the other direction.

@tobbetj

It is artificial incentive without significant good reasons to exist, it might cause more harm then it does good.

Nah, I think you are seeing problems where there are none. The “good reason” is that there is no other physical way of getting the money out than to actually get it out. We could do airdrops and lotteries and all sorts of things, but I think the simplest and most reasonable thing is to pay farmers?

@tobbetj

Coins that suffers 10x inflation within the first year

This is far from the numbers I’ve seen. The simulations I have done has rather been showing that it is hard to get enough money minted. It takes time to get it out.

[tobbetj]

@bones

You would rather airdrop than pay farmers.
Seriously? Thats a joke.

If there would be an initial need for farmers early on in the beginning of the networks life, then yes, that would be one option to choose. No, not to substitue for paying farmers as they getting payed by clients/users of the network.

@oetyng

It really isn’t deeper than that.

There needs to be alot deeper than that, such an important thing that will have a chance to impact the success of the network needs much deeper thinking. What maybe was right over 10 years ago might not be true today.

@oetyng

If we look at nanos, we have ~4.3E18 units of payment. You could choose to call things gigasafecoin,

I don’t care for prefix, I care about large inflation which could have very negative effects the first years of the network existence, very important years.

@oetyng

If you don’t have a net minting, then you are stuck at 15% supply (current supply).

Yes that is what would be good if the supply would be fixed, because a supply/demand market will always find a price, so there will always be coins you can get. And with the balance of more farmers can join if earnings are higher then store cost could be the same regardless the price of the coin. There is no need for minting coins as clients pay farmers.

I hope we can get much deeper talks about this because it is very serious and very important. And also some of my important points, about if the network will know current coins in circulation, have not yet been answered

I know you have built economics software and such but I get a feeling that the problems
is on another level and would need knowledge closer to a economics professor in macro/monetary economics.

@oetyng

We could do airdrops and lotteries and all sorts of things, but I think the simplest and most reasonable thing is to pay farmers?

Farmers get’s payed by clients who buy data storing space from farmers, there is no need to mint about 10x new coins, which might give a hyperinflation like the GRIN coin.

Grin pris idag, diagram och börsvärde | CoinGecko