search

threefoldtech / minting_v3

minting code for grid v3, using v3 tokenomics
Apache License 2.0
0 stars 0 forks source link

Uptime enforcement not scaled with connection time #32

Closed scottyeager closed 2 weeks ago

scottyeager commented 3 weeks ago

My understanding was that uptime enforcement should be based on uptime percentage scaled according to the node's connection time, but having observed the results from the most recent minting it seems that is not the case.

Checking the code I see that this uptime percentage, which is explicitly not scaled

https://github.com/threefoldtech/minting_v3/blob/3b59eee6393c959828e39d84cd34e760e272d83b/minting/src/main.rs#L2054-L2055

is also used for the SLA enforcement:

https://github.com/threefoldtech/minting_v3/blob/3b59eee6393c959828e39d84cd34e760e272d83b/minting/src/main.rs#L2077

Therefore a DIY node that connected after more than 5% of the period has passed can't possibly pass this check and therefore won't mint. Is this the intended behavior?

LeeSmet commented 2 weeks ago

This is indeed intended. Uptime scaling in the period was implemented initially since we wanted farmers to migrate from v2 to v3 ASAP, and not doing that would mean farmers should wait until roughly the period end to avoid loss of rewards. The plan was to remove this after most of the v2 farmers had migrated (i.e. to only enable it for a couple of months). The comment is a leftover which should have been removed, but also indicates why we still had the scaling when we switched to linear payments on V3: in a linear payment scheme, the scaling of both the period to the actual time between connecton and period end, and the scaling of the payout based on uptime in the aforementioned calculated range, cancel out. Essentially, if a node is started roughly 3.045 days before the period end, and is online for 100% of the time, it will get 10% of the reward, irrespective if of whether we calculate the reward for 100% of the shorter duration, or if we calculate 10% uptime in the total period. So at this point, the only purpose of the code was to have the start date nicely marked in the overview file. Since we now enforce the SLA again, this changes is reverted back to what was initially intended. It should further be noted that scaling this has always been considered a bad idea, since it undermines the idea of SLA entirely as long as a node id is cheap to create.