Minting calculations have low precision

[scottyeager]

I noticed that the results produced by the minting code, as reflected in the receipts accessed through the receipts API, didn't match an independent calculation of the expected rewards based on the capacity figures. The differences I noticed are small enough that this isn't an urgent issue, but large enough that I think it warrants further investigation.

It's possible to demonstrate the issue with nothing more than the data from the receipts API. Here's a script that recomputes the TFT amount minted for a node based on the CU, SU, and uptime values in the receipt. It then prints the newly computed value along with the original TFT minted value from the receipt.

The following limitations are intentional:

• Works for DIY only
• NU calculation isn't implemented

import sys
import requests

REWARD_PER_CU = 2.4
REWARD_PER_SU = 1.0

TFT_SCALE = 1e7
TFT_ENTRY_PRICE = 0.08

STANDARD_PERIOD_DURATION = 2630880

rhash = sys.argv[1]

url_base = "https://alpha.minting.tfchain.grid.tf/api/v1/receipt/"
receipt = requests.get(url_base + rhash).json()["Minting"]

cu_reward = receipt["cloud_units"]["cu"] * REWARD_PER_CU
su_reward = receipt["cloud_units"]["su"] * REWARD_PER_SU
period_duration = STANDARD_PERIOD_DURATION
total_reward_tft = (cu_reward + su_reward) / TFT_ENTRY_PRICE
scaled_reward_tft = total_reward_tft * (receipt["measured_uptime"] / period_duration)
receipt_reward = receipt["reward"]["tft"] / TFT_SCALE

print("Calculated reward is:", scaled_reward_tft, "Receipt reward is:", receipt_reward)

We can run this script with some different receipt hashes to see what happens.

Here's an example that looks good. We expect a bit of precision loss due to minting using integer division, and this seems within acceptable ranges.

$ python check_receipt.py 4f7cc79e1aae9882fbfff3f539768710f429d35c0822b627f1eb3811e6727bdb
Calculated reward is: 3064.51192 Receipt reward is: 3064.5

Here's another example that's more problematic.

$ python check_receipt.py 0fe007734e7094d746e6c0be1bbbc9ea7104b8ddd3db071f5337f4caaf32461c
Calculated reward is: 3063.301175757617 Receipt reward is: 3061.410525

While a difference of 2 TFT is not catastrophic, this looks a lot less like a rounding error.

What's especially weird is that these nodes are basically identical, differing basically only by their uptime.

https://alpha.minting.tfchain.grid.tf/api/v1/receipt/0fe007734e7094d746e6c0be1bbbc9ea7104b8ddd3db071f5337f4caaf32461c

    "measured_uptime": 2629869,
    "tft_connection_price": 80,
    "cloud_units": {
      "cu": 94.200415,
      "su": 19.077308,
      "nu": 0
    },
    "reward": {
      "musd": 244912,
      "tft": 30614105250
    },

https://alpha.minting.tfchain.grid.tf/api/v1/receipt/4f7cc79e1aae9882fbfff3f539768710f429d35c0822b627f1eb3811e6727bdb

    "measured_uptime": 2630880,
    "tft_connection_price": 80,
    "cloud_units": {
      "cu": 94.201519,
      "su": 19.077308,
      "nu": 0
    },
    "reward": {
      "musd": 245160,
      "tft": 30645000000
    },

The difference in CUs is negligible. The difference in rewards for these nodes should therefore be determined by their uptime only. We can also notice that the second receipt has uptime equal to the standard period duration and therefore is precisely 100%.

So this should hold:

reward1 = reward2 * (uptime1 / uptime2)

However:

reward2 * (uptime1 / uptime2)
30645000000 * (2629869 / 2630880)
30633223676.10837

30614105250 = reward1

I don't understand why I can't reproduce the minting calculations based on the values in the receipts, and why the rewards of two nodes with practically identical specs don't seem to scale linearly with their uptimes.

[LeeSmet]

I'll take a look when I have some time, however this looks like an issue as a result of working with floats. This is avoided as much as possible in the minting code, but values are converted to float to put them into the receipt (CU, SU). It seems likely that during the conversions some precision is lost (not all numbers are representable by floats, for instance), which leads to slightly different values being calculated from the minting receipts alone. For this reason, the actual tokens to pay are expressed in the smallest possible unit as a uint instead of a float, so the value there is exact.

[scottyeager]

@LeeSmet, I did consider rounding errors from float conversions, but this seemed too large to be totally explained by that.

With a bit more digging, I traced it to here:

https://github.com/threefoldtech/minting_v3/blob/b5c074adc63915a1b051d76969fba3f40c7ae6f3/minting/src/main.rs#L2185-L2186

The use of 1_000 scale actually means that this gives precision to 0.1%. For instance, 99.94% becomes 999. That's why a node with base reward of 3064.5 steps down to 3064.5 * .999 = ~3061.4.

This is fine for checking the uptime SLAs, which are also expressed with 1000 possible values, but for scaling the payouts this seems needlessly coarse.

[scottyeager]

@sameh-farouk, might you be able to look into this and give your opinion?