LeeSmet
commented
2 years ago Technically we can make a change reflect instantly without problem (would make the code a bit more cumbersome but that is not an issue in itself). In fact I thought about this even before the implementation. The actual problem is in the tokenomics. Specifically these 2 things come to mind:
- CU is defined as
MIN(cru * 4 / 2, (mru - 1) / 4), sru / 50), meaning a CU is essentially a combination of multiple (3) individual resources. Now, if a node upgrades and gets more CU as a result, the additional CU might be a combination of 1 resources connected at a different price than another resource. Hence the connection price of the CU is technically undefined. Example:- Initial config 8 cores, 32GB mem, 1000GB SSD (connected at 0.08USD). CU is MIN(16, 7.75, 20) = 7.75
- Additional stick of 32GB mem gets installed (at 0.10USD). CU is now MIN(16, 15.75, 20) = 15.75, an increase of 8 CU
- The 8 CU are a result of: 4 cores and 400 GB SSD connected at 0.08 USD, and 32GB mem connected at 0.10USD. The connection price of the CU is therefore not defined under the current tokenomics.
- Even ignoring the above issue, we can't identify which capacity is which. This is not a problem when capacity increases, as we could create "brackets" of capacity in a node with different prices, but becomes an issue when capacity is removed (e.g. HDD failure). Let's say you have a node with a 16TB HDD connected at 0.08USD. After some time you connect a new 16TB HDD at 0.10 USD. Since SU is a linear combination of sru and hru, we could calculate how much SU is connected at 0.08 USD and how much at 0.10 USD (13.33... at each price point as a result of these HDDs). But if further down the line one of these HDD's breaks, we don't know which one that is. So from which price point do we deduct capacity? If we deduct from the first bracket the farmer might receive insufficient tokens (e.g. if he simply disconnected the most recently added drive). On the other hand, if we deduct from the last bracket (highest price) we might be overpaying. For example, the original drive might have died, resulting in the new drive now being considered to be connected at the original price, therefore too much tokens are paid as this new drive incorrectly is considered to be connected at the lower price point.
It should be noted that the current implementation pays for the minimum amount of capacity during the period. This is imo a sane default, due to the uptime SLA, set at 95% to get tokens in the first place. If a farmer loses capacity at some point, than the "additional" capacity on top of the minimum would likely not get the SLA, so it shouldn't be paid regardless. Hence a reduction in capacity is immediately visible.
All in all, as said, and hopefully as explained above, the current issues regarding this stem from a lack of rules regarding these cases in the tokenomics.
Some farmers change their HW specs (adding RAM or SSD) during the minting period. This only affects their minting payout for the next minting period. Is there way to change this in the calculations during the minting period in which they made these changes?