Suggested farming reward improvements

#1

Dear all,

I believe it’s in all our interest to make sure that farming is in line with intended purpose of the TFGrid.
As such we believe that all together we need to look at possible scenario’s where farming rewards would not be fair or in worst case even can be abused.

Some scenario’s

1. 3node capacity cannot be fully used.

Example. 3Node has 1 TB SSD, and one customer reserves all SSD but with low/cpu requirements.
This means that the 3Node can no longer be used for new virtual machines because there would be no available storage space, which means the box is no longer useful for grid.

Example, a 3Node has not enough CPU to service the storage available.

2. Farmer does not have enough bandwidth available or internet connection unstable.

Imagine situation where farmer has large amount of storage capacity but the bandwidth available (size of internet connection) is not enough which means storage can never be fully used.

Ofcourse same issue when network connection is unstable e.g. packetloss …

3. There are too many nodes in 1 location.

In an ideal scenario, capacity is as distributed as possible.

Some Possible Solutions

Measure quality of network connection.

I case network is overloaded (can be measured), the farming reward is lowered automatically or if really not good enough the service level agreement is broken. This was already planned anyhow, measuring bandwidth & quality should be done.

This resolves partially 2 and 3.

Some additional capacity planning rules with impact on reward.

We could introduce some additional rules to make sure computers are well balanced, e.g. minimal CPU requirement for storage size, e.g. measure speed of network if not enough to allow people to use storage lower the reward.

Additional rewards for more distribution.

Reward farmers more if the distance between their node and other nodes around them is large, this is also I believe something Helium did.

Additional rewards if machine is used above certain percentage.

e.g. if machine is used + e.g. 50% give additional rewards. This would motivate farmers to promote people to use their machine and have an interest in utilization. We could even work with 2 levels e.g. 50% and 75%.

Feedback

  • Do you know other scenario’s we need to think about?
  • Any other solutions?

As always feedback more than welcome.

3 Likes
Let's share our farming setup
#2

I think scenario 1 is better address on the utilization side. Farmers have no control over what is deployed to their node, and no matter how much storage it has, the scenario is still possible. This is already addressed on the farming side through the SSD requirement for CUs. For utilization, this could look like a requirement that reserving the whole SSD means reserving all the CUs (or half/half, etc). Deployers who need lots of SSD and low CU would then be motivated to deploy on nodes with larger amounts of SSD relative to their CUs.

Adding additional rules around hardware configurations is not something to take lightly. Farmers are investing in gear based on the current rule set and simulated returns. Any changes that impact farming rewards should go through due process, including public comment and DAO deliberation or voting, in my opinion. I think we need to be more careful with how decisions are made, rolled out, and communicated.

Some idea of network speed should definitely be considered in farming rewards. How to handle this exactly is tricky. We must first define what the bandwidth expectation are, and then implement some reliable way to measure this. This is not really a change, as you’ve said, but at least making requirements concrete will help avoid it feeling like a surprise when activated.

As far as node distribution, I don’t think it’s as simple as distance. Nodes will tend to be clustered around populations centers, where more capacity is needed. I think that offering TFT grants or bonuses from the foundation for installing capacity where it’s lacking is a better approach than trying to build this into the farming model, at least to start.

Finally, increasing rewards when nodes are utilized is intuitive and provides another incentive to install capacity where it’s needed. As long as this is built in as a bonus on top of existing rewards, rather than a penalty, I think it should be considered.

3 Likes
#3

for 1, yes, indeed SSD vs CU can be addressed at provisioning side.

There is no need to change anything for already registered farming rewards, they are stored in blockchain and should be ok.

But SLA (Service Level Agreement) is something different, the docs are very open about the fact that the current SLA definition is too light and need to be improved, I think most of above worries can be addressed that way. e.g. not being able to fill up storage to me is same as SLA cannot be met. It’s not in the benefit of the TFGrid to allow someone to provide 100TB behind a small DSL line, it will never be filled. We can choose to implement this by means of SLA or do a protection when CU/SU are calculated. We have to think what to do with locations where this is already the case.

