Upgrade proposal for minting code v3.2 (CLOSED)

[sabrinasadik]

Welcome to our first Grid Enhancement Proposal (GEP) for TF Grid 3.0. As the DAO is not yet live, we are executing this GEP by means of a forum post and poll.

This Grid Enhancement Proposal aims to get approval for upgrading our minting (farming) code and corresponding documentation as well as some confirmations for our single source of truth.

Inconsistency in the documentation on wiki in relation to minting

In v2.0 we always used 1024 as a base for going from (as an example) MB to GB. In v3.0 it was specified on the wiki as 1000 (MB to GB), while in the code it was 1024. This was a documentation issue. The wiki will be adjusted to 1024. To clarify, the minting uses base 1024 when expressing gigabytes, i.e. 1 GiB = 1073741824 bytes. A section in the wiki will be added to clarify this. Pull request: see here.

Please note we will only ask approval for upgrading the wiki if the information is important for anything to do with calculations or pricing in relation to farming or cultivation – otherwise it will become too heavy.

Bug Fix in Minting Code

Thanks to our community reports we found a bug in the minting code. This bug only affected the February minting.

The bug caused incorrect calculations for some of the nodes on the TF Grid. The issue has been fixed and is ready to be implemented. Code is available to rectify the past minting period (February) and can be executed after achieving consensus. Fixed code is here on Tag v3.1.1.

Please note that the minting code is executed off-chain. Our Grid Guardians do the verification. A human blockchain of 5 people out of 7 need to sign the minting process result. The minting code gets the information from the TF Chain blockchain for TF Grid 3.x. The TF Chain blockchain keeps track of the uptime reports in non-modifiable ways by the Zero-OS nodes.

The minting code is fully deterministic and reproducible by everyone, all data comes from the TF Chain. The minting code (tool) produces reports which can be looked at by everyone.

After approval from the community, a new minting cycle will happen to fix the bug for February.

For safety reasons, the minting for March will happen on the 8th of April, not the usual 5th of the month, to give us more time to verify the process.

Uptime simplification in minting code

There are requests to simplify the uptime calculations in farming/minting logic. We suggest implementing a payout in relation to uptime achieved. So if a node is 85% of the time operational, it gets 85% of the farming. This will simplify the process for now and be most easy to understand.

Once the right tools are in place, it will be easier for farmers to monitor their node uptime, and the uptime requirement will go back to a minimal uptime requirement in order to unlock farming rewards. The logic behind this is that a node which is down too much is not usable by anyone, so there is no reason to reward the farming.

Minting code will be tagged as 3.2 when finished, see here.

Acknowledgement of single source of truth in relation to minting code

Information in relation to how the minting code works is on: https://library.threefold.me/info/threefold#/tfgrid/farming/farming_reward

Voting Terms

Poll will be closed on Friday 18th of March at 8am CET.

Minimal required positive votes = 60%

• Agree
• Disagree

[sweden]

I choose to agree, but my alternative suggestion would be that if your node is online and operational 90%, you should get 100% (happy to take another threshold)…just my thoughts

[duckpond]

Honestly this seems like a good idea and I wholeheartedly agree.

Maybe like Sweden suggested a small error threshold (99% Uptime = 100% reward) or even a smaller margin to offset any small downtime windows.

[FLnelson]

Just to clarify, these are three independent issues/proposals?

[Mik]

Nice. I added the 8th of April for March Minting in the FAQ.

[FLnelson]

Can you elaborate on what the bug was?

[hagenaar]

I agree but would add a lower boundary as well, for example minimum uptime of 60%

[FLnelson]

I think this rule is just temporary as people setup their nodes. When we get down to business the strict rules will resume.

[duckpond]

I think we need some elaboration from the team in regards to this and the points you raised

[m19s]

As a temporary it seems to be a good solution - buying time for devs and bringing forgiveness to those people who misunderstood previous minting rules.
In a long term i prefer previous minting rules.
Why? Because faultless network can bring more investors.

[isyal]

I have such Bugs - in my and mine friends nodes ZeroOs see SSD disks as HDD - i should recive about 5200tokens but i took like 600 because of it. What’s more that some friends lost their’s node id when they checked disks in RAID controllers ( main disk is plugged into Sata socket - avoids RAID controller) and when they rebooted serwer node id was lost.

[Mik]

That’s exactly the plan. The 95% uptime rule will be implemented when people can know in real time their 3node total uptime of the month.

[Mik]

That’s a bummer for the node ID. Thankfully if they reboot this month, it’s still the same token entry price. There’s a Q+A on how to backup 3node ID in the FAQ if you want.

[isyal]

Sure i will do this asap

[sabrinasadik]

The CRU was incorrectly weighted in the CU calculation causing some nodes to be credited for less CU than they should have.

[BruceL]

Why is the question of the poll not clearly stated with the poll? Are we agreeing or disagreeing with all of the forum post? If this is the case, I vote to disagree because the questions are not clearly stated, nor is there even a statement as to what specifically one is voting on.

[FLnelson]

I think it is to adapt all the proposals.

[isyal]

But what with issue i have (8 nodes i know by myself) - bad disks detected HDD instead of SSD.

[scott]

We’ll be compensating farmers affected by the capacity reporting issue (SSD recognized as HDD) on a case by case basis, rather than correcting it through the minting mechanism itself. These are actually separate concerns, one is about how Zos is reporting node resources, whereas the thread here is about minting logic and uptime requirements. That said, we’ll need to wait for the additional payments mentioned here to settle so we know the actual baseline amount from which to calculate compensation in cases like yours.

If you haven’t already, please reach out to support or DM me on Telegram (@scottyeager) so we can track your case and get you paid.

[isyal]

About ideas for farmers, i have 2 thoughts. That won’t affect rules orsomething but would be great for farmers itself. At portal.grid.tf/farms we have (at “your nodes”) : farm id, node id, city, region, etc. Would be wonderful if we could see there 2 more things, First: “downtime left to current period” and the second “% capacity left to unlock” (or % of utilization). The first one will show us how much time we can be offline (power failure, matiance etc) and the second would tell us how much capacity is taken in ours node.