Ofcourse anything impacting the TFGrid should be discussed and voted for, but isn’t this what we are doing here (-:

There is another possible issue I see, which can be partially addressed at provisioning (utilization) side which is, what if there is a large storage farmer and you decide to put a lot of your data onto this one farmer. Then in 2y from now for whatever reason that farmer removes the storage, this would put a lot of strain on the network because so much data would have to be re-generated. We need to think how to make sure that A: farmer with lots of storage is certified so people know what to expect or B: data is decentralised enough so impact is small, but this leads back to making sure one side does not have too much storage unless A is covered.

2 Likes
#4

Good points here, and an interesting topic. As @kristof you do often this is something that nature must have figured out for us, and nature tends to end up in a harmonious balance between demand and supply. I don;t have a real example or answer now but will let this topic process in the background and look for nature’s inspiration this weekend.

4 Likes
#5

I think this one is quite impossible to do for the daily user who set up servers to farm TFT. Most of us have set up multiple machines at our home to help the network and also earn tft. If this reduces the reward base on multiple nodes in one location. It will have a negative impact on the network.

2 Likes
#6

I think farmers are interested in TF Grid’s health and resilience. Most, I’d say, come in part thanks to the great ethos of Threefold. Concerning the point 2., and the availability of bandwidth, if we can give farmers the information needed such as bandwidth needed per farm, 3 nodes and loads, I am pretty sure farmers would go on to honour it seriously. Matter of facts, I think many are trying to figure this out as we discuss.

For those who would not follow the ratio, once that ratio has been properly communicated and given enough time for farmers to adjust, indeed then there could have negative consequences. That being said, these type of negative reactions must always happen after knowledge has been communicated. Without knowing what is the right ratio, how could one know and build in consequences? (In the bright side, if some farmers learn they have a too low bandwidth for many nodes, this could incentivize them to reallocate some resources and it would thus help point 3., too many nodes in 1 location.)

Also, the farmers themselves would be penalized as users would run away from ineffective farms with a bottleneck in data transfer. Users will go and pay for effective farms with the best statistics on Threefold’s market (demand and supply). As per game theory, farmers will thus rationally decide to follow the best bandwidth/load ratio if it directly benefits them (good ratio = more chances of cultivation!). Having this ratio knowledge is a win-win for the community and the users.

Personally, I asked around a lot to find out the bandwidth, and I haven’t found the exact answer yet. So I can’t predict with accuracy.

What I got so far was that a fibre connection (1.5gbps/1gbps, up, down) was a big enough number to encompass a big farm, so I made sure I could have access to this level of bandwidth before building.

Also, there could even be smart contracts on the grid that would guide users to specific farms and 3nodes that are suited to their needs. So if someone needs e.g. a low CPU, high HDD storage 3node, the Grid would provide a list for them to choose and explore. This would obviously maximize the efficiency of the Grid itself and make sure 3nodes are fully or maximally used, thus helping point 1..

What Kristof said is of great importance:

what if there is a large storage farmer and you decide to put a lot of your data onto this one farmer. Then in 2y from now for whatever reason that farmer removes the storage

Could it be possible to have a mechanism that freezes TFT rewards if someone acts like this? And implement a system where if a farmer wants to leave, they are strongly invited to advise 1 month (or more) before, in order for the Grid to have time to reallocate the load.

As rewards are paid monthly, there would be a time in the month where you’d need to give your one month (or more) notice as a farmer wanting to stop farming, then the Grid have time to reallocate the load (the user is asked to change farm) and it could be done safely, not manually, during the given period by the TF Grid. Then, when the farm/3nodes have been reallocated, the TFT is unfrozen and the farmer can spend it. It can be more than a month depending on the size and value of the loads, etc. Would this help prevent such situations?

4 Likes
#7

For those of us who plan to spend as much renting rack space as they do renting their home, additional rewards if machine is used above certain percentage is a fantastic incentive. I have a nice geographically spread out network of smaller consumer grade nodes, but I also have almost 3/4 of a rack full of nice stuff. One of the motivators of the rack is that the larger capacities and higher speeds will be more attractive to network users and reach a high usage percentage.

2 Likes
#8

Agree - there is a spectrum of use case for grid capacity and the two categories are:

  • close together to create speed, IOPS and HA
  • spread out to be disaster proof and reliable.

both have good and specific use cases. What we are talking about here is how do we create (if needed and then agreed in the DAO) incentive to go to the less obvious places (not in the home/garage and not in a DC).

1 Like
#9

Finding the right capacity for a given workload is definitely a feature that can be improved. Our weblets already have something like this working on a pretty basic level. It really doesn’t require anything new within the Grid itself, just a system that can query available capacity and then deploy to the right place.

Regarding the question of removing storage from a node, it could be the case that locked farming rewards on minting v3 simply don’t unlock if a node has reduced capacity (or they unlock proportionally to what’s left). However, that doesn’t help in the case that someone waits for their rewards to unlock and then takes capacity offline. We could do some things to discourage this, like resetting the lock conditions or token price used for calculating rewards. If someone wants to stop farming entirely after they get their tokens, I don’t see much we can do to discourage this (hazard of a decentralized system).

The idea of allowing farmers to signal when their nodes are going down for maintenance or migrate workloads when they need to retire a node came up before. To paraphrase what I wrote in that thread, I think it’s best to avoid introducing complexity and management features into the core system. Farmers who want to offer communication around planned downtime or removal of nodes can certainly do so through channels that they manage.

I don’t think requiring certification for large farms is really a solution. Certified farmers may be less likely to take their capacity offline, but it is of course still possible. In either case, things will happen–people will decide to close shop for whatever reason, disasters will destroy hardware, and so on. The network will need to tolerate some amount of these events no matter what.

Ultimately, I think there are strong incentives already under minting v3 for farmers to keep on farming. If the token price keeps growing, they’ve locked in a minting rate that gets more attractive with time. Maybe there’s something to think about there. If nodes go offline for too long, they could lose their minting rate. This would discourage farmers from jumping ship to new projects that might offer attractive but unsustainable yields, for example.

4 Likes
#12

Another element that came up to me is that we should provide some elementary ‘stress test’ workloads, able to identify the reliability of the node setup. And a reliability score is certainly an element that will push farmers to provide the best internet conditions for the capacity users.
I concluded that there is already a workload that has given me in the past a lot of information on the stability of my infrastructure. Already in times of the VDC on TFGrid2, I ran a Presearch node, and I continue to do so on TFGrid3, because it gives me a lot of benefits:

  • It is a very lightweight container, does not consume a lot of resources and doesn’t cost a lot (in phase 1 of the Presearch node project, it simply routes searches over a decentralised network of IPv4 addresses; crawling and indexing will come and will be heavier, but is for a later phase)

  • I get a permanent report of how my node has behaved in the past 24hrs
    Screenshot 2022-02-11 at 15.15.17 .

    It showed me in VDC times when the K8S cluster disconnected, and it shows me now that TFGrid3 is way more stable than TFGrid2 (no interruptions at all since I first launched my node). And Presearch sends me an e-mail mail message when the node is disconnected for more than 5 minutes, and also when it reconnects.

  • I contribute to another project in the decentralisation of the internet, as I help with a decentralised search engine. And I know my search behaviour is not being abused to create my user profile. I am not tracked.

  • I earn a passive income (OK, it’s only a bit more than 1 PRE per day which corresponds to about 0.30 USD / node/day, but it basically covers my expenses in TFT usage).

  • It makes me think about my own internet connection: I ran a node with Freefarm which gave great results. Reliability of my home node, however, was way lower, to me a signal to check for a provider giving me a better upstream speed on my connection.

PRE is just an example of how easy it would be to bring reliability as a factor to reward farmers. It’ll be available as a weblet, however, running it inside a VM is pretty easy as well (if you want to know how to do it from the playground, here are some instructions.

I know that in the Threefold tokenomics there is already a reliability factor in terms of uptime, but a refinement seems justified.

5 Likes
#13

I like the idea of tracking and rewarding reliability somehow.

#14

Definitely something we (DOA in the near future) are working on. We will start a topic on the forum to discuss. :slight_smile:

3 Likes
#15

Curious to learn which challenges a DAO should fix? A description I hear from time to time is “a group chat with a bank account”. I’m not saying it’s pointless, but most “shared decision models” gradually evolve into delegation. In other words: leave the decisions to those in the know.
On a not so side note: there aren’t that many proper legal structures for a DAO. So be careful on how it looks like from a legal angle.

#16

If I understand the farming system correctly, the main reword is based on PoC, regardless if the capacity is being used or not (the lock period is affected not the reword amount). And that for the beginning if fine in order to build the network capacity but if that capacity is not used (or the network has a significant excess of capacity) that does not affect the farmer. If we were to gradually link the rewords to the PoU (i e. 50% of your rewards depends on capacity provided while 50% on how much it is used) the farmers would also become sales reps for TF actively promoting the network usage. Also it would prevent adding unnecessary capacity before time in one place, as if it’s not in use the farming is less attractive. Once again, I’m new to the community so perhaps I just didn’t get the farming system correctly :slight_smile:

#17

@KoenVingerhoets. Well said. It is a tricky balance between attracting people that have material knowledge on certain topics and others that have less. Still, at this point in time, we believe the best strategy to make the ThreeFold grid go large is by making it a people thing.

#18

You are 100% correct: Farming get farming rewards and you get 100% of them by making capacity available (Proof of Capacity).

Capacity consumption requires tokens and those tokens are put buckets as follows:

Percentage Description Remark
35% TFT burning A mechanism used to maintain scarcity in the TFT economy.
10% ThreeFold Foundation Funds allocated to promote and grow the ThreeFold Grid.
5% Validator Staking Pool Rewards farmers that run TFChain 3.0 validator nodes.
50% Solution providers & sales channel managed by ThreeFold DAO.

Please find more details here

1 Like
#19

I’ll add that farmers acting as sales channels for their own capacity is in line with what @petar was suggesting.

#20

I hope @scott won’t mind that I post his answer from the Telegram ThreeFold chat group here.
It may help others as it helped me to better understand how the current reward system is actually working.

Under the current model, the only advantage to the farmer in utilization is if they are the sales channel. There have been proposals to boost farming rewards for nodes that reach certain utilization levels

You are correct that utilization would create additional electricity and bandwidth consumption without creating additional rewards, unless something changes

The sales channel field is not exposed in any interface to TF Chain currently, but anyone is free to build a front end that diverts the sales channel revenue as they see fit. One idea I think is cool is a farmers coop for marketing capacity, where most of the sales channel revenue goes to the farmers but some is split off for a marketing/operations budget

1 Like
#21